Spring RTS Engine

Hmm, not sure what you really mean. But one of your AI ally is building a window inside an enemy kernel, which is not a very polite behavior.

I realised it would be better if AI turned their buildings toward the map center, especially on this map: vertical sockets have their exits blocked, and that could be considered a bug too.

Also, I had no problem watching the replay because I "opened it with", "Spring.exe", but it appears lobbies are much more touchy about start scripts syntax than Spring.exe and won't show it. Stuff like double semi-colon, comments, or not having exactly all the tags themselves would have generated, confuse them alot.

Then there is also the problem that AI fire obelisk on themselves, enqueue stupidly too much stuff in constructor queue, do not use any special abilities beside NX and nuke, cannot play network, etc...

But overall, that multiplayer lobbies can't parse single player demos or that the AI doesn't play to the best that it could doesn't prevent the game from enjoyable imo. I'll fix eventually, but no urgency. Actually I already changed a bit the generated start scripts, and added an EngineOptions.lua to remove the useless options, but such small edits don't warrant a release.

Is it ok to double post?

I have improved a bit and bugfixed alot the AI. Still need to add network faction support though.

I made some shields textures for ONS:





[Click to enlarge]


And so now I am upgrading the O.N.S. mode:


[Click to enlarge]

Currently, only the sockets that are furthest (in number of jump) from kernel are unshielded, instead of all sockets that are at extremities. That means that if only one socket is furthest, then only one socket is attackable. Which is like super-ONS: even less sockets to defend. But I admit not what I had in mind. I'll probably make it a mod option between:
- No ONS
- Unshield all extremities
- Unshield all sockets at the max number of jump from kernel
- Unshield only one socket, the furthest (taking into account first number of jumps then distance of last jump)

From that pic you can see it looks like I will have to learn how to draw with LUA, as my current method to draw beam by using C.E.G. flares spawned by script looks unpretty. You can also see each socket only draw one beam to its closest source (=other socket more closely linked to kernel and in range), even if it has more than one source. I may have to fix that.

Would appreciate help on making shields team colored.

Heh, that reminds me of Fibre.

Proper Onslaught rules would be requiring that a player captures a spot adjacent to an enemy node to attack that .

KDR_11k wrote:Heh, that reminds me of Fibre.

Oh. Do you mean you had the same sort of node-scanner algorithm in Fibre and that I totally forgot about it?

KDR_11k wrote:Proper Onslaught rules would be requiring that a player captures a spot adjacent to an enemy node to attack that .

It's been a long time since I played UT2K4 but I really can't remember that rule. I could still implement it though.


I made progress. The node-scanner now doesn't make mistake when there is a loop in the web.
Pix: Before fix, after fix.

The LUA code is much closer to final now. When only one player, it now works very well.

However, the extremity finder and count from extremity still get utterly confused when there is more than one kernel in the network: Infinite loop, breakage of symmetry, etc.. And it can't be left like that or else team games would be impossible.

I managed to draw the web of geo with some openGL function when selecting a building or pressing F4. Unpretty but it'll do. However I still need to learn more openGL LUA to also draw pretty team colored arcs, the ones that are now still done with COB/BOS and CEG. I looked into your network_arceffect.lua but couldn't understand it.

It's been a long time since I played UT2K4 but I really can't remember that rule. I could still implement it though.

In UT2k4 you have to capture a node next to the main base in order to be able to damage it.

But I think that this is not a good idea for KP.

Ok. Maybe I'll make it as yet another ONS option, as that sound like an ultimate anti-rush, and the whole point of ONS (beside me having fun drawing fluo webs) is to newbify KP by forbiding rush.

Today I fixed the node scanner, and then, I learnt Spring's Lua's OpenGL!
Pic1 -> Pic3

Yeah, KP is very slippery slope, once you're too far behind in unit production the ONS mode would just waste your time.

Well, you could make an ONS mode where the only bases that produce units are the leaves of your tree. That would eliminate the slippery slope. It would also probably be lame and confusing, though.

zwzsg one question: you said that idea of the kernel panic is to be a simple mod, in a future (or far future) kernel panic will have many simple factions instead of just 3, or this will make the game complex (even with simple factions)???

Don't ask me, I don't make Kernel Panic, KDR_11k does.

Personnaly I'd rather have many simple factions. For instance I don't even like the terminal/obelisk/firewall nor the minelauncher & NX flag.

Oh @§*#, I just realised my Geo Web analyser has a flaw.

On all maps I used it so far it worked fine:


But today, I just realised such is not always the case:


Appears I have to put more thought into my algorithms.

Anyway, I still hope to release 3.1 for next weekend.

you might want to start from a spanning tree, perhaps a minimal one; then try applying your current algorithm.

Thanks, but I just fixed:



The new algorithm is however much more complex, I just hope it won't eat too much CPU, fail, or even worse, hang!

I just uploaded KP 3.1

• Kernel Panic 3.1 - Complete Installer: http://jobjol.nl/1683
• Kernel Panic 3.1 - zipped mod and maps: http://jobjol.nl/1684
• Kernel Panic 3.1 - Just the file Kernel_Panic_3.1.sd7 http://jobjol.nl/1685

KP 3.1 changelog:
- Made again a complete installer
- Better LuaAI. Now handles all three factions, with all three specials, and ONS
- ONS mode overhaul
- Most of the sudden flood of lua errors in mid-game should be fixed
- Bugs can't turn into exploit too soon after spawn, to prevent them from blocking windows
- The hole now has an "autohold" setting, and the LUA gadget has been edited so that it passes it down to the produced worms.
- Lots and lots of other tiny fixes everywhere

I think the Flows speed scaling should be removed. It makes it bad to start with then too good at the end and it's very unintuative and hard to keep track of.

Also give all constructors and factories a workertime of 1 so that build costs are easier to interpret. Also find some way to display the build speed bonus that the kernal gets from owning extra sockets.

Google_Frog wrote:I think the Flows speed scaling should be removed. It makes it bad to start with then too good at the end and it's very unintuative and hard to keep track of.

The problem was with the stupid Marble Madness map that's still highly popular, on that map you can make a flow and perform a near uncounterable attack. People proposed much worse solutions like disabling flow construction until x minutes have passed.

I actually think that Marble Madness is a good size for KP 1v1, and its main flaw is that it has too many vents that are too close together. Larger maps just make the game into a big aimless sea of bits, which sounds nice but imho isn't all that much fun.

It may be a little bit small, but certainly not so microscopic that tactics that work exceptionally well on it should be disregarded as gameplay problems.

The problem is physical distance. The flow can arrive so fast that it's too fast. I don't want to nerf it, the thing's already weak enough once the game gets going and must be used in large numbers to have some effect which doesn't really apply to any other medium or heavy units (well, except Touhou but that's not really the main game).

I always figured that KP could just use a little extra last-line-of-defense. A handful of turrets spawned at game-start at the home base would protect you from various rush-balance issues that are really hard to fix with the more elaborate tweaks like the flow-boost thing.

It worked well in Z.

But that would mean raiding cons near the kernel would no longer work. The last line of defense is that units coming out of a fac are invulnerable so small numbers of units can't destroy the kernel, the problem with the flow is that it will usually get the player who uses it ahead, if e.g. system opens with a byte they're going to be screwed on expansion, if they open with anything else the flow will kill it and set them back. The other factions don't have such an easy raid attack, walking over with a few bits to kill a con takes more time. Also the MM hill makes it easy for a flow to escape.