Jump to content

Recommended Posts

6 hours ago, El_Duderino said:

Do I understand that "clean break away" correctly in that you're suggesting that users will ideally have to do a 100% Toys only playthrough, or a 100% DD-only playthrough, depending on what mod(s) they want to play with?

No, that would indeed be bad. When I started the very first consideration was to make it able to run side by side with DD. This is a requirement and a reality.

 

What I mean by clean break away, is at the mod level, not the load order of a user. A mod might as well use just one or the other, unless there is a very good use case to set out to use both, knowing that it will be harder. Think of cars on the road, all initially with ICE (internal combustion engine) engines. Now along comes Hybrids (ICE and Electric both under the hood) and Teslas (electric only). I'm saying the Hybrids are ineffective and over complicated, you might as well get the Tesla. But Teslas are most certainly built to drive on the same roads as the ICE cars.

 

So Toys does need to make it easy to detect DD items occupying a slot in advance (right now Toys just fails and you react in your code by the return error). And do I need to find a way to prevent DD from removing toys, or some other solution? Yes. That's needed and planned for V1, but not in v0.1.

7 hours ago, El_Duderino said:

Sorry if I may be thick here, but how does that work with the chastity gear included in the mod? Will NPCs just stick their dicks through them if I'm wearing one?

 

They could. That's the mod author's choice. Toys has a very simple way to temporarily "store" toys, so the mod author could choose to build into their story "NPC takes the Chasity belt off". Or you can tap into the backstory we have in Toy Story, where toys can have a phasing enchantment, that lets NPCs stick their dicks through.

 

You see the goal of the DD animation filter is to force device appropriate animations. Sounds reasonable on the surface. But the result is an overbearing solution that has no choices for the mod author or users. So Toys is not going there. Toys will have alternatives, beyond the one I just described, that are always optional. For the sake of fun sometimes toy "inappropriate" animations is the better compromise, versus broken scenes, long delays, or repeating the same animation over and over.

Link to post
7 hours ago, Lupine00 said:

I'm optimistic about Nemesis, but we're still a long way from the end of FNIS, unfortunately.

I agree. 

 

As for number of animations maxing out problem, I think we all have different play styles, where some are constantly bumping up against that, and others never do. I had kinda thought the latest situation is not too bad. But I accepted long ago that I'd never run both DD and newer versions of ZAP together, and this is for reasons unrelated to FNIS.  I also, as a rule, stick to the regular FNIS, not the XXL, as I think it keeps my load healthy. So I'm not "first hand" aware of the maxing out that you face.

 

7 hours ago, Lupine00 said:

detecting whether a character is actually capable of having sex at all, or exactly which holes are open

Now that is some good feedback. I had not thought about it in this way. An API that is "tell me what's open" before you call for a love scene huh? :)

 

7 hours ago, Lupine00 said:

And then there was the recent "manipulate devices" thing.

Yes I want to do something that is very different from this. Toys will never pop up menus and dialogue while equipping manually so its going to be different. I've got some ideas but wanted to see the feedback. Lock as a separate thing *scratches her head thoughtfully*

 

6 hours ago, kziitd said:

But I still want to say that from the introduction of the pictures. Some of your items don't seem to have a good match for the bone weight of the characters, such as the rope, which has a rather exaggerated deformation.

Maybe you need someone who is very experienced in BS to make props.

We have a few contributors but their time is limited and currently more are interested in doing it for SE when the time comes. I could certainly use more volunteers for bodyside in LE. You volunteering? :P

 

4 hours ago, audhol said:

You might want to change the wording for the insignia set as I did not create the belt, harness and chastity piercing that feature in the screenshots. Perhaps you could say some items by audhol?

Fixing now.

3 hours ago, MonVert said:

You can download the already compiled Nemesis from Github; you do not need to build it yourself.

The key point for me on Nemesis is that it, when I last checked, can't do AAs. Know when that is coming?

 

1 hour ago, Hylysi said:

In ToysHandler and ToysPlayerAlias you used a Mutex but a State would have (to my understanding) worked as well and would likely be faster.

 

Is this not the case?

Is there benefit to using one over the other or is using a Mutex for everything done for the sake of simplicity?

 

I don't know if its faster. Conceptually, I've always guessed that there is more overhead to states and that states are more of a convenience/design pattern.

 

Do you know you can run out of states? I found out the hard way in MCM menus in SLaV. I have often wished you look look up documentation that tells you which things are slow and fast relatively speaking in Papyrus. But I use the simpler method because I do have the feeling its also faster. If you dig deeper into my code you will find I've done some things that on the surface appear to be not so elegant and "hard coded", but I've done them for performance.

Link to post
56 minutes ago, VirginMarie said:

Do you know you can run out of states? I found out the hard way in MCM menus in SLaV. 

Using states for the simplest of MCM options such as text and toggles is a waste of states if your mod is feature heavy.

Milk Mod Economy has this "problem" because of that. There's a limit on states but that doesn't stop you from adding MCM options, instead you have to use the older non-state methods.

1 hour ago, VirginMarie said:

I have often wished you look look up documentation that tells you which things are slow and fast relatively speaking in Papyrus.

The closest thing I know of is Papyrus Speed Test but that only covers common functions. Writing custom tests is supported but, of course, you wouldn't be able to do mod specific tests without adding it as a dependency.

A script framework for modders that allows you to time the speed of code segment in a script by adding a start and stop function would be interesting.

Link to post
4 hours ago, Hylysi said:

There's a limit on states but that doesn't stop you from adding MCM options, instead you have to use the older non-state methods.

Yes I learned that the hard way and in SLaV had to fix in that way. I'm doing this right, from the start, in Toys, although with Toys I don't expect the MCM to go crazy with too many more options.

 

For testing, I do make my own script to throw a curve ball at the functions. For Toys api, I've purposely spammed them, to ensure the mutex is doing its job.

 

You can throw this at it...

If TStoryHandleToy(Toys.AnalBellChainGoldExotic) && TStoryHandleToy(Toys.ChastityPiercingGold) && TStoryHandleToy(Toys.NippleClampsGoldExotic) && TStoryHandleToy(Toys.AnkleChainGold) && TStoryHandleToy(Toys.RopeHarness) && TStoryHandleToy(Toys.WristChainsGold) && TStoryHandleToy(Toys.BrattyThroatTeaser)

and it wont even trigger a single mutex, which is good. So I spammed it with hotkey presses, which is more like if 2 mods are calling at the same time.

 

That line of code above is in Toy Story's TStoryMain.psc. Its one of the tests you trigger from the MCM, and it uses a wrapper that handles return codes, to call HandleToy(). That's the sort of thing I'm demoing/suggesting through Toy Story, that mod authors can use.

 

Link to post

So assuming the needed functionality is available in toys for a mod (sorry Lupine gonna use DF as an example) - say devious followers - since detecting both DD And toys present the mod author could put a switch in their MCM to expressly use one or the other.. So would that bypass or resolve at least some fighting between frameworks? So to pick on DF As an example, if a player is locked in a DF Slave collar that's being handled by toys, all other "accessories" would be handled also by toys (or DD If the DD Framework was being used). I don't know how easy that would be to work in but having both frameworks installed but only one being used at a time might be great. It also allows players to use some of the older mods that haven't had love in a while (obviously not using toys but Older DD Mods that aren't really updated anymore could rollover to DD for handling).

 

I guess the question there is would the overhead of that add a bunch of unnecessary script load? I don't know if there's a way to intercept DD stuff and swap it for Toys stuff without a lot of work but that'd be amazing IMO...

 

Keep up the good work! Will be paying close attention!

Link to post
8 hours ago, nokturnihs said:

put a switch in their MCM to expressly use one or the other.. So would that bypass or resolve at least some fighting between frameworks?

A switch in MCM would have to actually do something. What would it do?

It's not a matter of a user controlled switch, in fact if there is something it could do, it could be transparent to the user.

 

My intent IS to make it possible to do this, but you'd need a big reason to want use it because you, as the mod author, would be doing LOTS more work to support both frameworks.

 

Being able to use Toys along side DD is a requirement and a reality. But I think it would be a rare case where you'd want to support both frameworks, at the same time, which is a whole different thing, than running with some mods using DD and some using Toys.

 

Will you be able to use old mods that need DD? Yes. Toys will never fly if I don't support Toys running side by side with DD.

 

8 hours ago, nokturnihs said:

I don't know if there's a way to intercept DD stuff and swap it for Toys stuff without a lot of work but that'd be amazing IMO..

I don't see any technical possible way to do that at all. This is not a 1 to 1 feature mapping. Toys is not a DD clone. Toys is doing things very differently.

Link to post
1 hour ago, VirginMarie said:

A switch in MCM would have to actually do something. What would it do?

It's not a matter of a user controlled switch, in fact if there is something it could do, it could be transparent to the user.

 

My intent IS to make it possible to do this, but you'd need a big reason to want use it because you, as the mod author, would be doing LOTS more work to support both frameworks.

 

Being able to use Toys along side DD is a requirement and a reality. But I think it would be a rare case where you'd want to support both frameworks, at the same time, which is a whole different thing, than running with some mods using DD and some using Toys.

 

Will you be able to use old mods that need DD? Yes. Toys will never fly if I don't support Toys running side by side with DD.

 

I don't see any technical possible way to do that at all. This is not a 1 to 1 feature mapping. Toys is not a DD clone. Toys is doing things very differently.

Oh yeah I'm sorry if it sounded like that's what I thought - it's got a lot of core (fundamental) differences. I was talking more along the line of use cases in other mods. There's a little overlay in some of the features (mainly) fancy accessories :) that hold some relation to some of the existing content out there. I believe that in some cases DD Became the framework of choice simply due to limited options.

 

Toys will be super interesting to watch going forward! As (mostly) a player I will be very interested to see who adopts it moving forward for third party mods and what kinds of fun features get implemented using some of toys unique features (like transformations). Just off the top of my head I could see some -really- interesting things coming from mods like chain beasts and others like that. 

 

I'll also be interested to see what mods like DBA And DT or corruption do with Toys!

 

Thanks for the quick reply! Will keep and eye on it!

Link to post
On 2/1/2021 at 9:00 PM, nokturnihs said:

gonna use DF as an example) - say devious followers - since detecting both DD And toys present the mod author could put a switch in their MCM to expressly use one or the other..

The problem with porting a mod like DF is that it has a lot of dialog conditions and code in fragments that are all tightly bound to DD.

Swapping it over to use Toys is not really a good use of time.

 

But, that doesn't mean you wouldn't want to make it play nicely with Toys if possible, but that might not be a good use of time on old mods either.

And you might conceivably want to add a facility to use certain toys in new functionality - but Marie is saying you probably won't - and undoubtedly has good reasons to say that.

 

If every dialog condition that DF tests for DD had to be duplicated with another Toys one, testing for the same item "type", it would likely bloat the dialog conditions on many dialogs to a silly level. A good many of those dialogs have a lot of conditions already. Too many for my taste.

 

Maybe that's just not something you do in a Toys world? If I want to ensure that the PC is in the appropriate state to offer some game, or add, or remove some device, maybe there's a completely different way to achieve that in Toys rather than checking for device keywords?

 

But, I imagine that if I want not to stop DD bumping into Toys, I need to do some Toys checks before adding DD items?

Unless DD adds reciprocal support for Toys, though that seems optimistic.

 

 

I'd imagine that SLAV has to face completely converting a staggering amount of dialog conditions and fragments to Toys, and if that's done it can rely on Toys built-in safe-with-respect-to-DD-ness? That avoids double checking, but does require a major rework of the mod.

 

It seems like a situation where one nervously stands back and watches to see what others do, but the more I think about it, the more I think Toys probably makes most sense for all-new mods.

Link to post
3 hours ago, Lupine00 said:

If I want to ensure that the PC is in the appropriate state to offer some game, or add, or remove some device, maybe there's a completely different way to achieve that in Toys rather than checking for device keywords?

 

This is a copy/paste from some documentation within ToysFramework.psc...

Spoiler

;/========== Registered Worn Toys ==========
;===========================================
- To access worn toys, no function call is required. Instead, worn toys are always kept in memory (the properties below)
Examples:

	ToysFramework Property Toys Auto

	If Toys.WPelvis
	- True if a Plevis toy (chastity belt etc) is currently worn
	
	If Toys.WGenital.HasKeyWord(Toys.Arousal)
	- True if the worn Genital toy (a clit or penis piercing etc.) has the Arousal effect

	Debug.Notification(Toys.WNipples.GetName())
	- display the name of the currently worn Nipple toy

	Toys.HandleToy("MyMod", PlayerRef, Toys.WMouth, UnEquipToy=True)
	- uses HandleToy() to unequip the current mouth toy (gag), if not restricted
 
- please do not use script to modify these properties directly. Never makes sense to do so. Toys manages them for you/;
Armor Property WHands Auto
Armor Property WFeet Auto
Armor Property WMouth Auto
Armor Property WNeck Auto
Armor Property WWrists Auto
Armor Property WAnal Auto
Armor Property WPelvis Auto
Armor Property WGenital Auto
Armor Property WNipples Auto
Armor Property WLegs Auto
Armor Property WEyes Auto
Armor Property WBreasts Auto
Armor Property WVaginal Auto
Armor Property WTorso Auto
Armor Property WArms Auto


;/.......... IsSlotAvailable
- Checks a slot to see if can be used
- IfUseStore False, means the check is based on unequipping a toy to inventory. True means by moving to storage

Returns True if:
= Slot is empty, or toy that occupies it has no restrictions, or the player equipped (in which case restrictions are ignored)
Returns False if:
- Invalid ToyType
- when IfUseStore False, an occupying toy from another mod has a restrictive keyword
- when IfUseStore True, an occupying toy from another mod has the 'NoRemoval' keyword
- when another mod has reserved slots
= Mutex wait timeout
/;
Bool Function IsSlotAvailable(String ShortModName, Keyword ToyType, Bool IfUseStore=False)

 

 

So for example, instead of checking a keyword, if using script, you can simply use

If Toys.WPelvis

That will return true if the player has a Pelvis toy.

I hadn't considered that people check for devices directly in dialogue conditions. I've not done it that way myself. I always pre-check outside of dialogue. But I can see why for a follower, this would be different.

 

If I were to add the "Conditional" flag to the Armor Property WPelvis Auto, you could check Toys.WPelvis in conditionals.

This is more efficient. But while worthwhile, I don't think it makes your updates to conditions any less tedious.

 

In the copy/paste above, I also included IsSlotAvailable(). Now you can't use that in conditionals, but see my suggestion below at the end of this post.

 

I'd like to see an example of what you have in conditions to check for DD items. Because I'm not saying nobody is going to want to do this (support 2 frameworks at the same time). So I'm putting my mind around this.

 

I'm going to make one of my next priorities, to be on these...

  1. Figure out best way for Toys to know if a DD item is in a given slot, without hard dependency on DD. It could then have auto play nice built into HandleToy() and UnequipToys(), just like it does for Toys toys
  2. Figure out if I can stop DD from blindly removing Toys

 

3 hours ago, Lupine00 said:

But, I imagine that if I want not to stop DD bumping into Toys, I need to do some Toys checks before adding DD items?

Yes. Unless you don't play nice, and just let DD remove a Toy that another mod could be counting on being there. I can't think of any way to make this easier or automatic, beyond the stuff above.

 

3 hours ago, Lupine00 said:

Unless DD adds reciprocal support for Toys, though that seems optimistic.

Yes, but I'm trying hard for the 2 to work side by side.

 

3 hours ago, Lupine00 said:

If every dialog condition that DF tests for DD had to be duplicated with another Toys one, testing for the same item "type", it would likely bloat the dialog conditions on many dialogs to a silly level

Maybe setup a "conflict check function" does all the work of checking both for DD and Toys, returning true or false, then trigger it from your dialogue just in advance of it being needed, land the "answer" in a variable that is conditional to be read in your dialogue, then use that, it becoming a single check in the dialogue stuff.

 

Such function could use IsSlotAvailable() which would now include checking for Toys restrictive keywords, automatically for you.

Link to post

To all the super smart coding genius types out there..... ! 

 

Can anyone come up with...

 

Best way for Toys to know if a DD item is in a given slot, without hard dependency on DD

 

- must be soft dependency

- must know its DD item (for example has keyword Zad_InventoryItem or whatever it is). If we cant read the keywords, maybe DD is detected by the fact that its got those dual armor parts or something else creative

- as a bonus, if we CAN read the keywords, then also check for if device is generic, or QuestItem

 

Write me the code, that is the most efficient way to do this, and win the prize! The prize is your bragging rights, and be in Toys credits :P

 

 

Link to post
5 hours ago, VirginMarie said:

Write me the code, that is the most efficient way to do this, and win the prize!

See SLD item scanner. It uses a classic soft-dep in global function file  to obtain the forms, then uses informed knowledge of what slots what items can actually appear in to detect the items in the core code.

 

It scans almost all the item types across all the slots. It's "time to complete" is long, because it has to fetch slot contents, but the Papyrus load of doing that is minimal because it spends nearly all its time descheduled, waiting for latent functions to return.

 

If you want a quick result, then getting keywords by soft-dep, or by name gives you some information, but it doesn't necessarily confirm occupation of a particular equipment slot reliably.

 

The _fwb_dd.psc global functions should only be called once you know DD is present, which I establish by a check for its ESP.

No DD "types" are present in the slot handling code.

 

On load, or at some other sensible time, you call the global code in _fwb_dd.psc to populate the Keyword variables in the handling code.

It's only called once per load. Or it could only be once per game.

However, I recall it on load, after establishing DD is present, so that bug fixes in that file will be picked up and will repair the stored state.

 

The snippet code puts the device/slot state into a bunch of variables that can then be referred to as needed.

The idea is that the slot scanning runs periodically on the PC, and it takes a while, but is low load.

 

The exact state of the PC will not always be perfectly up to date, but with Papyrus and DD that's irrelevant anyway.

DD's mutexing system doesn't work, so items splat over each other internally, corrupting the StorageUtil state and creating dysfunctional item adds.

Also, there's no way for an external application to link into those mutexes, even if they worked, so it's all moot.

Clean synchronisation with DD is impossible, and not even worth attempting. You can only know the current keywords, and you can never really ensure that some DD item doesn't perform an asynchronous commit while you're processing that state, because the Papyrus threading model means that doing anything meaningful to a slot, or with an item can potentially deschedule your thread, and you might not run for ... a very long time ... or ever again.

_fwb_dd.psc

Snippets from SLD slot handling.txt

Finally, there is a known bug in GetKeywordArray. I thought I fixed this but it still seems to be there. My memory is hazy and I'll need to review the SLD forum, but it was raised a couple of times. Or there might be a fixed version on my Mac somewhere, but I don't have time to look just now. For sure, the plugVaginal and plugAnal hex values shouldn't have the top byte set, and I think there could be an item keyword that is fetched from the wrong file (integration instead of assets, or vice versa), and thus is garbage - probably something to do with hoods, because hoods are all over the place in DD (at least in 4.X, I'd like to dream they're fixed in 5, but probably not). Due to the chaotic state of hoods, I think my testing of them was sketchy, because I was inclined to ignore odd results, because their slotting is highly erratic to start with.

 

If you're actually interested in this, I can identify the issue and post the fix, otherwise I won't bother.

Link to post

Oh wow thank you so much Lupine, this is loads of help.

 

I've also received ideas from another person in Discord. Between the two of you, a combination of ideas, I already see a clear and easy way, I think, to do a clean thing in Toys.

 

1 hour ago, Lupine00 said:

If you're actually interested in this, I can identify the issue and post the fix, otherwise I won't bother.

I'd not by copying any code, so not needed. It's the technique/approach I needed. I've read tons about soft dependency, but this is my first time implementing in that fashion. Toys is largely all about lessons learned, and I think you said that yourself, that we now have that luxury.

Link to post
1 hour ago, VirginMarie said:

I've read tons about soft dependency, but this is my first time implementing in that fashion.

This probably explains things better than my hasty comments above.

I noticed one mistake though:

I say "1) Put all the mod interactions for a single foreign mod into a single global function. Do not (ever) mix mod interactions between different mods in the same file!"

What I actually meant was "into global functions in a single file".

Though, in some extreme cases you might need more than one file to partition that code, it would still be all global functions.

 

I mention processing OnLoad above, but that was a simplification; the correct details are in the blog post.

Don't miss the bit hidden in the spoiler at the bottom, as it digs a little deeper into on load issues and type resolution.

Link to post

I'm looking for someone who wants to make a content mod for Toys, that provides keys in unique and interesting ways. If we find someone, I wont build the feature into Toys other than maybe something very basic in either Toys, or Toy Story. 

 

Anyone interested?

Link to post

@Lupine00

 

For next release, Alpha 2...

HandleToy() and IsSlotAvailable() now have DD awareness built in, meaning they will check for a conflicting DD device, if no conflicting toy, and if DD is installed. 

 

[02/06/2021 - 11:07:48PM] [*TOYS] DD IS installed
[02/06/2021 - 11:08:26PM] [TStory] Book that shall not be named READ
[02/06/2021 - 11:08:26PM] [Toys] Slot has a DD item
[02/06/2021 - 11:08:26PM] [Toys] (IsSlotAvailable) [Keyword <ToysType_Pelvis (0C0038DA)>] slot is NOT available (but it might be if storing)

 

So that covers Toys side of playing nice, making it dead easy. You do no extra code beyond what you'd do if there was just Toys in use.

 

In the opposite direction, DD wont have this awareness, but if you are wanting to make a mod use both frameworks at the same time, you'd already have the Toys awareness from the Toys side, so not a problem. For example if you are about to equip a DD pelvis device, and want to make sure the slot is available, it's just... 

 

IsSlotAvailable("<ShortModName>",Toys.Pelvis)

Link to post
14 hours ago, VirginMarie said:

a content mod for Toys, that provides keys in unique and interesting ways

Definitely by harvesting plants! 🤣🤣🤣 I find keys in my garden all the time. No tentacle monsters so far though.

 

More seriously, the gameplay of Skyrim has only a few actions: combat (being hit, cast spell, swing weapon, fire arrow), sex, looting enemies/containers/plants, praying, equip or unequip an item, eating, drinking, NPC conversations, and the various trade skills. Most of these have been done as key sources in one form or another in the past, except maybe combat and praying. You can theoretically create new actions, like dancing, or pulling a cart, and they've been done, but not as universal as sex in sexlab.

 

Dance for keys? Could be a thing? Maybe they throw keys at you?

Or maybe you can find a key at the bottom of a wine bottle? :) 

Link to post
6 hours ago, VirginMarie said:

I think you can find keys in dragon dung?

I bet you can find loads of them there. Presumably, from key-laden adventurers that were gobbled up and pooped out.

 

This suggests a mod that I'm sure would be a big hit on Nexus: Turds of Skyrim - adding harvestable poops from wild and domesticated animals. Get the real horse experience! Muck out the cow shed! Wonderful. Sofia can roll around in it next time she's spreading her legs in the stables.

 

Uses:

  • poop alchemy
  • burn instead of firewood
  • fertilize your planter boxes and fields
  • farmers will pay you to spread it on their crops and it causes instant growth (because Skyrim!)
  • LL-only patch to find keys.

This is too big and exciting a mod for me to develop at my slow pace though. It needs a mod-making-machine like Monoman.

 

But more seriously, I was trying to think of a way to get keys that would be a little different from normal, and useful when you are bound and really need keys. Roaming around Skyrim in a hobble dress and armbinder, searching the wilderness, or horror-infested tombs, seems like a poor decision. It's like saying, "I'd rather be eaten by spiders, or raped, murdered, and then raped again by draugr than stay alive, but at the mercy of capricious humans." At least the humans have reasons to keep you alive that sabretooths and bears don't normally have. But maybe that makes no sense in the topsy-turvy world of LL Skyrim, where friendly spiders let you go after giving you a little gift, where draugr conjure brand-new armbinders to dress you up for their bondage-sex parties, then let you wander off with them, and where bandits rape you then put you in a chastity belt and simply let you go. Though, in some versions of this world you might have to spend a couple of weeks on your knees and staring at a wall before they'll release you.

 

I guess my point is that the best place to get out of bondage should always be in a town that's mostly filled with people who aren't actively attacking you as their normal activity, and if you go somewhere else, you are definitely taking a big risk.

 

A feature I keep meaning to add for use with DD, and it is on my to-do list for DF, is "the bondage bus". Basically, whenever you're thrown out of a dungeon blindfolded and covered in restraints, instead of having to waste three hours of real time walking to civilization, you can stand at the side of the road for five minutes, and a cart, or a carriage, or khajit with a pack horse, or ... something ... would wander past and collect you, like a package for delivery. They would then drop you at the nearest town. Maybe you have to pay them for it, later, or immediately.

 

In the DF version, you just open a dialog with the follower and pathetically beg, "Please, get me home!" and the follower throws you over their shoulder and one fast-travel later, you are at an inn, or one of your houses, and have a nice new deal to work off.

 

This also suggests a mechanic that runs counter to Laura's Bondage shop, and other mechanics we've seen in the past. Historically, many mods have wanted you to fork over huge sums of cash for keys, or help with restraints. This is mostly useless, as when you're restrained you don't have any cash, you're usually naked and destitute apart from a shiny new yoke, some uncomfortable shoes, and maybe some pretty mittens. So that sort of thing only works if you have a home to store things in, and buy keys in advance.

 

But what if there were somebody who would simply remove restraints for free? The Temple of Mara, or Dibella, or The Nine Divines, or even a weird little shop that manages to earn a living selling extremely niche bondage gear in the middle of a civil war (and you thought SLAV was the only pure comedy mod on LL other than Hydra's?) Yes! That somebody could remove bondage items for free ... without charging you a single coin. But nothing is really for free, right? Who knows what those sinister religious cultists, or creepy sex-addicts in the shop really want from you? Whatever it is, you'll wish that it had just been cash.

 

SLAV's Dibellans sort of fit that mold, but the punishment there is losing points with Kinkturnal - the most badass follower in the game - and the simple issue that the Dibellans are a bit annoying and you'd hate to be stuck in the kitchen with them at a party. So, it's more about who you upset rather than an obligation to your rescuers.

Link to post
57 minutes ago, Lupine00 said:

Presumably, from key-laden adventurers that were gobbled up and pooped out.

Yes. Key-laden poop.

 

57 minutes ago, Lupine00 said:

"the bondage bus"

Yes. Mobile Key/removal services even, why bother going to town when you can't afford the fare?

 

58 minutes ago, Lupine00 said:

But what if there were somebody who would simply remove restraints for free? The Temple of Mara, or Dibella, or The Nine Divines

The Lily guys, Biggs and Wedge might take pity on you.

 

So when you getting started? :P

Link to post

A sneak preview (work in progress) of the first part of the Toy Story quest. Not going to give away what happens next, beyond the intro. :P

 

You will also see the new "Blind" animations we are working on for Toys, part of the time since she wears the Dwemer Blinders toy. This is an alternative to a dark screen etc. The Player has no vision impairment, but the character acts blind.

 

There is a new Chastity toy in this video too. It's not got final textures yet, just a prototype.

 

If you want to know more about what Toy Story is, see HERE.

 

Link to post

Added toys + toy story to a running game and played thru AHO Project mod while keeping my PC constantly in various toys combos.

No issues or conflicts found. All looks very promising! (or even works already and is stable).

I like the spontaneous orgasm animations too and found they work better than those of SLaV, which tend to not stop if a new mod scene gets triggered (like chain SL scenes).

Toys is ideal for playing thru quests while wearing devices without issues. This on the other hand makes them only fetish items without the feeling that the PC is bound for real.

I love the crawling effects lol, the toy collar is my favorite.

Toys would go well on PAHE slaves too, because the would force NPC that idle in various bondage animations according to the worn devices, without preventing them to do any tasks by HSH or AYGAS.

The new "escape" option for the locked toys is great, like the possibility of them to break in combat. Adds completely new ways to escape and offers new tactics.

Everything went smooth, which is impressive for an entirely new framework.

👍

Link to post

Thanks for the feedback :D

 

Test harder if you get the time! There must be something you can break. We do have Alpha 2 coming soon, maybe 1.5 weeks. Can wait for that, it will have the first part of the Toy Story quest.

 

Did you run side by side with DD, or no DD?

If with DD, was there any DD mod that likes to throw on lots of devices (SLaV would be in included in that category)? This I'd not expect to go very well in some cases, however, Toys does play nicely with DD, just not the other way around so much.

 

1 hour ago, donttouchmethere said:

I like the spontaneous orgasm animations too and found they work better than those of SLaV, which tend to not stop if a new mod scene gets triggered (like chain SL scenes).

SLaV will get that benefit too then, because it wont need to do its own scenes for innocent self loving things. But I'm not sure I understand where SLaV gets it wrong and would like to make sure Toys is truly getting it right. Can you clarify the example if you remember in more detail?

 

1 hour ago, donttouchmethere said:

Toys is ideal for playing thru quests while wearing devices without issues. This on the other hand makes them only fetish items without the feeling that the PC is bound for real.

I'm sure you meant to say "while wearing toys without issues" :P

 

What does it need to give that real bound feeling? Note that armbinders, yokes, and prisoner chains ARE coming, and your PC is going to get its ass tied up tight ! :P We might even be using all new animations for those toy types. The plan is that Toys offers both types of experience (hardcore/not hardcore), and its up to the mod author to pick, which would sometimes be purely the config of the toy.

 

If we are getting that wrong, I want people to say so and why.

 

 

Link to post
14 minutes ago, umbex32 said:

Will Toys come with beast compatibility by V.1?

Yes this is the plan. By V1.0 I think you mean... the first non-alpha/beta public release.

 

We are also working on a beast-ish feature. An effect that can be configured on a toy that makes you "DeerFu" which is deer hooves, antlers, and optional texture.

 

We will also have some initial male and futa support in V1.0

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   1 member

×
×
  • Create New...