Kernel Panic
Moderator: Content Developer
Re: Kernel Panic
'sides, can we split all this AI talk into a separate thread? Most of us have given up on NTAI long ago, mostly because the issues in it cannot be ignored and aren't getting fixed. Expecting users to do your debugging won't help you getting them fixed either since few are willing to go through that procedure (why bother, it's easier to just abandon the AI). I know I won't use NTAI if I'm expected to invest this much time that I could spend on things I actually care about instead.
Re: Kernel Panic
I've nto asked you to debug it
I have asked you simple sets of questions and been totally ignored, questions which fi unanswered could be answered in a single game using simple logic, and because nobody will answer these questions I am left guessing and clamouring for more information.
Questions the Kernel Panic People Refuse to Answer That could be retrieved within the hour and Should have been given 9 months Ago!
1: Builders or Attackers?
Units in NTai follow either the builder route or the attacker route. Which route is causing the problem? To test this spawn lots of units of the builder type, see if it lags, then repeat with non builders and describe how laggy each one was, and which one lagged the most.
2: Are There Any Patterns to Lag?
Kernel Panic people dismissed this out of hand and insisted there were no patterns whatsoever, 'it just lags'. Tests by me showed this was not the case, and a slew of laggy performance issues involving weapons fire were found and have been optimized for, showing improvements in TA based mods.
I lack the time to test kernel panic further for more patterns but patterns should exist, and considering Kernel panics relative lack of complexity, I find it hard to see how kernel panic developers couldnt find any patterns in 9 months, the XTA and BA config builders who found bugs hours after NTai releases without use of a compiler or debugger must have had brains the size of planets.
3: Hidden Weapons and lua/cob interference
Kernel panic developers refuse to acknowledge the existence of this question and ignore it completely. Tests by argh and others have shown flaws in AIs caused by compatibility issues, there have been threads discussed at length, threads even the kernel panic devs have posted in.
So to be precise:
a: Are there hidden weapons that fire but do not directly do damage? Such as a weapon for sfx and a weapon that does the actual damage? Or a purely graphical effect? What about the construction sfx? Are they weapons or explosion generators? Could they be causing extra UnitDamaged() calls? If so this isn't just an AI problem it could also be a problem shared by all AIs, groupAIs, widgets, gadgets, even some internal spring code.
b:Is the usual unit event system being circumvented or meddled with by lua code in any place?
Now I have been asking these questions for 9 months and nobody has answered me. Question 3 requires no debugging or play testing because you wrote the damned thing you should draw the answer from those memory banks. #2 and #1 could have been done very easily by now. The only help here was zwzsg geothermal placement problem, which is fixed then broken then fixed then broken even when the code doesn't change it somehow fixes and breaks itself! And that bug has been doing that for the last year so it pre-dates this problem.
I have asked you simple sets of questions and been totally ignored, questions which fi unanswered could be answered in a single game using simple logic, and because nobody will answer these questions I am left guessing and clamouring for more information.
Questions the Kernel Panic People Refuse to Answer That could be retrieved within the hour and Should have been given 9 months Ago!
1: Builders or Attackers?
Units in NTai follow either the builder route or the attacker route. Which route is causing the problem? To test this spawn lots of units of the builder type, see if it lags, then repeat with non builders and describe how laggy each one was, and which one lagged the most.
2: Are There Any Patterns to Lag?
Kernel Panic people dismissed this out of hand and insisted there were no patterns whatsoever, 'it just lags'. Tests by me showed this was not the case, and a slew of laggy performance issues involving weapons fire were found and have been optimized for, showing improvements in TA based mods.
I lack the time to test kernel panic further for more patterns but patterns should exist, and considering Kernel panics relative lack of complexity, I find it hard to see how kernel panic developers couldnt find any patterns in 9 months, the XTA and BA config builders who found bugs hours after NTai releases without use of a compiler or debugger must have had brains the size of planets.
3: Hidden Weapons and lua/cob interference
Kernel panic developers refuse to acknowledge the existence of this question and ignore it completely. Tests by argh and others have shown flaws in AIs caused by compatibility issues, there have been threads discussed at length, threads even the kernel panic devs have posted in.
So to be precise:
a: Are there hidden weapons that fire but do not directly do damage? Such as a weapon for sfx and a weapon that does the actual damage? Or a purely graphical effect? What about the construction sfx? Are they weapons or explosion generators? Could they be causing extra UnitDamaged() calls? If so this isn't just an AI problem it could also be a problem shared by all AIs, groupAIs, widgets, gadgets, even some internal spring code.
b:Is the usual unit event system being circumvented or meddled with by lua code in any place?
Now I have been asking these questions for 9 months and nobody has answered me. Question 3 requires no debugging or play testing because you wrote the damned thing you should draw the answer from those memory banks. #2 and #1 could have been done very easily by now. The only help here was zwzsg geothermal placement problem, which is fixed then broken then fixed then broken even when the code doesn't change it somehow fixes and breaks itself! And that bug has been doing that for the last year so it pre-dates this problem.
Re: Kernel Panic
Just test 1 yourself.
2: Zw said the pattern was that it started lagging like mad after a minute, that looks pattern-like enough to me. He also described what the AI is doing. Not enough? Look, we're not your debugging squad. Test it yourself, you know what to look for.
3:
a: There are no linked weapons but there are weapons that are used to show build effects (build lasers, should have been pretty damn obvious that these are being used). The only attack that uses two weapons is the worm's attack which hits one target with a melee weapon and then fires an AOE weapon to hurt additional targets. We're not going to change this.
b: What do you mean?
2: Zw said the pattern was that it started lagging like mad after a minute, that looks pattern-like enough to me. He also described what the AI is doing. Not enough? Look, we're not your debugging squad. Test it yourself, you know what to look for.
3:
a: There are no linked weapons but there are weapons that are used to show build effects (build lasers, should have been pretty damn obvious that these are being used). The only attack that uses two weapons is the worm's attack which hits one target with a melee weapon and then fires an AOE weapon to hurt additional targets. We're not going to change this.
b: What do you mean?
Re: Kernel Panic
What debugging I do nowadays involves no rendering and me watching a script output in Visual studio because rendering means driver crash which means interrupted debugger session. There's a reason I rarely play, and when i do its usually BA or XTA for 5 minutes then a crash out after installing new drivers. The 8800 cannot be relied on and the x1100 express is too slow, and has that blue ground bug so it wouldnt be worth it anyway.Just test 1 yourself.
I am not fobbing debugging off on you, but you must understand I have limited time and resources.
In case you hadn't noticed one of the most repeated sentences on these forums in the last year has been about me and graphics card drivers. But "start game, it lags later" is not a pattern, its a description fo the effect not a pattern. It's like saying that footsteps are caused by people looking out the window in busy places, afterall if you look outside a window in a busy place someone is bound to be using their feet?2: Zw said the pattern was that it started lagging like mad after a minute, that looks pattern-like enough to me. He also described what the AI is doing. Not enough? Look, we're not your debugging squad. Test it yourself, you know what to look for.
But I still don't know if this means spammage of UnitDamaged calls to AIs groupAIs widgets and gadgets, I would assume these lasers fire 20+ times a second? This is not just an NTai issue here, this is a potential ticking time bomb.3:
a: There are no linked weapons but there are weapons that are used to show build effects (build lasers, should have been pretty damn obvious that these are being used). The only attack that uses two weapons is the worm's attack which hits one target with a melee weapon and then fires an AOE weapon to hurt additional targets. We're not going to change this.
An example of 3b would be trepans deployment mutator, and any other gadget that meddles in the building process either by spawning destroying or controlling the logic flow of the build process.b: What do you mean?
Re: Kernel Panic
When a unit dies after getting infected a virus is spawned, that's not related to building anything though, just a side-effect of combat.
The lasers do fire every frame (as would any beamlaser with beamtime). Most likely UnitDamaged is called every time so make sure that function is fast. For buildlasers a workaround is to just not run the function if damage is <= 1 but for any other beamlaser you're out of luck.
The lasers do fire every frame (as would any beamlaser with beamtime). Most likely UnitDamaged is called every time so make sure that function is fast. For buildlasers a workaround is to just not run the function if damage is <= 1 but for any other beamlaser you're out of luck.
Re: Kernel Panic
I did streamline that function and add a damage check for <= 0 damage but I have no idea if it really had an impact on the problem as can be seen in zwzsg reply further up.
Re: Kernel Panic
Questions I have already answered the previous page
1: Builders or Attackers?
Builders.
2: Are There Any Patterns to Lag?
Lag happens as soon as assemblers are built.
3: Hidden Weapons and lua/cob interference
- Issues arises well before any combat take place.
- I use "System" units, which function like regular units.
So to be precise:
a: Are there hidden weapons that fire but do not directly do damage? Such as a weapon for sfx and a weapon that does the actual damage? Or a purely graphical effect? What about the construction sfx? Are they weapons or explosion generators? Could they be causing extra UnitDamaged() calls? If so this isn't just an AI problem it could also be a problem shared by all AIs, groupAIs, widgets, gadgets, even some internal spring code.
The lag appears well before the first shot is fired. Well before the units come into range even. Hiddens weapons and other sfx don't matter at this point, you're just looking for scapegoats to divert attention.
b: Is the usual unit event system being circumvented or meddled with by lua code in any place?
The usual unit event works like usual. There's lua code to add special abilities, but it can be ignored, the regular abilities are still there and following regular methods.
What part of "There wasn't hundreds of units doing hundreds of things. Just couple bits and assembler sitting still next to kernels (which pumped bits and asm). There was no attack." was that hard to understand?
Have you even glanced at the picture I posted? Doesn't it clearly depict a moment so early ingame that nothing you're tying to lay the blame on is relevant?
I edited my config to make sure every unit has at least two task, and every task at least two items. I still get [-]|21:7:13| < Frame: 0 >error in buffer. And the kernels still do nothing. (With SVN NTai on SVN Spring)
< 1 min
So it doesn't matter if your vid card crash at 5 mins, you'll be outlagged long before. I find it hard you can't even find a single minute to test your own AI. Because then I might as well stop considering you as an AI dev.
1: Builders or Attackers?
Builders.
2: Are There Any Patterns to Lag?
Lag happens as soon as assemblers are built.
3: Hidden Weapons and lua/cob interference
- Issues arises well before any combat take place.
- I use "System" units, which function like regular units.
So to be precise:
a: Are there hidden weapons that fire but do not directly do damage? Such as a weapon for sfx and a weapon that does the actual damage? Or a purely graphical effect? What about the construction sfx? Are they weapons or explosion generators? Could they be causing extra UnitDamaged() calls? If so this isn't just an AI problem it could also be a problem shared by all AIs, groupAIs, widgets, gadgets, even some internal spring code.
The lag appears well before the first shot is fired. Well before the units come into range even. Hiddens weapons and other sfx don't matter at this point, you're just looking for scapegoats to divert attention.
b: Is the usual unit event system being circumvented or meddled with by lua code in any place?
The usual unit event works like usual. There's lua code to add special abilities, but it can be ignored, the regular abilities are still there and following regular methods.
Like I said half a dozen times already, the uberlags now appears BEFORE ANY SHOT IS FIRED. So before any damage is dealt, before any unit is killed, before any special gadget code is executed, etc...AF wrote:But I still don't know if this means spammage of UnitDamaged calls to AIs groupAIs widgets and gadgets, I would assume these lasers fire 20+ times a second? This is not just an NTai issue here, this is a potential ticking time bomb.
What part of "There wasn't hundreds of units doing hundreds of things. Just couple bits and assembler sitting still next to kernels (which pumped bits and asm). There was no attack." was that hard to understand?
Have you even glanced at the picture I posted? Doesn't it clearly depict a moment so early ingame that nothing you're tying to lay the blame on is relevant?
Well, when a unit has only one thing to build, seem natural to give it one task with one item. I could understand that zero item would cause issues, but had no idea 1 was such a big nono. Sorry to not know by heart the 82 pages of the NTai topic, and to not be aware of every single NTai bug.AF wrote:Tasklists with 1 item in them == big no no, thats the only thing I can think of right now. Nobody has answered my question about hidden weapons yet either.
I edited my config to make sure every unit has at least two task, and every task at least two items. I still get [-]|21:7:13| < Frame: 0 >error in buffer. And the kernels still do nothing. (With SVN NTai on SVN Spring)
I overheard that AI get confused if you .cheat .give some units, that's why I didn't do it. Would NTai handle being cheat-given units?AF wrote:You have made no attempts to generate scenarios that would test basic events, such as spawning hundreds of static units that do nothing to see if that's what lags it, or making lots fo units fire weapons to see if processing that is what does it.
I'll stress again, in 76b1 the lag issue is glaring before the 1min mark.AF wrote:I rarely play, and when i do its usually BA or XTA for 5 minutes then a crash out after installing new drivers.
[...]
you must understand I have limited time and resources.
< 1 min
So it doesn't matter if your vid card crash at 5 mins, you'll be outlagged long before. I find it hard you can't even find a single minute to test your own AI. Because then I might as well stop considering you as an AI dev.
Re: Kernel Panic
Going past the 666 reply count:
http://xta.wolfgame.org/lurker/Kernel%2 ... %20PB1.sd7
First test version of the third faction, Network. Their minifacs don't produce units directly, they fill a Buffer. To withdraw the units from the buffer use Dispatch from a Port or Connection, hold ALT to dispatch the entire buffer.
http://xta.wolfgame.org/lurker/Kernel%2 ... %20PB1.sd7
First test version of the third faction, Network. Their minifacs don't produce units directly, they fill a Buffer. To withdraw the units from the buffer use Dispatch from a Port or Connection, hold ALT to dispatch the entire buffer.
Re: Kernel Panic
On Neddiehost.
AF, if you could find some time to test KP and NTai in your schedule, I'd be thrilled. Few other projects even attempt to use it, and I think Kernel Panic and NTai would benefit from the investigation.
AF, if you could find some time to test KP and NTai in your schedule, I'd be thrilled. Few other projects even attempt to use it, and I think Kernel Panic and NTai would benefit from the investigation.
Re: Kernel Panic
Awesome! The swarmers themselves don't seem to bring much to the table... but the deployment concept wrawks! Itching to try this out online - or at least against a System bot.
I'm shocked you brought in an air-unit. It's a neat idea to use flight as a "special power" unit. Very cool. Any plans for what to do for the Network's "Nuke" building? Their "static" power?
An auto-dispatch toggle for the minifacs would be nice - I know it would defeat the purpose a bit, but sometimes you just want your units to be well-distributed.
I'm shocked you brought in an air-unit. It's a neat idea to use flight as a "special power" unit. Very cool. Any plans for what to do for the Network's "Nuke" building? Their "static" power?
An auto-dispatch toggle for the minifacs would be nice - I know it would defeat the purpose a bit, but sometimes you just want your units to be well-distributed.
Re: Kernel Panic
http://mitglied.lycos.de/KDR_11k/files/ ... 20WIP2.sd7
KP.net WIP2
- Decreased Packet Buffer fill rate (1/128->1/164)
- Decreased Gateway range (400->350), increased buildtime (1400->2000)
- Decreased Flow range (500->350), increased buildtime(1200->1400)
- Increased Packet rate of fire (1/.75->1/.5), made it unable to shoot through friendlies
- Increased Connection buildtime (3000->3300), decreased range (600->450)
- Restored old Worm splash damage (300->800), reduced AOE (210->180), reduced rate of fire (1/3->1/6)
- Fixed Worm retraction bug
- Reduced Virus health (400->300) and damage(120->100)
- Added Network sideicon
- Updated keybindings for Network (numpad will now select Port for building, Dispatch is D and Enter is E)
- Made Autospam widget deal with the Carrier, too
- Updated license information on defaultCommands and noRes to be Public Domain
KP.net WIP2
- Decreased Packet Buffer fill rate (1/128->1/164)
- Decreased Gateway range (400->350), increased buildtime (1400->2000)
- Decreased Flow range (500->350), increased buildtime(1200->1400)
- Increased Packet rate of fire (1/.75->1/.5), made it unable to shoot through friendlies
- Increased Connection buildtime (3000->3300), decreased range (600->450)
- Restored old Worm splash damage (300->800), reduced AOE (210->180), reduced rate of fire (1/3->1/6)
- Fixed Worm retraction bug
- Reduced Virus health (400->300) and damage(120->100)
- Added Network sideicon
- Updated keybindings for Network (numpad will now select Port for building, Dispatch is D and Enter is E)
- Made Autospam widget deal with the Carrier, too
- Updated license information on defaultCommands and noRes to be Public Domain
Re: Kernel Panic
Zwzsg, I have already said in this thread several items that my spring lags playing kernel panic even if NTai is not loaded, because tis a debug build not a release build and the overhead of it being a debug build means I cannot tell the difference between debugger lag and NTai lag.
You obviously didn't read my post properly either, nor it seems did your ead any of KDRs replies. If you did you'd realize that just because there have been no offensive units built does not mean that no weapons fire has occurred, and just because that weapons fire does not cause damage does not mean it doesn't count. How else do you explain the shiny beams on the kernels and the assemblers in that screen shot? There are at least 16 weapons being fired at any one time in that screen shot from the kernels alone.
Also, when I did manage to get kernel panic working for that short period a few months ago, what you said about assemblers causing lag before the minute mark didn't happen, in fact you yourself said there was no lag problem before the minute mark.
You obviously didn't read my post properly either, nor it seems did your ead any of KDRs replies. If you did you'd realize that just because there have been no offensive units built does not mean that no weapons fire has occurred, and just because that weapons fire does not cause damage does not mean it doesn't count. How else do you explain the shiny beams on the kernels and the assemblers in that screen shot? There are at least 16 weapons being fired at any one time in that screen shot from the kernels alone.
Also, when I did manage to get kernel panic working for that short period a few months ago, what you said about assemblers causing lag before the minute mark didn't happen, in fact you yourself said there was no lag problem before the minute mark.
Re: Kernel Panic
Well it's not our problem if your AI can't handle the resulting UnitDamaged calls, our Lua doesn't have a problem with that.
Either way I'd prefer if this AI talk was split into another thread.
Either way I'd prefer if this AI talk was split into another thread.
Re: Kernel Panic
Wouldn't it be trivial to test this all just by swapping out your buildlaser weapon with a dummy weapon that doesn't hit the construction in progress? Wouldn't even take any COB script. Presto, no UnitDamage calls.
Re: Kernel Panic
The connection design leaves to be desired.
But otherwise zomg impressively awesome work! (like usual)
But otherwise zomg impressively awesome work! (like usual)
Re: Kernel Panic
http://mitglied.lycos.de/KDR_11k/files/ ... 20WIP3.sd7
KP.net WIP3
- Increased packet size (1x1->2x2), should reduce vulnerability towards AOE attacks
- Made Packet able to shoot through friendlies again, reduced damage (100->90) in turn (was disabled because 1x1 packets can fit a crapload of firepower in range)
- Reduced Connection rate of fire (1/2->1/3), increased damage (5x400->5x600) to maintain DPS while reducing the ability to kill spam units
- Prevented spawning of Packets on occupied spaces during dispatch order
- Disabled ONS for now since the Network faction does not support that yet
KP.net WIP3
- Increased packet size (1x1->2x2), should reduce vulnerability towards AOE attacks
- Made Packet able to shoot through friendlies again, reduced damage (100->90) in turn (was disabled because 1x1 packets can fit a crapload of firepower in range)
- Reduced Connection rate of fire (1/2->1/3), increased damage (5x400->5x600) to maintain DPS while reducing the ability to kill spam units
- Prevented spawning of Packets on occupied spaces during dispatch order
- Disabled ONS for now since the Network faction does not support that yet
Re: Kernel Panic
There's a crashbug caused by the Dispatch command BTW, I looked into it earlier, it's caused by Packets being spawned inside other units (or something, not sure that's necessary) and being given a move order (not sure it needs to be an order or just moving at all). I've tested it, the order is what causes the crash, not the spawn. If they're spawned without an order it crashes once an order is given.
Happens infrequently now
Happens infrequently now
Re: Kernel Panic
Right, I forgot that there was all the buildlasers, which indeed are weapons, that hit units, and do a little damage.AF wrote:If you did you'd realize that just because there have been no offensive units built does not mean that no weapons fire has occurred, and just because that weapons fire does not cause damage does not mean it doesn't count. How else do you explain the shiny beams on the kernels and the assemblers in that screen shot? There are at least 16 weapons being fired at any one time in that screen shot from the kernels alone.
So I just removed all buildlasers from kernel, assembler, socket, on my local copy of Kernel Panic. Still uberlag at 30 second. Notice clock, FPS, lack of buildlaser, and that no fight has occured yet.
Use the repeat button!Pxtl wrote:An auto-dispatch toggle for the minifacs would be nice
Don't forget to edit the C.E.G. so it match!KDR_11k wrote:reduced AOE (210->180)
The connection lightning last so few frames it's hard to see what it hit. Can you make it last longer? (and also make it a bit less curvy.)
From the games I had with Overkill, it seems that, on Marble Madness,
System >> Network
Maybe it's just because I don't know how to play network yet, or maybe there's imbalance.
Re: Kernel Panic
http://www.springplayersclub.com/mods/K ... 20WIP4.sd7
KP.net WIP4
- Added Network superweapon, the Firewall
- Added Pendrokar's sounds
- Network Carrier now turns like the other bases and is just as resistant to SIGTERMs
- Reduced Bug buildtime (448->240) but reduced Window workertime as well (128->64) so bugs build at roughly the same speed at Windows but faster at the Security Hole
KP.net WIP4
- Added Network superweapon, the Firewall
- Added Pendrokar's sounds
- Network Carrier now turns like the other bases and is just as resistant to SIGTERMs
- Reduced Bug buildtime (448->240) but reduced Window workertime as well (128->64) so bugs build at roughly the same speed at Windows but faster at the Security Hole
Re: Kernel Panic
zwzsg, what you describe with assemblers and not finding geos causing lag sounds identical to a bug that was found and squashed while testing EE hubs under the newly coded build algorithm.
Thus I have just committed a change that makes units wait 64 frames after a failed task before considering the next one. This should help rule out this issue if it is indeed the cause.
Thus I have just committed a change that makes units wait 64 frames after a failed task before considering the next one. This should help rule out this issue if it is indeed the cause.