commy2

No.

@DieselJC Thanks for the report. Should be fixed in the next version. Pull request with fix: https://github.com/CBATeam/CBA_A3/pull/670

Please upload it.

Is that your mission?

@belbo It's supposed to work. Make sure to save the mission once, which triggers CBA to search for the file and mark your mission as one that contains the file. That should also be logged in the RPT.

If it says that the server is using a different version of whatever, then it probably is, even if you think you got it right. Check the servers RPT file. If you have no idea what to look for, upload it.

I debugged the savegame issue. https://github.com/CBATeam/CBA_A3/issues/661 I'll be working on a fix after dinner / tomorrow. No further help needed as of now. Thanks for the report, will be fixed. No workaround, just be patient.

Can you upload the full log? Ref: https://github.com/acemod/ACE3/issues/5126

Ah, right.

@Larrow's example is bad, because it errors out in line 8 (used undefined variable used in scheduled environment). The example would work without error if line 1 and the last line were removed. >I always assumed that private or params secures the variable in parents and child scopes, but not that call is also included. That is exactly what a child scope is. Everything that could be encapsulated in curly brackets is a scope.

Might also add that magic variables like "_x" and "_this" are always set to private to their respective scopes: private _x = 10; {} forEach [1,2,3]; _x // 10 The iterator (I think that's the technical name for the variable) in a for-loop is also treated like a magic variable: private _i = 20; for "_i" from 1 to 3 do {}; _i // 20 One mildly interesting detail here is the difference between the unary and the binary syntax of "call". unary call: _this = 30; call {_this = 1}; _this // 1 binary call: _this = 30; _this call {_this = 1}; _this // 30 This proofs that the unary syntax of "call" does not have the magic variable "_this" and only inherits it from the parent scope, while the binary syntax creates a "_this" variable "private" to the call-scope with the value of whatever was passed as argument.

Yeah, you generally should define functions during preInit (before objects are initialized and their eventhandlers executed) and not postInit, to avoid race conditions. I also don't recommend using execVM in an init eventhandler, because that means that you read from disc, preprocess and compile the init script for ever objects instead of once and keeping it in memory.

Thermal simulation only has these three properties and TI textures only three channels, so this is not going to happen without some deeper changes, R3vo. If you fire the commanders machine gun on a tank for example, the main gun will heat up and it has been like this since this was implemented. You'd have to overhaul every model and probably add a system that uses selections like the damage material system.

>is this supposed to happen? No, but that is how the new 3den editor works and there is nothing we can do about. >must i make sure ace isn't running when saving and editing a mission or is there a way to prevent this? Yes, or edit the mission.sqm by hand, which is tedious.

Wasn't targeted at anyone specifically. And I don't mind them here either tbh. But don't expect an answer or be mad if you're ignored. A forum is just a really bad place to keep track of these things. Same for the Steam Workshop. And while this is the official BI forum, it still isn't monitored by any of the devs on a regular basis.

Reminder that issues go on the Github tracker and are ignored in "random" forum threads.

It's not really possible to have different sounds for the weapons inside and outside of a vehicle in Arma. Yes, they are muffled inside, but the samples are the same.

There are no dependencies created from settings.

There were a lot of other script errors in that code. I don't think a forum is the right place for debugging scripts.

I fixed a crash when using BWA3 with the x64 EXE in 1.4.1, but the update was over a month ago. See the first post on page 33.

The type filter of nearestObjects and probably similar commands is broken for simple objects. _type = "Building"; _pos = [1000, 1000, 0]; _obj = createSimpleObject [_type, AGLToASL _pos]; systemChat str nearestObjects [_pos, [_type], 1]; // [] systemChat str nearestObjects [_pos, [], 1]; // [7: empty.p3d] systemChat str(nearestObjects [_pos, [], 1] select {typeOf _x == _type}); // [7: empty.p3d] Still reports the simple objects if the type filter is empty. The work-around is using select with typeOf, which for whatever reason still works.

No. The user is supposed to change the settings. I don't want mission and servers to change the users settings without consent.

Yes and if you're doing it regardless then don't complain if it breaks in future when internals change.

It's CBA_fnc_addEventHandler and not CBA_fnc_EventHandler.

Now add a fileExists command. Thanks.