Trouble comparing precision values over ticks

I have a script that sets the skysphere sun based on latitude and longitude which are both pre-set floats.

I’d like to add how far the player moves from 0,0,z to latitude and longitude, I started with latitude (+/- x)

I was at best able to get it to go to 0.000000+/-1 but any attempts to try to re-add in the original value failed.

How might I take a value, wait a tick, compare it to itself last frame, then add or remove a value based on whether it was higher or lower. Were talking at least 5 digits of precision here.

Currently im setting variable latitude to a variable called lastLastFrame on beginPlay and then on tick compareFloat latitude vs latlastframe and if higher set latitude to itself + the new different then set latlastframe to latitude and the same for if lower just subtracting but i end up just setting latitude and latlastframe to the same value.

How can I compare between ticks. This seems like a very easy programming issue but I cant seem to blueprint it.

My setup http://i.imgur.com/UUhCMO2.png

Use higher float precision? Or setting up level streaming to get more precise return values?

If the source wasnt running into precision errors, id suggest an (expensive resource-wise) two step conversion of double float to 2 floats programatically. each frame (gasps).

Seems ineffecient though.

Hey! I think that division should be with 111e5 or 1.11e7 instead of 111e7. A km is 10e5 cm…

Its not a precison issue its an issue of how to save the original value one frame and then compare the vector.x difference between the actor at 0,0,0 and my player the next frame then add the difference to the original value.

This is quite messed code, i would say Cthulhu or spaghetti monster. You should clean it, split into modules/functions, test step by step. Else you are facing major cursing and scratching head in few weeks when you return to this code to add some tiny feature.

For eg in begin play second pin of first sequence node, that delay there, its leftover of something you do not use anymore.
Then that branch and gate for update time of day, cleaner would be just check if skydome is valid on event tick.

you are also dividing on per tick base, distance than pawn made during last frame by very big number. I think it will be 10-100 units divided by 1110000000.

Instead of tick, get GAME delta seconds, do all calculations every second. You really do not need to recalculate sun position every tick.
You are probably out of precision range for float.

Unless you are making some stronomical simulation application you do not need that accurate timing. Yes for submarine simulation accurate calculations can be a must, but you do not need them so precisely timed. Some slower update like 1sec or even 1 minute could be just fine.

and watch this: https://www.youtube.com/watch?v=PZRI1IfStY0

Ps. really use game time in seconds instead of delta seconds. Game time seconds gives you that time, it can be slowed down or accelerated, and at some point you will add time compression.

Normally my BPs are very clean I have keybinds to the new 4.10 node alignment functionality. I never thought of using game delta seconds… I usually preach that too because it makes things FPS independant. Will play with it more today and see what I get. I had a solution at one point that worked just fine except when I moved it changed my latitude to 0.000001 or -0.000001 going up or down depending on the direction I couldht add in the original latitude value in any way.

I tried functionizing some things but this was obviously just trying to get something working first. Thanks for the advice will play with game time.deltaS

I think I got it it increases when I move north and decreases when I move south in a boat or on my person. Its a start.

Unless theres any glaring errors anyone sees gonna try longitude now.