Daggerfall transition persistence behaviour

Discuss Daggerfall Unity and Daggerfall Tools for Unity.
Post Reply
User avatar
Hazelnut
Posts: 3015
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Daggerfall transition persistence behaviour

Post by Hazelnut »

I'm currently working on persisting state across world transitions, and I would like to confirm my observations of classic behaviour.
  • Building interior state is kept until you leave the town/city/place.
  • Shops restock shelves... when?
  • Enemies inside buildings - do they persist if you leave then re-enter? Can they transition outside, or is leaving a surefire way to escape quest enemies who are kicking ya butt? (not guards, they are different)
  • If you are surrounded outside, can you recall and if you come back are enemies gone?
  • Renting tavern rooms - does dropped loot persist until room rent expires? Can you store in furniture? Is it room specific or can you use any room in the tavern?
  • Are there any buildings (i.e. not dungeons or palaces which are actually dungeons) which have action objects (i.e. levers etc)
If you have any requests for enhancements over classic behaviour let me know, but please give it a little thought first. (e.g. Persisting dungeon state on exit would remove one of the signature Daggerfall gameplay features where you have to survive inside until you've met your objective... you can't leave and carry on when you come back. I already considered that)

Oh and for extra credit, is there any relationship between the "House for Sale" buildings you can find and the houses sold by banks? I can't see one.
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Daggerfall transition persistence behaviour

Post by Interkarma »

Let me be the first to thank you for all this hard work. :) Not everyone will recognise it right now, but this lays the groundwork for player housing in future. It's kind of incredible just how much of the 0.6 feature line you guys have knocked over already.

I'll try to answer some of your questions to get the ball rolling. Others are more than welcome to chime in with corrections or more information. I don't mind if I get something wrong, just correct me. :)

I'm at work right now so will add to this over next couple of days if I get a chance to test something properly. Right now information is from the top of my head.

Building interior state is kept until you leave the town/city/place.
Yeah, it seems to be. I haven't stressed this system though. Maybe it only stores the last 5 (or 10 or 20) buildings the player enters in that location. Whatever limits classic has, I would be more than happy for you to cache all buildings player enters inside a location and persist that until they leave location.

Shops restock shelves... when?
I believe every 24 hours of game time. Can anyone confirm?

Enemies inside buildings - do they persist if you leave then re-enter? Can they transition outside, or is leaving a surefire way to escape quest enemies who are kicking ya butt? (not guards, they are different)
I believe they persist if player runs outside and back in - but cannot transition outside themselves. Right now I don't persist any building interiors and quest enemies are simply re-injected when player enters building again.
If you are surrounded outside, can you recall and if you come back are enemies gone?
I believe if you recall to a different map pixel, the exterior state will be cleared. But if you recall to elsewhere within same map pixel, state will persist. Would really need to test this to be sure.

Renting tavern rooms - does dropped loot persist until room rent expires? Can you store in furniture? Is it room specific or can you use any room in the tavern?
I think any dropped loot in the tavern uses standard persistence rules for interiors. I believe you can initiate rest from anywhere inside tavern after renting a room and player will awake on top of a REST marker. Enable "Show Editor Flats" in StartGameBehaviour Inspector to see these in scene. They are generally placed at the foot of each bed - there's no "room" allocated as such.

It's likely player is allocated a random REST marker at time of renting so they have a constant bed to wake up next to on subsequent rests. Not sure if player is allocated same REST marker when they renew renting or just get another random one.

Are there any buildings (i.e. not dungeons or palaces which are actually dungeons) which have action objects (i.e. levers etc)
Nope, interiors do not carry any interactable objects like this. The action record structure is only present in RDB records and not at all in RMB block data where interiors are housed.

I'm guessing this is why original developers didn't use action records for basic interior doors and just made doors a standalone interactable object.

Oh and for extra credit, is there any relationship between the "House for Sale" buildings you can find and the houses sold by banks? I can't see one.
No extra credit for me then. :) I thought the "house for sale" buildings were 1:1 what the bank would offer. If this isn't the case, I'm not sure how else banks would ID an available player home. This is probably something we need some reverse engineering on to uncover.

User avatar
Hazelnut
Posts: 3015
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Daggerfall transition persistence behaviour

Post by Hazelnut »

Thanks for the answers Interkarma, Seems I mostly have it right. Can you say more about the quest enemy re-injection mechanism. Is it a general thing?
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Daggerfall transition persistence behaviour

Post by Interkarma »

When quest item or enemy is actively placed by quest (e.g. "place item" / "place foe"), a virtual item or foe is assigned to a SiteLink in the quest system. This assignment is virtual as player may or may not be in target location at the time. The quest system just needs to track what belongs where.

When the player enters the appropriate building or dungeon, the layout process will examine SiteLink data and inject the live enemy or item into the scene (with a QuestResourceBehaviour to link it with owning Quest). These live resources are placed to their "QUEST" or "QUEST ITEM" marker in scene - which was selected when resource was reserved by quest system.

In some cases the live resource is not added until certain conditions are met. A great example is the M0B30Y08 quest where player needs to kill a woman's undead husband. Quest will not call "place foe" until player is physically inside target location after a certain time of day. I call this "hot-placement" when player is already in target location.

These live quest objects will self-serialize if player saves inside a building. There's a little bit of house-keeping to prevent duplicates from spawning and to not re-spawn previously killed enemies.

One detail to note is that "place foe" is different to "create foe". The first form assigns the enemy to a specific SiteLink (e.g. find and kill the werewolf), the second form places enemies around the player in scene (e.g. kill 8 harpies). The second form does not use SiteLinks at all, it just spawns enemies nearby.

My feeling is that you can probably let all this be handled by the quest system as-is. The SiteLink-managed resources probably don't need much help at all. Mainly just need to ensure there's no double-ups injected by interior cache.

For "create foe" styled spawns, it might be nice to cache these, but again not necessary if you don't want to tackle them right now. The only effect is if player keeps running in and out of building during a quest (e.g. kill 4 rats), the previously spawned rats will be gone on re-entry. Then quest system will start putting them back again.

I hope I was able to describe the high points clearly. Just let me know if any more detail is needed. I'm happy to help work through the issues.

User avatar
Hazelnut
Posts: 3015
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Daggerfall transition persistence behaviour

Post by Hazelnut »

I think I will leave enemies for now then, since dungeons are not cacheable and enemies for quests are already handled just fine.

If quest authors ever express a desire to be able to cache dungeons during quests (so you can leave for some reason/goal and come back to it in same state) then I'll flesh out enemy caching. All the infrastructure is there, the effort will be integration with existing code and flow.
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Daggerfall transition persistence behaviour

Post by Interkarma »

Sounds fine to me! Quest items are their own thing as well, you shouldn't need to worry about these objects. They don't use loot containers, they're just a billboard with a QuestResourceBehaviour attached. They don't even serialize directly, the live object is relinked to quest data at scene layout time if still in play.

User avatar
Hazelnut
Posts: 3015
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Daggerfall transition persistence behaviour

Post by Hazelnut »

Interkarma wrote:Let me be the first to thank you for all this hard work. :) Not everyone will recognise it right now, but this lays the groundwork for player housing in future. It's kind of incredible just how much of the 0.6 feature line you guys have knocked over already.
You're welcome, half of it was really fun to do (the half that didn't involve me being perplexed about the Unity/DFU timing stuff) and it will support several items on my todo list. I hope it's allowing you to concentrate on the big systems of magic and factions so we can all play this game sooner! :D
Interkarma wrote:
Oh and for extra credit, is there any relationship between the "House for Sale" buildings you can find and the houses sold by banks? I can't see one.
No extra credit for me then. :) I thought the "house for sale" buildings were 1:1 what the bank would offer. If this isn't the case, I'm not sure how else banks would ID an available player home. This is probably something we need some reverse engineering on to uncover.
Allofich also thinks this, and it makes sense - that's what I initially assumed as well. I'm going to retest because my assertion is based on a single test where I spotted a for sale and then it didn't appear in the bank's list..
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

Post Reply