Hi, I am troubleshooting some strange behavior. Videos will explain a lot faster than words in this case:
Normal behavior in a small map:
Jittery behavior in 4kmx4km world when about 2km from the origin:
In the “large world”, which is a 4x4km terrain, when I get about 1.5km or more from the origin, the tools which can be moved via mouse start to jitter heavily. I thought I was well within the bounds to not have floating point errors, but perhaps because these actors are so small the issue is pronounced? For reference, the compass is about 12cm’s long.
I am exploring the world composition ability to shift the origin, but this is extremely complicated - if anybody can say that this might be some other issue I’d be happy to explore that before spending days trying to figure out world comp.
I’m in 4.26 by the way. I appreciate any help, thanks.
And additional question, if this is a problem for origin shifting to fix, how can i reduce the max world size which the world comp origin shift feature looks too? It is many times larger than my level, so I would need to reduce it in order to make the origin shifting happen sooner.
(i’m not a programmer, I am doing everything with blueprints.)
Pretty sure you’re right about the precision error and there’s a way to rebase the world but I’m not sure of the details. You should be able to find out how with some googling
Implementing the origin shift is possible somewhat easily with world comp, however it seems to have a hardcoded number at which it shifts at. I need to do it much sooner I think. So I am trying to discover how I can change that number.
unfortunately scaling them up isn’t making enough of a difference. if it was purely cosmetic i could live with it but this does effect ability to perform important gameplay task.
i am searching the api but I can’t find where to access this “MAX_WORLD” value. I think that if I can just make that number smaller, world comp will make origin shift happen sooner, which would solve the problem.
I have been doing blueprints for about three weeks now, with no prior coding experience. I can share the blueprints of how these are working, but I have no idea what you are asking
Here is the code for dragging actors with the mouse, this lives with the player character:
That is the that longer bit of code in the first screenshot. It’s just a mouse trace, looks for a custom trace channel, also has an offset so that center of the mesh doesn’t jump to point of hit. Then it sets actor location to mouse position. It’s the same for all tools, this code is run from the character.
Just a report about changing the MAX WORLD SIZE in the EngineDefines.h file: Didn’t seem to change anything… however I am not really sure what I am doing with world comp.
The size of the yellow extent did not seem to get any smaller. I think I’d need to get a programmers help though to really know.
It may be simpler to roll a custom world origin shift, rather than use the world composition tools, but there again I got to get programmer help.
I am not sure moving to a beta engine version is advisable. I can probably finish this project before it’s out of a beta.
I am not sure it’s wise to move to a beta version, especially since I will be ready to publish this game in several months…
I will take a day to move the project to UE5 though just to test. I guess if I can successfully build it should be okay? I kind of don’t want to open that can of worms though.
Rendering from a different camera is an option I would choose second to just living with some jitter at the edge of the maps. For multiple reasons it just isn’t going to be a good fit with the game design.
It seems too simple almost, but it’s working. I don’t see any problems, everything is staying in place like it should be… obviously i replace the key press with like a trigger sending an event later, but this basically seems to jsut work.
Lol, I was just about to post that. However, you’re doing the location wrong. You need to make sure to transform the character’s location back into the “true” location by adding the player’s location to the world origin. This way, when the world origin shifts, the player will always be at the origin (your character’s location should always be “0.x”). Make sure to add them as int vectors, not regular vectors, so that floats aren’t used.
From experience.
You guys are barking up the wrong tree.
Yes, the issue IS world origin.
Yes, you can change it and thus “solve” the issue.
But the better solution is Math.
Simply allowing the drag to move in full floats would probably be enough.
Also, Simply get the compass working on a 0 to 360 integer (if the needle is twitching).
And get your location solver to compute the proper integer for the job.
At that point distance from origin will probably never matter.
also from experience.
Make yourself a “north” blueprint that the compass detects the position of and points towards.
Otherwise you keep having to adjust things in different maps and it gets to be a pita.
Would be nice to see how you are setting the compass variable currently to be able to help.
However keep what I said in mind.
A degree value is a degree value. There needs to be no floating point issues on it at all.
For dragging it around like the video, sticking to integers would probably also help.
Last but not least, you can always store the full value of the location as a string.
Usually you do that when dealing with custom double cpp to BP as well.
It’s not practical, but if you really need to allow for .00000001 to work, the best “avaliable” way is to use text and not perform any math.
(Truncate, separate what’s tossed from what’s usable. Do the math. put what was tossed back).
Potentially, multiply what was tossed by 1000 or so, and do the math on it separately. (Better accuracy then tossing it)
Another edit.
Looking at the bit of code you did share. I would blame the hit result.
Sanitize that value before obtaining your offset. And it might just stop flickering about.
Hi thanks for the detailed reply. Unfortunately I am very new to this and only have art game dev experience, not coding, so most of this is over my head.
There is no problem with the dial jittering, but the way it is rotated is that it simply sets the local rotation to a constant rotation of 0. In other words, it always points to X+. I didn’t want to point to an actor because that seemed like it could allow a possibility for errors, whereas a constant value would always be the same.
About changing the hit location into integers, or “sanitizing” the value, can you explain or show an example of that?
I’ll post this here as the answer because it is testing out okay so far. Same thing as midgunner I just didn’t condense the addition operation, so other noobs can see how this is working:
I think a good way to implement this would be to do a check every 10 minutes or so, and if player is above a certain threshold in distance from origin, go ahead and reset. In my case I think that will be safe because the max straight line distance player can travel in 10 minutes wouldn’t be more than 2km’s (and in normal gameplay they’d never be going straight line that long)
Thanks for the help team! I was pretty bummed about this yesterday. Solved in half a day with some help, not bad!
