$100 to anybody that can fix the PathShape resource (paid.)
by Sorin Daraban · in Jobs · 10/03/2012 (12:54 am) · 28 replies
Original job description: http://www.garagegames.com/community/forums/viewthread/131656
Possible fix discussions: http://www.garagegames.com/community/forums/viewthread/131477/2#comments
My e-mail: sorind1 AT hotmail.com.
Possible fix discussions: http://www.garagegames.com/community/forums/viewthread/131477/2#comments
My e-mail: sorind1 AT hotmail.com.
About the author
http://www.visitorsthegame.com
#23
02/19/2014 (11:38 am)
Just got tied up with some nastiness this end, so can't really personally verify this one, but: does the same occur with a physicszone? If so, it'll be deeper down. If not, that might be a decent guideline for how to handle that.
#24
Agreed that this could be a crucial resource, that should be part of the stock engine, but yes it needs to be brought up to date. A lot of it hasn't changed since the TGE days it seems.
For now at least it works, but would be overjoyed if somebody here can improve on it.
Like I said, if it gets fixed I'd be happy to write up the resource with instructions, etc, so all could make use of it. With big credit given to the fixer of course :)
P
02/19/2014 (11:39 am)
Love the sound of all these experts diving into this :)Agreed that this could be a crucial resource, that should be part of the stock engine, but yes it needs to be brought up to date. A lot of it hasn't changed since the TGE days it seems.
For now at least it works, but would be overjoyed if somebody here can improve on it.
Like I said, if it gets fixed I'd be happy to write up the resource with instructions, etc, so all could make use of it. With big credit given to the fixer of course :)
P
#25
Since it was so long ago the linked commit on the ticket is lost, but the suggested fix in the comments of the ticket was to use mathWrite in place of writeCompressionPoint Player::packUpdate. The reason for the issue was because the Player's position was sent with full accuracy when it is the control object as opposed to when it is not it would be sent as relative to the compression point with varying accuracy.
I'm not sure if that was what the fix ended up being, I'd have to dig down into the code for a while to see since the linked commit is gone. I would suggest starting in PathShape::packUpdate and try using mathWrite in place of writeCompressionPoint.
02/19/2014 (11:56 am)
This sounds like the PathShape resource was never updated to be compatible with T3D 1.2 retail and is reintroducing the jitter bug that was fixed in that version at least in relation to the Player. Prior to 1.2 the Player, and I believe Vehicles sometimes would jitter when not the control object.Since it was so long ago the linked commit on the ticket is lost, but the suggested fix in the comments of the ticket was to use mathWrite in place of writeCompressionPoint Player::packUpdate. The reason for the issue was because the Player's position was sent with full accuracy when it is the control object as opposed to when it is not it would be sent as relative to the compression point with varying accuracy.
I'm not sure if that was what the fix ended up being, I'd have to dig down into the code for a while to see since the linked commit is gone. I would suggest starting in PathShape::packUpdate and try using mathWrite in place of writeCompressionPoint.
#26
04/14/2014 (1:03 pm)
Well, for what it's worth for folks that come along later, I can confirm thatPoint3F pos;
getTransform().getColumn(3,&pos);
stream->writeCompressedPoint(pos);to Point3F pos;
getTransform().getColumn(3,&pos);
mathWrite(*stream, pos);andPoint3F pos,rot;
stream->readCompressedPoint(&pos);toPoint3F pos,rot;
mathRead(*stream,&pos);takes the edge off a bit. Still a bit of jitter on the pathshape itsself when connecting to a server on the same box, which doesn't seem to propagate to the player to nearly as high a degree.
#27
Now at least if my player is looking away from the shape in 1st person there will be next to no jitter, which is better, thanks!
But in 3rd person it's still crazy - the entire screen shakes and it only gets worse the faster you try to move the pathshape.
For example at speed 2 it's not bad, at speed 10 (which is where I want to be at in terms of flying platforms around over long distances) it's unbearable in 3rd person and in 1st person you can't look anywhere near your feet at the platform or your eyes will bug out lol :)
There has to be a better way to do moving platforms, wonder why nobody has ever figured it out for T3D.
Could we maybe use the flying vehicle class somehow, with a platform with mount points put on a path? I have a flying vehicle that hovers, for use in a space game, ie. with no gravity, so could that somehow be made to move along a path and I could hop on it to mount it, and achieve the same effect?
Then again, I guess that wouldn't be the same because you can't walk around the platform and stuff when you're mounted... bummer lol
Thanks again for posting that code snippet.
Cheers
P
04/26/2014 (9:21 am)
Thanks for that - tried it and you're right, it improves things a bit...Now at least if my player is looking away from the shape in 1st person there will be next to no jitter, which is better, thanks!
But in 3rd person it's still crazy - the entire screen shakes and it only gets worse the faster you try to move the pathshape.
For example at speed 2 it's not bad, at speed 10 (which is where I want to be at in terms of flying platforms around over long distances) it's unbearable in 3rd person and in 1st person you can't look anywhere near your feet at the platform or your eyes will bug out lol :)
There has to be a better way to do moving platforms, wonder why nobody has ever figured it out for T3D.
Could we maybe use the flying vehicle class somehow, with a platform with mount points put on a path? I have a flying vehicle that hovers, for use in a space game, ie. with no gravity, so could that somehow be made to move along a path and I could hop on it to mount it, and achieve the same effect?
Then again, I guess that wouldn't be the same because you can't walk around the platform and stuff when you're mounted... bummer lol
Thanks again for posting that code snippet.
Cheers
P
#28
04/26/2014 (1:05 pm)
Well, as far as it goes, if folks want to collaborate on that a bit, did go ahead and shove up a branch over github.com/Azaezel/Torque3D/tree/pathshape last night, with a few stepwise commits. Haven't made a whole lot of headway on resolving the connected client viewing an attached player end of things yet though.
Torque Owner Kenan Chabuk
Default Studio Name
Also shouldn't child objects update them-self based on their parent's movement instead of the parent forcing an update on the children? Static objects you wouldn't notice a difference but for the few movement objects (player, vehicles...) they need to update their own position otherwise it breaks their collision detection and network position extrapolation and interpolation (see player.cpp player::_move).
I'm wondering what others' thoughts are on this. This could be a very important resource, but it needs to be done correctly.