Widget v0.1 http://www.mediafire.com/?7gtwhdsfmjf811cSelect a bunch of units that includes more than one racketeer. Give ANY order to selected units. Racketeers that are being selected will split their fire among targets in the front of the order queue of one particular racketeer (I'm not sure what controls the selection). Example use 1: 6 racketeers and 1 bandit selected. Issue area attack command to group of 4 enemy units. Shift-queue a move command after that. Each enemy unit gets 1 racketeer targeting it. 2 of them get 2 racketeers instead (the first 2 in the order queue). Racketeers retain their move command. (I think, potentially buggy there) The bandit is not affected. If there is only one enemy unit, no reassignment happens. Known Issues: unit_tactical_AI.lua will complain when it triggers. Very verbose stacktraces that will clog up your chat. Not sure what's causing that. I've tried tracking down the bug in tactical AI but I can't find it.
+0 / -0
|
Can you make units retain their fire command after a move command, period? That really should be in engine, but it is SO DAMN FRUSTRATING when you run up to a fusion, try and snipe it, then give a move command to do ring-around-the-rosy and your unit re-targets...
+0 / -0
|
Ye-es. I can do that. That'll need to be a gadget for best performance, but I believe if player #1 wants it in, it'll get in. =) -- A gadget, I believe, could make units fire at a specific target in range while moving. If moving inserts before attack commands, then yes, that'll be perfect. (the attack command decides the target the gadget will prefer) There'll need to be some method of clearing your attack command. Because if you just right-click move, and that does not clear attack commands, units asked to retreat after attacking will run right back into the fray. My thinking is that if they run out of range of their target, the attack command disappears. But then how to tell whether a unit has been queued an attack command rather than a move command being inserted...?
+0 / -0
|
How does tactical AI complain, make a proper bug report on the ticket system. Although... widget installing voids your warranty.
+0 / -0
|
[f=0001540] LuaRules::RunCallIn: error = 2, GameFrame, [string "LuaRules/Gadgets/unit_tactical_ai.lua"]:95: Bad unitID parameter in GetUnitLosState() stack traceback: [C]: in function 'spGetUnitLosState' [string "LuaRules/Gadgets/unit_tactical_ai.lua"]:95: in function 'getUnitState' [string "LuaRules/Gadgets/unit_tactical_ai.lua"]:400: in function 'updateUnits' [string "LuaRules/Gadgets/unit_tactical_ai.lua"]:452: in function 'GameFrame' [string "LuaRules/gadgets.lua"]:945: in function <[string "LuaRules/gadgets.lua"]:943> (tail call): ? ---------------------------------------------------------------------- Repeated many many times. Every 20 frames.
+0 / -0
|
RE saktoth's widget request: Unit Move Attack v0.1 http://www.mediafire.com/?qsubgz7tard6k6eI have a preliminary version of the gadget here. Basically, move commands will insert themselves in front of an attack command if the attack command is at the top of the queue and the target is in max weapons range. Giving a move command again will cancel the queue as per normal. (since the first command in the queue is now a move command) I am unsure if the SetUnitTarget is working at all. Tests with and without the gadget show no real difference. They just continue to shoot whatever they were shooting at.
+0 / -0
|
Anyone know how gadget:AllowCommand(unitID, unitDefID, teamID, cmdID, cmdParams, cmdOptions) actually works? cmdOptions always seems to be an empty array. Is there any way I can detect whether the command that triggered the call in had the shift modifier?
+0 / -0
|
Can Gnats also be included along with other movement attacking units :)
+0 / -0
|
They already are. Currently, there is no unit type detection. It works on ALL units. Gnats though, ought to get spread fire, like racketeers.
+0 / -0
|
Does Unit Move Attack have to be a gadget? If you are just messing around with command queues I don't think it does. I also doubt this is a good solution.
+0 / -0
|
I was referring to the Racketeer Spread Fire widget. here is the list of units that only attack movement (as far as I know): : arm_venom : Venom : Riot EMP Spider : bladew : Gnat : Light Paralyzer Drone : slowmort : Moderator : Slowbeam Walker there is also the tick and empmissile but I don't think they need to be included.
+0 / -0
|
I'm almost certain the tactical AI crash is due to something wrong in the construction of your order queue but I've added a check for it anyway. I've added a general solution to changing targets when a move command is issued. I like it because a unit's command queue remains untouched and player commands are not messed with, it also never loses it's target. The general solution just adds 2 commands for setting and removing target, this can be done manually by the player but widgets can also use these commands to replicate the behaviour of "Unit Move Attack v0.1". http://code.google.com/p/zero-k/source/detail?r=3860
+0 / -0
|
I'll look into using that. Perhaps it is time for me to migrate my gadget testing to ZK latest test version. Racketeer spread fire and Unit move attack will be updated/reprogrammed as widgets to use the general solution commands if they work as required. (Racketeer spread fire in particular uses a pretty hackish method)
+0 / -0
|
Scratch that. I thought I had a working gadget and then ran into this problem: GiveOrder(unitID, CMD_UNIT_CANCEL_TARGET, {}, {} ) gives me the following error: LuaRules::RunCallIn: error = 2, AllowCommand, [string "LuaRules/Gadgets/unit_move_attack.lua"]:68: GiveOrderToUnit() recursion is not permitted I presume this is due to some problems with the CallIn AllowCommand triggering when it gives the order to cancel targets. Problem of course is that it kinda sucks not being able to cancel a set target.
+0 / -0
|
Still v0.1, now using the added commands. http://www.mediafire.com/?6uurfkvkjn4v615All the gadget does is send Set_Target commands to whatever a unit was attacking before it received a move command if that target was in range. This could be a widget as well although that would become subject to latency issues.
+0 / -0
|
It does not send Cancel Target commands so you have to do that yourself.
+0 / -0
|
This should be a widget. It only performs actions when a player issues a command and everything it does is doable by a widget. There will be no latency issues beyond that of the player command and a gadget cannot solve latency issues with player commands. If I read this correctly it tells all units to target the thing they last attacked... this may be overkill. Also it only needs to do that for move commands.
+0 / -0
|
It tells units to target the last thing they attacked if they received a move command while their attack command target was in range. Point taken about the latency. I'll convert it and clean it up (still has alot of unused functions I 'ported over from gunship no swarm)
+0 / -0
|
There is a problem (also the problem I faced with Racketeer Spread Fire). The AllowCommand callin doesn't work for widgets. The analogous one I've found is UnitCommand. But that doesn't trigger once for each unit and doesn't register the type of command given. It can't work this way, I have to use a gadget.
+0 / -0
|
There is a callin (I forget the name) which triggers when the player gives a command. It has no latency as widgets are unsynced and it only triggers once per command, not many times for all the units selected.
+0 / -0
|
