View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000385 | Spring engine | General | public | 2007-01-15 08:07 | 2007-01-29 04:15 |
| Reporter | redstar | Assigned To | ILMTitan | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000385: [patch] Transported units are able to recieve commands | ||||
| Description | If you load a comamnder into a transport ship and then area select the ship, you can see a tiny square and that it says 2 units are selected. You can also issue commands to the commander while it's inside the transport ship. You can build thigns nearby etc. You can even enter fps mode and see the innards of the transport ship. You can even then reclaim the transport ship resulting in a com explosion. | ||||
| Steps To Reproduce | load a unit into a transport ship or other closed transport medium. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Checked infolog.txt for Errors | |||||
|
|
Patch uploaded. Note: neither pressing ctrl+c nor area selecting will now have any effect other than to play the commander's/unit's "acknowledgement" sound if the commander/unit is being transported, regardless of the type of transport (air, sea) the commander/unit is in. |
|
|
has unitDef->isfireplatform been considered? |
|
|
Yes, however, whether a unit is stunned while in transport should perhaps not have any influence on the ability to select it, as they are semantically unrelated properties. Also, stunned units (including the commander) can still be ordered to build and reclaim, which would enable similar behavior as described in the report in mods that contain units capable of reclaiming as well as having isfireplatform set to true. |
|
|
With isfireplatform set on a transport, units should be able to fire even while being transported by it. One would think it convenient to be able to tell them what to fire at. With your changes (afaict), you can't select the units so as to dictate their target. |
|
|
Ah, I was under the impression that target selection for units being carried by a fireplatform-enabled transport was intended to be fully automatic, rather than under the user's control. To still allow for that possibility, it should suffice to change the transport check to: if (unit->transporter != NULL && !unit->transporter->isfireplatform) { return; } |
|
|
Committed. Thank You. Revision 3339. !unit->transporter->isfireplatform needed to be !unit->transporter->unitDef->isfireplatform |
|
|
Try this (BA45 mod, any map): - .cheat - .give armatlas - CTRL+A (select all) - Load unit (load the commander) - Build Radar (close to the recently loaded commander) I don't think that putting the blocking mechanism in unsynced code is the best idea (although it is nice to have for user feedback). The selection should probably be updated when units are loaded as well. |
|
|
SelectedUnits is unsynced code, I think. It's different for every client. I am not sure why you would have a problem with that. In the command flow, from mouse clicks to unit movement, the whole thing syncs up when a command (as defined by the command structure) is sent over the network. This is between the mouse-click and a command sent. As for removing when picking up, I agree and am now working on it. |
|
|
If the intent of this patch is to forbid units from performing actions while being transported, then I think there should be checks within the sync'ed part of the code. Otherwise, it is easy to modify a client to bypass the mechanism without being detected by sync checks. Anything involving game rules should be sync checked. To better explain, let's look at two players, Arthur and Bob. Arthur likes to hack around a little and has decided that he should have the ability to fly his commander around to reclaim rocks more quickly (a poor example, but I'm not fully awake). Bob does not know C++ from Esperanto. Arthur hacks the selection block and can now do as he pleases. Bob is now at a disadvantage (he's forbidden from doing something that Arthur can do). All game rules should go into sync'ed code, imo. |
|
|
It appears the problem is that units can still build while stunned. Should that be a separate bug? |
|
|
Units that are stunned should not be able to do anything except self-destruct, imo. They should however be selectable (unless carried by a non-fireplatform transport :)), since there'd be no way to tell them to do that otherwise. I think it merits a separate fix. |
|
|
Revision 3353; Stunned units can no longer build (fulfilling the requirement that game rules be enforced in synced code). Units picked up by a transport are removed from selected units, and can not be selected again. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-01-15 08:07 | redstar | New Issue | |
| 2007-01-15 15:52 | Kloot | File Added: SelectedUnits.patch | |
| 2007-01-15 15:54 | Kloot | Note Added: 0000566 | |
| 2007-01-15 19:12 | trepan | Note Added: 0000567 | |
| 2007-01-15 20:19 | Kloot | Note Added: 0000568 | |
| 2007-01-15 20:21 | Kloot | Note Edited: 0000568 | |
| 2007-01-15 20:21 | Kloot | Note Edited: 0000568 | |
| 2007-01-15 21:48 | trepan | Note Added: 0000569 | |
| 2007-01-15 22:43 | Kloot | Note Added: 0000570 | |
| 2007-01-15 22:53 | tvo | Summary | Transported units are able to recieve commands => [patch] Transported units are able to recieve commands |
| 2007-01-28 05:56 | ILMTitan | Status | new => assigned |
| 2007-01-28 05:56 | ILMTitan | Assigned To | => ILMTitan |
| 2007-01-28 06:49 | ILMTitan | Status | assigned => resolved |
| 2007-01-28 06:49 | ILMTitan | Resolution | open => fixed |
| 2007-01-28 06:49 | ILMTitan | Note Added: 0000637 | |
| 2007-01-28 08:30 | trepan | Status | resolved => feedback |
| 2007-01-28 08:30 | trepan | Resolution | fixed => reopened |
| 2007-01-28 08:30 | trepan | Note Added: 0000638 | |
| 2007-01-28 08:35 | trepan | Note Edited: 0000638 | |
| 2007-01-28 09:43 | ILMTitan | Note Added: 0000639 | |
| 2007-01-28 17:35 | trepan | Note Added: 0000640 | |
| 2007-01-29 00:18 | ILMTitan | Note Added: 0000643 | |
| 2007-01-29 01:00 | Kloot | Note Added: 0000644 | |
| 2007-01-29 01:05 | Kloot | Note Edited: 0000644 | |
| 2007-01-29 04:15 | ILMTitan | Status | feedback => resolved |
| 2007-01-29 04:15 | ILMTitan | Resolution | reopened => fixed |
| 2007-01-29 04:15 | ILMTitan | Note Added: 0000645 |
