CnC Gen Jarmen Kell

So, rather than simply mind-controlling the unit you have to use a special weapon to turn it neutral, then get an engineer over there to capture it like a hijacker?

I can't see any benefit to this over using the existing mind-control or hijacker logic.

There are so diffrence with this and mind control.

- This is used on sniper weapons with long range, if a mind control had long range it would be overpowered.
- Enemy can put a engineer to get it back
- If you kill the mind controller, you get your unit back, not in this case

Whilst it could be useful or fun to see used in-game, given as Marshall noted the existence of two other forms of what is essentially mind control, I'd consider this a lower priority issue.

I think this is way different than mind control and could be used by sides which don't use that logic, in order to capture enemy units. Also, if there's a driver logic now - possibility to kill the driver with a special weapon sounds like a must.

Unless there already exists a possibility to kill the driver.

This is just a weapon that disables vehicles until they are entered. I think it would only be worth it if it is not too hard to implement, tbh.

Perhaps a special type of EMP, is a way I suggest. Since EMP already disables vehicles, this could just be a different tag on the weapon, that makes the EMP'd vehicles 'hijackable' by any infantry.

Or for a more roundabout idea: have the weapon make the enemy unit transform into a building type that is neutral (since the object can't move anyways), and making it somewhat UC in that any side can occupy it and own it. So when an infantry goes in and takes position of the building, the player undeploys it to get the unit back, the new ownership being kept.

Of course these are only suggestions, they may not be practical due to my lack of familiarity with the engine setup.

Turning the object neutral actually isn't all that hard.
What's concerning me is the Engineer part of the request - it would make way more sense to fix up VehicleThief to work as expected and just use that.
If you want the Engineer to be the one doing the hijacking, then you can just make him a VehicleThief. *shrugs*

The drawback with that is that it would also allow occupied vehicles and actual civvy vehicles to be stolen as well, which may not be the intent of the modder.

IMO, it would be more optimal if any type of infantry (obvious not animals :P) could enter these types of vehicles, regardless of "VehicleThief" by default. (which is how it worked in Generals and Red Alert 3)

Relevant tags could be
PilotSnipe=
-Put on warhead, successful hit turns the unit into a harmless neutral
Capturable=
-Put on VehicleType, recycled tag. Defaults to yes and determines whether it can be captured if pilot sniped.
CapturableBy=
-Put on VehicleType. Defaults to none (or all NonHuman=no InfantryTypes).

I can add a general TurnNeutral=(true|false) warhead effect, and I can add functionality so that you can enable all troopers to capture neutral vehicles. (Because, frankly, allowing them to steal neutral tanks, but not civilian cars, would be kinda silly. EDIT: And also impossible unless you add specific capturing rules for every VehicleType.)

(Note to self: TurnNeutral requires killing Drivers.)

IMO, there should be a distinction between "pilot-sniped" vehicles and neutral vehicles.
Just making neutral vehicles enterable by infantry means that certain things mappers could do previously, like Hills Have Eyes-like maps and "neutral until you finish this bonus objective" wouldn't be possible.
Civilian vehicles pose similar issues. Mappers may just want them to be eye-candy, and modders may want to give them perks, like passenger space for buses.

Well, instead of making them neutral, I can assign them to the Special house, how about that?

That way, I can use the same, simple logic, but the general civilian stuff remains untouched?

Heh, that's a much simpler (and equally effective) solution than what I had in mind.

May I make a suggestion?

[VehicleType] HasPilot=y/n
[InfantryType] Pilot=y/n
[Warhead] KillsPilot=y/n

-Pilot= is VehicleThief, but limited to neutral units with HasPilot=yes.
-KillsPilot= turns the unit neutral, if HasPilot= is set to yes.

Actually, I've already half-way implemented the Warhead part of this - just missing some API stuff for the moment. Flag will be KillDriver=(true|false) on Warheads, turning the vehicle over to the Special house, as discussed above.

While suggestions are always welcome, Pilot=(true|false) already exists - it defines the InfantryType that parachutes from an AircraftType when it is destroyed.
Redefining it to mean "IsVehicleThiefLight" would likely confuse people, even if it were on a *Type.

The problem I see with restricting it to targeting a particular flag is two-fold:
For one, it defeats the purpose. It turns the flag from "make this weapon able to kill the driver of a vehicle" to "turn units with this flag neutral". It's a totally different thing in-game if you have a Sniper that you know can snipe the drivers of incoming vehicles, or if you have a dude which is effective against units Foo, Bar and Baz.
For two, that makes it kind of pointless...if you only want a particular weapon to have a particular effect on a particular group of *Types in the game, you could just add a custom armor and set the verses right.

However, I could add something like ProtectedDriver=(true|false) which counteracts KillDriver, if that is wished?

The reasoning for the HasPilot= tag was more then immunity, the thought was that you could preplace units to be piloted. That way you could have GIs jack cars, or place high-teir units as a vehicular version of a tech building.

Pilot= (maybe CanPilot=?) was intended as a limiter. Would prevent dogs from driving tanks, or wasting hero units by misclicking. Moreso it could make piloting a distinctive ability, such as giving surviving pilots a use.

I do, however, understand the points you've made. I am not trying to complicate this.

As for ProtectedDriver=, a tag like that would making coding in the logic easier and neater. Then again, armors were designed well, and can do the same job.

Dogs can be filtered out by blocking units with NotHuman=yes, just like KillDriver won't work on Organic units.

I'll guess I'll have to add something like HasDriversLicense=(true|false). Default false or true?

I'd personally recommend false. Its easier to add HasDriversLicense=true to all military personel then it is to add HasDriversLicanse=false to all civilian units. Makes even more since if you want the ability reserved for a pilot type unit.

BTW, how will this work with mind control?

"Its easier to add HasDriversLicense=true to all military personel then it is to add HasDriversLicanse=false to all civilian units." - Fail, you know Renegade was joking right?

And just how would you know that?

Droke: Do I want this to be reserved for pilot-type units? I mean, wanting it to work on everyone by default is a valid usage case. The reverse is like saying "sure you have hundreds of GIs, but none of them can drive a car - now go build SpecialDriversLicenseGI".

Implementing it as a turn-off-flag is just as valid as as a turn-on-flag, imo.

Do you? Driving a tank is quite different from a car. You can have hundred of GIs, and likely none of them would have been trained in the specialist role of operating a tank.

Sorry for not being able to tell sarcasm apart from irritation. Thinking that it was a prompt for information, I gave it. Honestly, I waited a day or so in the hopes that someone else would post, as it seems I have a nack for opinions counter to the popular consensus.

That being said, I know this is a game. GIs, civilians, and everyone else could have taken a "Tanks and You" class in high school. I considered both options and gave my personal view with supporting reasoning. I almost gave supporting reasoning for both defaults, but figured that would have been indecisive and irritating.

Code related to this issue has just been checked in; Renegade wrote in revision 382:
On WarheadTypes: Added KillDriver=(true|false), default false
On TechnoTypes: Added ProtectedDriver=(true|false), default false
On TechnoTypes: CanDrive=(true|false), default false

General logic should, on principle, work, but re-capturing with normal units isn't implemented yet, that would need VehicleThieves at the moment. Thus, CanDrive is not hooked up to anything yet, either.

The case of Operator=-using targets needs to be implemented better, ejecting "innocent" bystanders rather than killing them all.

Related to issue #733.
This change pertains to Ares 0.2. It does not affect the upcoming Ares 0.1.
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=382&sc=1

Code related to this issue has just been checked in; DCoder wrote in revision 413:
Related to issue #733 - missing headers, code corrections.
Also slightly refactored survivors code to make more sense.
Related to issue 733 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=413&sc=1

Code related to this issue has just been checked in; Renegade wrote in revision 550:
Merging 0.2 branch into trunk.

issue #599 and issue #803: AlternateTheaterArt & NewTheater - transferred AlternateTheaterArt property and Hooks.Art.cpp; this was written by D and looks complete - since it's marked as resolved, I'll assume that's all I need to do.

issue #733: KillDriver - basic implementation, lacking (proper) handling of specific operators, but *should* work in general - unless there are silly mistakes I made. Only tests (and raging compilers) will tell.

P.S.: For confused newbies: This is internal and only for testers. These changes are not in the public, stable release.
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=550&sc=1

Current problems:
- Ignores Iron Curtain
- Slaves of Slave Miners do not change sides. They should switch sides to the killer like with other weapons.
- Same with spawning units. The spawns should die.
- Special house Slave Miners start harvesting ore
- If a unit is mind controlled, it is freed. If a unit is a mind controller with captured units, they are neither freed nor do they change sides.
- Units with killed drivers still drive around and do stuff (when in teams?).
- Shooting on a Special house unit can cause it to move a little to dodge fire.
- Special house is allied to everyone. Infantry can enter transports/operated units and you won't get them back.

Code related to this issue has just been checked in; Renegade wrote in revision 597:
Issue #733:

This should fix:
- Iron Curtain being ignored
- Controlled units not being freed
- Enslaved units not being freed
- Spawned units not being killed

This will hopefully fix:
- Units still moving around after the driver was killed
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=597&sc=1

From Alex:
- IC works
- both capture cases, too.
- IsImmobilized causes the unit not to be targettable any more
- Slaves change side to the killer.
- allowing to kill drivers of aircraft is a bad idea (ports rendered unusable. game thinks you can build more aircraft).
- SpawnManager keeps attacking stuff even after the owner is Special. Setting SpawnM->Target and ->Destination = NULL helps here.
- QueueMission(mission_Sticky, true) should be more fitting than mission_Sleep(

Code related to this issue has just been checked in; AlexB wrote in revision 598:
Related to issue #733: Small alterations. Added Temporal warhead check.
Related to issue #856: Units that are being warped out don't make a good target.
Fixed issue #896: Implemented with string constants.
Fixed issue #878: EMP'd infantry is no longer allowed to deploy. TS doesn't know deployed infantry and thus could not handle it.
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=598&sc=1

Code related to this issue has just been checked in; Renegade wrote in revision 603:
Issue #733:
- Should not work on AirportBound=yes or aircraft with a Dock= list anymore.
- Should properly handle operators and passengers.

If no further issues remain/surface, this should finish the killing side of KillDriver; next stop: Retaking those vehicles.

Also renamed ParadropSurvivor to EjectSurvivor as per D's request.
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=603&sc=1

Yehaaw, this is my first Note in here.
I'm following ares for some time, but in "read only"-mode

reading the notes "above" i wondered what happens if a mindcontrolled unit enters a vehicle with killed driver?

My suggestion:
Vehicle is controled by the mindcontroller.
if mindcontrol breaks up, the vehicle is owned by the player, owning the unit which was mindcontrolled before.

if this happens, and the mindcontrolled hijacking infantry unit is a civ, the vehicle should be a civ-vehicle from then on.

----

anyone noticed that the combination of mindcontrol, hijacking and dead drivers is quite confusing?

In the unmodded game, MC'd units can't enter anything except Absorb structures. Unless someone explicitly codes (or already coded, I can't keep track of their achievements anymore) that, they won't enter these either.

Code related to this issue has just been checked in; Renegade wrote in revision 609:
Issue #733:
Fixed NULL-pointer/crashing bug in slave management code - all credit for discovery/analysis to D and Alex.
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=609&sc=1

@Firefly/DCoder: I am unaware of any such extension, so MC'd units should not be able to drive in the first place.

Crash still happens when an Slave Miner exits the War Fac an the driver gets killed while still inside.

Also, when a unit has its driver killed while being kicked out of War Fac it will keep driving around. Maybe the kicking out code overrides the sticky mission.

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r629
Revision comment:
Fixing some warnings MSVC complained about, first binary recompiled after REORG! I think.
Updated KillDriver through YR++ update.
Related to issue 733 .
SVN: http://svn.renegadeprojects.com/Ares/629

So. Before I start screwing with this again, can I please have a report on what works and what doesn't?

According to my own commentary and that of the other coders, the KillDriver side of things should be working, and the code implies that ProtectedDriver is properly parsed, and that the only thing left missing is CanDrive - iow, if you have a VehicleThief the system is already usable.

Is this correct, or are there parts of KillDriver/ProtectedDriver that remain buggy or unimplemented?

Alright, since community interest in this issue is apparently so low that, over the course of one month, no one could be bothered to even check if a single flag works, I assume this feature is no longer desired.

As such, there is no point in developing it further.

hm, I didn't notice your earlier post, otherwise I may have given it a shot sooner...

Well, it may be pointless now, but fwiw, I did some quick testing for both flags and both seem to work as intended. I may test them a bit more thoroughly tomorrow.

Well, should this be picked up again, a full report would be helpful, but for now, I'm removing the targeting, and I'm assuming after 0.2's release, it'll be queued up way, way behind the likes of #bug:349 and #bug:981.

Not too interested in this but just to comment, currently what happens when a hijacker hijacks a vehicle that has a driver?

He hijacks it, I guess? Whatever Westwood coded for VehicleThief against Passengers...

Yeah, I was just thinking should the driver be killed or is it a "at gunpoint drive" hijacker?

I think you're missing the point - VehicleThief is a Westwood logic. It doesn't know about Ares's logic. All it does is switch the vehicle's owner with no regard to anything else, afaik.

Yes, that's kinda my point. Should it be left at that or should it also kill and replace the driver?

You're still missing the point: What Westwood did is what it is. The "won't fix" in the bug description isn't there for fun. There seems to be no interest in this feature, so we're not going to screw around with it anymore.
It doesn't matter what should be, what matters is what is.

Either way, according to MT in chat, hijackers don't work on KillDriver'd vehicles anyway.
He's gonna check mind control tomorrow.

Also, finally, I was killing a driver while it was moving
 and it moved to the gathering point anyways
 with the rest of still alive friends

...probably not setting a stop mission or not setting the right one.

OK, tested a bit more and as far as I can tell, KillDriver seems to work fine against vehicles with an Operator.

When I had an AI-controlled tank with KillDriver weapon attack my tank without Operator-logic however, it only changed the house of my tank to that "neutral" special house, but they still continued shooting at each other.

Oh well. Sucks, but since no one cared, it's okay. Thanks for taking a look.

The unit not stopping after the driver was shot was resolved silently in rev973. The unit is liberated from its team. And just to recap what I said in IRC months many ago: I'm not aware of any bugs in the KillDriver logic - all bugs listed here are resolved so far. Taking back empty vehicles is still not possible, though.

KillDriver/Jarmen Kell logic could suffer from the same issue as bug:1422 (TemporalClass not being restored because PassengerClass is interacted with directly, skipping the Gunner special handling in Foot::Remove[First]Passenger), thus I updated it in rev1020, too.

Code related to this issue has just been checked in!
Author: AlexB
Location: ft-hijacker, r1039
Commit contains DLL: Yes
Revision comment:
Related to issue #322: VehicleThief doesn't check NonVehicle any more. It now uses VehicleThief.Allowed.
Related to issue #733: Unlinked permanent mind-control and delete hijacker if KillDriver is used.
Fixed issue #762: Hijacker and mind control should work well together now.
Fixed issue #1403: VehicleThief doesn't need Thief=, Infiltrate= or Agent= to work.
Fixed issue #1493: CanDrive= implemented to reclaim neutralized vehicles. Compatible with VehicleThief.

Documentation updated.
SVN: http://svn.renegadeprojects.com/Ares/1039

Just saying that I tested it with permanent MC and KillDriver, and they seem to be working fine together.

this issue should be set to resloved fixed or closed, becuse it works and no new bugs have been reported for a while.

This issue will stay open for some more time to remind all testers confirming an issue isn't done by just checking whether the implemented stuff is working as documented, but also whether all the unrelated stuff isn't negatively affected.

Thats what I did, I tested this with tons of other stuff.
But there is nothing wrong with keepnig this one open, just saying that I did deep testing with this logic.

It wasn't directed at you personally. In the last time, there were just too many obvious bugs that should have been encountered. They weren't because development was fast-paced and the code-test-debug-close-goto1 cycle was spinning way too fast. Before I'm not sure this is long-term tested, I can't merge the hijacker branch.

Doesn't work? No more info like "I don't get an enter cursor" or "I get an enter cursor, but the hijacker doesn't accept the command" or "It moves to the aircraft but won't capture it"?

EDIT: This answers a deleted post. Aircraft works, as long as it isn't docked to an airport.

Me sorry, me don't meant to. I missed the point that the aircraft have to be AirportBound=no and Dock unset to be killdrivered.

This feature works fine for me.

Ok, I think it's safe to close this now. No new bugs for almost three months. If this is to be included in 0.2 and problems arise, please request this issue to be reopened. For now: Thanks to all testers! Closed.