Common Minor Troubleshooting Items
This is a small list of minor issues or questions that do not generally need a dedicated troubleshooting page, but have still been prevalent enough in the community that keeping the knowledge available is worthwhile.
This is most commonly caused by not reading the initial configuration instructions. ARES does not come pre-authorized for you to be an owner of yourself, and must run the initial configuration items contained in the autoexec.as notecard that came packaged with your controller in order to prepare you for setup. Follow the instructions from the Getting Started notecard that came with your controller (also available here) and then attempt to run @setup or whatever commands you were attempting again.
This issue started manifesting some time after ARES 0.5.3 was released and seems to possibly be related to scripts not being woken/slept when they should have been, and may be influenced by many factors (including sim lag, connection quality, phase of the moon, etc.) The current "fixes" for this tend to be:
If you have no owners, simply do @security audit. If you have an owner, you will need to ask for your access to be granted back to you.
If you have listed owners, but they are no longer present or you wish to no longer have them, you can use the @runaway command to purge your user list and restore your self-ownership.
The most common reason for this is a lack of available attachment points. ARES updaters and software installers will need at least one free attachment point to attach themselves to your HUD, and it is recommended to have at least 2-3 attachment points free when installing software or running an update just in case the installer needs to attach any additional items as part of their operation.
This is usually fixable by the following:
If this fails, detach and reattach your ARES HUD.
This happens if one of your input pipes ends up with a clog, when you add something new to the pipe stream, it pushes off the oldest item in there, which may be one or more attempts previous. To clear these pipes, do @input purge and then attempt speaking or running a command again.
This is usually because ARES comes pre-set with the default chat tones for the default genders. This can be rectified in one of two ways:
If you want to say a single message that does not play a chat tone, include the string #@! in your message and it will suppress your chat tone for that message only.
If you want to disable your chat tone entirely, run the command @db set hardware.controller.volume.marker 0 and then do a @device probe to refresh the controller's settings. Your chat tone will then be muted entirely. You can re-enable this by re-running the command with a 1 in place of the 0.
If attempting to sit on a charger results in you getting booted off the charger with a "Charger already connected" (or similar) message, this is usually caused by utilizing an old charger that has not been updated to properly disconnect from ARES. Run the command @baseband restart to restart the system that controls/recognizes chargers and you should regain the ability to utilize chargers.
Note: It might also be a good idea to recommend to whomever has the old charger placed that they upgrade their charger to a current/modern version to avoid affecting units in the future as well.
This can either be rogue attachments or an issue with the baseband service getting stuck somewhere. Try removing any third-party attachments to make sure none of them are generating unwanted load, and if this doesn't resolve the issue, attempt @baseband restart
To disable wireless charging: @db set chassis.induction.remote 0 followed by @baseband restart
To re-enable wireless charging: @db set chassis.induction.remote 1 followed by @baseband restart
There is one additional possibility that may cause this. If you have an iKitten avatar setup, and have run the iKitten autoexec.as file to badge your HUD for it, you likely have a block in your persona settings that prevents you from changing your chat tone away from the iKitten's characteristic "sproing" chat tone. This can be fixed by doing @db set persona.block [], setting another chat tone, and then reloading the default persona.
Typically this issue is just a device detection order issue. Do @device probe and, provided you are wearing your battery on the Spine attachment point and your controller on the Chest attachment point, these should auto-align.
If this is persistent even through device probes, or you have a body shape that is not a typically-sized humanoid female avatar, you may need to adjust your battery's positioning. See the steps on the battery alignment information page regarding battery positioning for tips on how you can reposition your battery.
Caveat: For users of the CX/Supervisor controller, there is a known issue with certain body shapes that causes the battery to be "correctly aligned" and yet slightly angled in respect to the battery socket on the controller. You can attempt to adjust the controller's position a bit vertically up or down your spine and then do the probe command above to see if it will line up.
This can manifest as being unable to sit on things, unable to touch things, unable to see/speak/move, etc. If you are not being specifically restricted by an owner, the most likely reason is that a subsystem got disabled somehow. (The most common culprit is loading the backup persona, which is supposed to be a minimal-power backup personality for RP purposes.)
To resolve this, do @power all off to turn off all subsystems, then @power all on to re-enable all subsystems.
If this doesn't resolve the issue, it's possible there's a stuck RLV restriction on your system from somewhere. Make sure you're wearing NO other RLV control gear (collars, restriction rigs, blindfolds, etc.) and do @service effector restart to restart ARES' RLV restriction manager. (Note that this will clear your chat capture, you will need to use /1capture to recapture your chat afterwards!)
This can stem from a number of issues. The most common ways to troubleshoot this are:
This can be an unfortunate result of plugging incorrect numbers into the screen calibration section of @setup, or through accidentally misconfiguring the settings in the database. To reset this, do @db set interface.height 1008, then @db set interface.width 1920, then @service interface restart. This should set the HUD's setting approximately back to defaults, and you can use @setup to attempt to resize it again.
This seems to be most easily fixed by doing @db set nav.follow.target, followed by @reset nav and then detaching and reattaching the collar.
(Note: This means that if your locking bolts are enabled, you will need to disable them temporarily to fix this issue with @policy bolts off. Once you confirm the issue is resolved, you can re-enable your locking bolts.
Sometimes ARES loses track of your local inventory, simply do @service storage restart and try again.
This is caused by ARES overheating briefly, commonly due to a minor bit of lag during a teleport, and the overheat warning alarm getting "stuck" playing.
Try running this command to stop the alarm: @media -i -n 7 stop (Note: This requires ARES 0.4.2+. If you're still running an earlier version, skip this and either go upgrade or follow the step below.)
If this fails, come to the Helpdesk in Eisa and touch the box on the floor next to the Helpdesk, which will attempt to induce another minor overheat to get the alarm to recognize it should cease once you cool back down. (This may take a few attempts.)
Setup or security issues
I'm trying to do @setup or run a command but keep getting a "Forbidden" error
This is most commonly caused by not reading the initial configuration instructions. ARES does not come pre-authorized for you to be an owner of yourself, and must run the initial configuration items contained in the autoexec.as notecard that came packaged with your controller in order to prepare you for setup. Follow the instructions from the Getting Started notecard that came with your controller (also available here) and then attempt to run @setup or whatever commands you were attempting again.
Setup or the autoexec notecard has hung!
This issue started manifesting some time after ARES 0.5.3 was released and seems to possibly be related to scripts not being woken/slept when they should have been, and may be influenced by many factors (including sim lag, connection quality, phase of the moon, etc.) The current "fixes" for this tend to be:
- Restart your kernel via =ddt reset and try again
- Detach/reattach your HUD and try again
- Try moving to a less-busy or less-script-heavy sim and try again
- If all else fails, try logging out and logging back in again, or trying again in an hour or two.
I accidentally banned myself...
If you have no owners, simply do @security audit. If you have an owner, you will need to ask for your access to be granted back to you.
If you have listed owners, but they are no longer present or you wish to no longer have them, you can use the @runaway command to purge your user list and restore your self-ownership.
I get "Could not attach; unknown error." when attempting to run an ARES update or software install.
The most common reason for this is a lack of available attachment points. ARES updaters and software installers will need at least one free attachment point to attach themselves to your HUD, and it is recommended to have at least 2-3 attachment points free when installing software or running an update just in case the installer needs to attach any additional items as part of their operation.
Chat-Related
My chat won't capture!
This is usually fixable by the following:
- Do /7770 !release
- Do /1capture
If this fails, detach and reattach your ARES HUD.
My chat is coming out backlogged
This happens if one of your input pipes ends up with a clog, when you add something new to the pipe stream, it pushes off the oldest item in there, which may be one or more attempts previous. To clear these pipes, do @input purge and then attempt speaking or running a command again.
I set a custom chat tone but I'm still playing the default
This is usually because ARES comes pre-set with the default chat tones for the default genders. This can be rectified in one of two ways:
- Load the default persona, and then attempt to set your chat tone again
- Run the command @persona set marker $marker-neuter $marker-female $marker-male and then attempt to set your chat tone again.
I want to chat but not have a chat tone play.
If you want to say a single message that does not play a chat tone, include the string #@! in your message and it will suppress your chat tone for that message only.
If you want to disable your chat tone entirely, run the command @db set hardware.controller.volume.marker 0 and then do a @device probe to refresh the controller's settings. Your chat tone will then be muted entirely. You can re-enable this by re-running the command with a 1 in place of the 0.
Power/Battery Related Issues
"Already connected to charger" error OR Issues receiving a charge.
If attempting to sit on a charger results in you getting booted off the charger with a "Charger already connected" (or similar) message, this is usually caused by utilizing an old charger that has not been updated to properly disconnect from ARES. Run the command @baseband restart to restart the system that controls/recognizes chargers and you should regain the ability to utilize chargers.
Note: It might also be a good idea to recommend to whomever has the old charger placed that they upgrade their charger to a current/modern version to avoid affecting units in the future as well.
My power draw is WAY too high
This can either be rogue attachments or an issue with the baseband service getting stuck somewhere. Try removing any third-party attachments to make sure none of them are generating unwanted load, and if this doesn't resolve the issue, attempt @baseband restart
How do I disable or enable wireless charging
To disable wireless charging: @db set chassis.induction.remote 0 followed by @baseband restart
To re-enable wireless charging: @db set chassis.induction.remote 1 followed by @baseband restart
There is one additional possibility that may cause this. If you have an iKitten avatar setup, and have run the iKitten autoexec.as file to badge your HUD for it, you likely have a block in your persona settings that prevents you from changing your chat tone away from the iKitten's characteristic "sproing" chat tone. This can be fixed by doing @db set persona.block [], setting another chat tone, and then reloading the default persona.
My battery is off-center
Typically this issue is just a device detection order issue. Do @device probe and, provided you are wearing your battery on the Spine attachment point and your controller on the Chest attachment point, these should auto-align.
If this is persistent even through device probes, or you have a body shape that is not a typically-sized humanoid female avatar, you may need to adjust your battery's positioning. See the steps on the battery alignment information page regarding battery positioning for tips on how you can reposition your battery.
Caveat: For users of the CX/Supervisor controller, there is a known issue with certain body shapes that causes the battery to be "correctly aligned" and yet slightly angled in respect to the battery socket on the controller. You can attempt to adjust the controller's position a bit vertically up or down your spine and then do the probe command above to see if it will line up.
General Issues
I'm unable to do random things
This can manifest as being unable to sit on things, unable to touch things, unable to see/speak/move, etc. If you are not being specifically restricted by an owner, the most likely reason is that a subsystem got disabled somehow. (The most common culprit is loading the backup persona, which is supposed to be a minimal-power backup personality for RP purposes.)
To resolve this, do @power all off to turn off all subsystems, then @power all on to re-enable all subsystems.
If this doesn't resolve the issue, it's possible there's a stuck RLV restriction on your system from somewhere. Make sure you're wearing NO other RLV control gear (collars, restriction rigs, blindfolds, etc.) and do @service effector restart to restart ARES' RLV restriction manager. (Note that this will clear your chat capture, you will need to use /1capture to recapture your chat afterwards!)
HUD is unresponsive
This can stem from a number of issues. The most common ways to troubleshoot this are:
- Try cycling the HUD subsystem: @power hud off followed by @power hud on
- Restart the variatype service: @service variatype restart
- If using a viewer that supports it, try Refreshing Attachments
- If all else fails, detach and reattach your ARES HUD
I resized my HUD off the screen
This can be an unfortunate result of plugging incorrect numbers into the screen calibration section of @setup, or through accidentally misconfiguring the settings in the database. To reset this, do @db set interface.height 1008, then @db set interface.width 1920, then @service interface restart. This should set the HUD's setting approximately back to defaults, and you can use @setup to attempt to resize it again.
My Devotion/NS collar leash is stuck!
This seems to be most easily fixed by doing @db set nav.follow.target, followed by @reset nav and then detaching and reattaching the collar.
(Note: This means that if your locking bolts are enabled, you will need to disable them temporarily to fix this issue with @policy bolts off. Once you confirm the issue is resolved, you can re-enable your locking bolts.
A file/persona/package is claimed to be "Not Found" yet the item is there in local
Sometimes ARES loses track of your local inventory, simply do @service storage restart and try again.
I'm constantly beeping
This is caused by ARES overheating briefly, commonly due to a minor bit of lag during a teleport, and the overheat warning alarm getting "stuck" playing.
Try running this command to stop the alarm: @media -i -n 7 stop (Note: This requires ARES 0.4.2+. If you're still running an earlier version, skip this and either go upgrade or follow the step below.)
If this fails, come to the Helpdesk in Eisa and touch the box on the floor next to the Helpdesk, which will attempt to induce another minor overheat to get the alarm to recognize it should cease once you cool back down. (This may take a few attempts.)