Chastity & Control System (CCS) API Developer Documentation

Modified on Sun, 16 Aug 2020 at 03:28 PM


Introduction

The letters CCS stand for Chastity & Control System, which is the name of a new API for all version 5.0 PsiCorp bits. This API allows for remote control of the bits and bits HUD, and is intended to work as a supplement to other things like RLV, OpenCollar and similar BDSM implements. The main idea is to allow owners to control their subs’ genitals, or for objects to interface with them and modify them. There is no licensing or fees. You can make it, sell it, give it away or do whatever!

Possible applications can be collar plugins, cock cages, game extensions - such as a Tentacles in Space plugin to control arousal state, object interfaces - for example bdsm or tentacle play sets, as well as impregnation play such as forced impregnation or oviposition by means of scripted objects. Many other applications are possible, since the API is openly documented and free to interface with.


Communication

All communication in the CCS API runs on channel -555, and generally is using llRegionSayTo() to communicate with specific bits and/or to facilitate targeted status return messages.

The basic concept is that a CCS device may register itself with compatible objects and then may assume control over certain functions. System commands such as bit modding or changing settings are not available to the CCS API to prevent griefing by intentionally mis-configuring worn bits.

Furthermore, the API may be set to one of four modes by the wearer, which changes the behavior of them when presented with a registration request. These modes are as follows:

  • Mode 0 - Off: No CCS functions are available, all registration requests and other commands will be ignored

  • Mode 1 - Land Owner: All CCS registration requests made by objects either belonging to the object owner or belonging to the owner (or being set to owner parcel owner group) of the parcel the target avatar is in will be granted, all others will be refused

  • Mode 2 - Ask: All CCS registration requests will prompt a yes/no dialog for the object wearer

  • Mode 3 - Open: All CCS registration requests will be granted.

Up to five CCS devices may be registered at any one point with any given CCS enabled object. If this list is full, a negative response will be sent upon attempting to register. Any CCS device will clear its whitelist upon detach to avoid stray whitelisted objects, so registrations will not persist indefinitely.


General commands

ccsregister

This command registers the given device with whichever script it is sent to, i.e. a bits HUD or bit. Depending on the wearer’s CCS settings, a reply will happen either automatically or once the user gave consent to registration. A successful registration will transmit “success” directly back to the device, otherwise “failed” will be transmitted. It is recommended to add a 30 second or similar timeout to this check to allow for owners not answering a CCS permission dialog in time.

Furthermore it is reccommended to use llRegionSayTo() and target the desired avatar, rather than relying on whispers and other non-targeted chat input.


ccslock, (rlv) / ccsunlock, (rlv)

Both commands can lock/unlock the device they are sent to, taking away control from the wearer. Sending such a command to a cock will prevent the wearer from controlling it at all, sending it to a HUD will prohibit the wearer from accessing the options menu. Adding the “rlv” parameter to it will cause RLV to make the target bit non-detachable. Calling ccsunlock will revoke the restrictions.


ccsclear,  <device UUID>, (rlv)

This command will remove the device from the list of authorized devices. If the device was the last registered device, any restrictions such as chastity mode or attachment restrictions will automatically be lifted. The format has to be a CSV with the device’s key in second place, due to SL restrictions. the “rlv” command is optional


ccsscan, <avatar UUID>

This command will trigger a return response from any CCS enabled devices worn by the target avatar, regardless of CCS level. The return is a list, led by “ccsscan” and followed by object type (hud, penis, etc), wearer UUID, and the current CCS level as integer. This can be used to get general information, such as whether the wearer’s CCS level is set to the desired one, or whether specific bits are being worn.


ccsadd, <device UUID>

Allows a registered device to add another one to the object, essentially allowing relay behaviour for things such as collar plugins.


Penis / Vagina specific commands

ccsstatelock / ccsstateunlock

Will lock the target bit in its current selected state. Using ccsstateunlock will revert this. This also prohibits other CCS devices from changing the active state of the bit. This may be useful for chastity cages for example where you want the bit to be locked in a certain position.


Breasts specific commands

ccsoutfitlock / ccsoutfitunlock

Will lock the target breasts on the current choice of outfit, and prevents other CCS devices from modifying said outfit choice


Pregnancy HUD specific commands

ccscuminside

This command triggers a standard “cum inside” event in the pregnancy HUD, and only has effect if the target person is wearing such a HUD and is able to become pregnant. The command can be used standalone for a default event, but it is recommended to use it as a CSV with the following parameters:

  • UUID of the donor avatar, aka the male performing the climax. Allows NULL_KEY for unknown/anonymous partners

  • Species of the donor avatar as string

  • Gender of the donor as string

  • Virility value as integer, suggested values are anywhere between 0 and 100

  • Knot flag as integer, true/false, determines whether donor has a knot

  • Flare flag as integer, determines whether donor has flare

  • Barbs flag as integer, determines whether donor has barbs

  • Condom flag as integer, whether or not a condom was being worn during the climax


ccsimpregnate

Almost the same as ccscuminside, except it bypasses the standard delay before the pregnancy is determined, instead forcing a calculation to occur immediately. The format matches ccscuminside, although for forced impregnation play, a virility value of 200 or more is recommended to ensure impregnation.


ccsoviposition

Used for egg insertion play. The special thing about this command is that it will succeed regardless of whether the wearer is able to become pregnant, so will also work on males and other infertile genders, as well as those who are already pregnant. It will not override any children the target is bearing. The command can be transmitted alone for a default event, or with a CSV with the following parameters:

  • UUID of the donor avatar, aka the male performing the climax. Allows NULL_KEY for unknown/anonymous partners

  • Species of the donor avatar as string

  • Amount of eggs deposited as integer - it is suggested to randomize this on the device end

  • Incubation time in seconds as integer - this determines how long until the eggs are born / laid and runs separately from any other pregnancy/egg insertion currently ongoing


ccspregstatus

Will query anyone in chat range to respond with their pregnancy status. No reply will be sent if a target wearer has privacy mode enabled. Otherwise the HUD will respond directly to the device that made the query, in the form of a CSV led by “ccspregstatus” and followed by their species, gender name, ability to become pregnant as boolean, pregnancy status as boolean, fertility status as boolean, forced partner accept status as boolean and auto partner accept as boolean.

The pregnancy HUD utilizes this in the “Check Area” command to gain information about who in the surroundings may be in heat and/or interested in play.


ccssetforced, true / ccsssetforced, false

This command controls the “forced acceptance” status. If enabled, the wearer of the HUD will have to automatically accept any sexual partner requests made by other people, allowing them to climax inside them and/or perform oviposition etc. This can be utilized for forced play and other bondage devices, for example a set of stockades in a club etc.


ccschastity, true / ccschastity, false

Controls the chastity mode setting. In chastity mode, the wearer of the HUD can not climax inside people or otherwise interact with them, nor can they be climaxed inside, impregnated, or receive oviposition. This may be used in conjunction with the state lock command and other ccs commands to simulate a full chastity belt experience.


ccsspermsample

Can be used to obtain a sperm sample from any able participant. Expected return message will be ccscuminside followed by the standard data set, so reference this entry for the format. If the participant is not able to produce sperm / has no cock / etc, then a default data list will be transmitted instead, led by a NULL_KEY after the cum inside command and with gender and species set to unknown, as well as zero virility. So by checking for the NULL_KEY in the response, you can determine whether the participant was able to donate any sperm, physically.

It is recommended to use the preg status command to determine gender of target participant first though, generally.

This event also does not generate a notification for the user, so transmit your own once you receive the response message.


ccsforceclimax / ccsforcefemaleclimax / ccsforcemaleclimax

These three functions can force the receipient to climax. Male and general climax take an optional target UUID separated by comma, if no UUID is specified, a “cum inside” event is sent back to sender for general and male climax functions, otherwise sent to specified UUID.

Male climax will trigger cum inside, female climax will trigger a female climax event if receipient is able to peform it. ccsforceclimax will trigger both mechanisms and can be used to - for example - give a herm both a male and female climax.

Unlike ccsspermsample, this event will notify the receipient that they have been forced to climax.


ccsaddchild

Allows for surrogate mothership by adding a child to a person who is able to become pregnant. Unlike oviposition, this function can not override the status of a non-fertile person, aka someone who is unable to become pregnant at all will not respond to this call.

The call needs to be transmitted as a CSV including all of the following in this order:

  • The tag “CHILD” in all caps as string

  • The child’s gender as string

  • The child’s species as string

  • A live birth flag, TRUE/FALSE as integer, determining live birth if true, egg birth if false (for reptiles and other non-mammals)

  • llGetUnixTime() + Incubation time as integer in seconds, to set the time/date of the birth

  • Incubation time as integer in seconds, describing the time from the current moment until the child will be born

  • Incubation time as integer divided by ten (typical), describing the time until a pregnancy test will be showing a result. It is possible to set this to 0 for surrogate mothers since it will be known ahead of time that the target is receiving a child

  • Father name as string. Should be either a name, or "none" for an anonymous father


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article