Spring RTS Engine

As i have often pointed out and others did too: spring sometimes has terrible collisions, pathfinding and targeting.
My game is currently unplayable and its not just in mine.
What i have observed is:

• Units getting stuck on cliffs
• Stuck in features
• Stuck in other units
• Refusing to fire even though there is a clear line of sight
• Line of sight based weapons attempting to fire trough up to two layers of ground
• More friendly fire than enemy fire damage.
• Blobbing of extreme degree

I have already sent mantis reports and complained in the past.
As google frog suggested me to debug these i have come up with the idea of making screenshots of those for starters.
Since i have no idea how to debug or reproduce those issues in a way that could be useful i thought illustrating the issue with screenshots is the first step.
Can i dump them here or does anyone have some other suggestions?
I am hoping that perhaps some other gamedevs can also contribute.
Is there something like /debugcolvol for pathing/targeting or some other tool to help nail those issues down?
Perhaps together we can crush this terrible menace.
Any feedback would be appreciated.

These are *all* the issues you have ever reported on mantis, and I am having difficulty seeing any (alone or combined) that match the level of apocalyptic unplayability you are sketching here.

code_man wrote:Refusing to fire even though there is a clear line of sight ... i have no idea how to debug or reproduce those issues

How could you possibly *not* know to setup a simple demo reproducing just this bug if it occurs so often that it breaks your game?

Is there something like /debugcolvol for pathing/targeting or some other tool to help nail those issues down?

debugpath (alt+P) for pathing.

For targeting: /debugcolvol already shows a red dot for aim-at pos (if it's different from mid pos - the purple dot), yellow dots for each weapon's aim-from pos, and more (exact colours and meanings here).

Apparently there's also /debugtraceray which might be relevant but I never used that one.

Can i dump them here or does anyone have some other suggestions?

What's the problem with Mantis? You can add screenshots as attachments.

Kloot wrote:CodeManTickets.jpg

These are *all* the issues you have ever reported on mantis, and I am having difficulty seeing any (alone or combined) that match the level of apocalyptic unplayability you are sketching here.

Maybe i got things confused, i was sure i did make those issues, but its been a long time.

And im not exagerating, its pretty horrible.

How could you possibly *not* know to setup a simple demo reproducing just this bug if it occurs so often that it breaks your game?

I was thinking i needed something a little more solid.

Also my game is not released yet, i could attach a copy of the sdz but i dont know if its such a good idea.

sprunk wrote: debugpath (alt+P) for pathing.

For targeting: /debugcolvol already shows a red dot for aim-at pos (if it's different from mid pos - the purple dot) and yellow dot for each weapon's aim-from pos (exact colours and meanings here).

Apparently there's also /debugtraceray which might be relevant but I never used that one.

What's the problem with Mantis? You can add screenshots as attachments.[/quote]
I have quite a lot of screenshots, i dont know how many i can dump enough there.

code_man wrote:I was thinking i needed something a little more solid.

Like what, instructions chiseled into a block of granite? Either the simulation has a deterministically repeatable bug or it doesn't, a demo is the most solid form of evidence (short of pointing out flaws in the actual code) you can present for one.

code_man wrote:Also my game is not released yet, i could attach a copy of the sdz but i dont know if its such a good idea.

You have a choice between doing that (open a private ticket if you must keep it secret) or reproducing your issue(s) as closely as possible in an existing game, cool stories and screenshots don't cut it if you expect anything to be fixed.

I don't have most of your issues with the pathfinder. That does not mean they don't exist, just that I have implemented configuration (or hax) in ZK that removes the issues. The engine is not easy to use in this regard. You also need to be more precise.

I never see units stuck on cliffs in the sense that they are stuck in impassible terrain. However, there is a default enabled (iirc) modrule that makes units able to become stuck on cliffs. You may want to check if it is enabled.

I never see units stuck on features. Units only become stuck on other mobile units when the other unit is a nanoframe, and you can remove this if you design your factory spaces correctly. Units can become stuck between structures (https://springrts.com/mantis/view.php?id=5729) and if I notice it occurring too much I might make a workaround. I recon setting the typemap below structures to impassible would solve the issue. I almost forgot about factories. Factories are full of pathfollowing nonsense and ZK has had a gadget to stop units getting stuck on them for many many years. I don't know what issues in the base engine exist at the moment with units getting stuck on factories.

On to targeting. Targeting in Spring seems fairly solid. I don't see units refusing to fire when they have clear line of sight or trying to fire through the ground (unless I use the tag that makes them able to fire through the ground). Of course, you can get broken looking behaviour if you don't pay close attention to your units collision volumes. Worse, many maps contain features with ridiculous collision volumes so this is somewhat beyond your control. My solution is to not use those maps.

Define 'blobbing'. Do you mean units stacking up on each other? If you dislike that then modify your footprints to suit your needs. If you dislike how they blob to move you should be using a raw move gadget.

code_man wrote: [*]Units getting stuck on cliffs[/*]

https://github.com/Balanced-Annihilatio ... og.txt#L21

Issue acknowledged in ba-changelog. Might ask them how they fixed it.

Jools wrote:

code_man wrote: [*]Units getting stuck on cliffs[/*]

https://github.com/Balanced-Annihilatio ... og.txt#L21

Issue acknowledged in ba-changelog. Might ask them how they fixed it.

Basically, we disallowed GroundUnitGravity, which caused ground units to jump/fall off cliffs with their speed and get stucked on these.
" allowGroundUnitGravity = false," in modrules.movement"

It seemed like it did cause some lags upon collisions, so we also enabled " allowUnitCollisionOverlap = true," but i'm not sure it had anything to do with disallowing unit gravity.

Pros: No more units stucked on cliffs.

Cons: more collisions with ground it seems -> more units get pushed away from impassable grounds with the same effect as unit-unit collision, which as you know is pretty ugly without a proper handling of those(unit keep their velocity and are only moved away.

Without testing - perhaps turning off all ground unit gravity is a bit of a sledgehammer solution, and you could get the benefits without the downsides by increasing units mass to a suitable value, instead.

Wow, thanks for the open answer, it's appreciated.

code_man wrote: [*]Refusing to fire even though there is a clear line of sight[/*]

I'm a bit rusty, but I recall we had some issues with the annihilator shooting the commander in the neck, or not shooting because there was some shrubbery in the way. You might experiment with the ignorefriendly or similar named tag, but this is a bit difficult balancing issue. Ideally, you would want units to fire through features with low density or through friendly units that are worth less than the enemy unit you want to destroy. I think it's difficult to value this automatically.

You also don't want the annihilator/bertha stuck on shooting at a cliff or similar obstacle.

Kloot wrote: Like what, instructions chiseled into a block of granite? Either the simulation has a deterministically repeatable bug or it doesn't, a demo is the most solid form of evidence (short of pointing out flaws in the actual code) you can present for one.

You have a choice between doing that (open a private ticket if you must keep it secret) or reproducing your issue(s) as closely as possible in an existing game, cool stories and screenshots don't cut it if you expect anything to be fixed.

The screenshots idea was to figure where those things happen often and detect patterns in those and help nail things down.
I was thinking perhaps making a debugging map/gadged based on some common cases.

From my imaginations its a lot of hard work till you can nail something so complex as pathfinding down from just one or more replays, so i assumed you need more data than just one.
But if devs think a replay or a few suffices then by all means ill give you some.
I just wanted to make things easier for the engine devs since this is a major issue for me and i don't want it ending up on the stack of the todo list.
Perhaps i overthink this a litte, but i just want to find the best way to resolve this, sorry if i seem a bit irksome.

I file a issue and upload a demo, once i figure out where to put the game, since i cant attach it.

Google_Frog wrote:Define 'blobbing'. Do you mean units stacking up on each other? If you dislike that then modify your footprints to suit your needs. If you dislike how they blob to move you should be using a raw move gadget.

Yes and when of them sees a target and fires, it almost always leads to a chain reaction.
The footprints, and i belive the radiuses are already set to fairly resonable values, i dont think this helps.
What is a rawmove gadget? Do you mean writing my own lua pathfinder or something like that?
It wouldnt resolve the issue that units often commit friendly fire anyhow.