A way to be able to 'deploy' vehicle hijackers out of a hijacked vehicle

Bug #894951 reported by Black Temple Gaurdian
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ares
Incomplete
Wishlist
Unassigned

Bug Description

or something similar.

Maybe just a general tag 'hijackerscanexit=[bool]' that could be used on individual units aswell as an override.

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

Umm...What would be the point of this?

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

Umm... So that the hijacker doesn't have to get his vehicle destroyed and lose health to exit. Useful because it means you can choose when to leave the vehicle (eg, hijacker spy doesn't have to sit around waiting for his vehicle to be destroyed to enter building.

The abandoned tank should become a neutral unit in sleep mode.

Revision history for this message
Blade (nadia-xy) wrote :

Would conflict with capturing transport units or other unit types that deploy.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

This can conflict with Deploy function indeed, but I suppose the modder can be given a choice which one, Deploy or Eject, takes priority.

Revision history for this message
skyboy (skyboy) wrote :

When transport units are hijacked, the contained units could be held prisoner or ejected, by a flag set on the hijacker (EjectUnits = bool ?) and when opentopped units are captured, the contained units should be ejected; Explain as though the units are leaving of their own accord for some reason.

Revision history for this message
reaperrr (reaperrr) wrote :

While I don't mind if this gets implemented one day, the fact that nobody has voted for (or against) it indicates that most people don't care that much - or even not at all - about this feature, so I think it would make sense to postpone this in favor of more popular issues.

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

^ Actually this is just an old issue. As in "before the ICS system wqas introduced old", so of course it got ignored. Would you kindly not jump to conclusions if you're going to backseat mod? (Who gets the refrence there?)

For instance, I only just noticed this issue again even after trawling through issues to rank on the ICS. Why? Because I thought, "Why support/resist something that's already been asigned for implimentation?

Revision history for this message
reaperrr (reaperrr) wrote :

Renegade asked the community to rate and voice their opinions on existing, scheduled feature requests as well. That's what I did. Many other features were pre-ICS too and have received several, sometimes dozens of votes already.

And it's not like I said "kill it", I'm just saying that in my personal opinion there are more worthwhile feature requests that should have a higher priority.

Revision history for this message
modder666 (modder666) wrote :

I hate to bump this, but according to the Roadmap this is prepared for an Ares 0.2 release. Why not add a new hotkey function that tells hijackers to eject? It's a rather limited condition, but this is a rather limited stuation.

Revision history for this message
WoRmINaToR (worminator) wrote :

It's probably not as simple as that. Ejecting passengers is logically tied to the "deploy" logic, and I'm not sure how much work would have to be put in to create an independent eject logic that, while having many other potential uses in the future, would probably turn out to be more work than it's worth for this issue.

If there is significant support/demand/necessity for such a feature (I personally would actually like to see something like this someday) then of course the idea's fine. I'm not sure though that there is a significant enough demand or necessity for such a feature to accomplish this very limited scenario.

Now of course I could be completely wrong about the depth this feature and difficulty of implementing it and it could be something that takes a couple of hours to complete, but reaperr makes a good point about this: not a whole lot of people really care that much about this issue to begin with. 7 people decided to actually vote on it and of that 7, 2 voted against it.

Not saying it shouldn't ever happen and an option for a secondary "eject" button (which could be used for other purposes if it's coded for a more general purpose) would be a major step forward for modding, but for this issue I say it looks like too much work.

Revision history for this message
AlexB (alexander-b) wrote :

A second way to just get a hijacker back is just not discoverable. It is an edge case and if you don't know about the new hotkey, you would have to read the manual and who does that? And if you don't know the feature existed, you wouldn't even know what to look up in the docs.

The hijacker isn't a passenger. The unit "remembers" which InfantryType hijacked it, but it doesn't remember the actual hijacker (and its health and other properties). This means the hijacker would have to use a custom mechanism to eject (and the game needs to be fooled to detect this situation). Then the newly ejected hijacker would have full health again. Thus ejecting is not just getting one passenger out.

Revision history for this message
Renegade (renegade) wrote :

Also, how many people would use that, really?

I mean, there are really only two options here:
1. The hijacker leaves, the hijacked unit returns to its previous house.
2. The hijacker leaves, the hijacked unit turns neutral.

The former is just plain an unlikely scenario...who would hijack an APOC, drive it somewhere else, and then leave it, in the full knowledge that the APOC will turn hostile and attack the hijacker?

And the latter is almost exactly the same as the apathy-killed "Jarmen Kell" functionality.

Deploying the hijacker out of the vehicle can only be one of two things: Utterly useless, or a fancy way of turning enemy units neutral.

Neither functionality is worth the effort.

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

Spies?
Units that just "nip out" plant C4, blow building, come back in?
Engineers?

Revision history for this message
WoRmINaToR (worminator) wrote :

all viable usage cases, sure, but honestly, can't you just as easily use one of your own transports to get them there? Sure the "nip out," plant C4 and come back in scenario is kinda cool to think about but really, what else would this be critically necessary for (even then, that idea is just a cool little trick not many people would use or even know about)?

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

Because if the stolen unit gets destroyed it can just hijack another one?

Revision history for this message
Renegade (renegade) wrote :

Umm...you do realize that, if you hijack a car, it transfers to your house, thus making it hostile to your enemy, thus triggering all of his automatic defenses and showing up bright red on his radar, thus being totally useless to infiltrate him in any way?

Sorry, but still no convincing usage case. Wanna try again?

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

The term spy was more reffering to it's function. After all, why sneak around when you can, I dunno, hijack that huge ass tank and drive it through the front door?

Revision history for this message
Renegade (renegade) wrote :

And this is different from (permanent-)mind-controlling parasites how?

Revision history for this message
Blade (nadia-xy) wrote :

As a suggestion, how about a way to cause the unit to self destruct to get your hijacker back rather than leaving it neutral or back in the hands of a hostile enemy? There were times in TS where I would want the unit to get destroyed so I could hijack something else but had to go in harms way to get the hijacker back first.

Revision history for this message
Renegade (renegade) wrote :

That would be a more reasonable approach...

Revision history for this message
Renegade (renegade) wrote :

Is this on our pseudo-mental "list of stuff to do"?
If so, somebody set this to "invalid" and update the blueprint.
If not, somebody set this to "won't fix" and the blueprint to "obsolete".

(Alternatively, the original requester can, of course, proactively start whipping the blueprint into shape.)

Changed in ares:
assignee: AlexB (alexander-b) → nobody
status: In Progress → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.