Page MenuHomeFeedback Tracker

Cannot connect to empty UAV vehicle
Closed, ResolvedPublic

Description

Player isn't able to connect to empty UAV's.
But isn't a AUV an empty vehicle ?

Details

Legacy ID
766982804
Severity
None
Resolution
No Bug
Reproducibility
Always
Category
UAV (Unmanned Aerial Vehicle)
Steps To Reproduce

go into editor as blue UAVSoldier place all "empty" UAV's and try them.

Event Timeline

Tripwire edited Steps To Reproduce. (Show Details)Aug 16 2013, 3:25 PM
Tripwire edited Additional Information. (Show Details)
Tripwire set Category to UAV (Unmanned Aerial Vehicle).
Tripwire set Reproducibility to Always.
Tripwire set Severity to None.
Tripwire set Resolution to No Bug.
Tripwire set Legacy ID to 766982804.May 7 2016, 4:03 PM
Bohemia added a subscriber: Bohemia.May 7 2016, 4:03 PM

Solution: add AI agent when somebody trying to connect to 'empty' UAV :)

Actually it is possible to connect to an empty Qaudrocopter by disassemblying it and picking it up, then reassembling it, as this seems to somehow "sync" it with the soldier, i suppose due to the *take* action.
Still that doesn't work for the other drones as those cannot be picked up.

@Kol9yN: what du you mean with "add AI agent" how do i do that? Anyway, sounds more like a workaround than a fix.

kylania added a subscriber: kylania.May 7 2016, 4:03 PM

You can spawn an empty flying UAV and fill it with controllable crew via:

myUAV = [getPos player, 0, "B_UAV_02_F", WEST] call BIS_fnc_spawnVehicle;
createVehicleCrew (myUAV select 0);

A possible fix could be to have "empty" Unmanned vehicles become part of the faction that the uav operator who activated them is part of.

But then again someone may want an empty Unmanned vehicle for show or static vehicle in a base.

I think this might be intentional.

It's entirely intentional:

http://forums.bistudio.com/showthread.php?152866-Development-branch-discussion&p=2470272&viewfull=1#post2470272

"That is intended behaviour. You are able to connect terminal to the UAV of the same side. Empty UAV doesn't have any side (it has only camo of some side). That is the way how UAVs working right now and you can easily insert non-empty UAV, if you want to control it. Empty UAVs can be used as non-accesible vehicles in the mission or there can be inserted AI of desired side by script. If you think this is too confusing, you can create ticket in FT and we will reconsider that. Thanks for feedback" - DarkDruid

Spud added a subscriber: Spud.May 7 2016, 4:03 PM
Spud added a comment.Aug 28 2013, 11:03 AM

Surely it would be up to the mission designer to decide whether UAVs are usable or not? For some game modes objects spawn dynamically, if an empty UAV spawns which is of the opposing faction, then whatever actions triggered the reward of the spawn become pointless.

Not going to happen. You can't take control of empty vehicles, since there's no one to take control from.

It was mentioned above - this is intended situation. We can reconsider it, but what is the requested fix/change actually?

If we let you to connect empty UAV according to its camo, there still will be the issue mentioned by Spud. Select the side of empty UAV according to first try to connect. This doesn't seem very good either. In that situation everyone on the map should see it in UAV Terminal. You are faster, you have UAV. Or if we are talking about spawning, then all UAVs will belong to the person, who is checking its UAV Terminal most often.

I think there are some mods which need to use UAVs specific way. We can change current behaviour and help one of them, but I don't see any better solution which can help all of them. All these issues can be handled by author of that mod in current situation. If we change it, we can break this possibility to handle it for some mods.

Since a mission maker can "lock" a vehicle to make it static, an "empty" UAV should be able to be used by any side and not belong to any side in peticular. Once th player connects to it, it would take the players side. If an enemy connected to it, it wold become his/hers and not belong to the original player.

I guess this UAV should be visible in UAV Terminal. You spawn an UAV in your mission and it depends only on who will be faster to take it (really we want to motivate player to check his UAV Terminal every 5 seconds?). And if you take this (in this case lets say armed) UAV and place it somewhere near of your units, you can't disconnect it. Because if you do it, enemy will probably soon notice that and use the UAV against your units. And how are you supposed to know which UAV can be connected by enemy and which one belongs only to your side? Different camo? Some marks in UAV Terminal? And how we can explain this to player? How is possible that some UAVs are simply usable by everyone and some of them are not?

Yes, we can find some answer for all my questions if we really want to. But it wasn't easy for many players to use UAVs even in current version. When we released them, there was a lot of questions and you can find even tutorial how to use UAVs on forums. This change would take a lot of time to implement, because it is inconsistent with all what we already have in the game. And that is the main issue even for players, because it would be very confusing and extremely complicated for new or not very advanced players.

I don't think that this is the way how to make UAVs better or more atractive/usable.

if an empty UAV spawns which is of the opposing faction, then whatever actions triggered the reward of the spawn become pointless.

That's a problem of mission designer, not game design. It's pretty simple to edit scripts which are reponsible for reward creation:

if(getNumber(configFile >> "CfgVehicles" >> typeof _vehicle >> "isUav")==1) then { createVehicleCrew _vehicle; };

I think the ticket is non-issue. Current logic is good enough, if you use it correctly.

I mean, if you are in the editor, just place one that isn't empty... problem solved. The only issue I can see here is if a mission maker wasn't aware of this, they may place an unusable UAV, but besides that, it's intended situation.

This is intended behaviour and no one offered anything which would seem as significant improvement of current situation -> marking resolved as not a bug.

MadDogX added a subscriber: MadDogX.May 7 2016, 4:03 PM

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.