Devious Devices Framework Development/Beta

[GreatCroco]

imho, but this is slightly off topic, it would be best to move the Princess Start out of LAL and into a proper quest. Auto start it silently (like the Dragonborn questline) at the level that is set in DCL when more than normal trap events start to happen. Then anybody could configure it to start when they want, maybe also add a chance, but that's not necessary. 

With that you're not bound to any alternate start mod. The alternative (heh!) could be what Trappings of Fate does, but I kind of like the surprise factor of triggering a trap and then starting the Cursed Loot quest line.

 

  

1 hour ago, krzp said:

But the quest worked for me without ASLAL, so maybe someone with more creation kit experience can just create a sort of a bridge for the other mods, some new alternate start quest that starts up the dcl delivery refused quest?

IIRC the Alternate start just starts the quest when you use the bed, so any mod that does the same should be able to provide that start.

Edited June 29, 2023 by GreatCroco

[krzp]

1 hour ago, GreatCroco said:

but I kind of like the surprise factor of triggering a trap and then starting the Cursed Loot quest line.

One second you're going about your day blasting draugrs, and suddenly you are collecting 78 loafs of bread for 3 hours with no fast travel, no off ramps, and the speed penalty of -80%? I'd smash my head into my screen ? (or, you know, just reload, but that's missing all the excitement of smashing heads into screens)

 

That's an option, sure, but I still think it might be a good idea to separate the starting quest and the actual "saving private chloe" quest line.

Still, though, I totally agree that the starting quest needs more love and recognition, i'd argue it's one of the better ones in the whole quest line.

 

1 hour ago, GreatCroco said:

IIRC the Alternate start just starts the quest when you use the bed, so any mod that does the same should be able to provide that start.

While Alternate perspective has a neat instruction set on converting LAL quests into it's own framework, but maybe the easier path is just to create a separate simple bridge start to place you somewhere in the world near rifen, call "startquest dcur_hq_delivery" and shutdown to let DCL proceed as if it's been called through LAL? No patches for DCL are needed that way.

[Maddac]

On 6/28/2023 at 8:32 AM, Xenoramos said:

On the topic of LE to SE\AE - I will leave here my opinion (which won't change anything anyway lol)

While I can understand that some thing on technical level are better in SE (like engine capabilities etc.), but for me, as for a regular player, SE is worse in most ways than LE, and here's my reasoning:

1 - LE is done in development, it does not receive patches, so game won't accidentally break in case of a sudden patch, and while I was playing SE, few unneeded-for-gameplay patches got released (I believe they fixed something in CC store) which completely broke SKSE and a few mods, so I had to wait around a week to play again, when mod authors released compatible patch for new update

2 - Manual mod installation is much easier in LE. Yes, I know what most sane people use any type of mod manager, but it's very difficult to come to it after many years of installing mods manually. I have tried... with very much patience from nice people who helped me understand at least basics of how to use it... but it's way too complex for me.

3 - Some things in general I can't understand and fully accept in SE.

3.1 - One of these - is very long fade-out from black screen when loading a game, when I can't do anything, but enemies are already active for several seconds, which is most important while playing higher difficulties and do save-load tactics, have to load and immediately open console to wait through that stupid inability to do anything ingame while enemies can land several hits on you. 

3.2 - Other thing - is that some genius decided that "Esc" button should lead to quest log instead of save\load\config screen. Yes, there's mod "fixing" it, but the mod isn't completely stable so sometimes it still opens quest log on "Esc"

3.3 - Overall performance. My LE modpack has pretty stable performance, dropping a few FPS only when something HEAVY happens (like first loading a heavy modded stuff, e.g. Angeli's DD Addon, because of it's huge textures), while SE with just a few mods works way worse, it's MUCH more resource-intense, so if I would want to do a serious playthrough with mods - I would have to accept being constantly below even 30FPS . That again, is my personal issue, but I can run some modern games better than SE with a few mods (literally a few, less than 20 already noticeably drop performance) in terms of FPS.

 

That are my main reasons why I keep LE as my main installation. If DD at any point will become SE-exclusive - that would be incredibly sad for me, even though I understand that it might be better overall.

DD was actually one of reasons I even started playing Skyrim many years ago (and probably the most important one too).

 

But anyway, good luck in further development, no matter what way you will choose.

I agree with all of the above, which is why I still prefer LE to SE. its crazy that SE is 64 bit yet performs worse than LE. I couldnt imagine running SE with all the mods I have in LE, and I also do manual install and tweaking in tes5edit where needed to ensure stability.

[naaitsab]

6 hours ago, Maddac said:

I agree with all of the above, which is why I still prefer LE to SE. its crazy that SE is 64 bit yet performs worse than LE. I couldnt imagine running SE with all the mods I have in LE, and I also do manual install and tweaking in tes5edit where needed to ensure stability.

It's a very stubborn misconception that 64-bit is some kind of magic trick to make everything twice as fast. It isn't. It only allows a program to natively use more system recourses so in theory it can run faster and more stable as it has to swap less. A bit like removing a restrictor on a bike, without swapping the engine it's still the same engine but it can output more power.

 

SE also ships with a lot more graphical ENB like stuff, which impact the performance out of the box. But I'm quite curious what PC's you both are running as on my rig SE runs a lot better in FPS and more important way better 0.1% lows (stuttering etc). 

[Xenoramos]

3 hours ago, naaitsab said:

It's a very stubborn misconception that 64-bit is some kind of magic trick to make everything twice as fast. It isn't. It only allows a program to natively use more system recourses so in theory it can run faster and more stable as it has to swap less. A bit like removing a restrictor on a bike, without swapping the engine it's still the same engine but it can output more power.

 

SE also ships with a lot more graphical ENB like stuff, which impact the performance out of the box. But I'm quite curious what PC's you both are running as on my rig SE runs a lot better in FPS and more important way better 0.1% lows (stuttering etc). 

Obviously I don't have any kind of high-end hardware, considering how expensive the hardware is.

Spoiler

Actually my hardware is around minimal requirements for Resident Evil 4 remake

https://store.steampowered.com/app/2050650

But my hardware still theoretically should be enough to play SE without heavy mods with good performance, but in fact even pure vanilla game with 0 mods runs lower than 60FPS, which, added to other things I mentioned, is making SE much worse personal experience than LE

[thedarkone1234]

Random issue I just found: catsuits are considered nude by EVG conditional idles. Any idea what condition I can add to EVG to consider catsuits as clothing? Maybe some keyword thatt indicates that the boobs and holes are covered?

[Miauzi]

Vor 13 Minuten sagte thedarkone1234:

Zufälliges Problem, das ich gerade gefunden habe: Catsuits werden von EVG-bedingten Leerläufen als nackt betrachtet. Irgendeine Idee, welche Bedingung ich zu EVG hinzufügen kann, um Catsuits als Kleidung zu betrachten? Vielleicht ein Schlüsselwort, das darauf hinweist, dass die Brüste und Löcher bedeckt sind?

 

then one would perhaps still have to differentiate ... because in a transparent catsuit one is really "naked".

if you also have a chastity belt and the matching metal breast cover on your body - you should NOT be considered "naked" according to the usual definitions.

I have finally deleted the whole thing from my "catalogue" of meaningful comments and I ignore NPC's linguistic statements.

(whether the necessary programming and testing effort is really worth it - of course only the authors themselves can decide)

[Taki17]

1 hour ago, thedarkone1234 said:

Random issue I just found: catsuits are considered nude by EVG conditional idles. Any idea what condition I can add to EVG to consider catsuits as clothing? Maybe some keyword thatt indicates that the boobs and holes are covered?

The issue is that the "zad_DeviousSuit" keyword used on catsuits is also used to denote any other restraint that replaces the body when equipped, which means it's also used on the breast yoke, the box binder or hobble dresses.

 

Ideally, the keyword that marks such items should be separated into a new one like "zad_BodyReplacer". I may do something about that in the form of another contribution, however I need to assess its impact first.

 

Edited June 30, 2023 by Taki17

[thedarkone1234]

10 minutes ago, Taki17 said:

The issue is that the "zad_DeviousSuit" keyword used on catsuits is also used to denote any other restraint that replaces the body when equipped, which means it's also used on the breast yoke, the box binder or hobble dresses.

 

Ideally, the keyword that marks such items should be separated into a new one like "zad_BodyReplacer". I may do something about that in the form of another contribution, however I need to assess its impact first.

 

 

Tbh that wouldn't be an issue in my case because FNIS wins against OAR/DAR so the yoke would prevent nude animations anyway. As long as the end result is my character is NOT considered naked with arms free, the rest doesn't matter

[krzp]

5 hours ago, thedarkone1234 said:

Random issue I just found: catsuits are considered nude by EVG conditional idles. Any idea what condition I can add to EVG to consider catsuits as clothing? Maybe some keyword thatt indicates that the boobs and holes are covered?

I have a "cover yourself" animation as well, without EVG - iirc, this is what I've added to the condition set so the catsuits don't trigger.

 

NOT IsWornHasKeyword("Devious Devices - Assets.esm"| 0x02AFA3)

 

[HexBolt8]

As it is, every mod that checks for body clothing or armor concludes that the wearer of a catsuit or hobble dress is nude.  It might make sense for the rendered non-transparent versions to have the ClothingBody keyword.  Although they're form fitting, they provide a lot of coverage.  That would remove the need for player workarounds for nude idles or helpless when naked mods.

 

Edit: A few posts below explain why this is not practical.

Edited July 2, 2023 by HexBolt8

[GreatCroco]

21 hours ago, Maddac said:

I agree with all of the above, which is why I still prefer LE to SE. its crazy that SE is 64 bit yet performs worse than LE. I couldnt imagine running SE with all the mods I have in LE, and I also do manual install and tweaking in tes5edit where needed to ensure stability.

Naturally, if you just take the mods you have on LE and use their SE conversion you run into the risk of leaving performance on the table. It is usually a wise choice to clean up the load order a bit and replace as many mods as possible with newer versions. Of course, the first thing you do on SE is to install all of the engine fixes and performance mods that LE doesn't have. It's not a magic "get 60FPS for free" solution, but even a Ryzen 7 2700X and a 1080 are sufficient to run a quite heavy load order with ENB at around 40 FPS. Although, it might be wise to leave out the ENB with that Hardware.

 

11 hours ago, Xenoramos said:

But my hardware still theoretically should be enough to play SE without heavy mods with good performance, but in fact even pure vanilla game with 0 mods runs lower than 60FPS, which, added to other things I mentioned, is making SE much worse personal experience than LE

which is quite odd given that a NVIDIA GTX 780 3GB is really nothing powerful. Do you have the game on a SSD or spinning Rust?  

Edited June 30, 2023 by GreatCroco

[knots1353]

On 6/22/2023 at 2:13 PM, Kimy said:

It's unfortunately not a clear win for either solution. Both have their ups and downs. In favor of switching you could argue that any new features I might add to DD at this point would likely make use of SE-exclusive functionality anyway, so it's not that remaining LE content mods and LE users would lose out big time here. They could still use the latest LE DD version, and it's not that I couldn't back-port serious bugfixes to the LE version. I have zero plans to make another API-breaking DD release, so the impact on LE content mods might be marginal?

 

In the end...I am not sure. Feel free to let me know what you guys think! 

 

So... I never *released* any of the mods I was working on, but for a year and a half back in 2021/22, I did some rather extensive work on a replacement extensible event framework mod.   As part of that, I did pretty extensive testing and experimentation on both SE and LE, on how event threading worked, how mod upgrades affected existing threads, and a lot of different edge condition testing in both papyrus and C++.   The framework would have meant fairly significant rewrites of a lot of mods if they wanted to take advantage, but my early performance testing suggests a massive improvement in pretty much every area because it would have taken so much processing out of Papyrus and done it in C++.

 

That said, while I think such a framework would have *hugely* benefited mod development had it come out six or seven years ago, I ultimately realized that there was just too much legacy modding out there, even for SE, for it to make the impact I wanted.   And when I realized I'd need to abandon LE support, well, it took a lot of wind out of my ideas.   Other games caught my interest, and I shelved the project, although there's a good chance I may revive a version of the framework for Starfield if it looks like it can benefit from it - by getting it out early, it might catch on much better.

I mention that mainly for background because of the part where I had to remove LE support.   There were a lot of reasons I had to do that.   One big one was that papyrus threading is less significantly less quirky and much more forgiving in SE, especially when you have multiple papyrus threads calling each other and papyrus threads are running on a script which is being updated across a save.  (For those unaware, the *original* version of the compiled script is cached and loaded from the save so it can resume the thread exactly where it left off, and that papyrus thread continues running that older version until it returns outside the script... but functions it calls in *other* scripts may load the new version of those scripts... and if those scripts call a function in the original script it's likely to run the new version of that script.)

But the big one was the strings limit.  LE has a hard limit of 65535 strings... if you have more, it will start failing in unpredictable ways without warning you.   SE also has limits on this, but they're a couple orders of magnitude higher.   And I could see that the framework design I had, which used named events, and was designed to break down events into chains of smaller events with decision branches and nested events and a lot of other things like that, was going to be used to make unpredictably huge number of event strings.   I tried a redesign which worked with numeric IDs instead of names, but it broke some of the core design concepts, so I had to abandon LE completely.

 

Once I made the decision to abandon LE, it greatly simplified development of the remaining version.  Only one version of the DLL needed to be built, I didn't have to worry about significantly different versions of SKSE built with different compilers, and the papyrus side became a lot simpler as well as I didn't have to worry about a lot of the LE quirks.

I'm not sure if any of those reasons have any application to you, but I thought I'd put them out there for you as part of your decision.
 

[Maddac]

On 6/30/2023 at 3:09 PM, naaitsab said:

It's a very stubborn misconception that 64-bit is some kind of magic trick to make everything twice as fast. It isn't. It only allows a program to natively use more system recourses so in theory it can run faster and more stable as it has to swap less. A bit like removing a restrictor on a bike, without swapping the engine it's still the same engine but it can output more power.

 

SE also ships with a lot more graphical ENB like stuff, which impact the performance out of the box. But I'm quite curious what PC's you both are running as on my rig SE runs a lot better in FPS and more important way better 0.1% lows (stuttering etc). 

Intel I7 11700k, 16GB ram, Gigabyte Z590 Aorus Master Ultra, Gigabyte 3060 graphics card, 1TB PCI4.0 NVME SSD, 3 x 2TB sata drives. but its the monitor that surprised me when I upgraded recently from 24" Viewsonic 1ms 60Hz to Samsung G50A @ 165Hz, as Skyrim for LE loads superfast, whereas it loaded like a dog on the old viewsonic. doing a new game with my 400+ heavily modded skyrim would take a few minutes, whereas with the new monitor its done in 30 seconds. loading an existing game is really fast, like 1 second. I never thought a new faster monitor would make such a difference.

[Taki17]

15 hours ago, HexBolt8 said:

It might make sense for the rendered non-transparent versions to have the ClothingBody keyword.

That I can see causing issues with existing mod implementations that check for items worn by the player or being in their inventory. So far Devices not having clothing and armor keywords was a safe and straightforward of differentiating them for regular outfits.

[naaitsab]

2 hours ago, Maddac said:

Intel I7 11700k, 16GB ram, Gigabyte Z590 Aorus Master Ultra, Gigabyte 3060 graphics card, 1TB PCI4.0 NVME SSD, 3 x 2TB sata drives. but its the monitor that surprised me when I upgraded recently from 24" Viewsonic 1ms 60Hz to Samsung G50A @ 165Hz, as Skyrim for LE loads superfast, whereas it loaded like a dog on the old viewsonic. doing a new game with my 400+ heavily modded skyrim would take a few minutes, whereas with the new monitor its done in 30 seconds. loading an existing game is really fast, like 1 second. I never thought a new faster monitor would make such a difference.

Probably something else going on here. The only game I know of that has a FPS load menu bug is Fallout4. On which increasing/unlocking FPS using a mod greatly reduces load times. This involves the load screen, so not desktop -> main menu load time. As far as I know this was fixed when they modified the engine for SE. I haven't seen much difference between LE and SE load times on general if you use a custom DLL loader procedure (ENB). SE loading takes a bit longer from desktop but as it crashes almost never anymore it's something I don't care about. One of the benefits is that SE has some ENB functions buit in natively. So if you don't want to tinker a lot with it you could run SE without ENB vs LE with ENB to make it more even, will greatly increase performance.

[Xenoramos]

14 hours ago, GreatCroco said:

which is quite odd given that a NVIDIA GTX 780 3GB is really nothing powerful. Do you have the game on a SSD or spinning Rust?  

I don't have any SSD, they were really expensive by the time I got my PC, so I remained on HDDs.

[GreatCroco]

2 hours ago, Xenoramos said:

I don't have any SSD, they were really expensive by the time I got my PC, so I remained on HDDs.

Well that's probably the cause, as HDDs are just too slow nowadays. I'd suggest getting a decent SATA SSD, which can be had for around 50 bucks per TB. That's just 10 bucks more than an equivalent HDD.

 

 

3 hours ago, naaitsab said:

Probably something else going on here. The only game I know of that has a FPS load menu bug is Fallout4. On which increasing/unlocking FPS using a mod greatly reduces load times. This involves the load screen, so not desktop -> main menu load time. As far as I know this was fixed when they modified the engine for SE. I haven't seen much difference between LE and SE load times on general if you use a custom DLL loader procedure (ENB). SE loading takes a bit longer from desktop but as it crashes almost never anymore it's something I don't care about. One of the benefits is that SE has some ENB functions buit in natively. So if you don't want to tinker a lot with it you could run SE without ENB vs LE with ENB to make it more even, will greatly increase performance.

I don't know if the duration changed between SE and LE, and I'd have to check the ini files;  but there's a setting that forces the game to stay in the loading screen. This setting exists to give the game some time to ramp up the loaded papyrus scripts.

 

 

13 hours ago, knots1353 said:

So... I never *released* any of the mods I was working on, but for a year and a half back in 2021/22, I did some rather extensive work on a replacement extensible event framework mod.   As part of that, I did pretty extensive testing and experimentation on both SE and LE, on how event threading worked, how mod upgrades affected existing threads, and a lot of different edge condition testing in both papyrus and C++.   The framework would have meant fairly significant rewrites of a lot of mods if they wanted to take advantage, but my early performance testing suggests a massive improvement in pretty much every area because it would have taken so much processing out of Papyrus and done it in C++.

[...]

That's very similar to what the "Fully Dynamic Game Engine" plugin does. I wanted to try it, but there's a VCPKG issue that prevents me from getting all the required dependencies. That's a bummer, but VCPGK is what it is.

[knots1353]

1 hour ago, GreatCroco said:

Well that's probably the cause, as HDDs are just too slow nowadays. I'd suggest getting a decent SATA SSD, which can be had for around 50 bucks per TB. That's just 10 bucks more than an equivalent HDD.

 

 

I don't know if the duration changed between SE and LE, and I'd have to check the ini files;  but there's a setting that forces the game to stay in the loading screen. This setting exists to give the game some time to ramp up the loaded papyrus scripts.

 

 

That's very similar to what the "Fully Dynamic Game Engine" plugin does. I wanted to try it, but there's a VCPKG issue that prevents me from getting all the required dependencies. That's a bummer, but VCPGK is what it is.

Looking at that, FDGE looks more like a wrapper for more easily creating DLL plugins -- although it's hard to say because the docs are incomplete and the sample project they point to doesn't exist.  XEvents was going to be a way of doing Papyrus events differently, by adding extensible ModEvents that had a context containing arbitrarily large datasets of tagged parameter data, a return mechanism so you could identify when an event was complete and return a result, allowing triggering a chain of events in a list, with special handling for Conditional events (events which trigger different choices based on data in the context), Alternative events (events which trigger different choices based on a random weighting), and cleanup events which can be scheduled by an event, during it's handling, that will be triggered when the major event list is complete.   All sub-events could access the context of their parents, and mods could make certain events public by name (such as a Alternative list) and other mods could easily add to it.

So, if Mod A provided a trigger (say - fast travel via cart), and a event which operated on that trigger that had weighted alternatives, OTHER mods could easily add their own weighted alternatives based on the event name, and it would just work - and the other mods wouldn't even need to do soft dependency checking -- if the alternatives event existed, they simply add their own to the list.  A lot of the Conditional checking would have been doable without even calling back into Papyrus as it was going to have a set of basic event operators built into the DLL that could compare, test, and even modify data in the context.  The net effect is that most of the busywork that goes into every mod ends up in the Xevents DLL, leaving smaller and more maintainable Papyrus fragments to do the actual unique behavior of your mod, and encourage coding of Papyrus in those smaller fragments instead of huge monolithic functions which do setup, then comparison checking, then more setup, then execute the compared result, then do cleanup, often with manually defined delays to allow other events to complete because they had no return to indicate completion.

[HexBolt8]

7 hours ago, Taki17 said:

22 hours ago, HexBolt8 said:

It might make sense for the rendered non-transparent versions to have the ClothingBody keyword.

That I can see causing issues with existing mod implementations that check for items worn by the player or being in their inventory. So far Devices not having clothing and armor keywords was a safe and straightforward of differentiating them for regular outfits.

Could you explain a little bit more about the problem?  I don't see it, but I might be missing something.  Just to be clear, my suggestion was to add the ClothingBody keyword to a few devices that cover the body, leaving all the existing keywords in place.  Mods that check for those keywords would continue to work as before.  The zad_DeviousSuit keyword on the worn devices would distinguish them from regular outfits.  The inventory devices wouldn't need to change.  That seems very compatible with existing mods, but possibly you're aware of a conflict situation that I haven't considered.  In the absence of any conflict, the advantage is that NPCs will stop reacting as if the wearer is naked despite being covered neck to foot in a catsuit (or hobble dress).

Edited July 1, 2023 by HexBolt8

[thedarkone1234]

2 hours ago, HexBolt8 said:

Could you explain a little bit more about the problem?  I don't see it, but I might be missing something.  Just to be clear, my suggestion was to add the ClothingBody keyword to a few devices that cover the body, leaving all the existing keywords in place.  Mods that check for those keywords would continue to work as before.  The zad_DeviousSuit keyword on the worn devices would distinguish them from regular outfits.  The inventory devices wouldn't need to change.  That seems very compatible with existing mods, but possibly you're aware of a conflict situation that I haven't considered.  In the absence of any conflict, the advantage is that NPCs will stop reacting as if the wearer is naked despite being covered neck to foot in a catsuit (or hobble dress).

 

I am not sure about the implementations, but for example, if a single mod punishes you for wearing clothes (like some DCL collars), it would kill you for being stuck in catsuits. You need exactly one mod that exists that punishes clothes and is not dependant on DD, and that mod will break, and require an external patch to fix it.

 

I bet other uses for ClothingBody for other reasons. Each one that would need to logically exclude catsuits would have the same issue and require a DD-specific patch.

[HexBolt8]

1 hour ago, thedarkone1234 said:

 

I am not sure about the implementations, but for example, if a single mod punishes you for wearing clothes (like some DCL collars), it would kill you for being stuck in catsuits. You need exactly one mod that exists that punishes clothes and is not dependant on DD, and that mod will break, and require an external patch to fix it.

 

I bet other uses for ClothingBody for other reasons. Each one that would need to logically exclude catsuits would have the same issue and require a DD-specific patch.

I see, it makes sense.  That's what I was missing.  Thank you.

[GreatCroco]

5 hours ago, knots1353 said:

Looking at that, FDGE looks more like a wrapper for more easily creating DLL plugins -- although it's hard to say because the docs are incomplete and the sample project they point to doesn't exist. 

The sample plugin is another program in gitlab. What you want to do it can as well, via function hooks, although those seem to be more low level, seing as the user needs to deal with addresses themselves.  However, what you say could've been a real game changer back in the day. Even today, if it was to be implemented into something like CommonLibSSE.

[krzp]

On 6/22/2023 at 4:00 PM, ponzipyramid said:

Just wrote a quick version of the plugin using CommonLibSSE-NG. Thanks to @zarantha for suggesting this. I am by no means an expert on DD's scripts so it's tough to validate whether or not what I've done actually works; feedback is appreciated.

I have updated to 1.6.40, finally, and, despite the overall flaming wreckage that is my mod list is right now, your plugin seems to be working A-OK, not seeing anything DD plugin related in my logs, so another confirmation of it working from me. ?

[naaitsab]

Small adaptation to the script "zadBQ00" on the "StartValidDDAnimation" procedure that currently does not allow the 'center on' parameter to pass to the associated SL function. If you want to use that you need to use the SL function which then needs to go the filter adding latency.

 

zadBQ00.psc

line 1352:
Bool Function StartValidDDAnimation(Actor[] SexActors, bool forceaggressive = false, string includetag = "", string suppresstag = "", Actor victim = None, Bool allowbed = False, string hook = "", bool nofallbacks = false, ObjectReference CenterOn = none)

line 1406:
SexLab.StartSex(Positions = SexActors, anims = Sanims, victim = victim, CenterOn = CenterOn , allowbed = allowbed, hook = hook)

 

Edited July 2, 2023 by naaitsab