Page 71 of 95
Posted: 19 Aug 2007, 14:00
by koshi
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.
Posted: 20 Aug 2007, 00:36
by AF
What 4 lines have changed
Posted: 20 Aug 2007, 01:31
by koshi
As you suggested I have started a new thread for this: spring.clan-sy.com/phpbb/viewtopic.php?t=11609
Posted: 20 Aug 2007, 02:11
by zwzsg
AF wrote:You didnt tell me wether my newest builds still lagged or follow up on anything zwzsg.
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.
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?
Posted: 20 Aug 2007, 12:06
by 1v0ry_k1ng
the version with KP lagged just as much as the version previous to this one iirc
Posted: 20 Aug 2007, 12:29
by AF
test show that 9% of the cpu load when it get unplayable is NTai. 60-80% is the simulation.
Posted: 20 Aug 2007, 13:03
by DJ
yes the CPU usage of NTai is improved but it is still executing a command that causes massive slowdowns to the simulation. Did you try changing the retreat order upon move failed to a re-initialization of the unit like I suggested?
Posted: 20 Aug 2007, 14:42
by AF
No, IIRC I pointed out flaws in that problem.
Theres no logical reason I can think of that would cause retreating to do that especially when the problem suddenly appeared one day in a new version in code that hadnt changed for a problem that persisted once the code had been changed afterwards
Posted: 20 Aug 2007, 14:51
by DJ
actually your response was
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.
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.
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...

Posted: 20 Aug 2007, 20:32
by url_00
OT: 71 pages!?!?!
Is this STILL a pre release?!?
Posted: 20 Aug 2007, 20:58
by AF
people keep finding faults and flaws
Posted: 21 Aug 2007, 06:02
by zwzsg
AF wrote:test show that 9% of the cpu load when it get unplayable is NTai. 60-80% is the simulation.
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.
Posted: 21 Aug 2007, 10:49
by DJ
I had absolutely no joy in trying to setup a dev environment last night. Got spring built OK but if i try and run it with a compiled NTai it just boms out before the message "arrays filled" any ideas?
Edit: In fact f*ck it, I should have used netbeans anyway...
Posted: 21 Aug 2007, 13:38
by AF
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 ='(
Posted: 21 Aug 2007, 13:47
by DJ
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!
Posted: 21 Aug 2007, 13:54
by AF
I get TDR crashes anywhere between instant as soon as the game starts and 40 minutes in.
Posted: 22 Aug 2007, 14:53
by DJ
Been trying to get this to build with MinGW but it seems like the makefile is incompatible with mingw-make. I get an error about .validate-impl.
I'm a total noob at this, how do you build the svn version with MinGW?
Posted: 22 Aug 2007, 14:57
by imbaczek
I got it to build and submitted a patch that worked for me in svn - but you need msys for it to work. You'll find it on mingw.org.
Anyway, I'll prepare a debug build soonish (wonder if it'll work on a different machine...) and maybe profile with KP as was suggested elsewhere.
Posted: 22 Aug 2007, 15:03
by DJ
thanks I'll try downloading msys.
Posted: 22 Aug 2007, 16:25
by AF
I just use a codeblocks nightly build, its much better than the rubbish official release thats not been updated in ages.
And that make file was generated by netbeans. Netbeans 5.5+the c++ pack should be able to open and compile the project.