Stay in bed

[pango]

Started as a RP improvement idea after watching someone play Daggerfall for the first time:

If you click on a bed, it should bring the Rest window.
As a benefit, if you then select to rest, you'd wake up near the selected bed, or at very least stay at the same place instead of forcefully teleported to a preselected room of the tavern.

Goal is not to replace existing way of resting in taverns/fighters guild, just to give more options.

I was hoping it would be a minor patch, but the code is already a bit intimidating

[pango]

Crude implementation, works in taverns only, found beds' modelIdNum by experiment, etc:
https://github.com/Interkarma/daggerfal ... tay-in-bed

I was thinking about changing your allocated bed with the one you clicked (so that the next time you activate rest the classic way you get to the same location), but didn't know how to do that

[Interkarma]

It's an interesting concept! The trick will be in preserving the rental contract and dropped object serialization during rental period as well, while still allowing player to rest from a bed of choice. It would make an interesting mod with the right hooks in core.

Hazelnut is the dev behind the room rental, he's the best one to bounce ideas around with if this is something you're looking at continuing with.

[Hazelnut]

This can probably be done, but I'm not convinced it's a good idea. I think it will lead to many new players thinking that they have to manually walk to a bed and click on it, never realising that it's unnecessary and they can simply rest anywhere in the building if they have permission and have a bed auto allocated - as in classic.

[pango]

That could happen, even if logically players should have used Rest key before at that point, say in dungeons.
I can't think of any mechanic way to avoid that, so ok, that's probably mod or option material.

That said, to be perfectly honest, Daggerfall Unity interface as it stands assumes a lot from the player; barely less than Daggerfall classic interface. Some streamers figure out very late that they're 4 modes of interaction, to give just one example.
So until the interface is made more self explanatory, or we get good (embedded) documentation/tutorials (in which case any mechanics we chose to implement can be explained), some people wasting 15s is not the biggest ergonomic issue in our hands.

[Hazelnut]

All fair points, and re-reading my concern it's basically saying lets not - just so that this unexplained not-entirely obvious mechanic for bed allocation is learned by players.. not the most solid argument.

Maybe this could be the first little feature of an RP mod? That would be fine, and I bet you and others can come up with more ideas for it. What do you think? I have some time off coming up and would be happy to start one.

[Interkarma]

This is really more of a mod discussion, as the current behaviour matches classic.

[pango]

Okay!
I'm not sure yet what set of features it could be bundled with, this one just grew up from the observation that beds were currently only a bunch of pixels in houses...
Making food useful thru effect over time, for example?
But looking at Creator's Corner it seems the community is not running out of ideas yet

[Jay_H]

Fast travel with inns could include the benefits of food, and fast travel with camping could exclude it.

Some people have mentioned interest in temperature mods like Frostfall for Skyrim.

[Hazelnut]

So tonight I gave this a try. Thought I would see how allowing custom methods to be registered in PlayerActivate would work. See PR #1075 for the core codebase changes, and https://github.com/ajrb/dfunity-mods/tr ... layRealism for the mod code that uses it.

Would like feedback on this approach which matches the GameObject name (everywhere is calling same method to generate it to ensure consistency) and calls the delegate method registered. This is different from the existing way of adding a component to the GO when laying out the models, and has the advantage of not needing the different model layout code (interiors & dungeons) to both allow action registration. Instead it's registered and checking in the PlayerActivate class.

Not entirely sure this advantage is worth diverging from existing process, but thought I would give it a shot and see what others thought.

Pango, Interkarma - thoughts? Should I switch this to registering MonoBehaviour components to be added to the model GO or do you think this is a better way for mods to register custom model actions?