NTai XE10.1b
Moderators: hoijui, Moderators
has anybody had any success getting a debugging version of this running yet. I still have a crash bug that i just can't pin down. I even enabled the full logging to see if that revealed the problem but it gave me nothing.
I have tried everything I can think of to track this bug down. The only other thing i can think of is to find out how the stack trace translator references spring code and see if we can't create a version that recognizes NTai code...
I have tried everything I can think of to track this bug down. The only other thing i can think of is to find out how the stack trace translator references spring code and see if we can't create a version that recognizes NTai code...
http://rapidshare.com/files/54684776/NTai.rar.html
Test that build and if all is good Ill start asking for config files for an installer.
Test that build and if all is good Ill start asking for config files for an installer.
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
it works fine with XTA/BA from what i can see (except the old old issue of attack groups retreating randomly and then never being used to attack). it still plays up with s44 though, not sure why yet. it dosnt like using builders as attackers, and it dosnt like using s44 infantry at all. it causes epic lag in s44, maybe somthing related to that. i called it a lost cause and gave up making the config
The odd thing is I found the cause and fixed it yet you reported there was no change of any kind, and now the list of issues appears to have grown.
If anything this build should be faster than the previous build I sent you as little much changed, and the most notable change was that threat matrixes depreciate every 10 seconds now rather than every second which should be an improvement.
What's more can we be very clear what the retreating business is? Are the units retreating and then not doing anything or are they being given an attack order at home rather than at the enemy then moving home in an attack move order (not a retreat move order). Use .verbose to look for attack markers, if your not using .verbose then I'll have to come to the conclusion that there isn't enough information to define what the bug is nm fix it.
Remember, a moving attack units does not mean a always retreating attack unit.
Also I did not add anything to thsi build, its purely fixes. The only possible explanation of any kind, the remotest long shot explanation is the extra check to fix a kernel panic bug, but s44 has no geothermals so that cannot be it.
Also your tests are inconclusive. NTai says in its logs that attackers where added, along with the unit type of the attacker. Setup a good test with control variables and expected results to make sure that is the issue. You have to be very clear as to what the bug actually is.
Also I do not have any full copies of your latest s44 config that I can look at atm. Nor do I have anything I can use to test with.
Last of all can you delete NTai and then use the copies off of rapidshare? Just to be 100% sure the NTai your using is the NTai I gave out and not a previous version?
If anything this build should be faster than the previous build I sent you as little much changed, and the most notable change was that threat matrixes depreciate every 10 seconds now rather than every second which should be an improvement.
What's more can we be very clear what the retreating business is? Are the units retreating and then not doing anything or are they being given an attack order at home rather than at the enemy then moving home in an attack move order (not a retreat move order). Use .verbose to look for attack markers, if your not using .verbose then I'll have to come to the conclusion that there isn't enough information to define what the bug is nm fix it.
Remember, a moving attack units does not mean a always retreating attack unit.
Also I did not add anything to thsi build, its purely fixes. The only possible explanation of any kind, the remotest long shot explanation is the extra check to fix a kernel panic bug, but s44 has no geothermals so that cannot be it.
Also your tests are inconclusive. NTai says in its logs that attackers where added, along with the unit type of the attacker. Setup a good test with control variables and expected results to make sure that is the issue. You have to be very clear as to what the bug actually is.
Also I do not have any full copies of your latest s44 config that I can look at atm. Nor do I have anything I can use to test with.
Last of all can you delete NTai and then use the copies off of rapidshare? Just to be 100% sure the NTai your using is the NTai I gave out and not a previous version?
OK tested this latest build. I got massive lag, looked like it was caused by construction vehicles following the b_guardian keyword which I had quite alot of.
Also I got a crash about 45 minutes into the game, the commander had just been blown up although i think this may have been coincidence. Last few lines of the log were:-
in the info log i notice some bad pos messages
I also seem to get these in a build i'd made around crash time but as I say I can't pin it down. I've emailed you the config. The crash happens every game so hopefully you should be able to reproduce it yourself.
Also I got a crash about 45 minutes into the game, the commander had just been blown up although i think this may have been coincidence. Last few lines of the log were:-
Code: Select all
[46:42]|19:37:18| < Frame: 84071 >CKeywordConstructionTask::Init b_rule
[46:42]|19:37:18| < Frame: 84071 >Feasable:: armalab
[46:42]|19:37:18| < Frame: 84071 >Feasable:: armlab
[46:42]|19:37:18| < Frame: 84071 >Feasable:: armvp
[46:42]|19:37:18| < Frame: 84071 >Feasable:: armap
[46:42]|19:37:18| < Frame: 84071 >Feasable:: armsy
[46:42]|19:37:18| < Frame: 84071 >Feasable:: armhp
[46:42]|19:37:18| < Frame: 84071 >gotten targ value of armalab for RULE
[46:42]|19:37:18| < Frame: 84071 >CKeywordConstructionTask::Build() :: armalab
[46:42]|19:37:24| < Frame: 84071 >CKeywordConstructionTask::Build singlebuild armalabCode: Select all
GlobalAI0: [46:37]bad pos(1)6
GlobalAI0: [46:38]bad pos(1)6
Janus: Can't reach destination!
GlobalAI0: [46:40]bad pos(1)6
Janus: Can't reach destination!Late game is too late. The logs are too obscured and packed full of messages that one can no longer track the flow of logic within the AI.
Your going to need a debugger and a profiler.
I'm still not sure what you mean by massive lag. I don't know what type of lag . Continuous lag? as in lag that's continuous or lots and lots of very close spikes? How far apart are the spikes? How far in does it start?
The word lag is meaningless
Its about as descriptive as the word error, its not helpful at all.
Unless you can give a direct method of reproducing lag or identify a good pattern that's 100% reliable and can be verified using means other than speculation then your going to need a profiler.
Your going to need a debugger and a profiler.
I'm still not sure what you mean by massive lag. I don't know what type of lag . Continuous lag? as in lag that's continuous or lots and lots of very close spikes? How far apart are the spikes? How far in does it start?
The word lag is meaningless
Its about as descriptive as the word error, its not helpful at all.
Unless you can give a direct method of reproducing lag or identify a good pattern that's 100% reliable and can be verified using means other than speculation then your going to need a profiler.
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
an easy way of looking for lag; spawn 100 con vehicles, measure lag, spawn 100 attackers, measure lag. whichever is laggier is the basis of the problem.give each kind of builder a diffrent command; one make mex, one gaurd, one factory assist etc etc and spawn them in batches of 100 to see what does lagz
from that i take it YOU can't get a profiler working so unless someone else can YOUR project is dead.Your going to need a debugger and a profiler.
I don't appreciate your tone in forums, quite frankly it sucks. I've seen your code remember and spent days trying sift through it so this big attitude quite frankly won't wash.The word lag is meaningless
The reason we can't effectively debug NTai is becuase its a f*cking mess, a maze of redundant code with little or no sensible structure. Its bizarre really becuase it looks like it was started with a high quality bit of code and has since had stuff just appended on, appended to the point at which this current code base is pretty much useless.
This project had the potential to build the best AI but you will never get it to a stable state like this especially if you keep using this attitude with the people who are trying to help you!
Ive spent the last 3 months being told ambiguous meaningless things that could mean a huge number of things.
And no. It didn't start with high quality code and move towards bad appending, its the opposite way around! The cleaner the code the newer the code is!
The main reason I haven't scrapped large chunks is because that would mean loosing chunks of the tool kit support and thus incurring the wrath of the remaining config makers.
On top of that I'm not keen on adding rewriting NTai to my list of commitments.
And on top of that I'm not sure where exactly I should begin cleaning up. Usually in the past if a problem is untraceable I rewrite the system that causes it however the clues people have given me are so ambiguous that I cant point out a general part of the AI that needs redoing.
IK, your experiment wont work precisely because you said spawn 100 units, and 100 units is far too many. For that I would expect instantly to see 300 to 400 lines of AI logs to appear in the second they were spawned, and then a huge number of log lines following that thus defeating the whole point of the experiment.
So for your experiment to work:
1) All the con bots must have the same task list, with the same initial task and of the same unit type. They must be sufficiently spaced apart to make sure that the build system is the cause f any lag, not the units piling up in a traffic jam.
2) The player must be able to monitor the current commands of all con bots. Simply observing them will not work and gives misleading results.
3) Patterns must be observed.
And finally
4) If lag occurs does it occur at intervals.
The last one is important because if it occurs every 4 frames then this is something that's supposed to happen every 4 frames so its hard coded into NTai which means ctrl+f in a C++ IDE will tell me the possible culprits.
However to date whenever lag occurs all I get is something along the lines of "lag occurs" with perhaps the word massive or immense prefixed to it.
It also seems that build A causes bus xyz and build A +2 weeks causes bugs abc. Its very confusing. Sometimes I wonder if waiting 2 week will make the bugs vanish because it has happened in the past, I start work on a bug and then the bug reporter tells me to forget about it because it vanished. Then they complain about it a few days later citing completely different causes or possible circumstances.
I keep asking about the retreat and left behind bug and I keep on saying "are you sure they're retreating and not just being given an attack order back at home" and yet when I ask this the topic suddenly changes and I get no answer?
This is not helping me and its getting extremely annoying.
And no. It didn't start with high quality code and move towards bad appending, its the opposite way around! The cleaner the code the newer the code is!
The main reason I haven't scrapped large chunks is because that would mean loosing chunks of the tool kit support and thus incurring the wrath of the remaining config makers.
On top of that I'm not keen on adding rewriting NTai to my list of commitments.
And on top of that I'm not sure where exactly I should begin cleaning up. Usually in the past if a problem is untraceable I rewrite the system that causes it however the clues people have given me are so ambiguous that I cant point out a general part of the AI that needs redoing.
IK, your experiment wont work precisely because you said spawn 100 units, and 100 units is far too many. For that I would expect instantly to see 300 to 400 lines of AI logs to appear in the second they were spawned, and then a huge number of log lines following that thus defeating the whole point of the experiment.
So for your experiment to work:
1) All the con bots must have the same task list, with the same initial task and of the same unit type. They must be sufficiently spaced apart to make sure that the build system is the cause f any lag, not the units piling up in a traffic jam.
2) The player must be able to monitor the current commands of all con bots. Simply observing them will not work and gives misleading results.
3) Patterns must be observed.
And finally
4) If lag occurs does it occur at intervals.
The last one is important because if it occurs every 4 frames then this is something that's supposed to happen every 4 frames so its hard coded into NTai which means ctrl+f in a C++ IDE will tell me the possible culprits.
However to date whenever lag occurs all I get is something along the lines of "lag occurs" with perhaps the word massive or immense prefixed to it.
It also seems that build A causes bus xyz and build A +2 weeks causes bugs abc. Its very confusing. Sometimes I wonder if waiting 2 week will make the bugs vanish because it has happened in the past, I start work on a bug and then the bug reporter tells me to forget about it because it vanished. Then they complain about it a few days later citing completely different causes or possible circumstances.
I keep asking about the retreat and left behind bug and I keep on saying "are you sure they're retreating and not just being given an attack order back at home" and yet when I ask this the topic suddenly changes and I get no answer?
This is not helping me and its getting extremely annoying.
OK well there is another way, turn on your uber logging and write a program that monitors the records being written to the log. Every function is listed when it begins so you can count the number of times each funtion is called. Then you have an order for which methods to optimize first.
Ideally each method would also write a log file when it ends, if you can be bothered to insert all those log entries then further to this you could effectively write a custom profiler that could deduce the amount of time spent in all the methods by calculating the accumulated time between start and end calls.
This is quite a task though, the home made profiler is pretty easy to write but there's a lot involved in putting in the logging entries. Also you need to be careful because as the log file increases in size it distorts the results so you will need some way to start a new log file once it reaches a certain size.
Sorry i don't have any better ideas
Ideally each method would also write a log file when it ends, if you can be bothered to insert all those log entries then further to this you could effectively write a custom profiler that could deduce the amount of time spent in all the methods by calculating the accumulated time between start and end calls.
This is quite a task though, the home made profiler is pretty easy to write but there's a lot involved in putting in the logging entries. Also you need to be careful because as the log file increases in size it distorts the results so you will need some way to start a new log file once it reaches a certain size.
Sorry i don't have any better ideas
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24