So, I have no idea how but I'm consistently reproducing this now every time I launcher arma straight into eden and then immediately hit "play in SP":

Again. On the bright side they aren't hard locking my whole system anymore:

Another one. I had just launched the game into the editor and it happened immediately:

And another. This one was different, the screen went black then the display driver recovered and arma was just gone. Had to kill the process in task manager. Shows the same error message at bottom of rpt though.

Another one. Didn't crash driver completely. Had just launched arma straight into the eden editor and it happened almost immediately.

Also, just to provide further information I tested with "Sign_Arrow_Green_F" and it causes the same rising issue. So it's not specifically the helipad that causes the issue.

Yeah I can confirm for certain that it's because the camera target dummy object used is "Land_HelipadEmpty_F" (came across the same issue in overhaul process of ace spectator. Can be fixed by just using a "Logic" instead.

Another one that totally crashed all display input. Again on the profiling branch.

Another one, the same as the last. This time I was using the profiling branch to see if perhaps that would resolve the issue.

Another one.This one occurred while I was tabbed into the game doing some testing. Didn't crash my driver completely this time so I didn't have to hard reset. Error at the bottom of the rpt looks the same though.

Second time today. Happened shortly after I alt-tabbed out of the game in the eden editor. I had turned down some of my graphics settings to see if perhaps that would help.

Another crash, this one killed my display driver completely so the screen input ended and I had to hard reset my computer.

I've started to encounter this crash after the 1.70 jets update. So far it's fairly inconsistent and I've only produced it during development work for ACE - seems to happen while I'm alt tabbed out of arma working in my text editor. Has happened while idle in eden, while idle in game, while idle at the pause menu. Seemingly always when I'm tabbed out though.

I suspect this is because BI use a "Land_HelipadEmpty_F" in their spectator script as a dummy object which is attached to units for the purposes of camera tracking. (Line 78 of fn_EGSpectatorCamera in functions_f_exp_a.pbo)

Curious to know why the reason 2 people have voted this down? It's not exactly a hot topic so the votes themselves aren't obvious. Do you disagree with consistency?

I also think getRemoteSensorsDisabled should just be remoteSensorsDisabled (or enabled if the other command name is changed)

I agree with the sentiment, although it's a little problematic since they start off enabled. Though I guess the same is true for enableFatigue and allowDamage. Voted up.

Sorry adam, it seems I can no longer reproduce this with the same steps.

I think it must have been something relating to the specific addon I was loading before because I consistently reproduced it 6 times in a row.

I will attach the .vars.Arma3Profile file I had before it was wiped (yay for backups) and what I believe is the incorrectly packed addon I was using at the time.

Is there a way to retroactively make an issue private? I can't find one.

All virtual units won't appear in playableUnits afaik. This seems like a design decision and I think it's a good one personally.

Oh interesting, thanks for the info Moricky. (Can't be very well known as a google search for that function name returns only 1 result: this page).

Even better, I'll edit the post with that

It seems that I'm partially wrong about the controls being explained. They weren't explained in any of the three MP missions a unit I play with hosted over the weekend.

However when manually calling BIS_fnc_respawnSpectator in the SP editor, I was given a popup to explain them.

Don't think that's actually possible without spawning in an object to act as the background (which would have no effect on the lighting anyway)

BIS_fnc_MP is a way that you can execute local commands globally.

Triggers are created on every machine, that is to say their code will be executed on every machine when activated.

It sounds like you're running into a simple locality issue.

I have no idea what the spawnGroup command is (as far as I know there is no such thing), but you basically need to enclose your code in:

if isServer then {
<your code here>
};

I downvoted because this isn't really something that belongs on the tracker, the forums are a better place for solving mission making issues. Sorry I didn't have time to write a reply at the time.

Edit: Another solution is to edit the condition field of the trigger to say "this and isServer" - probably the simplest solution really

Again, it's not related to the scheduled and unscheduled environments.

preInit/postInit/etc. are a matter of timing. The scheduled and unscheduled environments are a matter of execution.

You can happily communicate between machines in an unscheduled environment, you can't do so before the game has initialized (which is a design limitation, not a free variable).

Edit: Though yes, your new feature request reflects something that is feasible and I'd like to see implemented.

I'm not quite sure you understand, I wasn't being sarcastic.

If you look at the comments of the issue posted by Xeno, you'll see that public variables do not work preInit (as confirmed by developer Karel Moricky). This behavior is intentional because why would public variables work preInit? It's being ran before anything is initialized so that doesn't make much sense when you think about it.

The reason your code works, is because you're using the spawn command. This delays the code long enough for it to no longer be ran in the preInit time interval.

I'm not quite sure I follow your line of thought with the unscheduled thing, it's pretty unrelated to this feature request and because you're spawning your code you're running it in a scheduled environment anyway.

Anyway, my point is that since nobody would ever use public variable preInit then there's no need for client ID's preInit.

^ I think the above means this ticket can be closed (Since the client ID would be no use preInit anyway).

I'm doubting my memory now, but I know for certain that using spawn causes the code to run late enough for it to no longer be preInit (you can verify this by trying to use paramsArray preInit on a client - it doesn't get PVd until time 0 - and then the same but spawning the code).

Will have to do some testing now.

I do agree that there should be a better way to get a clientID than the owner command, but I'm not really sure how. Maybe it could be added as another argument to the publicVariableEventHandler.

Just a heads up: public variables do not work preInit

"it takes days and even weeks to get enough time to learn enough scripting to deal with such a fundamental issue"

This is simply untrue. They added the arsenal for those who want to avoid scripting.

There's a config viewer in the editor, just look for the path shown in the error.

(That is: configFile >> "RscListBox")

The issue tracker is not the place for questions. Try the forums: http://forums.bistudio.com/index.php

Voting for the same reason as denis above. Might be nice to change this to a feature request for those damaged models to be implemented.

Middle click already does this

You can add a saving=0 entry to description.ext in the mission folder or you can use the scripting command provided by Killzone Kid

Just a heads up, what's being referenced in the spotrep is this line from fn_moduleRemoteControl:

[_curator,"curatorObjectRemoteControlled",[_curator,player,_unit,true]] call bis_fnc_callScriptedEventHandler;

I've also experienced this

It wouldn't be overly complex, but fairly complex relative to the result it'd produce. The most complex parts would be:

1. Displaying the system intuitively to users via the interface (documentation aside as I know first hand not everybody will read that).

2. Figuring out how best to handle magazines/items that can be stacked within such a system.

3. The process of integrating said new system into the existing one. I haven't looked at the module specifically yet - if it's passing a unique argument to the VA function then this wouldn't be too hard, but if it's using an existing argument and you want the new system to work for that argument you also need to think about instances of the VA outside of the module.

I'm not sure about this suggestion. Obviously I'm not a dev, but I imagine they need to draw the line between adding tools mission designers can utilize in a widespread fashion and tools mission designers should create for themselves on an individual basis.

You're asking for a feature that would be quite complex to implement which can be very easily scripted by a mission designer (in a much more flexible fashion that offers more control too).

Although, just to clarify: Are we talking about exporting the loadouts from the VA or using the Arsenal module? Or both?

"there is a small code bug that prevents using the VA with units other than player (eg AI units). See attached file for fix."

How can this be the case when there is a VA module that can be used on AI?

Well that cuts one more loop out of my missions :)

As for making a persistent group, I suppose you could add a game logic to the group or something to stop it becoming empty.

"At the moment, when a soldier squad (aka group) has no more units it is immediately deleted from the mission and all variables referencing it are unusable."

Since when has this been the case? I've always needed to create a loop to delete empty groups so as to avoid the limit.

Also, perhaps a better idea to add setVisibleGPS rather than update showGPS. Keeps the syntax in line with visibleGPS.

Edit: Plus I was told at some point that showGPS does actually have some kind of use.

Thanks KK!

My take:

I voted down as I don't think this is relevant to ARMA 3. However, I could see some minor implementation of such features being feasible for ARMA 4 (assuming there will be one).

I don't think we'll see full blown destructible buildings any time soon though as it would change so much and everything would need to be adjusted to work with it.

Read the title.

"You are rude and I have noticed that you have a very disturbing hobby of trying to provoke arguments with random strangers on the internet."

I can appreciate that I was a bit blunt, but I'm certainly not looking for an argument and don't know what makes you think it's my hobby. I apologize for the way my response was worded as it didn't clearly express my intent.

My comment was not intended as a personal attack of any sort, it was just meant as a comment to express my confusion at your response (as I genuinely couldn't tell whether you were being serious). I used "untaught" in place of ignorant as I wasn't sure how to express the idea without negative connotations - clearly I failed on that front and should have simply directly stated my confusion.

As for the actual feature request. I can respect the request, I just meant to say that it's not exactly "such a simple task" (especially this late into ARMA3's life).

Edit: Expanded comment

Well now I can't tell if you're trolling, untaught or just didn't read my comment.

I don't think you understand what you're asking for here. Here's my explanation as to why I downvoted.

It isn't possible without either:

1. Separate software packaged or integrated into ARMA 3 (and automated - though that might already be a feature)

2. Entire copies of the terrains without objects on them

3. A change to the engine itself to allow deletion of terrain objects

Do I want any of those things in the ARMA base game? Nope. Do I think the developers should spend time on any of those things? Nope.

It's nothing personal, it's just what the voting system is there for.

This isn't possible.

https://community.bistudio.com/wiki/shownGPS

Currently does nothing, also obsolete with the addition of:

https://community.bistudio.com/wiki/visibleGPS

Issues aren't being ignored, they're just not a priority.

Would be useful, though really belongs in the "config" category

Duplicate 0020233

Yeah, what KK said.

I've never really understood whether I've understood how the init event handler works. I understand how it works from mission.sqm, but how do you add it to an object that hasn't been created yet? :P

Nobody is preventing a fix. I voted down because I personally don't see it as an issue that needs to be fixed.

The corpses disappearing thing is something mission makers have to implement themselves if they want it, though this process could be greatly improved with an expanded body disposal system (currently only works for playable characters).

http://feedback.arma3.com/view.php?id=19377

And there's the mission I was working on at the time. It is a WIP so it has changed a little since I ran into the issue.

Okay, so the file size of that one is too big to upload. I'll see if I can cut out everything that happened after I figured out what was causing the issue and moved on to making my mission again.

Scratch that. Can no longer reproduce the issue.

I could definitely reproduce earlier by removing and adding that config entry (on an entirely non-modded setup).

My .rpt from that earlier session is much longer so I've taken a look and tracked down the point where I ran into the issue (I can tell because I switched the unit I was using from I_G_Soldier_TL_F to B_G_Soldier_TL_F to see if it was something to do with that). The point where I encountered it was around line 1228.

Going to upload that full .rpt now, with some personal info stripped out.

There we go, I cut out all the stuff that happened after I found the source of my issue. So it's still around about line 1228 that it occurred.

Sure thing, should be up in 10 minutes or so

I imagine this is due to the weird model issues there have been with the crate itself

This is not what the *feedback* tracker is for

"how waypoints should work

1. first set a position for a waypoint
2. settings window will open
3. do your settings, click ok
4. not until then the waypoint is active"

I quite like this idea

this setVariable ["BIS_enableRandomization", false];

Duplicate of issue:

http://feedback.arma3.com/view.php?id=19678

Have experienced this, it's painful

Ooh, sorry! I misunderstood your ticket. Ignore my first comment.

Can't confirm this. All my testing has shown that subfolders are being send to clients just fine.

Also didn't realize until recently that it also happens with helicopters. (Though I suspect the scripting for the action is much the same across all the vehicles that support it).

Proposed fix: Instead of choosing a parachute based on the side of the unit, choose it based on the faction of the vehicle.

Makes more sense that way anyway and eliminates an error message at the same time.

Can confirm the problem is only present for civilians