Kernel Panic v3.8.3 (Unoffical Bugfix)

[Cirno]

http://nanohatakamachi.x10hosting.com/d ... ffical.sd7

While playing some games with zwzsg, I noticed that sometimes a Hero unit in the Hero game mode would spawn on the wrong team. I think this modification should fix the bug.

The bug in question should be reproducible in 3.8 by starting a 1v1 hero mode game, having one player destroy their home base, then self-destructing their hero unit, and having the other player order their home base to build a new hero unit. (EDIT: With thiers alive)

[zwzsg]

I'm having trouble downloading it. I get a 11kb corrupted file. Care to explain what was the problem and the fix?

Edit: Nevermind, got it.

Code: Select all

			if n~="fairy" then
				hero.name="Mega"..hero.name -- Human Readable Name
			else
				hero.name="Cirno" -- Override for Touhou hero.
			end

Eh. I'm not sure I'll keep that change though.


Oh, also yesterday a minute after I left I realised what was wrong with Color War: I erroneously assumed every unit would be within the map, which is not true when a hero impulse send units flying away. Will be easy to fix.

[Cirno]

I'm having trouble downloading it. I get a 11kb corrupted file. Care to explain what was the problem and the fix?

Edit: Nevermind, got it.

I made it ensure that the hero was being spawned on the right team before actually doing it. Check gadget:UnitCreated in shoot_n_run.lua

[zwzsg]

So the bug was that Spring.GetPlayerList(team,true) returned players from other teams?

[Cirno]

I'm not sure what's wrong, really. All my fix does it make it refuse to spawn a unit on the wrong team.

[zwzsg]

Thanks to TheFatController, the root of the problem was found:

Spring.GetPlayerList(team,active) does not only return a list of PlayerID but also an element keyed "n" with the count as value.
For exemple, if it were to return the playerID 5,6,7:
{[1]=5,[2]=6,[3]=7,["n"]=3} instead of just {[1]=5,[2]=6,[3]=7}

So iterating with pairs made my gadget get that count value and interpreting it as a playerID. Hence mess. The fix is therefore to iterate with ipairs, not pairs.

[Cirno]

I see. So it was a error that was there all along?

[KDR_11k]

Always use ipairs on lists returned by the engine, that's just how it works.

[zwzsg]

I used to always use ipairs. Then I realised that the ability to iterate over table with holes, or tables not indexed by numbers, is nice, and started using pairs, which seemed "better" then ipairs, as it accepts more kind of tables (and I don't care about "optimisation" that result in a 0.000001% gain overall). Then I had this problem with the shoot_n_run.lua. TheFatController told me about how the engine adds the extra "n" entry. I checked by asking a widget to echo every key,value pairs, and indeed, there's that extra entry in the table. While I looked into the source code I saw that, like KDR_11k points out, most of the Lua commands that ask the engine to return a table have that "n" with the count added. Thanksfully the majority of Lua I added to KP still use ipairs. Of course if I don't forget I should check again that nowhere else I used pairs on a table returned by the engine that has an extra "n".

Here's a version of K.P. with H.O.M.F. bugfixed Kernel_Panic_3.845.sd7. In addition to Cirno fixes, I also fixed the issues with players disconnecting, going spec, or changing team while controlling a hero. And varied other fixes, mostly related to HOMF, CW or SP. However, unless you're playing MP HOMF, HOMF+CW, or SP with saves, you can keep on using KP 3.8 and wait patiently for a proper 3.9.

[Cirno]

going spec, or changing team

Read: Cheating