2024-05-16 17:31 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002832Spring engineGeneralpublic2012-02-18 11:47
ReporterGoogle_Frog 
Assigned ToKloot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Product Version 
Target VersionFixed in Version86.0 
Summary0002832: Enemied units can get stuck in each other with movectrl
DescriptionOccurs since 84.0. This looks like a 'wontfix' so I'll argue against that now; this used to work and a lua fix is basically impossible.

If the new pathfinder precludes a fix I think the next best thing would be a lua toggleable flag that lets units push enemies in the same
Additional Informationspring_84.0.1-461-gae47ae2
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0007908

user744

if this is about jumpjet gadget units jumping on top of each other:
Spring.TestBuildOrder can check if a unit can be placed at x,y,z

~0007909

Kloot (developer)

Last edited: 2011-12-14 11:59

_No_ collision detection/handling is done between MoveCtrl'ed units (if the collision involves a regular and a MoveCtrl'ed unit, the latter will not react to it) and you pretty much have to deal with these edge cases yourself.

~0007913

Google_Frog (reporter)

"if this is about jumpjet gadget units jumping on top of each other"
Infeasible, units move.

"if the collision involves a regular and a MoveCtrl'ed unit, the latter will not react to it"
It is perfectly reasonable that the latter does not react. In this case the former does not react either. This isn't an edge case and it is extremely difficult to handle as the entire pushing code would need replication and extra units movectrled. The engine already has a method of ensuring units are not stuck in each other, it just doesn't occur between enemies.

Also I copy pasted this ticket when I failed to make it the first time (some mantis error) and I missed the last bit. "..push enemies in the same way allies are pushed."

~0007914

Kloot (developer)

Last edited: 2011-12-14 13:35

"The engine already has a method of ensuring units are not stuck in each other, it just doesn't occur between enemies."

You could read the changelog:

    make pushing of enemy units during collisions a ModInfo option ("allowPushingEnemyUnits")

(this obviously has other gameplay implications, hence why it is optional)

Another change between 84.0 and the upcoming 85.0 that may help is that non-moving non-MoveCtrl'ed units will also scan for nearby collidees and react to their presence.

~0007924

Google_Frog (reporter)

"Another change between 84.0 and the upcoming 85.0 that may help is that non-moving non-MoveCtrl'ed units will also scan for nearby collidees and react to their presence."
Not fixed in spring_84.0.1-539-gd54b98a

"make pushing of enemy units during collisions a ModInfo option ("allowPushingEnemyUnits")"
Could this be a lua toggleable unit parameter instead? I only want enemies to repel when they are stuck in each other, not in normal movement.

~0007926

Kloot (developer)

Last edited: 2011-12-16 19:41

"Not fixed in spring_84.0.1-539-gd54b98a"

fixed in combination with allowPushingEnemyUnits, obviously


"Could this be a lua toggleable unit parameter instead?"

No, too much of a mess IMO.

"I only want enemies to repel when they are stuck in each other, not in normal movement."

You have other options to handle that, such as:

1) checking the landing position for the presence of enemy units
2) aborting/altering the jump if 1) does not come up empty, or
3) temporarily making the jumping unit non-blocking after it lands

(if you can detect the "stuck" situation you can also prevent it from happening, and you would still need to disable the repelling afterwards which requires doing 1 in any case)

~0007932

Google_Frog (reporter)

I don't think I could reliably detect stuck. My idea was to enable pushing for units in flight and maybe for a few seconds afterwards if required.

Could the engine detect stuck and push enemies in that situation?

I really don't think there is a good modside solution to this. Because units can be compressed I doubt Spring.TestBuildOrder or Spring.GetGroundBlocked are appropriate ways to detect stuck units for 1) and I am unaware of other methods. 2) is not workable because you're suppose to be able to jump at enemy units and changing the trajectory mid flight would look really strange. 3) just pushes the problem back a few seconds because there is nothing ensuring the units move off each other while the jumper is non-blocking.

The only way I can see to do it is with a moveCtrl implementation of pushing. But that is really really messy.

~0007938

Godde (reporter)

Its really easy to make enemied units get stuck inside each other in Spring 84. I tried ordering a mix of enemy and friendly units about. They got stuck inside eachother frequently.
I tried it with goliaths in Zero-K 9.2 and BA V7.62.
The units were on hold fire so they wouldn't kill eachother.

Em... Were this fixed in later versions of spring?

~0007940

Kloot (developer)

As said units of different allyteams get stuck because when they collide neither is pushed (unless allowPushingEnemyUnits), so the choice is between stuck units or seeing your lines of tanks being broken by enemy forces. And no, there is no magic solution that prevents stuck units _and_ disallows pushing for enemies at the same time.

I might add some code so that pushing is still allowed if a unit comes into contact while not on the ground (as with the jumpjet gadget), though afterwards it would still be likely to get stuck.

~0007944

Google_Frog (reporter)

"I might add some code so that pushing is still allowed if a unit comes into contact while not on the ground (as with the jumpjet gadget), though afterwards it would still be likely to get stuck. "
How is that significantly different to adding a lua controllable unit parameter?

~0007945

Kloot (developer)

1) the amount of work it involves
2) the amount of noise it introduces

~0008109

abma (administrator)

should be partly fixed with https://github.com/spring/spring/commit/d4d0308a3d9a60f767e4cb44a96a333f8b2e471d

(thx kloot!)

~0008136

Google_Frog (reporter)

That is a hacky fix for this particular situation that doesn't work consistently. What is the great problem with a movectrl setting in the locations of the added " collidee->inAir" checks?

~0008299

Google_Frog (reporter)

Not fixed in 85.0.1-188-g0514c38

~0008302

Kloot (developer)

release branch != develop branch
+Notes

-Issue History
Date Modified Username Field Change
2011-12-14 10:15 Google_Frog New Issue
2011-12-14 10:42 user744 Note Added: 0007908
2011-12-14 11:51 Kloot Note Added: 0007909
2011-12-14 11:54 Kloot Note Edited: 0007909
2011-12-14 11:56 Kloot Note Edited: 0007909
2011-12-14 11:58 Kloot Note Edited: 0007909
2011-12-14 11:59 Kloot Note Edited: 0007909
2011-12-14 13:16 Google_Frog Note Added: 0007913
2011-12-14 13:27 Kloot Note Added: 0007914
2011-12-14 13:35 Kloot Note Edited: 0007914
2011-12-14 15:02 Kloot Status new => closed
2011-12-14 15:02 Kloot Resolution open => no change required
2011-12-14 15:02 Kloot Fixed in Version => 85.0
2011-12-16 08:13 Google_Frog Note Added: 0007924
2011-12-16 08:13 Google_Frog Status closed => feedback
2011-12-16 08:13 Google_Frog Resolution no change required => reopened
2011-12-16 15:19 Kloot Note Added: 0007926
2011-12-16 19:41 Kloot Note Edited: 0007926
2011-12-17 06:30 Google_Frog Note Added: 0007932
2011-12-17 19:42 Godde Note Added: 0007938
2011-12-17 20:13 Kloot Note Added: 0007940
2011-12-18 00:31 Google_Frog Note Added: 0007944
2011-12-18 00:57 Kloot Note Added: 0007945
2012-01-09 23:28 abma Note Added: 0008109
2012-01-12 11:20 Google_Frog Note Added: 0008136
2012-02-14 04:27 Kloot Status feedback => resolved
2012-02-14 04:27 Kloot Fixed in Version 85.0 => 86.0
2012-02-14 04:27 Kloot Resolution reopened => fixed
2012-02-14 04:27 Kloot Assigned To => Kloot
2012-02-18 08:44 Google_Frog Note Added: 0008299
2012-02-18 08:44 Google_Frog Status resolved => feedback
2012-02-18 08:44 Google_Frog Resolution fixed => reopened
2012-02-18 11:47 Kloot Note Added: 0008302
2012-02-18 11:47 Kloot Status feedback => closed
2012-02-18 11:47 Kloot Resolution reopened => fixed
+Issue History