Trying to Compile Engine Changes(TAIK) using Linux

Expanding and utilizing the engine via C++.
33 posts Page 3 of 4
Jason Campbell
Posts: 182
Joined: Fri Feb 13, 2015 2:51 am
 
by Jason Campbell » Sat Mar 18, 2017 3:40 am
I've figured out the gdb debugger a little more and have been able to examine the backtrace frame by frame,, so I can find the exact line that caused the errors. Unfortunately, examining the local variables doesn't help much and every time I stop one, another pops up. Another thing, that -1/64 6 bit Fatal was not an Int, it was a Float name mRot, some sort of rotation calculation. After examining it, I realized that there was no real way to find out how it got to a -1 value. I used a real cheap method of catching it before it was written and checking if it was a negative number and if so, making it zero. I have no idea if that would make it worse? Also if it is a float, shouldn't it be -1.0? My c++ knowledge is limited.

Strangely the actual AI is getting better as I figure out more, it seems to be better then the original Windows 3.5 version I had compiled without errors, subtle things. Makes me think that I had errors in that version that I didn't even know about.

I've come so far, there is no way I'm giving up but it seems like a terrible game of wack-a-mole that never ends.

I have another question. In your experience can TorqueScript errors throw an error into the c++ code? Reason I'm asking is, I'm concentrating so much on the source code but may be making it worse. Some of the TS errors may be caused by conflicts in the source code, I'm guessing, but should I attempt to remove all errors from the console then work on the source code?

Thanks again.
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Sat Mar 18, 2017 4:06 am
https://github.com/GarageGames/Torque3D ... #L337-L347 first and last lines are why shoving a TS float value can trigger that. prolly does help verifiably isolate that down to a readFloat(&foo,6) in a packupdate or packdata then. fars TS errors goes, you'll recall that a .cs file will attempt to execute up to the point it hits a compilation flaw and stop there, so... pooooosssibly?

With more data, sounds like I'd eyeball
https://github.com/GarageGames/Torque3D ... 6225-L6227
+
https://github.com/GarageGames/Torque3D ... 6330-L6332
Jason Campbell
Posts: 182
Joined: Fri Feb 13, 2015 2:51 am
 
by Jason Campbell » Sun Mar 19, 2017 5:17 am
Well, you are right about the lines making the problem. It was this line, and it was a 7bit not the 6bit I talked about:
https://github.com/GarageGames/Torque3D/blob/7185d9664d7ee8c0469014acce9caad6d1380ea2/Engine/source/T3D/player.cpp#L6225

I don't understand really how to fix it.

I wrote this stupid bit of code into it and it stopped the Fatal but honestly it can't be good.
if ((mRot.z / M_2PI_F) < 0)
{
mRot.z = 0;
}
if ((mRot.z / M_2PI_F) >= 0)
{
stream->writeFloat(mRot.z / M_2PI_F, 7);
}


My newest error is being kicked off the server with a window telling me I don't have Full or access to some assets, I will write it down next time.

I was wondering could this cause a problem, since Float isn't defined?
https://github.com/GarageGames/Torque3D/blob/7185d9664d7ee8c0469014acce9caad6d1380ea2/Engine/source/T3D/player.cpp#L6080

Thanks again Az
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Sun Mar 19, 2017 5:45 am
Ok. so. Cliffsnotes on write, writefloat, writePacketData, and packUpdate

1)write/read packetdata or pack/unpack update, (or, to be thorough pack/unpack Data are paired methods. meaning if it goes in in one form in one order in a write, it needs to come out in the exact same order, and in the exact same form in a read. Mismatching can lead to leakage, since it's literally decoding bits. (so if for instance you had write{bool a, float b} and read{float b, bool a}, you'd actually be getting the true/false tacked on to float b and it's last bit thrown over to bool a in the read. common cause of 'hey this data went corrupt' aka 'These Aren't The Datablocks You're Looking For'}

2) in order of frequency run:
A) packData/unpackData: done once on loading a mission. these are your datablock setters/getters.
B) writePacketData/readPacketData: sent to every client in scope (scope gets a bit complex for a quick primer, so we'll skip that)
C) packUpdate/unpackUpdate: sent to a given controlled client alone. So stuff like personal energy level. (forget offhand if that's set to update at a higher rate than the PacketData pair.

3)straight write() / read() calls use the full 32 bits in a float. (Basically uses a sizeof() lookup) while writefloat lets you specify the size you're using in a lossy manner. why it's generally a Bad Thing to go lower than 6ish, and can conversely add up pretty bad if you just run with 32s.

That help any?
Jason Campbell
Posts: 182
Joined: Fri Feb 13, 2015 2:51 am
 
by Jason Campbell » Tue Mar 21, 2017 4:24 am
Thank you for the primer Azaezel,

edit: Thought I had it, I was wrong.

Just a note: Any Linux user who needs to merge code, Meld is a Godsend. I can't believe the ease of it and what ever formula they use to figure where code goes, is amazing.
Jason Campbell
Posts: 182
Joined: Fri Feb 13, 2015 2:51 am
 
by Jason Campbell » Tue Mar 21, 2017 6:36 am
Ok this seems to work so far but is this a bad idea?

I noticed this in some of the rotation calculations
// Constrain the range of mRot.z
while (mRot.z < 0.0f)
mRot.z += M_2PI_F;
while (mRot.z > M_2PI_F)
mRot.z -= M_2PI_F;


So I figured it wasn't making it to the writeFloat.

Is this a stupid idea, I placed it right before the writeFloat like so...

// // constrain the range of mRot.z
while (mRot.z < 0.0f)
mRot.z += M_2PI_F;
while (mRot.z > M_2PI_F)
mRot.z -= M_2PI_F;
stream->writeFloat(mRot.z / M_2PI_F, 7);


Seems to work without throwing all those other errors...so far.

Thanks
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Mar 21, 2017 6:45 am
yeah, that'd be the generally accepted pre-compression step. just remember on the out end to re-multiply it by that same M_2PI_F. https://github.com/GarageGames/Torque3D/pull/1358/files uses the same principle.
Jason Campbell
Posts: 182
Joined: Fri Feb 13, 2015 2:51 am
 
by Jason Campbell » Tue Mar 21, 2017 7:28 am
I was excited for a second. I think I understand what you are saying.

I didn't apply the division, that was already there, I just re-applied the constraint right before the writeFloat. Should I endeavor to find out why that constraint isn't making it to where (mRot.z / M_2PI_F) is being written?

It was here

https://github.com/GarageGames/Torque3D/blob/7185d9664d7ee8c0469014acce9caad6d1380ea2/Engine/source/T3D/player.cpp#L2625-L2629

and here

https://github.com/GarageGames/Torque3D/blob/7185d9664d7ee8c0469014acce9caad6d1380ea2/Engine/source/T3D/player.cpp#L2705-L2709
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Mar 21, 2017 7:32 am
See what you're saying... It'd likely be a good idea to track it further if time allows most likely, given that if you're introducing the rotation clamp in the pack/unpack, 10-1 on the server end it aint in a proper range to begin with...
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Mar 21, 2017 7:38 am
Waaaaitaminute....
stream->writeFloat(mRot.z / M_2PI_F, 7);?
not
stream->writeSignedFloat(mRot.z / M_2PI_F, 7); ?
33 posts Page 3 of 4

Who is online

Users browsing this forum: No registered users and 1 guest