Modifies EntityStateStore application to include support for dead-reckoning

[met4000]

Modifies EntityStateStore to use the new DrEntityStatePdus, allowing dead-reckoning to be performed on stored entities.
Provides support for all 9 dead-reckoning algorithms in the DIS v7 specification.

Resolves: #93

[michaelrfraser]

Thanks Nathan, this all looks good. No philosophical issues, just a few structural questions and code formatting changes requested to keep things consistent.

Major themes are:

• I'd suggest merging the Dead Reckoning Store with the Entity store so that all entity related things are in one spot
• Use Logger vararg overloads rather than formatting strings inline
• Ensure javadoc is filled out for all public methods and classes
• A couple of notes on code style that probably aren't apparent unless explained :)

[michaelrfraser]

Hey Nathan, just had a re-read of your latest changes and have a few more comments (again mostly documentation and logging related).

Might be also worth tagging in @timpokorny as this is getting closer to completion.

[met4000]

Looks like the order I pushed changes in while rebasing this time did manage to mess up the comparison that github links to. This should be the recent changes: https://github.com/openlvc/disco/compare/edfd53ce7a23ee45adb25f40804b13131e06eab5..e8dca7462fa88abb47bfe80ca31b2e41790fee21

[timpokorny]

Just starting to look at this, but unfortunately I have some other afternoon commitments. I'll be back later so I will attempt to re-pick up, but I am formulating some thoughts around the store. I need to actually be able to articulate them better, so let me browse more first, but broadly speaking I'm not sure the functionality belogs at the store level. I also share the questions about the marker interface on EntityStatePDU, which feels like its bringing semantics from the "application" layer into the core area which is only meant to be about seralizliation/deserialization.

Let me look at it more to articulate what I think is needed and I'll come back.

Small Naming Stuff
Again, haven't go through properly yet, but like all terrible reviews I got some small/easy fix stuff first. On that front the one thing that jumped out at me was just the verbosity in some of the namings for the PDU stuff. I think we can trim down the naming in a number of places. Stuff like:
- DeadReckoningParameter.getEntityAngularVelocity() can just become DeadReckoningParameter.getAngularVelocity()
- DeadReckoningParameter.setDeadReckoningAlgorithm() can just become DeadReckoningParameter.setAlgorithm()
- and so on.

I'd take a look at what's there and trim down some of the names.

I'll come back with more articulated guidance on the application level stuff shortly.

[timpokorny]

Right, first things first, as a first step for getting DR into the framework this is excellent. All the hard work done of sorting out the enhancements to pull DR data out, and then do something intelligent with it, including the utility math to do the work is done and in place. To be honest, that's 94.2% of the world.

My only major comment would be on infrastructure at the moment. There are a couple of changes I'd suggest that can reduce the infrastructure "touch" and keep it much lighter, while also keeping things feeling more consistent with the existing stuff.

Notes

• I concur with your feeling on the IDeadReckoningEnabled marker interface. The pdu package to me is really only meant to deal with serializing and deserializing PDUs. More "extended" stuff that helps a developer start to manage their data like this belongs in the application package and kind of layers on top of the core stuff. So pushing an interface downward from application to pdu feels a bit like mixing concerns.

• I also don't think we necessarily need a separate store for dead-reckoned things. All the existing stores have a bit of consistency to them in terms of API and approach at the moment, and the DeadReckoningModelStore doesn't fit with those. It's also the only one that wraps around another store, which feels like it's making another layer, but only half of one.

There are a few other small things like that where I think structurally at the moment it's like a hexagonal shape for an octagonal hole - it's close, but not quite smooth.

Suggestions
Dead-recknoning as defined in DIS is implicitly "utility", in that its pretty much stateless. That might not be entirely true if you want to do some cache for efficiency, but for the most part it is true.

To ligten some of the infrastructure, I'd suggest the following (noting there may be reasons why we can't, so this is just opening suggestions):

• In the application package, I'd create a DrEntityStatePdu that extends EntityStatePdu

  • This class will add overrides that return values factoring in dead reckoning
  • It should go in the application package, because it's no longer just about ground-truth data, serialization/deserialization, which is what the app package "should" be limited to in theory

• I'd put into that class getDrWorldLocation(long), getDrOrientation(long) (and any other methods where, depending on DR algorithm, they get calculated) where the param is the targetTime

  • Those methods will look up the algorithm from the PDU, calculate a value and return it
  • Might be inefficient if there is a call to getDrWorldLocation immediately after a call to getDrOrientation, so could calculate all value and then cache request for the last 3 target times to help subsequent lookups
  • If doing that, I'd make DrmState an inner class of DrEntityStatePdu

• There are times where some sim apps will want to ignore the algorithm that the PDU says it should use, and use one of their choosing

  • To support this, I'd add overloads of getDrWorldLocation(DeadReckoningAlgorithm,long) (and same for all the others) to let users just be explicit about the values they want returned

• I would update the EntityStateStore to return DrEntityStatePdu instances instead of EntityStatePdu instances. People can ignore the dead-reckoning methods if they want.

• I'd remove package application.deadreckoning

  • No longer need the IDeadReckoningEnabled interface
  • DrmState could become inner class of DrEntityStatePdu, or if it is needed to help DR other things, I'd just put in a application.utils package or some such
  • All the model classes effectively do is provide a single method. These are entirely stateless (which is excellent) so they can just be put into the pdu.field.DeadReckoningAlgorithm enum. That will make it a bit big, so if it's too ugly, again just pull the methods out into a util class.

Benefits

• No need to register models or keep track of them by entity or any tracking infrastructure
• Don't need a separate store, and the consistency between the stores remains
• Access patterns all remain the same
• Don't need the IDeadReckoningEnabled marker interface
• Condenses all the model classes down into the enum, or at worst a couple of stateless util classes

Thoughts solicited!

[met4000]

@timpokorny I like those suggestion on how to structure it. A few discussion points:

• There are times where some sim apps will want to ignore the algorithm that the PDU says it should use, and use one of their choosing

  • To support this, I'd add overloads of getDrWorldLocation(DeadReckoningAlgorithm,long) (and same for all the others) to let users just be explicit about the values they want returned

DrEntityStatePdu sounds like it's meant to be 'an entity but incorporating dead-reckoning information'. Keeping a DrEntityStatePdu associated with only one algorithm makes it more straightforward to do caching of results. EntityStateStore will likely still be storing EntityStatePdus internally anyways (edit: to get the largest benefits of caching, it should probably store DrEntityStatePdus, but the rest of the question is still valid), so instead of overloads of DrEntityStatePdu::getDrWorldLocation etc. with an alternate dead-reckoning algorithm, would it make sense to have DrEntityStatePdu EntityStateStore::getEntityState(EntityId) and DrEntityStatePdu EntityStateStore::getEntityStateWithAlgorithm(EntityId, DeadReckoningAlgorithm), adding an accessor to EntityStateStore that allows for an algorithm override?

Another point, although I'm not sure if we do anything about this; one advantage of having the dead-reckoning store separate from EntityStateStore is we can have different heartbeat timeouts for each (or even no timeouts for dead-reckoned entities). A dead-reckoned entity will usually have a slower heartbeat than a 'general' entity, so a timeout best suited for one is likely not suited for the other. It seems like we don't currently have mixed heartbeat rate support anyways, so maybe this is an issue we deal with at a time where that gets added, and we assume that the current rather long heartbeat timeout should work for both.

[timpokorny]

@met4000 - Personally, I would strive to keep DR at the entity-level. At least the base implementation. It means that an entity can always resolve its own DR values without the help of any additional infrastructure. That’s probably the core theme id push for here. Keep it all inside the entity. Thinking about it on the fly (like I do most things), one could argue that the functionality belongs inside EntityStatePdu itself. I like the idea of a class that extends EntityStatePdu because it becomes a place to encapsulate any members for caching or other optimizations that might be useful without polluting the core EntityStatePdu code, which is just for serialization/deserialization. Let’s chat tomorrow with a whiteboard quickly. Notes for me to refer to then so I don’t forget: - Maybe not a store, but a “resolver” or some such (part of my issue with the store is that it’s not really a store). Could just have a utility “DeadReckoner” with methods that you pass a PDU to, and get a Dead Reckoned version back. That’s not as neat as just having it all in the entity, but a possibility - Maybe DrEntityStatePdu should be the default version. Make it extend EntityStatePdu, but all the serializers just create the sub-type. Maybe pollutes the raw pdu layer a bit, but that may just be pedantic of me.

…

On Thursday, October 30, 2025, Nathan Townshend ***@***.***> wrote: *met4000* left a comment (openlvc/disco#94) <#94 (comment)> @timpokorny <https://github.com/timpokorny> I like those suggestion on how to structure it. A few discussion points: - There are times where some sim apps will want to ignore the algorithm that the PDU says it should use, and use one of their choosing - To support this, I'd add overloads of getDrWorldLocation( DeadReckoningAlgorithm,long) (and same for all the others) to let users just be explicit about the values they want returned DrEntityStatePdu sounds like it's meant to be 'an entity but incorporating dead-reckoning information'. Keeping a DrEntityStatePdu associated with only one algorithm makes it more straightforward to do caching of results. EntityStateStore will likely still be storing EntityStatePdus internally anyways, so instead of overloads of DrEntityStatePdu::getDrWorldLocation etc. with an alternate dead-reckoning algorithm, would it make sense to have DrEntityStatePdu EntityStateStore::getEntityState(EntityId) and DrEntityStatePdu EntityStateStore::getEntityStateWithAlgorithm(EntityId, DeadReckoningAlgorithm), adding an accessor to EntityStateStore that allows for an algorithm override? Another point, although I'm not sure if we do anything about this; one advantage of having the dead-reckoning store separate from EntityStateStore is we can have different heartbeat timeouts for each (or even no timeouts for dead-reckoned entities). A dead-reckoned entity will usually have a slower heartbeat than a 'general' entity, so a timeout best suited for one is likely not suited for the other. It seems like we don't currently have mixed heartbeat rate support anyways, so maybe this is an issue we deal with at a time where that gets added, and we assume that the current rather long heartbeat timeout should work for both. — Reply to this email directly, view it on GitHub <#94 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG6WULWOIT6TKT455TRU6L32FWK7AVCNFSM6AAAAACJ3IFHF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRVHAYTQMZWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[met4000]

I wasn't expecting more discussion to have happened so soon and did end up switching over to having it based on DrEntityStatePdu - still would be good to discuss these points tomorrow (e.g. how to 'override' the DR algorithm) and see what you think of this current implementation.

[met4000]

WIP/TODO from discussion:

• allow for overriding the algorithm when making dr request to DrEntityStatePdu (including caching alongside timestamp)
• error if the timestamp requested for dead-reckoning is in the past
• flag/config to disable dead-reckoning (make all algorithms behave like Static)
• body coordinate DR alg implementations
  • basic test for circular path (should return to original position)
• coordinate system handling
  • DeadReckoningAlgorithm support for testing what coordinate system an algorithm uses - new enum?
  • methods for switching DrmState between coordinate systems (static on DrmState?)
  • switch between coordinate systems if a DrEntityStatePdu algorithm override is of a different coordinate system

[met4000]

Not sure where application flags such as the one to disable dead-reckoning should be added - DiscoConfiguration as a Flag (description says Flags are 'PDU parsing/processing flags')? DiscoConfiguration as a system property? Some new config handler on DisApplication? Currently going with system property loaded into DiscoConfiguration.

[met4000]

... and we're back open for business. All DR Algorithms are now implemented, with rudimentary tests for RVW and RVB (the ones with 'all' features enabled, using world and body coordinates respectively). To perform dead-reckoning, instead of using DeadReckoningModelStore, EntityStateStore now gives DrEntityStatePdus. And dead reckoning can be disabled via disco.app.deadreckoning.enabled, causing the calculations to be skipped and things to behave as if static.

Might still need to shuffle some things around (open to suggestions on changing interfaces etc.), but this should at least be most of the functionality.

[met4000]

I'll still wait for Michael to give this a thorough look before merging, but @timpokorny interested to see if this new setup is in line with what you were thinking.

[timpokorny]

Some minor pieces to look at, but overall this is looking really good.

[met4000]

I've updated my IDE to catch more formatting issues. These new changes should (mostly) fix the line width and some other formatting issues I noticed, and also implement those other suggestions.

[met4000]

Some minor modifications; the recent commits have been renamed to make their naming consistent and clearer how they will be rebased in the previous commits. The latest commit has new formatting fixes and code tweaks to make Sonarqube happy(er).