Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dedupe ACMI strings #20

Open
nebriv opened this issue Dec 8, 2020 · 2 comments
Open

Dedupe ACMI strings #20

nebriv opened this issue Dec 8, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@nebriv
Copy link
Owner

nebriv commented Dec 8, 2020

Originally used ACMIStringOld function to diff the old string and new string to identify changed data. This was incredibly expensive. We need to find a cheaper alternative so we can avoid processing and writing unnecessary data.

@nebriv nebriv added the enhancement New feature or request label Dec 8, 2020
@TytanRock
Copy link
Contributor

This is primarily for stationary actors, correct? I think assigning every actor an ACMIDataEntry object that can be flagged as having changed position since last ACMIString call would be a relatively easy method to manage this. Then we can even increase performance by merely updating every actor's ACMIDataEntry instead of creating a whole new one.

@nebriv
Copy link
Owner Author

nebriv commented Dec 12, 2020

@TytanRock

Thats a start yeah. But essentially any unchanged data sent to Tacview once, doesn't need to be sent again. Originally I had a function that compared ACMI strings through reflection, it would great, but it was insanely expensive. I think theres a couple a solutions that should/could be implemented. If the actor is unchanged (hasn't moved/etc) we don't want to collect data for it at all. If the actor has moved, we STILL don't need to send data like IAS/TAS/AOA/AGL if it hasn't changed.

I don't know if its just faster to write the data out regardless. Obviously comparing each would be impactful - but is it cheaper than handling/writing out unnecessary data?

I think assigning the ACMIDataEntry object to the actor would probably be a way smarter way of going about this. It'd definitely require a bit of a rewrite though. (This mod could use a rewrite though, thats for sure...) Thats essentially how the MP mod works. HOWEVER by attaching ourselves directly to the game object - we might lose some flexibility with interacting with mods? Example MP mod deletes game objects, etc. If we work on a layer above that and work from each frame as a point in time we don't have to worry about it existing across frames...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants