| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0002962 | Spring engine | General | public | 2012-02-18 09:01 | 2012-07-07 19:47 | ||||
| Reporter | Google_Frog | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | 89.0 | |||||||
| Summary | 0002962: Unit on fireplatform cannot be the target of an attack command. | ||||||||
| Description | Right clicking on an enemy unit that is loaded into armtboat (a fireplatform) does not give an attack command. An explicit attack command ('a' - left click) does not give the command either. Rectangle attack can be used to put an attack command on the unit. I think attack commands should work on the loaded units. Units already automatically target them. Instead of hardcoded command blocking behaviour any game that does not want attack commands on loaded could add a simple allowcommand check in a gadget. Tested with armmanni loaded onto armtboat in ZK-5382 | ||||||||
| Additional Information | 85.0.1-188-g0514c38 | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|||||||||||
|
|||||||||||
 Relationships |
| Notes |
|
|
Kloot (developer) 2012-02-18 11:54 |
duplicate and intentional, there is an exploit route that relies on this. |
|
Google_Frog (reporter) 2012-02-18 12:01 |
Which exploit? Also if it is serious you should know that units on fireplatforms now have hitspheres and can be shot and killed. They can be targeted with lua. |
|
Kloot (developer) 2012-02-18 12:23 |
I'm well aware of the implications since it was me who fixed that bug, transportees are supposed to be hittable. The exploit goes something like: 1) make nuke silo, 2) put silo on wait, 3) queue attack command on enemy unit, 4) load unit into transport, 5) move transport to a location of choice, 6) unwait silo. I'm sure you can figure out what the effect of this will be if said location is somewhere high up. |
|
Google_Frog (reporter) 2012-02-18 13:00 |
That is an extreme workaround for an incredibly mod specific problem. Games can should deal with that possibility themselves with a simple gadget. Leave the command handling possibilities as open as possible when individual mods can fix it themselves for cases which are important for them. |
|
Kloot (developer) 2012-02-18 13:28 |
It is obviously NOT just limited to nukes... are you really that uncreative? |
|
Google_Frog (reporter) 2012-02-18 14:35 |
I didn't say it is limited to nukes, it is limited to games that have a flying fireplatform which can load enemy units. Off the top of my head I cannot think of any mods that have such a unit. |
|
Kloot (developer) 2012-02-18 14:54 |
Loading enemy units is common enough, and the transport does not need to be a fireplatform (projectiles fired at it are not guaranteed to connect, whether the transportees themselves are hittable or not). Aside from that I do not see why games should be responsible for fixing (or have the freedom to ignore, which is a slippery slope) engine exploits. |
|
Google_Frog (reporter) 2012-02-18 16:11 Last edited: 2012-02-18 16:11 |
The engine side fix of this exploit affects all mods and many do not suffer from the exploit at all. The engine should not handle it because it is very easy to address with a gadget and the gadget can specify which weapons need to be blocked. Engine side extra special command handling like this limits the engine and makes it more confusing to work with. Secondly the exploit is currently not fixed. Here is what would need to be done: * Restrict the fix to only block attack commands on enemy units in allied transports. * Block autotargeting * Currently attack rectangles can be used to put an attack command on units in fireplatforms. * Currently units in non-fireplatorms (corbtrans) can be targeted with an attack command. * Remove attack commands and weapon targets from enemy units that have just been picked up. You could currently drop an enemy, set the attack commands and pick it up. This would result in a messy widespread command and target handler full of special cases. It is exactly the kind of haky thing that would break every few engine versions. Here is a related exploit that hasn't been fixed; Get a allied gunship, set an attack command and share it to an enemy. Does that mean sharing between ally teams should be engine blocked? How about this; wait for an opponent air unit to move into a good location and give an attack command. Maybe missiles shouldn't be able to target air at all. Alternately my fix for ZK would look something like this and would work for all *A mods: * Make Nuke only able to target ground. * Ignore every other weapon because it doesn't actually matter. All missile weapons have always overshot when aimed at the very edge of a cliff. Everyone either doesn't care enough to fix it or have simply set some reasonable weapon timer values. Cannon projectiles kill themselves if they overshoot and Lasers are not a problem at all. |
|
Google_Frog (reporter) 2012-02-18 16:24 |
There is also no reason to restrict the command for ground based transports and fire platforms. |
|
Kloot (developer) 2012-02-18 16:52 Last edited: 2012-02-18 17:32 |
"Engine side extra special command handling like this limits the engine" 1) There are plenty of "special" limits that I don't hear you complain about. 2) You are assuming a solution is not being planned. "Secondly the exploit is currently not fixed." Yes, it is. * Restrict the fix to only block attack commands on enemy units in allied transports. Still exploitable. * Block autotargeting Still on my list, not as crucial. * Currently attack rectangles can be used to put an attack command on units in fireplatforms. Attack rectangles...? * Currently units in non-fireplatorms (corbtrans) can be targeted with an attack command. Nope, the command will be rejected. * Remove attack commands and weapon targets from enemy units that have just been picked up. You could currently drop an enemy, set the attack commands and pick it up. Which will cause the command to be rejected a few frames later. "Here is a related exploit that hasn't been fixed; Get a allied gunship, set an attack command and share it to an enemy." Nope, all orders are canceled when a unit is shared to an enemy. "Everyone either doesn't care enough to fix it" I cared. "reasonable weapon timer values" Long-range weapons cannot have reasonable values. "Cannon projectiles kill themselves if they overshoot" Depends on their burnblow setting. "There is also no reason to restrict the command for ground based transports" I can think of a few "fun things" a ground transport with enemy passengers could be used for. |
|
Google_Frog (reporter) 2012-02-19 00:43 |
"Restrict the fix to only block attack commands on enemy units in allied transports." How is that still exploitable? Someone could make an overshootable weapon that is able to target allied ground units? Noone has done that or is likely to so it would be much more useful to make transports usable for the games that currently exist. ""Everyone either doesn't care enough to fix it" I cared." Wrong it. It was general terrain based overshooting. It can mostly be fixed modside. If you want to enable us to fix it make myGravity work on missiles when their weapontimer is reached. Currently missiles fall under gravity but they do not fall fast enough, especially for fast missiles. |
|
Google_Frog (reporter) 2012-03-07 12:38 |
Can we at least have a modrules toggle for the transport attack command cancelling. There _currently_exist_ games with no air transports that have ground based ally-only fireplatforms which would really like the fire hax workaround disabled. |
|
FLOZi (reporter) 2012-03-08 17:58 |
http://springrts.com/mantis/view.php?id=3002 So it is fine for enemy units to be loaded and targetable but not friendly? |
|
Kloot (developer) 2012-03-08 19:24 |
AUTO-targetable != USER-targetable |
|
Google_Frog (reporter) 2012-03-08 23:36 Last edited: 2012-03-08 23:39 |
Oh so enemies are still autotargeted... This is stupid Kloot. You're fixing nothing and creating a lot of limitations for legitimate fireplatform use. As I said earlier the engine shouldn't even decide for me what IS legitimate use. |
|
jK (developer) 2012-03-08 23:49 |
Instead of artificial limit targeting, you should disallow unlimited out-of-map movement by forcing any unit outside of the map to go either on a left or right turn -> compare old speed vector with current one and make sure the unit is on a turn towards the map. |
|
Kloot (developer) 2012-03-08 23:53 Last edited: 2012-03-08 23:56 |
"Oh so enemies are still autotargeted... " Gee, might that be because the exploits were only possible through user-targeting? "As I said earlier the engine shouldn't even decide for me what IS legitimate use." And as *I* said earlier, there are plenty of accepted cases where the engine DOES decide legitimacy for you. The only difference here is that *you* happen to have a vested interest in this one. From now on, every time you nag about this issue again, it shall drop further in priority on my todo list, and eventually fall off the bottom end entirely. "Instead of artificial limit targeting, you should disallow unlimited out-of-map movement by forcing any unit outside of the map to go either on a left or right turn -> compare old speed vector with current one and make sure the unit is on a turn towards the map." There is already such code here and there, but the issue here is not out-of-map targeting. |
|
Google_Frog (reporter) 2012-03-09 02:45 Last edited: 2012-03-09 02:45 |
I was going to argue the general case but instead I'll focus on my vested interest. Of course I have one because I am trying to make a game with this engine that can do certain things. The engine doesn't exist in a vacuum. As apparently you are going to do *something* (implied by the priority list) here is what I would like done. I want to be able to manually target enemy units that are loaded into enemy transports. This is a practical goal that I will make use of, the rest of the argument for me is a matter of principal which I can ignore if I at least have this basic functionality. Now explain why I cannot have that functionality. If I can have it then good, if I cannot then we may as well argue because in that case I don't care if whatever else you have planned for this issue falls off the priority list. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-18 09:01 | Google_Frog | New Issue | |
| 2012-02-18 11:48 | Kloot | Relationship added | has duplicate 0002934 |
| 2012-02-18 11:54 | Kloot | Note Added: 0008303 | |
| 2012-02-18 11:54 | Kloot | Status | new => closed |
| 2012-02-18 11:54 | Kloot | Resolution | open => suspended |
| 2012-02-18 12:01 | Google_Frog | Note Added: 0008304 | |
| 2012-02-18 12:01 | Google_Frog | Status | closed => feedback |
| 2012-02-18 12:01 | Google_Frog | Resolution | suspended => reopened |
| 2012-02-18 12:23 | Kloot | Note Added: 0008307 | |
| 2012-02-18 12:23 | Kloot | Status | feedback => closed |
| 2012-02-18 12:23 | Kloot | Resolution | reopened => fixed |
| 2012-02-18 13:00 | Google_Frog | Note Added: 0008308 | |
| 2012-02-18 13:00 | Google_Frog | Status | closed => feedback |
| 2012-02-18 13:00 | Google_Frog | Resolution | fixed => reopened |
| 2012-02-18 13:28 | Kloot | Note Added: 0008309 | |
| 2012-02-18 13:28 | Kloot | Status | feedback => closed |
| 2012-02-18 13:28 | Kloot | Resolution | reopened => suspended |
| 2012-02-18 14:35 | Google_Frog | Note Added: 0008311 | |
| 2012-02-18 14:35 | Google_Frog | Status | closed => feedback |
| 2012-02-18 14:35 | Google_Frog | Resolution | suspended => reopened |
| 2012-02-18 14:54 | Kloot | Note Added: 0008312 | |
| 2012-02-18 15:39 | Kloot | Status | feedback => closed |
| 2012-02-18 15:39 | Kloot | Resolution | reopened => suspended |
| 2012-02-18 16:11 | Google_Frog | Note Added: 0008315 | |
| 2012-02-18 16:11 | Google_Frog | Status | closed => feedback |
| 2012-02-18 16:11 | Google_Frog | Resolution | suspended => reopened |
| 2012-02-18 16:11 | Google_Frog | Note Edited: 0008315 | |
| 2012-02-18 16:24 | Google_Frog | Note Added: 0008316 | |
| 2012-02-18 16:52 | Kloot | Note Added: 0008317 | |
| 2012-02-18 16:58 | Kloot | Note Edited: 0008317 | |
| 2012-02-18 16:58 | Kloot | Note Edited: 0008317 | |
| 2012-02-18 17:07 | Kloot | Note Edited: 0008317 | |
| 2012-02-18 17:11 | Kloot | Note Edited: 0008317 | |
| 2012-02-18 17:32 | Kloot | Note Edited: 0008317 | |
| 2012-02-19 00:43 | Google_Frog | Note Added: 0008318 | |
| 2012-03-07 12:38 | Google_Frog | Note Added: 0008411 | |
| 2012-03-08 17:58 | FLOZi | Note Added: 0008414 | |
| 2012-03-08 19:24 | Kloot | Note Added: 0008415 | |
| 2012-03-08 23:36 | Google_Frog | Note Added: 0008418 | |
| 2012-03-08 23:36 | Google_Frog | Note Edited: 0008418 | |
| 2012-03-08 23:39 | Google_Frog | Note Edited: 0008418 | |
| 2012-03-08 23:49 | jK | Note Added: 0008419 | |
| 2012-03-08 23:53 | Kloot | Note Added: 0008420 | |
| 2012-03-08 23:55 | Kloot | Note Edited: 0008420 | |
| 2012-03-08 23:56 | Kloot | Note Edited: 0008420 | |
| 2012-03-09 02:45 | Google_Frog | Note Added: 0008421 | |
| 2012-03-09 02:45 | Google_Frog | Note Edited: 0008421 | |
| 2012-07-07 19:44 | Kloot | Status | feedback => resolved |
| 2012-07-07 19:44 | Kloot | Fixed in Version | => 89.0 |
| 2012-07-07 19:44 | Kloot | Resolution | reopened => fixed |
| 2012-07-07 19:44 | Kloot | Assigned To | => Kloot |
| 2012-07-07 19:47 | abma | Relationship added | related to 0003159 |
| Issue History |