Any chance of this being fixed?

Issue still remains as of today's dev branch. Would it be possible to get any updates on this? CT_MENU is a really formidable control and would be very useful in many projects.

Confirmed, fixed in today's dev branch update. Thanks again.

As of today's dev build, this issue is still not fixed. Was the fix you mentioned pushed today or expected later?

Excellent news, thank you for fixing this so quickly :)

Richard, if you would follow Steps To Reproduce you would clearly understand the problem.
If even that is unclear, then a repo mission could be made I guess.

remoteExec and remoteExecCall is essentially useless in many scenarios unless this is fixed before 1.50.

Also tested without CfgRemoteExec (mode 2).

Currently you are still able to call any white listed functions on the server (regardless if they are defined client aide or not) but only if you provide 2 or less params in an array.

This will work:
[1,2] remoteExec ["serverfnc",2];

This will not:
[1,2,3] remoteExec ["serverfnc",2];

...using remoteExec obviously. It's not uncommon to have functions that are defined server side only that can be called by clients using BIS_fnc_MP for example.

You seem to have the wrong end of the stick. I want to call a function on the server machine from a client machine where the function does not exist.

I don't doubt it works, but you would still be unable to have some shared, and some sp and mp specific. Besides mlink is a bandaid solution at best.

Not without copying or moving files and folders. Please at least read the ticket before down voting .

Still won't allow you to have a shared folder, an sp folder and mp folder completely separate from each other. It's a good temporary solution however.

So wait, Jay Crowe has been replaced by Michael Bay as creative director?

Added repro mission. Try running this same mission in both the singleplayer and mutliplayer editor.
In the multiplayer editor when previewed, the 2 units will have the desired effect and have their simulation disabled as well as being hidden.
In the singleplayer editor however, when previewed both units simulation will still be enabled and both units will be visible despite using both hideObjectGlobal and enableSimulationGlobal functions.

Again this is very inconsistent behaviour for global functions and I implore you to read the ticket and comments in detail.

Hopefully this has been fixed today, will test soon.

Exactly, it's a definite quality of life improvement for mission makers!

There are other commands that say they need to be exectued on the server but work just fine in singelplayer (such as assignCurator). It's just inconsistent beacuse these are the ONLY 2 global functions that don't work in singeplayer at all.

If I was to make a mission for the steam workshop and added the singleplayer and multiplayer tags to the mission, it would obviously be available in both from the singeplayer scenario menu and when starting a multiplayer server.

Point being in that mission is if I have a missionFlow.fsm with a condition to run server side only, and after the condition say I want to hide an object, I would use hideObjectGlobal to hide it for all current clients and JIP. However this wouldn't hide anything at all in singeplayer so I would have to add an if statement (isMultiplayer) there to use either hideObject or hideObjectGlobal.

Just additional scripting for something that should work using the global command in both situations anyway.

Nope.

Both of those commands do work, however there are other "server" global functions that work fine in SP, such as setObjectTextureGlobal.

Like I said before, it's a real pain just these two commands not working in SP. So developers can't make a scenario to work both in SP and MP easily using one command.

This functionality has been present for a few versions. Can be marked as resolved.

+1 and bump for this issue, makes no sense to not have the alternative syntax. Having the ability to both hide AND show objects using this new global command is a must.

Definitely a step in the right direction. However there needs to be a way to disable the setTexture functionality of a vehicles altogether (exit the script).

So, you won't fix this during the ALPHA stage of the game? So what is alpha for exactly? An early showcase of mistakes and problems that won't be fixed?

Sleep is NOT an elegant solution to make sure your event handler is the last one applied. I find it completely unacceptable that BIS is unwilling to fix this during alpha.

Definitely a problem, the BIS handler seems to always get first "dibs" when it comes to returning the damage value, making it impossible for any addon or mission maker to actually "handle damage".

Running 2 way SLI here, issue is still present on the latest version of the development branch. The issue is especially noticeable inside of vehicles that have multiple monitors/screens, for example the Hunter HMG and GMG.

Nice new PiP sling loading camera in the CH-67 Huron. What a shame for us SLI users that it won't be usable...

Please Bohemia, do something about this. The issue has been present since Take of Helicopters.

Still no news on this from ANY developer? Not even a simple "yes we're trying to fix it" or "it's on our todo list".

If BI plan on adding any kind of PiP features to any of the new helicopters that are coming with the DLC, you won't get my money until this issue is fixed. Highly irritating and ruins immersion in most vehicles.

This bug is really irritating, makes the SDV and UAV menu unusable. Is anything even being done about this currently?

Definitely an SLI issue, I had the same problem in Take on Helicopters.
If you disable SLI in your video card control panel, flickering issue disappears.

Can anyone else confirm that?