A soldatscripter's work

[TheOne]

Hello, soldatworlds.

Can you remember a weird server, called "BombSki's MultiMode"? A server with many, many little scripted subgamemodes, of which each as unique as opposed to general soldat gameplay but still fun?
If yes, you may remember ss (Steyr & Soccom). In short: CTF, normal, you carry a steyr, which accelerates you hack-like, along with a soccom with one deadly bullet. Deadly? It's supposed to be. However, in 2 out of 3 hits (or even more often), it did not kill, not hurt.

Now we come to the server-discussion part. I was trying to fix this annoying bug, so I implemented a debug in the script-event OnPlayerDamage. Hm, the event isn't called by those fail-shots. It can't be the damage then.
Next, I changed the second weapon to the AK (Known to me as a precise and reliable weapon). Testing... Every single shot killed, no eats! Okay, I thought, either it's the Weapon-INI-File or the Soccom itself.
From then on I started different INI-settings. I copied Soccom's INI-Settings over to the AK, and the eats were there again. At least it's fixable, I rejoiced.
One by one, I changed the AK-Values to the original ones, which worked well. Speed... nope. MovementAcc... (whatever this does) not. StartUpTime and BulletStyle were identical to the working values. I even tried changing Bink and Recoil! Nothing helped. The last three are FireInterval, Ammo and ReloadTime, values which need to stay like this to keep the gameplay. They can't have any influence on hitting/killing someone.
Pretty confused I turned to the soccom again. I copied AK's values over Soccom's, and as before, it worked. This time I went the other way, changing each value to the one of the original Soccom. It still worked well, when I reached again the point FireInterval, Ammo and Reload. This time I went on changing values (you never know..). Ammo changed.. still kills. Reload changed.. still kills.

Wait. FireIntervall? Wasn't this the delay between two shots? I heard soldat was a spaghetti-code. This, though, beats everything I have experienced.

Forgive me the many words, I hoped to frame it into an interesting story. It was a surprise for me, you can imagine.

To those who know Weapon-Inis:
Soccom's original FireInterval=5 (does not kill)
AK's original FireInterval=10 (does kill)

[Falcon`]

when you specify invalid hair color value in bot file, it's not included in refresh(x) package. beaten?

[TheOne]

Not bad, but might be explainable! Exiting a procedure of sending a package because the exception-catching of an invalid hair color was not implemented? Mine wins.

[Falcon`]

Ok, how about this one:
When you set bot's favorite weapons to "Hands" (so that it does not take weapon by default), noone is able to pick up any weapon from the ground.

[TheOne]

Comes very close to being equal! However... there might be a connection between Hands and Weapons... Same method..

• [Error] Brain -> (OnThink): Type mismatch: Error occured while trying to explain.

[Falcon`]

Arrgh! you think you can make me give up? Never! Soldat bug's list is endless for me:
When you WriteLn/TCPAdminPM('ping') and sent it to some external (c++ best) parser that should respond you with 'pong', then pong arrives earlier than crapcore parses next line (after WriteLn) (OnAdminMessage is called earlier than next line is parsed). Not strictly a bug, but still.

[TheOne]

Funny one. You switched the topic a bit, though! Soldat's magnificient efficiency is an old trashcan here already
Doesn't count, don't compare a lovely pure soldatcode bug with... some lousy deeper-threaded half-soldat error!

[Falcon`]

Meh. next one will require some code:

Code: (pascal) [Select]

procedure test();
begin
try
//insert shitty code that sometimes crashes here
except
WriteLn(ExceptionToString(ExceptionType, ExceptionParam));
end;
end;
On error this will end with a deadly AV (deadly means that this single access violation crashes entire server)

[TheOne]

Hah, how does this effect players? Maybe from the programmer's point of view it might be considered a challenge to mine, but for the soldat player? No. At least it fits the topic.

Oh, I remember another one. We had a map, once, with one area where every player near died, in the air or on the ground. There were no causing polygons, no objects, no sceneries (I checked in PolyWorks). Explain that!

[Falcon`]

Because, excuse (aka because, soldat)
Ok you want a map bugs? fine!
Since 1.6, when you set map's jets to "Infinite" in polyworks (Value over 30 000) then every player is kicked for flood.

[TheOne]

Beats the one I posted last, but the first one? Come up with better errors.

Map bugs, sure. There were several maps, where bots were "stuck" (dancing around in the same place) in EXACTLY the same relative position on the map. Often wasn't fixable by changing any waypoints around. Had to move the entire place to a different height to make it work. How about that?

[Falcon`]

Ehh, i just encountered this one on ls_KernelPanic. Though i'll try to mess with waypoints anyway. Funny thing though is that bots there are stuck very close to 0,0.
Ok, yet another (not so big) map bug:
When you somehow forget about it and add more than 500 sceneries to your map (iirc 500 was the limit), then polyworks will compile it, but on load soldat will spam access violations. Both client and server.

[TheOne]

Ah, well. I thought about posting that time ago. But isn't it a real restriction? Though most mapmakers never noticed it, PolyWorks displays this restriction. Your own fault!

More buggy is, what every mapmaker knows, that sceneries which aren't on the map at all but not removed from the includes-list (placed once in the map, removed them later) still count for this limitation? Even if PolyWorks shows less than 500 sceneries, it bugs.

[Falcon`]

Grrr... what to write, what to wirte. Ok, how about this one:
When you create a bullet that would collide with shooter (bullet's owner) in next tick, that bullet is never spawned.

[TheOne]

Not sure about that tick, but the owner thing is correct.

One more.. Soldat tells the script that a key has been pressed (take 'throw weapon' as example), when in 90% of the cases this is not true...

[Falcon`]

When you ForceWeapon(ID, a, b, c), the for a few seconds after that GetPlayerStat(ID, 'ammo') provides you with better values than Random() itself. How about that?

[TheOne]

That's a good one! Good that they fixed saw, up to soldat 1.6 GetPlayerStat(ID, 'ammo') returned always a value higher than 0. Soldat believed that as well, I guess.

My last one.. if you spawn a flame in OnPlayerDamage at the victim, it magicly reduces the dealt damage! What do you think?

[Falcon`]

yea that's a lovely one. Burning zombies are unbeatable!
Since i'm slowly running out of ideas (however that doesn't mean that there are no more bugs in soldat!), here's a minor combo:
- When you set damage to 0 in OnPlayerDamage, LAW Missile and m79 shell still kills
- When you give bot (or player, if you have modified binaries) a bow, then enemy team(s) bots follow him no matter what, they just forget that there's such a thing like a waypoints on the map
- WriteConsole(255, ...) throws Access violations (and hey, that's likely in OnCommand() if you forget about it!)
- Right after spawning, player's coordinaters are still set to death's or 0,0 if just joined
Any judge over there that can post final scores?

[dnmr]

Any judge over there that can post final scores?

soldat wins.

You both won too though, this thread is priceless.

[tk]

In 1.5.0 (don't know about the current version) after killing all objects on the map with KillObject(), bots started to prone and couldn't move from spawn.