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

Same speed by default

15 posts, 1545 views
Post comment
Filter:    Player:  
sort
5 years ago
I know I must have overlooked it. I can't find the option to have selected units move at the same speed by default. I want this often, and without holding the Control key each time I issue a move command. Is there anything that allows the behavior of Control to be reversed (or is this tactically unsound)?
+2 / -0

5 years ago
select group, press and hold CRTL, give move command. here they go.
+0 / -0

5 years ago
quote:
I want this often, and without holding the Control key each time I issue a move command
+2 / -0

5 years ago
allright, allright...
+0 / -0

5 years ago
Not available at the moment but sounds like a decent feature to make. I've made a ticket https://github.com/ZeroK-RTS/Zero-K/issues/3162 , but (somewhat surprisingly) it's a fairly rare request so I expect it might be some time before somebody takes it up.
+1 / -0

5 years ago
Perhaps a toggle rather than making it default would work better? For my part, the main use of ctrl move is to try to keep raiders and outlaws close when shieldballing. Bandits seem the preferable dragnet option against phantoms native to shield factory (dirtbags don't even have the range of fleas) and need protecting from riots before they can do it. However, the ctrl move sometimes encourages units to go somewhere I don't want them to go (it seems to be something to do with the position of reinforcements relative to the front line force) resulting in frantic micro to stop them which usually results in rogues, racketeers and felons being caught unprotected when the ctrl move is cancelled and the thugs and bandits leave them behind.
+0 / -0
5 years ago
I been looking for the exact same thing. This is one of the biggest questions I still have at the moment. 90% of the time, I want the units to move at the same speed. There's usually no reason I want units to split up if they're going to the same place. Either I want them to go somewhere and it should be together, or I just want only the fast units to get there, and I've already re-control-grouped them at that point. The only consistent time I can ever remember wanting units to move at different speed is when I'm 450 elmo (~vision distance) away from an engagement, and I want my short-range scouts to move in ahead of my long-range riots so that they all start firing at the same time.
+0 / -0


5 years ago
This can't be too hard I think. I might give it a crack some time (cuz I love automation!). USrankRandomX you are expected to report for totally untested and highly dangerous testing of shitcode since you want this feature.
+0 / -0
5 years ago
Aye-aye!

Though playing on Windows, I don't know if I'll be able to actually compile/build any code myself.
+0 / -0


5 years ago
Nothing to compile. All widgets are made in lua. You just drop it in your luaui/widgets folder and call it good.

I did some testing of this earlier and found a method of breaking zero-k horribly. :D

I also found a way to have non-line fight commands go at the same speed.
+1 / -0
5 years ago
Sounds good to me. I'll just have to create the folder.
+0 / -0
quote:
Nothing to compile. All widgets are made in lua. You just drop it in your luaui/widgets folder and call it good.

I did some testing of this earlier and found a method of breaking zero-k horribly. :D

I also found a way to have non-line fight commands go at the same speed.


You are a god among men. Thank you.
+0 / -0
So far research hasn't progressed well. I don't understand what some of the basic commands are doing and how the engine handles group moves. So far I know how to replicate the fight ctrl command but not the line move. I'll publish some results of the research at hand and hopefully be able to invoke hoko or someone who is an engine sec. I'll release the current fight widget at the end of the day hopefully.

At the moment I learned there's a param called coded and it seems 80 does something with the group movement. No other command is issued. Commands can be modified in widget:CommandNotify() which is kind of interesting. It seems some units use this "rawmove" cmd. I have no idea what the difference is but it seems to go to some gadget and if you send it an invalid/unexpected input, the gadget throws errors and the units get broken (as seen in my post in the in game fails entitled the derpy circus).

This behavior causes some interesting effects. For instance, units with leading weapons will derp up and try to attack in front of the derped unit. It seems that it tries to predict the location based on the unit's acceleration (or something) and not actual velocity. This is akin to someone shooting the ground in front of you with a weapon while you walk in place. It's quite weird. One could in theory create a widget to derp units with a hotkey as some sort of micro and exploit it to break skirmishers and other things.

Update:
[5:56 AM] GoogleFrog: set wanted max speed
[5:56 AM] GoogleFrog: echo the order queue

This requires testing!
+0 / -0

5 years ago
quote:
It seems some units use this "rawmove" cmd. I have no idea what the difference is

Raw move doesn't use Spring pathing if possible (it devolves to turning towards target and running towards it with reckless abandon). Use it always (obstacles cause it to behave as regular move, pathing around them).

quote:
I learned there's a param called coded and it seems 80 does something with the group movement

80 is 64 + 16, these are the bit flags for CTRL and RIGHTCLICK respectively. CTRL is the modifier that makes units go in a group. The flags are available as Lua constants:
for key, value in pairs(CMD) do
  if key:find("OPT_") then
    Spring.Echo("CMD." .. key, value)
  end
end
+1 / -0


5 years ago
That explains a lot PLrankAdminSprung. It explains the weird behavior I was getting when I was trying to do stuff with it. I'll have to run this bit of code later on. This part really helped me understand the behavior I was observing:

quote:
Use it always (obstacles cause it to behave as regular move, pathing around them).
+0 / -0