NTai XE10.1b
Moderators: hoijui, Moderators
Hello,
I have compiled current (rev 4214) svn source of NTAI for linux. You can get it here: spring.unknown-files.net/file/3469/NTAI_-_linux_build/
Please note that I haven't done any play testing other than verifying correct startup.
I had to edit 4 lines of code to get it to compile. I'll drop you a pm about that AF.
I have compiled current (rev 4214) svn source of NTAI for linux. You can get it here: spring.unknown-files.net/file/3469/NTAI_-_linux_build/
Please note that I haven't done any play testing other than verifying correct startup.
I had to edit 4 lines of code to get it to compile. I'll drop you a pm about that AF.
Well, I assume http://spring.unknown-files.net/file/34 ... e-release/ is the lastest. I'm running Kernel Panic 1.5 "Easy Script", but without actually playing, so it's basically 2 AI vs 2 AI. At 3mins I start feeling some jolts, at first they're short and spaced so it's still playable, but progressively they last longer and longer and become closer and closer, and after 10mins, it has become utterly unplayable, it becomes a struggle to even select units with still frames so spaced out. I have an Athlon 64 X2 Dual Core 4200+, so my computer shouldn't be the problem.AF wrote:You didnt tell me wether my newest builds still lagged or follow up on anything zwzsg.
What saddens me most is that before, NTai worked very well. The version of NTai that I had included with KP1.3 did the job right, without creating massive lag, I could play play games with multiple AI up to their ends. But I can't use it anymore because it's for Spring74b3. And so far, all version of NTai for Spring75b2 I could find had that lag issue making them pretty unusable. Couldn't you just take your old code and compile it for Spring75b2?
- 1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
actually your response was
If i remember rightly we were having slow down issues caused by the unti move failed problem (hence why you implemented the retreat work around). I think that only alleviates the problem. I have found through alot of testing that the engine slows down because these retreated units get stuck in the base causing path finding problems. I have even proved this to a degree by playing on the same team as NTai and moving the units away from the base and noticing that the simulation speeds back up again. I've suggested to people to add more base positions to alliviate the issue but I think with the work around i've suggested there wouldn't be a problem any longer, if indeed it is three lines of code to implement i think it would be worth trying. Hopefully i'll get a build environment working tonight and get a chance to test it myself but if you did feel like doing a release with it in for me to test...
which for me is a far better solution than the untis retreating the base and never moving again, although as I said at the time its still a big hack.possibly,
G->UnitDestroyed(unit);
G->UnitCreated(unit);
G->UnitFinished(unit);
It would be asigned to a new attack group tho so ti may just sit there for while untill the new group fills up.
If i remember rightly we were having slow down issues caused by the unti move failed problem (hence why you implemented the retreat work around). I think that only alleviates the problem. I have found through alot of testing that the engine slows down because these retreated units get stuck in the base causing path finding problems. I have even proved this to a degree by playing on the same team as NTai and moving the units away from the base and noticing that the simulation speeds back up again. I've suggested to people to add more base positions to alliviate the issue but I think with the work around i've suggested there wouldn't be a problem any longer, if indeed it is three lines of code to implement i think it would be worth trying. Hopefully i'll get a build environment working tonight and get a chance to test it myself but if you did feel like doing a release with it in for me to test...

That casted some doubt in me. Could it be that it's the new version of Spring that is to blame for lag and stutter, and not NTai? But I got a couple online KP game tonight, and even when the whole map was covered with bit-pumping sockets and my unit count numbered in the 470's, all moving and pathing, the game stayed fluid.AF wrote:test show that 9% of the cpu load when it get unplayable is NTai. 60-80% is the simulation.
No you couldn't, Netbeans + C++ pack cannot debug dlls and so's only full programs, so you'd have to integrate NTai into spring to eb able to debug it that way.
Im going to have to put up another codeblocks project, only codeblocks too wont let me do the same thing, it wont even let me set the options as a checkbox hich reverts to checked everytime I close the dialog, and Im not even sure thats what I need sorting out =(
And VS2005 gives some rubbish about ELF even though I compiled Spring and NTai using VS2005 and the same sources ='(
Im going to have to put up another codeblocks project, only codeblocks too wont let me do the same thing, it wont even let me set the options as a checkbox hich reverts to checked everytime I close the dialog, and Im not even sure thats what I need sorting out =(
And VS2005 gives some rubbish about ELF even though I compiled Spring and NTai using VS2005 and the same sources ='(
I have no idea what's going on with VS2005 at all my VS build of spring seems to play fine but try run it with the VS version of NTai and boom. I suspect its something to do with compiling spring as release with error catching and ntai as release but really i'm just shooting in the dark. As for debug that was just hopeless I got an assertion error the moment I started.
Right now i'd just be happy to be able to compile some code changes, I don't really mind not having a step through debugger. Sure finding the crash bug won't be easy but it'll be a damn sight easier if I have the code and can change it.
Can you still not run a full game with the AI? Trying to develop something you can't even run can't be the best way to go about it!
Right now i'd just be happy to be able to compile some code changes, I don't really mind not having a step through debugger. Sure finding the crash bug won't be easy but it'll be a damn sight easier if I have the code and can change it.
Can you still not run a full game with the AI? Trying to develop something you can't even run can't be the best way to go about it!