Here is a set of re-occurring questions for the Corrade bot.
Yes. Corrade is software. You will need some form of hosting, whether it is your computer or rented space. Roughly, instead of wasting money on rented space, we recommend you look into
SBCs such as the raspberrypi which are computers the size of a TV remote. You can hook up the RaspberryPi to your network, leave it on, and run a bunch of Corrades on it unattended, rather than leaving your PC on all the time.
Corrade just exposes all viewer functionality such that it is accessible to LSL. You can certainly use Corrade for land rentals. In fact, Corrade is currently being used for some "games" in Second Life, such as virtual fishing and hunt games. Given Corrade's feature set, you can be quite creative using the
API provided by Corrade.
Some ready-made scripts are provided (called templates) that vary from notes to fully functional scripts. These are meant as examples for scripters but they mostly can be seen as individual ready-to-run projects.
Yes. Corrade is entirely free and licensed under a custom license.
Corrde will always be free!
Maybe. Corrade does not collect any data on its users for monetization purposes. However, if you wish to contribute, there are many ways to do so - ranging from advertisement and up to writing and sharing your scripts with the rest of the user-base.
No. The closest approximation for Corrade would be "freeware".
However, all the starting templates provided and any scripts written for scripters are OpenSource. Furthermore, all scripts written by Wizardry and Steamworks intended for Corrade can be used under a relaxed license. For more details please check the Corrade license. You are also free to monetize Corrade services, bundle Corrade as part of a larger project or use Corrade as you see fit provided you give attribution for Corrade to Wizardry and Steamworks.
Corrade runs natively on Windows and Unix-like platforms. The latter include Linux distributions and several kinds of hardware platforms (x86, ARM etc…).
The first thing to do is download Corrade and configure it to log-in to Second Life. The quick set-up guide should help you to achieve that. After your bot is in-world, you can use the provided example scripts to get the hang of how LSL interacts with Corrade. Provided is also the command tutorial that gives several examples of what you can do with Corrade.
Corrade manages access control per group rather than per avatar. In other words, once you specify that some group, with some password is able to trigger commands on Corrade in the configuration file, then Corrade will allow any scripts that authenticate with the same password to manipulate a group. Corrade does not care to whom the LSL script belongs to. You can, for example, create an inviter script in Second Life, set the appropriate permissions, and then sell the script as a black box, thus allowing buyers to manipulate a group without knowing the authentication details nor seeing the script.
Groups in Second Life are the lowest common denominator for permissions. Whilst grid Gods are usually able to issue grid-related operations, estate managers have a limited list of estate settings, avatars do not have any permissions to anything other than their own assets. Most actions in Second Life, even sharing land with someone, streaming music through a device, allowing avatars to rez objects from inventory and even very trivial operations such as creating a landmark are restricted by group-managed land. Most avatar operations, except from moving around or teleporting (n.b. teleporting is also restricted by teleport routing, that, in turn is restricted by land permissions, that, in turn, is restricted by some group permission) are sooner or later restricted by land which, in turn, is restricted by some group's ACL.
In order to ensure that commands are executed successfully, all commands have to query the grid for permission - this is because in the absence of a graphical display, trial and error (as it is with most viewers) will not be able to report back on whether a command executed successfully or not. Most of the checks performed by Corrade, in the end, end up querying group permissions.
It would be redundant to have Corrade restart itself because there are tools out there that are able to sense a lot of operating system conditions such as network status, CPU load, traffic and so on, and then restart a daemon based on those conditions.
No daemon restarts itself - examples include web-servers, mail servers and so on that, once crashed, will remain crashed until the operating system or the user restarts them. Even on Windows, services are usually run via a wrapper that restarts the service in case it has crashed.
It is important to use a restarter, because your system may go down or the grid that Corrade is connected to may become unresponsive. By running Corrade as daemon, you will be able to set it in the background and the operating system will make sure to restart Corrade.
The usual error returned when the password has not been accepted by Corrade is:
login failed : key
You may have forgotten to prepend
$1$ to the password hash that you generated. This is what an
MD5 password hash looks like:
$1$ at the beginning marks the hash as an MD5 hash whilst the rest (
59bcc3ad6775562f845953cf01624225) is the actual
MD5 hash that you may have obtained when hashing your password.
If you are on an Unix system you can generate an unsalted MD5 password hash locally after which you have to prepend
$1$ to the result. Otherwise, you can use a good client-side online MD5 unsalted password hasher.
If the password is hashed correctly, note that Second Life seems to discard passwords longer than 16 characters and will return the same error
login failed : key. If your password is indeed longer than 16 character, you can try a shorter password instead.
In certain circumstances, you may get the error:
login failed : presence
on start-up. This means that Corrade attempted to connect to an account to which a client (viewer, or bot) was already connected to.
The error may happen if you kill Corrade very fast (for example, on Linux, by using the
SIGKILL) such that Corrade does not first disconnect from Second Life properly before Corrade is started again. In such situations, it will issue the error above and then connect again.
Note that if you do this many times, you may see the error:
login failed : ban
which, aside from the obvious, means that the account has been temporarily throttled. Usually, you can wait a few minutes before starting Corrade again and the error will ago away on its own.
Other than group operations, Corrade follows the current Linden protocols and is always tested in Second Life. When running Corrade on OpenSim and encountering a situation where Corrade does not work, it is a good idea to check whether the same situation works in SecondLife. If a Corrade feature works in Second Life but does not work on OpenSim then it is an OpenSim bug.
From our perspective, OpenSim has been around for a very long time, the developers have in some cases deliberately, other cases non-deliberately chosen to stray away from the Linden specification resulting in protocol incompatibilities, some more serious than others, that would at this time require to fork Corrade into distinct SecondLife and OpenSim scripted agents. Unfortunately, given our constraints and design goals, we choose to only implement the official specification such that Corrade will only be verified against SecondLife. Corrade does already implement a few workarounds for OpenSim-based grids but no serious effort will be expended to make Corrade fully compatible with OpenSim.
This happens for SLURLs like
secondlife://Some%20Simulator/32/13/34 when Corrade transforms
%20 into space such that the buggy official viewer does not recognise it as a link anymore.
Send the link as:
secondlife://Some%2520Simulator/32/13/34 and it will work (
%2520 translates to
For an XML entity, some characters are special and must be replaced with their escaped counterparts. Here is a table of characters and what they must be replaced by:
So, for example, for a group named
Wizardry & Steamworks, the group name must be entered in the Corrade configuration file as:
Wizardry & Steamworks
Instead of passing the group name to the
group parameter, pass the group UUID. The reason of the error message is that Corrade cannot find the group due to the group being hidden and thereby not listed in the directory services.
You can do that directly with the
invite command and by specifying a
role (either by name or UUID). You will need:
grouppermission in Corrade's configuration file for the group you wish to invite to.
If you want to be on the safe side, the following role settings that Corrade is part of in your group should be exhaustive:
Membership→Invite People to this Group
Roles→Assign Members to Any Role
Roles→Assign Members to Assigner's Roles
After that, you can send the command as:
llInstantMessage(CORRADE, wasKeyValueEncode( [ "command", "invite", "group", GROUP, "password", PASSWORD, "firstname", "Bo", "lastname", "Derreck", "role", wasURLUnescape("Shits & Giggles"), "callback", wasURLUnescape(URL) ] ) );
Remember to always use a callback to check the result of sending the command to Corrade - Corrade goes out of its way to extensively provide you with error messages that will help elucidate the situation in case a command fails to work as expected.
Second Life uses both UDP and TCP - more recently, a lot of services have been moved through CAPS. It seems that some proxies interfere with CAPS and that Corrade is unable to retrieve the result. For example, trying to access SL through Tor is a funny experience.
Here is a list of common symptoms when you have an upstream proxy that does not play well with SL:
all these symptoms indicate that you are pushing Corrade's packets through an upstream proxy. If you have a complex set-up, first try to disable all proxies - you know what to do. Since Corrade acts as a console application, on Unix systems, there usually is no proxy set for the command-line.
In order to disable all proxies, up to Windows 7, you can open
Internet Explorer→Settings→Connections (Tab)→Lan Settings… and untick all the boxes:
Under Windows 10 you can find the setting in
Network & Internet:
There are two known possibilities for Corrade to rez as a cloud:
shape; for an avatar to render in SecondLife, at least one of each body part must be worn. Viewers tend to outright prohibit the user from removing a body part without a substitute but Corrade allows it.
Second Life contains a long-standing bug that makes an agent behave arbitrarily in case an altitude is specified to the
autopilot command. In case you want to make the bot fly to a location instead of walk, consider using the
flyto command which is much more versatile.
Or both could be combined:
Due to (a) bug(s) in libopenmetaverse, when wearing certain wearables (a skirt, for example), the wearables will not show on the bot. This is a bug that has been reported several times, fixed and then reported again.
This makes the
wear commands of Corrade have inconsistent behaviour. Once these bugs have been addressed in libopenmetaverse, the commands will work as expected.
Unfortunately, this issue is present in Radegast, Metabolt and all the other viewers. We are unsure what is causing this since Corrade does not take any special action on crossing regions on vehicles. It is most likely a bug in libopenmetaverse and has been previously reported multiple times in third party viewers. We are still looking to solve this one but there is little we can do so far.
Yes, but multiple simulator connections has to be enabled in the configuration file. However, connecting to multiple simulators will increase the load on the bot. Unless region crossings are imperative, we suggest not enabling multiple simulator connections.
The Corrade version cycle consists in pushing frequent updates in response to tickets for fixes and enhancements. All Corrade software releases are incremental, in that ulterior versions are deemed better than previous releases. Furthermore, the download website will provide a changelog for both release and continuous builds such that you can check whether any included updates are of interest to you.
Aside from the servers that Corrade implements and that you configure yourself, Corrade uses the same ports to communicate with SecondLife servers as any other viewer. For more information on the requited SecondLife ports, please see the Using Second Life with a Firewall knowledgebase.
No. Corrade will reload the configuration once it senses that the configuration file has been altered; this includes committing a configuration via Nucleus.
No. Wizardry and Steamworks does not receive any private data.
The RLV API up to 2.9 is mostly supported in what concerns actions such as sitting, standing or teleporting yet due to the inherited OpenMetaverse API some outfitting behaviours will fail to work. For instance, Corrade does not currently support multiple attachments per slot such that attaching to the same slot will result in undefined behaviour and will more than likely result in the avatar being rezzed as a cloud on the next login. Similarly, the handling of clothing items such as "Skirts" does not seem to work well with Corrade such that if an outfit contains them, Corrade might not process the outfit correctly.
Furthermore, RLV was designed, as per the nomenclature, to impose restrictions on the avatar and the the RLV API is geared towards restricting or restraining an avatar for the sake of roleplay. Wizardry and Steamworks has created many items that leverage RLV features and there are many other creations out there that use RLV however all these creations pragmatically do not conform to the intended usage of RLV. It does not make sense to apply RLV to Corrade because Corrade is a scripted agent and has no self-asserted agency; ie, Corrade will not suddenly decide to take its shirt off, chat on its own on local chat or teleport around in order for RLV to be necessary and meaningful.
The Corrade API greatly supersedes the very few capabilities that RLV makes available to the user and ultimately is geared towards data and control rather than being aiming to satisfy roleplay requirements. It is planned in the foreseable for RLV support to be entirely removed from Corrade and then provided as a separate program that interfaces with Corrade since at the current time of writing Corrade provides enough functionality to implement RLV just through Corrade commands. In case you intend to control Corrade solely through RLV then Corrade might not be for you.
No. And. . .
Since some time (cca. 2019) OpenCollar has split into two branches: the old opencollar and the new opencollar at opencollar.at due to some misunderstanding between the developers, summarily JT reports:
"Before I logged back in after crashing, I did a little checking on the OC thing and OC is still open source; however, there has been a divide in the developers and now there is a fork. Most of the work over the last 6 years was done by Wendy's team and they continue to develop the "fork" while the original founders of the OC movement have kicked Wendy and crew outta the "official" OC group and have released V7, which seems was a rollback to 6.7 with some mods. Wendy et alia maintain the same line of development everyone has known as OC and all the code is available on github https://github.com/OpenCollarTeam/OpenCollar. From what I read here https://www.opencollar.at/updates.html, I'd guess the OC's up to 4.0 would be a safe bet and probably anything updated by Wendy's group N°9 Peanut would probably work...now, where did I put 3.997?" - JT
Unfortunately, Peanut N°9 makes some vital changes to the way inventory items are handled and changes the way the RLV API works which would mean two side-by-side implementations.
Corrade is developed primarily with LSL scripting in mind where the stack, heap and even program code are coalesced together in of memory. Empirically, after more than 1000 lines of written LSL, undefined behaviour starts to surface and the application is best redesigned.
Key-value pairs and comma separated values is the only minimal format that can be used that benefits from the least amount of syntactic sugar. Otherwise, if developing out of world, Corrade can be switched to a different language (JSON, for example).
One has to keep in mind that only of data may be received by an LSL script in a single HTTP request such that the more meaning that can be packed in a message the better.
|"A is C"|| || ||7 vs. 1|
|"A is a list"|| || ||9 vs. 3|
|"A is a list of p by q"|| || ||14 vs. 4|
Google protobufs is really just JSON but with garbled data - a bit like Wizardry and Steamworks likes to create very long command names for Corrade XML is heavier than both…
For each bot a separate install folder can be created and then each bot can be run as a separate instance: one bot per install folder. Corrade does not mess with operating system parameters such as the registry such that Corrade can be considered a portable application.
No. At best, some cached items might be shared amongst the various instances but overall it would not pay off for the extra complication of keeping the internals of each bot to spill over each other.
Currently there is no way for a viewer to retrieve accurate positions of avatars within a simulator. Traditionally, simulators have been scanned for avatars and primitives using region scanners such as the region scanner created by Wizardry and Steamworks. However, depending on the nature of the application, there are several variants that might achieve similar results:
Unfortunately, temporary attachments attached via the LSL command
llAttachToAvatarTemp are not supported due to the underlying mechanisms requiring attachments to have an inventory UUID and temporary attachments are not registered within the agent inventory.
An additional yet simple workaround is to use the changeappearance command to reset the outfit and get rid of the temporary attachment. This works because changing the outfit works via a different mechanism to replace all the items on the avatar regardless whether they are temporary or not.
This is a broader issue and it happens with all viewers but it does not pertain to Corrade. For details, please check the tell command page.
If you receive the error "No usable version of libssl was found" when attempting to run Corrade, please install OpenSSL version 1.x. Our build system targets current stable distributions and it might happen that you are head or behind stable.