AIPlayer Spinning[Solved]

Expanding and utilizing the engine via C++.
22 posts Page 1 of 3
TorqueFan
Posts: 130
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Thu Dec 12, 2019 3:52 am
Hi all. I'm nearing an alpha stage on a game I've been working on but there is one looming bug that just continues to elude me. This particular bug has popped up from time to time for the past at least 10 years in Torque history, and it still(apparently) exists. I was hoping some of the hard hitters around here might be able to help with squashing this guy once and for all.

The Goal
Alright, so first what I'm trying to do. I want the mouse cursor visible on the screen and the AIPlayer to follow it. I have this currently working, check!

The Problem
Stock Torque3D 3.10.1 with default Soldier model and datablock:

The bug arises randomly where moving the mouse will result in the AIPlayer's forward vector 'spinning' visually. If the mouse cursor is still, the AIPlayer runs along to it just as it should because there is no rotation being calculated for the AIPlayer. As soon as the mouse cursor deviates from it's straight ahead forward vector course, something causes the AIPlayer to visually 'twitch' or 'spin'. As soon as the rotation is complete and the AIPlayer is once again following a straight ahead path to the cursor, all is well.

This is all intermittent, as in it occurs sometimes and sometimes it does not. I have noticed that when this happens there is a visual 'hitch'(similar to what you'd see when a new material appears for the first time in a scene) and immediately the rotation is whack. It will remain in this 'state' of visual ugliness until I hit the space bar to make the AIPlayer stop. Once the AIPlayer starts moving again by the space bar toggle, the rotation is working fine again until it decides once again it is time to fail.

This occurs whether I am calling a schedule to move the AIPlayer or if I only call the movement command 'per click'.

Sources
Here are some examples of how this problem has been around and continues to be around since(probably) Torque's conception:

Bare in mind the old GG site is throwing up certificate errors for awhile now on some of their old forum posts.

From 2005: Here the problem seems to have been caused by the 'Eye' node in the player art.
http://www.garagegames.com/community/fo ... read/34046

From 2010: Not sure if it's helpful but this is an early case of the problem. It does seem similar to what I'm seeing now.
https://www.garagegames.com/community/f ... ead/122291

From 2011: (In this case the bug 'disappeared' yet a fix was never found.)
https://www.garagegames.com/community/f ... ead/124932

From 2011:This one is particularly interesting since it's marked as resolved yet I have implemented the code here to try to fix it and it doesn't fix it today.
http://www.garagegames.com/community/fo ... ead/123597

From 2011: This is a resource that was made by @ GuyA . I did implement this to try it, and it still works to this day but sadly doesn't stop the 'jitter'.
http://www.garagegames.com/community/re ... view/21188

From 2013: This one is by @ Nils
http://www.garagegames.com/community/fo ... ead/133374

As you can see this has occurred as far back as 2005. Of course, we all have our own implementations and what have you but this can be replicated with current Torque3D 3.10.1 without altering any code. Just make an overhead cam, spawn an AIPlayer, set the camera to orbit that player, and hook in some standard raycast code to tell the AIPlayer where to go. The problem will show itself eventually. I can provide any and all scripts if necessary :geek:
Last edited by TorqueFan on Fri Dec 27, 2019 8:00 am, edited 1 time in total.
Duion
Posts: 1626
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Thu Dec 12, 2019 11:07 am
In the world editor you can spawn an AI test player and have him move around by clicking where he should go, that works just fine, what is so different in your implementation?

My AI players also do not spin, some rare occasion where I had them spin is when the point they were walking to was very high or very low from their position, seems like they don't like vertical so much.

Do you use the NavMesh for navigation or do you just send them blind?

PS: A video of them spinning would be helpful or at least funny.
TorqueFan
Posts: 130
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Thu Dec 12, 2019 1:03 pm
In the world editor you can spawn an AI test player and have him move around by clicking where he should go, that works just fine, what is so different in your implementation?
Actually not much at all. As a matter of fact, I directly copied Daniel Buckmaster's code from his NavEditor to replicate his exact method of movement through the source code via a custom GuiControl in an attempt to eliminate the problem. It still persisted.
Do you use the NavMesh for navigation or do you just send them blind?
This is on a built NavMesh that does test properly in the NavEditor.
PS: A video of them spinning would be helpful or at least funny.
Perhaps one of the only statements you've ever made on these forums I agree with...

This issue has cropped up for experienced dev teams and renowned T3D developers for as long as I've used this engine. It is most certainly a closet case scenario that occurs infrequently only under certain conditions. What I am attempting to find, in the name of science, is the true underlying issue. Blanket statements like, "My AIPlayers work" aren't helpful in ultimately tracking this down. It is obviously in my implementation - but simply pointing a finger at it and calling it names likely won't make it go away.

Anyhow, moving forward, upon closer inspection of the movement code...the math does seem to point to a vector being rotated by extremely precise(i.e. 2PI) floating point numbers...or imprecise depending how you look at it lol. This is almost certainly the culprit, and I have to question why this was used in favor of a matrix rotation. Given a bit more time on the issue, it's more likely than not I'll end up scrapping all of that and just rewriting the rotation to suit. The problem with that is, no one else will know how I did it and the problem will remain unresolved in the future for other users of the engine. I am a strong supporter of sharing solutions around things like this, hence the entire 'open-source' engine idea in the first place. That's why I'm here on the boards with the issue providing sources for the problem and attempting to solve this as a community. It's this type of response that discourages 'community'.

TLDR - If you don't have something helpful to contribute, why speak up at all?
Duion
Posts: 1626
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Thu Dec 12, 2019 1:28 pm
TLDR - If you don't have something helpful to contribute, why speak up at all?
Because I'm curious, I never saw this issue, so I wanted to see it.
TorqueFan
Posts: 130
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Thu Dec 12, 2019 1:58 pm
My AI players also do not spin, some rare occasion where I had them spin is when the point they were walking to was very high or very low from their position, seems like they don't like vertical so much.
Because I'm curious, I never saw this issue, so I wanted to see it.
You have somehow managed to contradict yourself in the scope of two posts. Just mark this as solved, I'd rather just keep pecking at this and solving it on my own. I'm hot on the heels of it now anyway.
marauder2k9
Posts: 418
Joined: Wed Feb 18, 2015 7:36 am
by marauder2k9 » Thu Dec 12, 2019 2:17 pm
are you sanitizing your ray cast? It seems like the ray is still being cast after the mouse press or at least still being received by the aiplayer, check out richards rts tutorial series, moving ai position with mouse clicks is covered quite extensively in his tutorial series.

i think this is the link but i thought there was a later version somewhere

http://docs.garagegames.com/torque-3d/o ... otype.html
Bloodknight
Posts: 307
Joined: Tue Feb 03, 2015 8:58 pm
by Bloodknight » Thu Dec 12, 2019 10:14 pm
you did make it sound like it was constantly chasing the mouse which would likely cause confusion, but if its click to move there was a sort of fix some time ago that involved some form of deceleration at a certain distance from the destination point. Another alternative is to add a 'dead-zone' to the algorithm so that very near destination is ignored.
TorqueFan
Posts: 130
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Fri Dec 13, 2019 1:16 am
Allow me to contradict myself in the scope of two posts as well. The truth is I don't want to solve this on my own because I likely won't and one bad apple shouldn't spoil the bunch. That being said, @
User avatar
Duion
did actually ask some valid questions. It doesn't stop me from equipping my Trollslayer +2 greatsword when I respond to his posts, but I'd hope we have a mutual understanding at this point. I acknowledge that I do have a tendency to proclaim things as fact prior to them being proven as such, and that just doesn't mix well with troubleshooting. I know that there are many minds far brighter than my own that have been doing amazing things with this amazing engine and I don't want that to be discredited by all of this being cast in a negative light.

With that all out of the way, I am going to need to post up some specific steps here for this issue to be replicated. Maybe try to get a Journal of the whole thing going on and post that as well. Maybe then it could be possible that community troubleshooting can actually occur. I mean, I am on here seeking guidance in the first place and I can't expect everyone to just write out all the scripts and what-not. I'll follow up here when I go through all the motions once again on a fresh build of 3.10.1.
TorqueFan
Posts: 130
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Fri Dec 13, 2019 6:12 am
Alright, I have managed to isolate this issue and reproduce it 100% of the time. Here is the relevant information:

After Respawning The Bug Is Gone
I noticed that if the AIPlayer dies, once it respawns the issue never appears again. I'm reading this as, "the respawn code is good, the initial load in spawn might not be". So I went through all of the initial spawn code with a fine-toothed comb and it actually mirrors the respawn code fairly accurately aside from the normal initialization of the new client stuff.

Only Occurs When Load-in Hitch Happens While AIPlayer is Rotating
So what I've noticed is this will ONLY occur within the first 5-10 seconds of a new game. We all know that Torque will hitch visibly when new objects or materials or what-not are loaded in for the first time. Basically what I'm observing here is a single hitch within that first 5-10 seconds, and within that tiny frame of time it's enough to bork the interpolation of the AIPlayer rotation.

Edited to add: Actually once that initial AIPlayer has been corrupted, it can potentially spin again even after stopping movement and resuming movement. Stopping will temporarily resolve it, but it will occur if instigated by things like impulses etc...UNTIL a respawn. After that, boom, no problems the bug disappears.

Here is why it's so hard for others to notice it and it's not evident in the NavEditor, or at least my hypothesis. If you click only, the AIPlayer generally is just going to walk forward with no rotation happening. Hence the AIPlayer is not attempting to calculate that yaw at the precise moment the initial load hitch occurs. However, if you click off to the right side of the screen and then click off to the left in quick succession...and the AIPlayer happens to be rotating to turn around at the precise moment an intial load hitch occurs...this can still happen when just directing the AIPlayer by way of a click. Additionally, if you are within the editor and working with the NavEditor gui, by that time all of the intial load hitching has already happened.

What Next?
So I'm not entirely sure what to do in order to combat this. I remember an old datablock preloading resource; I wasn't certain if that might help to alleviate the hitching but I doubt it. As far as I can remember, Torque has always had those little hitches when loading stuff in for the first time and I believe up-front datablock loading is just cutting back on load times for the level.

I had the notion of perhaps running a separate thread to handle the passing of 'AiMove' commands to the server, but I hadn't the slightest idea on how to get that rolling in Torque. I mean, the movement script is straightforward as it could be - Every 30ms or so grab the position under the cursor and send it to the server like so:
schedule(30, commandToServer('AiMove', %xyz)); // I have tested this schedule speed as slow as 500ms and same result
The move code feels solid, always smooth after respawning. I'm not entirely sure if this is an initial ControlObject issue or AIPlayer rotation...The initial ControlObject is the camera, and it remains that way during runtime.

Any suggestions are welcomed. I'm still open to posting up some scripts but tbh with the understanding of how/when it occurs it should be fairly easy to replicate.
Duion
Posts: 1626
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Fri Dec 13, 2019 12:21 pm
Why don't you use the respawn function also for the initial spawn? I only have one respawn function that is used for everything, anything else would not make sense in my case anyway.
22 posts Page 1 of 3

Who is online

Users browsing this forum: No registered users and 1 guest