target_practice

I do know that, but I thought there were no physics in DayZ at all.

That's a problem with the physical contraints of a given model, not physical simulation in general.

Well I haven't played DayZ myself, but I notice in videos that I've seen of it that it lacks ragdoll physics. Is there a particular reason for this?

Well I suppose that would explain why DayZ apparently has no physics right now.

That's not something that's going to happen.

I know that you can make a cfgPatches mod that alters the graphics settings to allow for values above vanilla limits, including light count. Apparently the hard-coded limit is 32 though, so it doesn't provide much more room.

Yes, markers do have a height value. It is however invisible in the editor so I am unsure how your friend managed to set it. From the BIKI page on createMarker: You can back up your mission and try this (untested) solution: Load up your mission in the 3DEN editor, select all the markers with the problem, and run this code from the debug console: { _pos = (_x get3DENAttribute "position") # 0; _x set3DENAttribute ["position",[_pos # 0,_pos # 1,(_pos # 2)-10]]; } forEach (get3DENSelected "marker");

I have absolutely no idea.

I'm willing to believe that BIS won't do this. DCS/Train Simulator DLC model is one that is only really practical for simulators with a dedicated niche community. Arma does of course have this, but these days the majority of the franchise's revenue comes from more casual players. Most of the Arma community is now comprised of these people, for better or worse (largely the latter, honestly) and I serioulsy doubt they'll be receptive to that kind of scheme. Bohemia runs the risk of sinking the franchise with such a method by driving away the mainstream audience; given that they seem to be moving in the direction of more mainstream appeal, I doubt they'll approach it in such a way if these are the circumstances. Either way, if BIS actually goes through with such a thing, I know for certain I'll be ending my (admittedly brief) time with the series. What I think is a far more likely concern is something I alluded to in my previous post; the design of Arma shifting away from being semi-milsim with extensive modding support, to being a military-themed Garry's mod. In other words, instead of trying to make a complete game in of itself, they'll take a page out of Bethesda's book and create something that is good enough, exploiting the pre-established modding community to do the remainder of the work for them. Furthermore, due to the success and recognition that mods for their games brought them before, they'll be less interested in creating a game, but rather a modding sandbox out of which they hope will emerge another industry trendsetter. Owing to how much they harp on about their "close relationship with our community" in their recent self-panegyrizing video, I feel this is a far more likely course for them to take. Make no mistake, I certainly hope I'm wrong about all this, and that those who work on the game, as well as the company at large, are invested in Arma for what it is. The company has undergone an undeniable change in priorities however, and so it is equally likely even those within Bohemia that would rather avoid such a route will be unable to do anything about it, and the franchise as we know it will end with Arma 3.

This game does not have a 'character creation screen', so it is unclear what you are referring to.

That's a built-in part of the game, not a custom feature.

It means you need a CPU with a high frequency and a storage device with a fast transfer rate (i.e. an SSD). I have both, and I often manage 60 FPS (even in multiplayer) and rarely fall below 40. Arma 3 itself is about as optimised as its going to get, so any improvements in performance will depend upon hardware configuration and game settings.

You actually raise a conerning point here, and one that has worrying implications for the Arma series; since DayZ, BIS seems to have been undergoing a gradual transformation from a relatively small studio genuinely invested in what they were creating, to yet another profit-driven AAA developer. BIS themselves have stated that their employee numbers have roughly quadrupled since the release of Arma 3, but honestly they had no real reason to grow this quickly. Plenty of successfull studios have no more than a few hundred employees, yet BIS seems to have opted for a strategy of expanding as quickly as possible. As you say, their emphasis on game design has shifted from original ideas to developing knock-off titles and shovelware mobile games. At this point, Arma is pretty much the only half-decent thing BIS makes, but given the changing mentality of the company, I'm worried Arma 4 will be developed less as a successor and evolution to the franchise, and more as an attempt to create a launchpad for the next big gaming fad.

For this code, I imagine it fails to work as the animateSource commands are run before the remoteExec'd command is processed by the server. Try adding something like this after the first remoteExec: waitUntil {simulationEnabled _curTarget};

Arma 3, like all of the Arma games, is CPU bottlenecked. Improvements in the video rendering capability of your system will result in negligible performance gains in A3 compared to a faster processor.

Well, that should work, so I'm not sure why it didn't. Another potential method is to use remoteExec to run the command on every client.

As I understand, disabling the simulation of an object also disables some network synchronisation of its states. In this particular case, it means that the animation state of the cabinet is changed on the machine it is local to (the server), but that change is not broadcast to remote clients.

It could just be me, but some of the engine sounds of some vehicles seem muffled since update 1.98. The sounds heard while driving a vehicle from the first person camera seem much clearer however. Since there is nothing in the changelog concerning vehicle audio, I assume this is some kind of bug.

BIS have stated that the intend to use Enfusion for future projects, including Arma. The unprecedented lifetime of Arma 3 compared to previous installments would certainly indicate that they intended to wait until they had a viable new engine, as opposed to further use of Real Virtuality. The current state of Arma 4's development is unknown, but it's unlikely to be anywhere beyond pre-production.

Use diag_log in your scripts.

From the BIKI page on setVehicleInit: https://community.bistudio.com/wiki/setVehicleInit

It is my understanding that it is possible to set up file patching such that the game can read unpacked data from the P: drive in accordance with a corresponding addon and $PBOPREFIX$ within the game directory. All official documentation on this matter is however quite unclear, and seemingly out of date in some regards. Furthermore, searching for information from other sources hasn't turned up anything either. So what gives? Am I misunderstanding this thing, or does no one actually seem to know for some reason.

You could try some of the official modes like endgame?

You could try including the first call in the formatted string to clean it up a bit, but otherwise, due to how compile works, I don't think there's any way around it; compile returns a code object, wrapped in parentheses, so you need to run that code first to return the value of the variable. Also, isNil takes a string as an argument, not a variable.

It simply says 'Operation Failed', with no further details. The only other thing of note is that an inactive instance of the program remains open.