Loading...
  OR  Zero-K Name:    Password:   

The problem with large clumps of units and move commands

22 posts, 903 views
Post comment
Filter:    Player:  
Page of 2 (22 records)
sort
10 years ago
When you have a large clump of units and you do an ordinary 1 click move command, they won't stop moving until they reach the point you set. The problem with that is that when all those units are trying to get into the same spot they bump into each other and may never even reach that spot. That causes a lot of problems and forces you to micro manage them more. I think there should be a widget that sort of makes a formation when you do a 1 click move command. Not ncessarily a complicated formation, as long as all the units are directed to move to separate spots near the general area of the click.
+2 / -0


10 years ago
While it may not be a bad idea to have units give up on moving to a location intelligently, why are you using 1-click move? Do you dislike line move for some reason?
+1 / -0
Well, it's just that sometimes I want to set a clump of units to a certain area but I don't actually want to engage the enemy so I see less of a point to put them in a line formation. Plus, it's a hell of a lot faster. I know that a lot of other rts games handle it similar to the way I stated it should be handled in and it's generally better design anyway. And I didn't mean that they should give up on moving to a certain location, I said I wanted to automatically have the units not all move to the same location and rather... I think I'm just repeating my self. Basically, giving a move command to several units should not put the move command for each unit all in the same spot, but instead around the area you clicked so they don't start having seizures.
+1 / -0

10 years ago
He has a point, if the default behavior is stupid and the user has to always work-around the default behavior, maybe the default behavior needs to be changed? Obviously this is something that should be handled engine-side especially since the clumping was started by mucking around with the pathfinder in the first-place, but a problem is problem.
+0 / -0
10 years ago
I always use line formations. Just having move commands spread out in formation by default doesn't help that much as the pathing will make the units collide anyway while it will become a problem when there are obstacles such as hills, ridges and builings as the units will get move orders on top of those.
If the implementation is good it might work but I'm not sure a simple solution will work well.
+2 / -0


10 years ago
Well, If you insist: Hold CTRL while clicking to move and that will get the units to arrive in the same configuration they are when you send the order. Alternativley, hold ALT while clicking to move and the units will form a box (though not intelligently by unit type or anything). It isn't ideal or recommended, but it will fix the issue you are having.
+1 / -0
EDIT: deleted some stuff because I misread some of the previous posts.

The solution involving the alt button doesn't seem to work and I'm totally already aware of the ctrl move command. Seriously though, it can get quite annoying if you always have to hold ctrl everytime you want to 1 click move. The point of 1 click moving is that it's quicker than actually formation moving and holding ctrl slows that down a little.
+0 / -0

10 years ago
quote:
He has a point, if the default behavior is stupid and the user has to always work-around the default behavior, maybe the default behavior needs to be changed? Obviously this is something that should be handled engine-side especially since the clumping was started by mucking around with the pathfinder in the first-place, but a problem is problem.

As I recall it was greatly improved in spring 92.0+.

quote:
First of all, the solution that involves pressing alt doesn't work. Second, why do you keep insisting on having workarounds rather than fixes?

Because fixes don't magically appear out of nowhere because someone demands them.
+0 / -0

10 years ago
As it happens though, someone already wrote a widget that does pretty much what you want:

http://code.google.com/p/evolutionrts/source/browse/trunk/evolutiondev.sdd/LuaUI/Widgets_Evo/unit_group_move.lua
+0 / -0
10 years ago
Huh, it would be nice if that was included by default with the game.
+0 / -0

10 years ago
The problem is that it is a lot of command spam, so if you are giving move commands to a very large group of units very fast, you will get 'packet lost' errors and responses will start getting slower. Or so I experienced the last time I was testing it.
+0 / -0
Huh, I thought it already worked like that without the widget. The packet problem I mean. Also, I just realised that the widget may conflict with the formations widget, haven't tested it enough to be sure. Lastly, the behavior of the widget is a little... off. Something about it just doesn't work that well. It behaves sort of like the ctrl move method but not quite and it positions the units in strange ways sometimes.

EDIT: it does conflict with the widget and like I said, it doesnt work very well. :/
+0 / -0


10 years ago
As far as I recall the Evo widget is exactly what you asked for. Move commands given to clumps of units are given in a small area around the command.

A big problem with what you suggest is queuing and cliffs. If you give a move command to one side of a cliff then all the units should at least group up on that side of the cliff. If they receive orders to move to a nearby location they could end up on the wrong side.

Move commands with orders queued after them do not have the clumping problem. There are also many situations where you want all the units to follow the exact location you set. Maybe you are queuing some move orders to skirt the range of some turret. Maybe you are queuing a jump command after move which is likely to fail if the units reach the jump command before they are in range.

In summary:
  • Your suggestion has drawbacks.
  • The problem is fixed by using line move. You should always do this anyway.
  • Things work better in later engine versions.
  • It would take work to do anything.
+1 / -0
10 years ago
I'm saying that the Evo widget is a little... broken. As in, it's not working as intended even by the author because it has strange behavior. Plus it's not compatible with custom formations widget.
+0 / -0
10 years ago
I dont know why you would'nt perfer the lasso formation or the deafult line formation, z-k (or any game on the spring engine for that matter) works alot diffrent for starcraft or whatever games you play. units cant shoot through eachother, they will even hit themselves if they try.
+0 / -0
Skasi
10 years ago
Oh look, somekid giving advice to someone! :)

If you don't want lines, just scribble a few things in an area. I think it's better to get used to always drawing lines though, just to make sure your army is set up in case your enemy decides to engage.
+0 / -0
10 years ago
quote:
I think it's better to get used to always drawing lines though

I agree, it is very important to get used to line move orders, especially for raider micro. There is also quite a problem with friendly fire if you use point move orders, and units cant shoot through each other so it you get more firepower on target if you use line move orders.
+1 / -0
I would prefer a "destination area" which is handled by gadgets for units which got a simple (no formation) move order.

First unit try to reach the centre -> no issues with just 1 unit.
Other units stop, if they are within destination area (size depends on accumulated unit footprint) and crash into another unit.

Sometimes I would want a unit with custom formation line move point to not move for laggards.

I think this is the least cpu+network-heavy, most simple, least annoying and most intuitive behaviour.
+0 / -0

10 years ago
http://springrts.com/wiki/Changelog

Spring 92.0:
quote:
units moving toward the same spot will no longer clump up into a jiggly ball (#3355 & #3381)
+1 / -0
@skasi
quote:

Oh look, somekid giving advice to someone! :)



Unsure if sarcastic, massive ego shouts louder than you anyway though.
+0 / -0
Page of 2 (22 records)