Spring RTS Engine

It would be nice if you could give unfinished buildings to allies, as I think Strategia was implying...

Tobi wrote:TBH the right solution is sharing turns stuff off and erases queues (or possibly puts them on wait), and .take'ing doesn't touch command queues or on/off state at all.

Yeah. That's what I thought of too.

But arguing with LordMatt in uppercase letters is so much more fun! I seriously can't see why you're playing Spring when you can do that

BUMP

Okay, I'm really sick and tired of any time I lose an ally to disconnection or desync and having to requeue all their stuff. If you just lost an ally it is totally ridiculous to suddenly have the huge additional micro burden of having to restart all their labs and cons. ALL UNITS SHOULD BE GIVEN IN THE EXACT SAME STATE THEY OTHER PLAYER HAD THEM, WITH THE EXACT SAME ORDERS NO EXCEPTIONS. There is no way, whatsoever that your ally is going to do you more damage by giving you units then the vast amount of micro time you burn as it is now.

PLEASE FIX THIS FOR THE NEXT VERSION FOR MY SANITY'S SAKE IF NOTHING ELSE.

There's a reason metal makers and such are turned off, Matt. Otherwise people could build a set of moho metal makers, give them to the enemy, and attack while their energy is gone.

Giving units to the enemy is disabled now, I'm pretty sure. In any case, that shouldn't be allowed at all.

Which is also highly debatable.

LordMatt:
As far as I know, giving units to enemies is still allowed.
You can disable it with a lua script, but it isn't hard coded.

Wasn't it already decided that orders should be reset on a give or at least a give to an enemy player but not on a take?

is it possible to put all shared units into "wait" mode, and then they will resume their orders when told to "wait" again with Shift+W or whatever the command is

I support this request. +1 LordMatt, I hope it gets fulfilled.

I've made the change so that allied unit transfers do not clear
the command queue, or deactivate units (ex: metal makers).
If someone wants the old behaviour, they can script it...

mastermat wrote:see, now that's why Tobi is an admin. cus he has brains smart.

Yeah!

trepan wrote:I've made the change so that allied unit transfers do not clear
the command queue, or deactivate units (ex: metal makers).
If someone wants the old behaviour, they can script it...

Sweet! trepan is once again the man!

On the topic of giving to enemies, please name on instance when that is used for something other than an exploit (tonnes of metalmakers to drain e) or a ragequit ('fuck you I'm not going to give you the satisfaction of completing the game so here are all my units').

I agree, there should be an option to disable giving completely. It's not nice in a FFA if one player quits and gives all his stuff to someone.

You can disable all unit sharing once the new lua script code is committed.

in LuaRules/main.lua (renamed it from luaMod) You can also use the GetChatMsg(message, playerID) command in
LuaRules/main.lua to configure the setting in-game (if you script it that way).

As for giving units to the enemy:

Remember that sometimes when training with a player/new friend, you want to give them units to let them tinker with them and see what they're capable of. That's one instance right there.

Also, there is a certain mode of play that basically goes like this: You have two opposing players, and one "neutral" one. The neutral one can "sell" units to the two warring players. This is really quite fun, i've done it a bit, and especially for mods with 3 or more sides. It adds an interesting dimension to some types of LAN games as well.

Not to mention, FFAs may see the occasional unit swap in order as a form of diplomacy.

Speaking of which, when will we be able to address messages directly to Player 1 or Player 2, etc, in 'whisper' mode?

Cheat mode...

ALL UNITS SHOULD BE GIVEN IN THE EXACT SAME STATE THEY OTHER PLAYER HAD THEM, WITH THE EXACT SAME ORDERS NO EXCEPTIONS.

So that Gnug tips #23 may return?

How about a dialogue box pops up, saying "XYZ just gave you some shit, do you want it to be in the same on/off state as he had it?"

So the new tactics to disrupt the player you're assaulting would be to have an ally give it a dozen windmills, one by one, in such a way that the player they're given to will have so many popup to acquit he'd be unable to play and repel the assault.

On the topic of giving to enemies, please name on instance when that is used for something other than an exploit (tonnes of metalmakers to drain e) or a ragequit ('fuck you I'm not going to give you the satisfaction of completing the game so here are all my units').

When I play newb in TA, sometimes, when I realise I have a huge army while my opponent has nothing, often I give my army to my opponent so we can still have fun blowing stuff up. Since such a newb wouldn't know how to operate the sharing interface, the units I give to him must be on, fire-at-will, etc.. and he mustn't have to touch anything to be able to receive them. In TA shared units are on hold fire, so I had to yell a couple time to turn them on fire at will.

Anyway, not sure where is the right point between opening exploit for hard core players, and allowing smooth sharing for normal use.

Oh and want about allowing dual control, like shared comm, but only for certain units?

In the code, I think the check is that if it's using more than 20 energy per second then it's turned off when you give it. Probably the best thing to do is just stop this check happening if you're giving to allies.

zwzsg wrote:

ALL UNITS SHOULD BE GIVEN IN THE EXACT SAME STATE THEY OTHER PLAYER HAD THEM, WITH THE EXACT SAME ORDERS NO EXCEPTIONS.

So that Gnug tips #23 may return?

Way to miss entire point of all my posts in this thread. I don't think you should be able to give units to the enemy, but if that is allowed, its trivial to turn off and dequeue units only when given to the enemy, not to allies. There is absolutely no reason allied unit transfers should change what the units are doing at all, and that's why the code change was made already.