Random possible bugs I've spotted while playing the game today. - Penetrator will attempt to move to engage targets while on 'Do not fire at radar blimps' and 'hold position' move state. (even those out of range, as if it was on limited move state) Replay: http://zero-k.info/Battles/Detail/215566 and http://zero-k.info/Battles/Detail/215528 (attempts to engage units in the middle) (Easily replicated) - Com upgrade will destroy combat drones + adv. combat drone and set Area Shield to 0 (or a near 0 ammount.). Personal shield unaffected? Replay: http://zero-k.info/Battles/Detail/215561Both of these I was just goofing around with CAI and testing the new com upgrades and stuff out. Enjoy. <3 Irish
+0 / -0
|
quote: Penetrator will attempt to move to engage targets while on 'Do not fire at radar blimps' and 'hold position' move state. |
It is such an old bug. And I HATE IT!!!!
+0 / -0
|
quote: Do not fire at radar blimps |
There are no radar blimps in zk. Yet.
+5 / -0
|
by radar blimps i mean firing at targets you dont have LOS of, but have radar coverage of. the little red dots on the map. Im unsure of the exact name of the fire state, but if set to off, the pene wont fire on things you dont have los of. that state. if its turned off the pene will attempt to move to engage which it shouldn't because move mode is hold position. Still highly annoying. Especially in http://zero-k.info/Battles/Detail/215528 when my penes tried to move directly into the line of fire, causing me to lose them.
+1 / -0
|
Radar blip: Radar blimp:
+6 / -0
|
More bug observations in the CAI mode: when u build a terra bridge veh refuses to follow it like its buring! Replay here. Bridge is wide enuf. http://zero-k.info/Battles/Detail/218624
+0 / -0
|
That's known. Pathing map updates really slow in standard pathfinder mode. And your memory overflows very fast in QTPFS mode :)
+0 / -0
|
well very slow ?= never? just take any version of spring engine (including latest) and test. bots have no issues, veh and hover are just helpless. also, hw to change pathing mode?
+0 / -0
|
quote: well very slow ?= never? |
Dozen or more minutes. For average ZK games, that's almost never, yes. quote: also, hw to change pathing mode? |
Assuming you were asking "how" and not "what kind of hardware i need": !setoptions pathfinder=qtpfs You can also find the option somewhere in zkl's "change room settings" feature.
+0 / -0
|
Thanks! Will test it out! Btw do you know why does it work for bots? And the hardware I'd imagine core i7 with 8 GB RAM should do just fine, unless that algorithm is made of insanity.
+0 / -0
|
@[GBC]HeadHunter: Unfortunately, insanity does appear to be a key component in that algorithm. It's not the biggest deal in 1v1 with those specs, but it doesn't scale that well for RAM usage.
+0 / -0
|
Isn't it just terraforming and the destruction of windgenerators that doesn't always update pathfinding. I've never really had trouble with stuff like nuke craters or Quake missiles.
+0 / -0
|
quote: Isn't it just terraforming and the destruction of windgenerators |
Hmm, i guess science has to be done, so i better get some cake and do what i must because i can. My naive assumption, however, is that there's nothing special about windgens and they are just the most common killable obstacle.
+0 / -0
|
is it possible to one-time-calculate a new pathmap with a widgetbased button or such? meaning is there a command or function to call the build?
+0 / -0
|
I believe path-updating have to be done on all machines, so it can't be a widget but a gadget. And all players would have to update paths. It would be a new strategy - to press "update-pathing" button and see how much your opponents are lagging. Player with more RAM wins. Definitely not a good idea. (If it really works this way)
+1 / -0
|
IF the pathing map is needed to be equal at all times on all pcs, the calculation could be done equally on all machines. once the first/fastest 1 or better 2 machines are done, the map is distributed and crosschecked. other machines stop at that point to calculate AND slower machines dont join the distributed crunching from that point on. solved.
+1 / -0
|
CRITICAL: Undead Scorchers in newest engine version Scorchers will not die when hitting 0 hp. They will leave a scorcher with 0 hp that wont be attacked nor will attack and will continue to give its own LoS of an area. When this occurs, the following error message is generated: quote: [f=0004499] [Lua unit script framework] Error: [string "scripts/corgator.lua"]:258: bad argument #2 to 'Explode' (number expected, got nil) [f=0004499] [UnitScript] Error: LuaRules::RunCallIn: error = 1, CLuaUnitScript::Killed, [string "LuaRules/Gadgets/unit_script.lua"]:259: attempt to index global 'debug' (a nil value) |
Screenshot:
+1 / -0
|
http://code.google.com/p/zero-k/source/detail?r=12293Way ahead of you. Scorchers were given a broken LUS between v1.1.12.0 and I did not notice that someone had done so when I made v1.1.12.1.
+0 / -0
|
Bug with ZKL (latest): Attempting to open a link (Such as ) will crash zkl. Would suggest adding code to the client to open external browser with external (non-zero-k.info) links to fix.
+0 / -0
|
you can force to always use external browser if you want (its in zkl settings at the bottom region). do you mean to force this behavior independent of this option for all external links?
+0 / -0
|