Jump to content

Recommended Posts

Anyway, just to bring my point across why playerControlled should absolutely, most definitely exist, you can set up this simple situation in the game right now with two lines of code.

It's absolutely beautiful that we can do this right now.

a remoteControl b;
c switchCamera "External";

AGLvBUL.png

Share this post


Link to post
Share on other sites

The main problem is that remoteControl, originally a BI sqf cmd hack meant for UAV use, is now used also in Zeus to easily switch into other entities.

This should use selectPlayer instead (especially giving the limitations remoteControl has). However as selectPlayer is somewhat tricky to get working,

I would assume BI went the easy way with remoteControl.

 

The secondary main problem is that people use Zeus with remoteControl and expect all scripted features to work as usually.

Even more the functionality seems also commonly used with Eden - so even more situations where player expectations are not meant.

 

Now players are blaming community made scripted systems to not work with Zeus or Eden, while the source of the issue lies with BI.

That are the ones to sort out this mess - its absurd to expect community modders to change their scripts from player to playerControlled

or any other ugly hack for this Zeus feature.

	class ModuleRemoteControl_F: Module_F
		scope = 1;
		scopeCurator = 2;
		isGlobal = 1;
		category = "Curator";
		displayName = "Remote Control";
		function = "BIS_fnc_moduleRemoteControl";
.\a3\modules_f_curator\Misc\Functions\fn_moduleRemoteControl.sqf
  • Like 3

Share this post


Link to post
Share on other sites

 

The main problem is that remoteControl, originally a BI sqf cmd hack meant for UAV use, is now used also in Zeus to easily switch into other entities.

This should use selectPlayer instead (especially giving the limitations remoteControl has). However as selectPlayer is somewhat tricky to get working,

I would assume BI went the easy way with remoteControl.

 

The secondary main problem is that people use Zeus with remoteControl and expect all scripted features to work as usually.

Even more the functionality seems also commonly used with Eden - so even more situations where player expectations are not meant.

 

Now players are blaming community made scripted systems to not work with Zeus or Eden, while the source of the issue lies with BI.

That are the ones to sort out this mess - its absurd to expect community modders to change their scripts from player to playerControlled

or any other ugly hack for this Zeus feature.

 

I disagree, while playerControlled doesn't exist, the alternative way of reading the remote control unit of those features via the variable was the was there for the start. Remote control for UAV and for Zeus is perfectly fine because it is what is happening, and the reality is, when you need a feature to control a different entity, in majority of the cases in this game you want remote control. While for cases like team switch, selectPlayer is what you want.

 

Just because an author expects player to work one way, and it doesn't, doesn't mean the command is at fault. It's the same exact thing like dividing something and forgetting that division by zero will error out, and then arguing that when dividing by zero, zero should actually be treated like 0.00000000000000000000000000000001 because many authors forgot to account for that possibility.

 

The ugly hack, that you describe, is solely due to lack of playerControlled (or any other command that would return you the destination unit of "a remoteControl b") and the necessity of actually exposing it to authors.

 

Look at the picture presented above and tell me how setting the player to anything else than it is in the picture is a sane option. Who is "player" for you there?

Share this post


Link to post
Share on other sites

Ok, but the bold part is not clear to me. Why do you think client "identity" and client "control" should be combined into a single "player" variable? What is not working out of the box?

 

Even if we were at step zero and started from scratch, to me it would still make much more sense to have "player" return the "identity" of the client, while something like "playerControlled" returned the control of the client.

There was no need to make zeus remote controlling like UAV remote controlling in the first place. Just look at how strange it is that you have to use the "leave UAV" action menu option to return to the zeus interface. The not dying part could've been handled differently.

Share this post


Link to post
Share on other sites

Sniperwolf572 i respect you very much, but on this case you are just dead wrong.

Just look back into the history of selectPlayer, remoteControl, Zeus and the various fixes/changes BI made.

You can even read back in the CIT Suma's comments on selectPlayer.

Or just read the BIKI limitations of remoteControl - it was a hack for UAV control and its abused now for Zeus.

 

Thats the situation - you can argue as much as you want. The history speaks for itself.

Share this post


Link to post
Share on other sites

There was no need to make zeus remote controlling like UAV remote controlling in the first place. Just look at how strange it is that you have to use the "leave UAV" action menu option to return to the zeus interface. The not dying part could've been handled differently.

 

This should've been simply fixed by better presentation, something BI is horrible at.

 

A "release control" keybind and proper localization of the action menu entry. Maybe even more of an on screen text that says "Press KEY to release control"

They already tried to make it clear you're remote controlling with the laughably vague vignette around the edges.

 

I don't see how it was better to do anything else than remote control, preserving the player context for the player Zeus is beneficial. As is for all the other possible cases of remote control, other than UAV and Zeus. What's the point of solving it differently when you have a perfectly functional way to do it. There'd be more workarounds needed if player context switched rather than how it is now.

 

Sniperwolf572 i respect you very much, but on this case you are just dead wrong.

Just look back into the history of selectPlayer, remoteControl, Zeus and the various fixes/changes BI made.

You can even read back in the CIT Suma's comments on selectPlayer.

Or just read the BIKI limitations of remoteControl - it was a hack for UAV control and its abused now for Zeus.

 

Thats the situation - you can argue as much as you want. The history speaks for itself.

Same here, I guess this is one of those situations where we have to agree to disagree. I agree there are things to be fixed with various commands, but I don't see this specific thing as one of them.

 

However, identity, view and control contexts seem perfectly logical to me, and I really dislike the fact that I'm arguing with clear examples of usage, solutions and beneficial points of current behavior and all I get back is "no, you're wrong, hacked, abused, broken".

 

All I'm asking is to provide me a better way to do what was shown in the image I've illustrated, that gives you more freedom and control, than what is currently given.

The question is so simple, why do you think it's better/beneficial if player variable becomes the driver logic of the UAV and why is it better if the player variable becomes the remotely controller Zeus unit after using "remoteControl".

 

I've clearly given you why I think it's better it does not. You have a command framework for switching all those contexts, and you want to shove them all into one due to ignorance on how to use them instead of expanding them so they work solidly.

 

As for your references to history, I'd appreciate it if you actually linked something, I can't find anything in CIT related to selectPlayer or remoteControl with any of Sumas comments and Biki only shows things not relevant to what we're talking about.

Share this post


Link to post
Share on other sites

I don't see how it was better to do anything else than remote control, preserving the player context for the player Zeus is beneficial. As is for all the other possible cases of remote control, other than UAV and Zeus. What's the point of solving it differently when you have a perfectly functional way to do it. 

Maybe it is, maybe it isn't. I wouldn't change it at this point.

 

There'd be more workarounds needed if player context switched rather than how it is now.

Proud to say that we are doing that anyway since AGM.

Share this post


Link to post
Share on other sites

Does anybody know why we can't rotate the camera while playing as animals ? for example dogs or rabbits

Share this post


Link to post
Share on other sites

Does anybody know why we can't rotate the camera while playing as animals ? for example dogs or rabbits

 

it is a limitation of the animal parent class afaik. the other possibility is lack of animation weighting masks inside the anim config (look under class blendanims). you'll probably be better off making a thread about it in the right editing section so people can share their findings on this subject. this topic here is more about code/sqf if i'm not mistaken.

 

 

on the subject of remote control used in zeus:

 

it's a very common issue for many mods that manipulate the input using UI eventhandlers to make the player do stuff. my memory is cloudy because i gave up on this a while back, but is the issue really just finding the right unit or is it related to the used UI EHs too?

 

now it seems you guys have digged deep into this subject so i was wondering if there is an easy fix for that.

Share this post


Link to post
Share on other sites

Any chance we can get make the "count" parameter in "array select []" optional?

_string select [3]

 works, but you have to write:

_array select [3, 1E7]

otherwise it complains about a missing parameter.

Share this post


Link to post
Share on other sites

The inventory commands don't report the integrated items.

player addHeadgear "H_PilotHelmetFighter_B";
hint format ["hmd: %", hmd player]; // expected: 'hmd: Integrated_NVG_F', actual: 'hmd: '

Major inconvenience. The slot is blocked and the command should therefore report the integrated item.

Share this post


Link to post
Share on other sites

Cleaning up variables from object namespace is broken.

 

works correctly:

missionNamespace setVariable ["testvar", nil];
[missionNamespace getVariable "testvar", "testvar" in allVariables missionNamespace]
// reports: [<null>,false]

but does not work for:

player setVariable ["testvar", nil];
[player getVariable "testvar", "testvar" in allVariables player]
// reports: [any,true]

There is no need for this. The variable name should be removed from the object variable hash.

Share this post


Link to post
Share on other sites

"setUnitLoadout" suffers from the same problem "addWeaponCargo(Global)" does regarding mine detectors - the mine detector is considered a secondary weapon / rocket launcher.

player setUnitLoadout [[],["MineDetector","","","",[],[],""],[],[],[],[],"","",[],["","","","","",""]]

9KEzJKH.png

 

Note that this version of the mine detector does not stack with the regular ones, does not detect mines as far as I can tell and takes up no space in cargo / has no "mass".

 

 

Btw. there seems to be no way to resize images on the forum.

  • Like 1

Share this post


Link to post
Share on other sites

The garbage collector is too eager regarding ground weapon holders.

 

Using:

test_gwh = "groundweaponholder" createVehicle position player;
test_gwh addItemCargoGlobal ["FirstAidKit", 1];
clearItemCargoGlobal test_gwh;
test_gwh addItemCargoGlobal ["FirstAidKit", 1];

does delete the ground weapon holder one frame later, despite there being one item in the cargo.

I know this example does not make practical sense, but it's the easiest way to reproduce. If you're trying to manipulate a ground weapon holder currently, you have to always add a safety item which is later removed in case the ground weapon holder is empty at any point in your script. This does apply to unscheduled environment too, so no fluke.

 

 

  • Like 4

Share this post


Link to post
Share on other sites

"setUnitLoadout" suffers from the same problem "addWeaponCargo(Global)" does regarding mine detectors - the mine detector is considered a secondary weapon / rocket launcher.

player setUnitLoadout [[],["MineDetector","","","",[],[],""],[],[],[],[],"","",[],["","","","","",""]]

9KEzJKH.png

 

Note that this version of the mine detector does not stack with the regular ones, does not detect mines as far as I can tell and takes up no space in cargo / has no "mass".

 

 

Btw. there seems to be no way to resize images on the forum.

There is "MineDetector" listed as weapon in CfgWeapons with type 4 which is secondary weapon slot. So if anything it is an error with config, unless this was intended.

Share this post


Link to post
Share on other sites

There is "MineDetector" listed as weapon in CfgWeapons with type 4 which is secondary weapon slot. So if anything it is an error with config, unless this was intended.

 

I have seen Mine Detectors attached to player multiple times in multiplayer games. I thought this was caused by a mod. Definitely a bug which should be squashed!

Share this post


Link to post
Share on other sites

It happens in vanilla, because the same bug applies, as I wrote and reported on the feedbacks, to addWeaponCargo(Global) which Zeus uses.

Every MineDetector added by a Zeus is affected by this. When scripting yourself you can always use addItemCargo(Global) instead, which adds a working version of the item.

  • Like 1

Share this post


Link to post
Share on other sites

whats up with the two new commands

 

isRemoteExecuted

isRemoteExecutedJIP

 

why not just one command which returns an array of bools?

 

_isRX = isRemoteExecuted;      // [<bool>,JIP<bool>]

Share this post


Link to post
Share on other sites

 

whats up with the two new commands

 

isRemoteExecuted

isRemoteExecutedJIP

 

why not just one command which returns an array of bools?

_isRX = isRemoteExecuted;      // [<bool>,JIP<bool>]

Developed at different times 

Share this post


Link to post
Share on other sites

Any chance to somehow make the already existing license plate system work on vehicles that are being spawned mid-mission and give some script commands to create/retrieve a vehicles license plate?

 

arma3_2014-07-14_09-31-08-05.jpg

 

This would open up quite a few mission making possibilities and enhance mission design.

 

Cheers

  • Like 4

Share this post


Link to post
Share on other sites

Am I the only one longing for an alternative version of the HandleDamage EH? One that would return passed damage raher than the resulting damage.

  • Like 3

Share this post


Link to post
Share on other sites

Any info on the new "PlayerViewChanged" eventhandler?

Adding this as unit or missionEventhandler with "hint str _this" does nothing.

Even adding a wee bit of additional info to changes/additions would be most welcome.

 

Cheers

  • Like 4

Share this post


Link to post
Share on other sites

Would it be possible to give vehicle colour randomisation another overhaul in the future? It seems that the colours are still not syncronised between players, which is incredible annoying.

https://feedback.bistudio.com/T120174

Share this post


Link to post
Share on other sites

Correct me if I'm wrong, but it's impossible currently to return the name of the music track being played? Meaning that we can't check if a soundtrack is being played before triggering another one, for instance.

A command like currentMusic would be nice to have... ;)

 

EDIT : I know this can be worked around with music EHs, but I've found those to be unreliable...

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×