Projects » Incontinence System

Disclaimer:

I know this is a polarizing subject, but no-one is forced to look at this if they don't want to.    

Out of respect for others - I would strongly recommend this is not used (or at least not set to announce to local) in locations that are not going to appreciate it.   I created this for use on my own grid - and its fine there, but many grids may not like this so either dont use it there - or have it only announce to you or your owner.


Overview:

This system is designed to add some "functionality" to any diaper wearers.   This is worn separately to any diaper which means it works with any you may wear - and even works without wearing any (so its more stealth).

This system was created by Claide.ai - over much trial and error and testing by myself (Glenys Bieler).

Code is totally free to use and change but no support is offerered other than the basic instructions:  Please see README for setup instructions.


Functions working:


To Add:



Any suggestions?

If you have suggestions then please feel free to drop me a notecard to Glenys Bieler on my grid (grid.sub-version.space:8002) or message me here on OpenSimWorld and I will take a look at it.  Obviously no promises and it also depends if Claude.ai can work out what to do (it is actually pretty good at this having created this whole system), but definately interested in any suggestions.


Added by: Glenys Bieler
Last Update: 18 minutes ago
Project Category: Attachments
👍 2 like

Code

File name Added By Last Updated Actions
README Glenys Bieler 2 days ago View
[Diaper] Core 1.8 Glenys Bieler 5 days ago View
[Diaper] Core v2.3 Glenys Bieler 2 days ago View
[Diaper] Core v2.5 Glenys Bieler yesterday View
[DIaper] Core v2.7 Glenys Bieler yesterday View
[Diaper] Core v2.8 Glenys Bieler 25 minutes ago View
[Diaper] Persistence 1.8 Glenys Bieler 5 days ago View
[Diaper] Persistence v2.3 Glenys Bieler 2 days ago View
[Diaper] Persistence v2.5 Glenys Bieler yesterday View
[Diaper] Persistence v2.7 Glenys Bieler yesterday View
[Diaper] Persistence v2.8 Glenys Bieler 24 minutes ago View


Comments

Version 2.8 released.

* Initial RLV integration completed.

* The wearer can add an Owner (max 6 owners in total). Once the first owner has been added - the wearer can no longer add or remove any owners - only owners can.

* The initial owner can add or remove additional owners (and remove themselves).

* The owner can lock the hud so the wearer cannot remove it (this currently does NOT relog on login - so this is work in progress)

* The owner can lock diaper changes to only owner, or owner+wearer, or leave open to all who have access

* The wearer can SAFEWORD which will remove all restrictions AND wipe the owner list.
like(1)
Version 2.7 released.

* Refactored all the menus to make it cleaner and more organised.

* Adds a new "Change Announcement" so this can be set to Owner IM so it does not display to everyone (also checks minimum region rating before announcing to everyone / local

* Minor changes to setting auto-wet to 0 (no longer goes into negative numbers but correctly displays "Disabled".

* Access mode: switch between open/lists and owner only.
like(0)
Version 2.5 released

* Added minimum region maturity so it wont do local chat if lower maturity than set.

* Fixed hypergrid reset issues (I think!).
like(0)
Version 2.3 released.

* Added ability to add/delete from whitelist or blacklist and view contents. Current access is owner (and until RLV implimented wearer counts as owner), and any third party. If a whitelist has entries (in UUID form) then anyone NOT in the whitelist is denied access (in this case blacklist is never consulted). If whitelist is empty, and blacklist has entries then all third party access is allowed UNLESS they are in the blacklist. This will change in the next version - as I will be adding an "access mode" that allows switching between the access mode above - and owner (and wearer before RLV) only.

* Added the ability to change the "State Names" (from the default Dry, Damp, Wet, Soaking, Leaking).

* Added an option to "reset to default settings" (this needs additional testing as I think sometimes this may sometimes get called - at least in part - when returning from hypergrid jumps. Some of the "status" may be reset.

* Added an option to change the command prefix from auto generated [first name initial][last name initial]diaper to anything you want, and to reset it to autto generated default by entering "auto".
like(1)
Not my cup of tea, but good on you! I have a suggestion, tho -ignore it if you've already implemented it. If there's a way to do so programmatically the hud should note the grid of origin and then switch off when hypergridding (but be able to be turned back on) -similar to the way that the aeros cock would disable and hide itself if you entered a PG parcel in Secondlife. That would save wearers from un-sexy embarassment and would aid foreign region managers (someone can't spam accidentally, so if they're spamming managers will know it's deliberate).
like(0)
Good idea to add a minimum maturity rating on a region - will add that to the "to be done" - thanks :)
like(1)
Maturity setting added as Harper has suggested. It will now withhold any local chat announcements if the maturity setting of the region is lower than is set.

JUST noticed that I misread Harper's suggestion. The solution I have put in place only looks at the maturity of the region - nothing to do with the origin grid. My bad on reading there! However, I personally think this is a better change as you can set it (for example) to only do local chat on Adult regions (you can choose ANY maturity) and then if you hypergrid somewhere (and re-wear or reset to get scripts working - assuming scripts are enabled there) the hud will still function perfectly well - it just wont announce anything in local chat. This means that you can still do any roleplay with it between yourself and an owner if you wish - and noone else need know anything is going on.
like(0)
This has been using llLinksetData for data persistence, however this doesnt reliably (at all?) preserve data across hypergrid. The next version will be storing data in description field of the item. As that only gives 255 characters of data - the system now has 10 linked child prims to provide more storage.

This may not be a particularly eligant way to store persistence - it is the most reliable. Reading from note cards is fine - but that cant store live status. To do so requires writing TO notecards and that requires ossl that may not be enabled - or at least not enabled for "most users" so while I can use that for myself - it may not be useful to anyone else.

Currently 7 or 8 of the linked prims are used for this storage - with the remaining 2 there to store items related to RLV in future. This SHOULD mean that if you are wearing this system and hypergrid, it may or may not WORK on the destination grid, but when you come home it definately will carry on from where it was when you left as it just reads from the description field of the linked prims. It does of course make it high LI but I dont think anyone should really have a problem with an 11 prim attachment these days.
like(1)
llLinkSetData is relatively new and needs more time to mature, my grid does not support it. Using Description field data is an excellent way to have a persistence while still supporting earlier 09x releases. :D
like(1)
llLinkSetData is also not robust enough for hypergrid travel it seems. Prim description fields should be "hypergrid" proof. The only issue I had with it was the item being reset on reloading on a foreign grid and then default values being written to descriptions. Making sure that the full startup (including reading data from the prims description fields) is completed before anything can be written to them should have solved that. Better than llLinksetData and much better than writing to notecards which requires ossl to be enabled and the notecard able to be written to which I believe is high or very high threat level so unlikely to be available to most users.
like(1)
Some people like to take their roleplay with them across HG. Bringing vanity huds and accessories can be quite fun but the destination may not always support the content. This is especially true because of the code fragmentation which is now taking place. You will have those who embrace and adopt the new technologies first, and then those people like me who are still releasing code on the older, tested code engine, upgrading would break a lot of stuff on my grid. That would be suicide LOL.

With that in mind, I aim for forward compatibility in any code I create but also have an understanding that the intention, while good, can still fall flat in some areas. Cheers =D
like(1)