Seemingly random crashes
Moderators: hoijui, Moderators
Seemingly random crashes
Ive been talking about them since i first started coding, and always managed to fix them by just moving code around, without actually "finding" what was wrong with, ever.
Sometimes nesting ifs instead of using && worked, sometimes removing all include files then sifting through 2k errors till they were all included again.
But i decided to investigate, so for the latest problems ive been having, i logged the bastards right down the the single lines of code that crashed it(making log files of 70+mb at times like in the parser).
Turns out ALL of them happen in loops, ALL of them do the loop for a while and for no particular reason crash!
The crash location seems random, eg sunparser will crash when parsing weaons\weapons.tdf in AA at the popup cannon at the lavagfx bit(i checked it, it seems perfectly fine). In other mods it doesnt crash at that definition or doesnt crash at all. With the same settings the crash always occurs at the exact same spot however!
Since the pathfinder, unitlist, sunparser etc are all loops of sorts, and always some of that loop gets executed before the crash, and changing the loop settings around change the location of the crash to another seemingly random location, i can only think that it is running into some memory location it shouldnt, or something to do with memory anyways. The debugger always seems to say access violation, but then again it pretty much always crashes even if a release version woudnt (maybe it uses more memory)
Are there ANY project settings that could affect that? do the dlls have a confined space of memory to work on? maybe my computer(i do have 2gb of ram though)?
I doubt ill get much help on that, since google has so far not helped me much, there are millions of other pages for me to look into, its worth a try!
Sometimes nesting ifs instead of using && worked, sometimes removing all include files then sifting through 2k errors till they were all included again.
But i decided to investigate, so for the latest problems ive been having, i logged the bastards right down the the single lines of code that crashed it(making log files of 70+mb at times like in the parser).
Turns out ALL of them happen in loops, ALL of them do the loop for a while and for no particular reason crash!
The crash location seems random, eg sunparser will crash when parsing weaons\weapons.tdf in AA at the popup cannon at the lavagfx bit(i checked it, it seems perfectly fine). In other mods it doesnt crash at that definition or doesnt crash at all. With the same settings the crash always occurs at the exact same spot however!
Since the pathfinder, unitlist, sunparser etc are all loops of sorts, and always some of that loop gets executed before the crash, and changing the loop settings around change the location of the crash to another seemingly random location, i can only think that it is running into some memory location it shouldnt, or something to do with memory anyways. The debugger always seems to say access violation, but then again it pretty much always crashes even if a release version woudnt (maybe it uses more memory)
Are there ANY project settings that could affect that? do the dlls have a confined space of memory to work on? maybe my computer(i do have 2gb of ram though)?
I doubt ill get much help on that, since google has so far not helped me much, there are millions of other pages for me to look into, its worth a try!
That'll be why it has exception handling in it.
Of course the problem si CSunParser is the main TDF parser used by me veylon and krogothe and we dont know TDFParser, or any specifics on boost libraries for the spirit parser it uses. I'm not even sure I have boost installed correctly.....
i used to have symptomatic problems like this with NTai 0.26, I ha dmy big for loop that cycled through tasks and buidlers but th buidlers where in soemthign like vector<Tunit*> and they went away and got replaced with mroe fixable problems when I changed to vector<Tunit>.
Every now and again i get a problem that gets fixed when I say switch from vector<xxx> to list<xxx> and then it occurs further on down the line and i switch back
Of course the problem si CSunParser is the main TDF parser used by me veylon and krogothe and we dont know TDFParser, or any specifics on boost libraries for the spirit parser it uses. I'm not even sure I have boost installed correctly.....
i used to have symptomatic problems like this with NTai 0.26, I ha dmy big for loop that cycled through tasks and buidlers but th buidlers where in soemthign like vector<Tunit*> and they went away and got replaced with mroe fixable problems when I changed to vector<Tunit>.
Every now and again i get a problem that gets fixed when I say switch from vector<xxx> to list<xxx> and then it occurs further on down the line and i switch back
Man thats really hard on me. I worked for over 28 hours on hunting down the problems and they boil down to really complex (for me anyways) 3rd party code, and unfortunately, due to the way they work, all the main features i had in mind for KAI cannot exist unless i have that code working (some features require one single, vital line to be parsed). I could still make a "normal" AI, but some of the real cool stuff (reason why i keep it closed source) wont make the cut:
-Baseline unit selection system (damn accurate with zero learning, so that any learning algos have a solid base to work from)
-Completely cfg-less and self installing AI (stick the dll in and it does all the rest)
-Strategic, high-level 3 group attack system - one of the most awesome bits, with transport usage, defense avoidance, real objectives (take out anti-air so air can go in, take out anti-nuke then nuke them, etc)
-Smart defensive placement - chokepoints receive priority, and a lot of other factors create a real defense system, not the "ring" or "mesh" we currently have, so on the_pass it would build anti-ground and mines only at the pass entrances (or on on the mountains overlooking them) and anti-air all along the map.
-Predictive dgunning(accurate from any direction of approach and facing of the comm) and shooting for any unit in any mod (criteria taken into account so only really powerful weapons are used this way).
-godlike micromanagement and raiding, very effective early game (early tests actually beat some humans down to their comm with one or two lvl1 units) to destroy whole bases if they are not protected from all directions
-Assistant groupai that displays holes in your base defenses and some handy game stats.
-Waste-less mex building - doesnt ever need to lose con units to learn a spot is occupied or dangerous.
-map oriented base building - kbots on hills, ships if water separates the bases, planes if no way through land.
Plus the standard features of KAI v0.0 with a few little tricks that most AIs currently already have.
To add to the frustration all of these except the assistant groupai and some bits of the attack system (such as transports) have been developed, tested, used and proven possible and worthwhile, even with the extreme reliability problems. I was aiming for a really special release, and now i have the choice:
Shall i spend hundreds of hours learning the algorithms for the parsing, pathfinding etc then hundreds more coding them, with no guarantee of speed and stability, both critical to its success, or just call it quits, be happy what i planned is feasible and either work on a toned down AI or simply leave it altogether.
I could always try the TDF parser, that would save me some work, then maybe look for some help for the other bits. Ill have to think long and hard about it either way...
-Baseline unit selection system (damn accurate with zero learning, so that any learning algos have a solid base to work from)
-Completely cfg-less and self installing AI (stick the dll in and it does all the rest)
-Strategic, high-level 3 group attack system - one of the most awesome bits, with transport usage, defense avoidance, real objectives (take out anti-air so air can go in, take out anti-nuke then nuke them, etc)
-Smart defensive placement - chokepoints receive priority, and a lot of other factors create a real defense system, not the "ring" or "mesh" we currently have, so on the_pass it would build anti-ground and mines only at the pass entrances (or on on the mountains overlooking them) and anti-air all along the map.
-Predictive dgunning(accurate from any direction of approach and facing of the comm) and shooting for any unit in any mod (criteria taken into account so only really powerful weapons are used this way).
-godlike micromanagement and raiding, very effective early game (early tests actually beat some humans down to their comm with one or two lvl1 units) to destroy whole bases if they are not protected from all directions
-Assistant groupai that displays holes in your base defenses and some handy game stats.
-Waste-less mex building - doesnt ever need to lose con units to learn a spot is occupied or dangerous.
-map oriented base building - kbots on hills, ships if water separates the bases, planes if no way through land.
Plus the standard features of KAI v0.0 with a few little tricks that most AIs currently already have.
To add to the frustration all of these except the assistant groupai and some bits of the attack system (such as transports) have been developed, tested, used and proven possible and worthwhile, even with the extreme reliability problems. I was aiming for a really special release, and now i have the choice:
Shall i spend hundreds of hours learning the algorithms for the parsing, pathfinding etc then hundreds more coding them, with no guarantee of speed and stability, both critical to its success, or just call it quits, be happy what i planned is feasible and either work on a toned down AI or simply leave it altogether.
I could always try the TDF parser, that would save me some work, then maybe look for some help for the other bits. Ill have to think long and hard about it either way...
- Targ Collective
- Posts: 202
- Joined: 12 Nov 2005, 14:16
- Targ Collective
- Posts: 202
- Joined: 12 Nov 2005, 14:16
The exams come first, of course - we respect that. But don't give up, you've got too much potential.
Reading through code is awful, I know. I seldom understand half the code I've written, let alone anyone else's. So I know the feeling, and we all have days when we feel like giving up, I'm sure.
Don't lose sight of what could be. It's like building a Krogoth - your base gets raided, your kroggie gets blasted but it's all about the finished product. So you've only got a pair of feet right now, but imagine what the whole bot could do...
Reading through code is awful, I know. I seldom understand half the code I've written, let alone anyone else's. So I know the feeling, and we all have days when we feel like giving up, I'm sure.
Don't lose sight of what could be. It's like building a Krogoth - your base gets raided, your kroggie gets blasted but it's all about the finished product. So you've only got a pair of feet right now, but imagine what the whole bot could do...
Well, im open for hiring!
What to expect from candidate:
-Can make reliable code, hopefully fast
-Experienced with pathfinding/parsers/form-based applications
-Can keep a secret so that we can push KAI out and have everyone wonder "how the hell does it do that??"
-Has lots of free time because theres lots to be done and i want this out before supcom so we actually have people to test and enjoy it
-Knowing where authority lies - im open for suggestions but my word is final.
What to expect from the job:
-If we pull this off (only hurdles are time and CPU time, pretty much all else has been proof-of-concepted) it will be one of the most awesome RTS AIs ever made.
-You get full credit for developing KAI too
-Lots of writing and rewriting to be done, youll never be bored!
-No pay whatsoever, not a penny!
What to expect from candidate:
-Can make reliable code, hopefully fast
-Experienced with pathfinding/parsers/form-based applications
-Can keep a secret so that we can push KAI out and have everyone wonder "how the hell does it do that??"
-Has lots of free time because theres lots to be done and i want this out before supcom so we actually have people to test and enjoy it
-Knowing where authority lies - im open for suggestions but my word is final.
What to expect from the job:
-If we pull this off (only hurdles are time and CPU time, pretty much all else has been proof-of-concepted) it will be one of the most awesome RTS AIs ever made.
-You get full credit for developing KAI too
-Lots of writing and rewriting to be done, youll never be bored!
-No pay whatsoever, not a penny!
Sorry, some self-centered crap coming up:
I don't want an ai that is super-microing and uses every small trick to absolute maximum advantage. Rather I'd want something that plays pretty much like a human. Doesn't do completely braindead moves, does some unexpected things, has some strategic ideas about the game.
Maybe it could be adjusted for various skill levels.
I don't mean "I want the ai to suck", but rather, that it's goodness is not based on "unfair" advantages, if you know what I mean.
Now, many of the things you listed, sound very exhilarating. Is anybody else working on the parser?
As a final word, I'd also like to say this: Contests have a purpose, but often they go too far. This point must be recognized, there is a reason why there is an "ai contest" in the first place - namely, that there doesn't exist a good, playable ai yet. (Some are pretty good already tho, but not quite there.)
Cheers to you hard-working AI makers. Don't take this bitching as negative.
I don't want an ai that is super-microing and uses every small trick to absolute maximum advantage. Rather I'd want something that plays pretty much like a human. Doesn't do completely braindead moves, does some unexpected things, has some strategic ideas about the game.
Maybe it could be adjusted for various skill levels.
I don't mean "I want the ai to suck", but rather, that it's goodness is not based on "unfair" advantages, if you know what I mean.
Now, many of the things you listed, sound very exhilarating. Is anybody else working on the parser?
As a final word, I'd also like to say this: Contests have a purpose, but often they go too far. This point must be recognized, there is a reason why there is an "ai contest" in the first place - namely, that there doesn't exist a good, playable ai yet. (Some are pretty good already tho, but not quite there.)
Cheers to you hard-working AI makers. Don't take this bitching as negative.
- Lindir The Green
- Posts: 815
- Joined: 04 May 2005, 15:09
AF wrote:If you're working on this after exams, then I wouldnt mind helping out, perhaps even an Epic/KAI merger. Otherwise it'll be a slugfest......

Yes! Do it!
You would completely obliviate all competition.
Wait...
AF is really against closed source-ness (as am I), but krogothe insists on keeping his AI closed source...

Krogothe says he wont be releasing source untill like V1.0, any previous releases or halfways will be closed source to protect the unfinished versions of KAI.
Also krogothes predicament is a little vague, having only pointed at TDF Parser and assuming CSunParser too as a result, he's given us little if any information to help him find alternatives or solve the problem.
Also krogothes predicament is a little vague, having only pointed at TDF Parser and assuming CSunParser too as a result, he's given us little if any information to help him find alternatives or solve the problem.
Some experiments last night continued to surprise me with the randomness of the crashes, however due to managing a yet perfectly working CSunParser in a groupAI, i have higher hopes of it being fixable, as well as a lot of the other bugs. I still cant seem to find a pattern in it.
Eg, one of the problems occurs when parsing the sidedata.tdf:
-E&E v0.152 will not crash
-E&E v0.154, 0.151, 0.15 will all crash, as well as many other mods.
Its either something really simple i havent yet noticed or something really obscure which i probably never will!
A merger would probably be a bad thing since i want to stick to my original plan and thus the resulting AI would end up being at the very least 90-95% KAI, very frustrating for any AI designer, so a fresh programmer would probably be the best call.
I am, however really eager to get at least one highly experienced programmer in the team, since my coding abilities and lack of organization are what have been letting KAI down for the past few months. My exams start soon so i dont really go all-out coding it as to not harm my results, which need to be AAA to meet the offer by cambridge, and further maths can be really hard! This break will allow me to maybe get 1-3 people to help me with KAI, getting a good skillset in all areas.
Eg, one of the problems occurs when parsing the sidedata.tdf:
-E&E v0.152 will not crash
-E&E v0.154, 0.151, 0.15 will all crash, as well as many other mods.
Its either something really simple i havent yet noticed or something really obscure which i probably never will!
A merger would probably be a bad thing since i want to stick to my original plan and thus the resulting AI would end up being at the very least 90-95% KAI, very frustrating for any AI designer, so a fresh programmer would probably be the best call.
I am, however really eager to get at least one highly experienced programmer in the team, since my coding abilities and lack of organization are what have been letting KAI down for the past few months. My exams start soon so i dont really go all-out coding it as to not harm my results, which need to be AAA to meet the offer by cambridge, and further maths can be really hard! This break will allow me to maybe get 1-3 people to help me with KAI, getting a good skillset in all areas.
As always I've offered.
As for CSUNParser, are you using the versionf rom NTai ro OTAI?
The version from OTAI logs errors and doesnt reutrn a default vlaue.
NTai instead returns string(""), so you may end up sending uninitialised variables ot CSunParser expecting a good value in return then it crashes when CSunParser cant deliver and KAI continues as if it had...
As for CSUNParser, are you using the versionf rom NTai ro OTAI?
The version from OTAI logs errors and doesnt reutrn a default vlaue.
NTai instead returns string(""), so you may end up sending uninitialised variables ot CSunParser expecting a good value in return then it crashes when CSunParser cant deliver and KAI continues as if it had...
Unbelievable, unbelievable.
It was ONE SINGLE line that i forgot to add, EVERYTHING works now, the pathfinder, the logging, the parser, and all thanks to Firenu and Tournesol. I love you guys!
Its a bit early to be optimistic but i forced it to run 200 billion calculations in a row and not even a cough, complain, anything.
so currently KAI works with any mod and map you throw at it (that i tested, from EE to XTA to FF), but only makes mexes. If that golden line solved the problem then expect fast development!
It was ONE SINGLE line that i forgot to add, EVERYTHING works now, the pathfinder, the logging, the parser, and all thanks to Firenu and Tournesol. I love you guys!
Its a bit early to be optimistic but i forced it to run 200 billion calculations in a row and not even a cough, complain, anything.
so currently KAI works with any mod and map you throw at it (that i tested, from EE to XTA to FF), but only makes mexes. If that golden line solved the problem then expect fast development!