Spring RTS Engine

It was usuall (with engine older than 84/5.0), that units at the end of the path from factory were not stacked on the place (so last waypoint was choosed a bit randomly). So outcome of this was, that units on rally point had space beetween each other.

Now they try to reach exactly the same postion, so its usuall, you can have 50 units on one square meter.

Is it a feature (i can imagine why) or bug?

(My observations are based on NOTA units behavior - mod was not changed - only engine)

it is not just factory rallyepoints, in 85.0 units can generally stack closer than on 0.82.7
example:

In 0.82.7 it would have been impossible to cramp so many units so close with just one move command. They would have spread out to cover at least 3x the area. Undecided if it is worse or better.

Since there were already changes on pathfinding/unit behaviour it is maybe better to get a test version and give feedback on that.
(some things are fixed/improved)

Here it its test on latest 85 - 85.0.1-183

My path:



and behavior with latest spring



And now, how it was (behavior in 82*). This example with more space beetween units at the end of factory_leave_path as it was usuall before 84/5... maybe before 83, im not sure:



I can understand, that adding scatter_command or random_ending_waypoint at the end of "leaving_path_from_factory" can be matter of game/mod developers, but theres no mention about such engine_developers decision in changelogs, so i think, its only bug.

You didn't read knorke's response to you. It's not about factories. It's about a bunch of units moving to one spot. It's not a bug, it's an engine improvement. Now there is a choice. If you want units to go to one spot you can. If you want them to scatter, a simple widget can implement that.

CarRepairer: I want such widget, under a WTFP License, with a lifetime guarantee of 24hr fix against any borkedness in the widget lua code introduced by future engine release.

CarRepairer wrote:You didn't read knorke's response to you. It's not about factories. It's about a bunch of units moving to one spot. It's not a bug, it's an engine improvement. Now there is a choice. If you want units to go to one spot you can. If you want them to scatter, a simple widget can implement that.

It was not clear to me, if it is ment as feature :). Yes, that was what I was asking for - "its matter of game/mod developers to scatter untis, its not bug".

Btw in 85.0.0.0.0,.... wasnt result such good as on picture 2. Units were all on a same spot.

Thanks for answers.

It's not really a feature but more correct behavior. If you order a unit or units to go to a single spot, they should do so, to the best of their ability, and not decide that someone is in their spot and run off far away (maybe into enemy territory). It would be nice to have an area-move just for factories and their rally points.

I like the new behaviour.

I like the previous one. because you always can see how much units you have built

Theres a difference between behavior of 85.0, that danil_kalina knows and that I was talking about, and behavior in latest 85.0.1-*+

The first (85.0), when units are on the same place not-respecting physical world, is bug, im sure. And that was I was talking about in first post and what danil_kalina knows (or I think hes talking about :)).

The behavior in latest 85.0.1* is better, so you can still reconize each unit. And I think that was what was other guys talking about (knorke, frog, carrepairer). Maybe in their mods its not such big difference in these engine versions, but for NOTA players its big difference.

Is it a feature (i can imagine why) or bug?

Feature, Spring 83.* and up allows units to cluster more closely together (without scattering randomly) than 82.* and older versions did. As a result of this and other changes their behavior / movement is less chaotic during collisions, which you can see in these videos:

http://www.youtube.com/watch?v=TyBeCD4dGDI [82.*]
http://www.youtube.com/watch?v=_HcaumIB20Q [86.*]

Note that "physical" limits are still respected at all times (units cannot normally be stacked), so this...

you can have 50 units on one square meter... The first (85.0), when units are on the same place not-respecting physical world ... in 85.0.0.0.0, wasnt result such good as on picture 2. Units were all on a same spot.

does sound like a bug, assuming it wasn't an exaggeration.

82.* video would have been funnier with rage faces.
---
One thing than can give the impression of clumping is that selection rectangles (=footprints?) quite often overlap like this:
/give 100 arm_flash in XTA 9.679 with 85.0


But it depends on the model etc if/how bad it looks.

For mobile ground units the minimum spacing is determined by the radii of their MoveDef footprints (the red rectangles that show up in debug mode, http://imageshack.us/f/846/blauk.png/), so some are worse off than others.

Ah so that explains this http://www.abload.de/img/blalflr5.jpg then.
What is the idea behind this though and how excactly is the red square calculated?
So to try keep them further apart I changed the movedef:
footprintx = 2, --was 1
footprintz = 2, --was 1
and everybody got caught in a mosh.
(on moving it looks good but when coming to a stop it takes several seconds for the pushing to stop, with 20 units)

you can have 50 units on one square meter... The first (85.0), when units are on the same place not-respecting physical world ... in 85.0.0.0.0, wasnt result such good as on picture 2. Units were all on a same spot.

does sound like a bug, assuming it wasn't an exaggeration.

with todays stable version, it not like on image2 http://nota.machys.net/images/examples/scatter2.jpg, its like this



last comix window is what units do in simple move. They dont do the same like on ending point (yes, different pathfinding in big group, but result respect more unit's size).

I've noticed this aswell. When you have alot of units they will go abit of zigzag before going straight. I think it is because of heatmapping.

Like if you have a group of tightly grouped Peewees some will start to move in the opposite direction of the command you just gave them.

Default heatmapping definetly makes Spring1944 infantry path badly in groups when I tested it.

Although I see that "HeatMapping=0; " in MOVEINFO.TDF in gamedata folder.

Hm... what else would cause the Peewees to turn around like that?

In S44 movedefs.lua it is "heatmapping = 0,". But that shouldn't matter right?

You could also try adding heatproduced = 0.5 but that shouldnt matter if heatmapping truly is off.
I think it makes them "produce less heat", reserve a shorter path for the units moving.

Kloot wrote: http://www.youtube.com/watch?v=_HcaumIB20Q [86.*]

How do you make the tanks drive through the other units? FPSing or is it possible to make units ignore pathing around other units? That would be cool.

knorke wrote:What is the idea behind this though?

Basically that the collision response function has to be smooth, ie. a small change in input should result in a small change in output.

Godde wrote:I've noticed this aswell. When you have alot of units they will go abit of zigzag before going straight. I think it is because of heatmapping.

Like if you have a group of tightly grouped Peewees some will start to move in the opposite direction of the command you just gave them.

The cost of a square is increased when there are mobile units present (by some code that long predates the heatmapping feature), which becomes more noticeable with dense groups. For 86.0 this will be optional to enable/disable.

How do you make the tanks drive through the other units? FPSing or is it possible to make units ignore pathing around other units?

It is just a function of relative mass (and speed and impact angle). So, give heavy tanks appropriately large mass-values in their UnitDefs compared to the light squishy peons.


wrt. the clumping in NOTA: http://imageshack.us/f/839/blamm.png/

Godde wrote:

Kloot wrote: http://www.youtube.com/watch?v=_HcaumIB20Q [86.*]

How do you make the tanks drive through the other units? FPSing or is it possible to make units ignore pathing around other units? That would be cool.

This looks pretty sweet - is it using QTPFS or regular?

Neither and both, it's independent of the PFS.