feersum.endjinn

With normal mapping 5k should be upper limit for most models unless you're modeling extremely large object (like ship). But as usual more important than poly counts is having proper LODs.

You can use "killed" event handler to do it. http://community.bistudio.com/wiki/addEventHandler

Armed Assault adds two new scripting commands, "date" and "setDate". Combined with publicVariable it could be possible to have a script that synchronizes time between clients every minute or so. As for basic OFP/Resistance, I don't think it is possible as there is no way to get or set current mission date explicitly.

Yes. I get these errors every now and then when connecting on public ArmA servers, at this point it is just better to leave squad logo out.

You can patch the .pbo just fine, you just need to supply new signature file (I assume bisign files hold the authentication signature). I'm not sure if current pbo tools like cpbo handle SHA-1 authentication block at the end of the pbo properly yet but it shouldn't be too much of an issue. Whatever structure we go with only affects development process, final releases are better off made as full complete downloads since patching system just confuses users unless you have idiot proof installer but writing one is a lot of work (just witness trouble people are having installing 1.01 at times).

Hmm, completely I forgot about binarize requiring PAA header info for proper alpha channel blending, scratch that idea then. What we did with FDFmod was that during binarize process we copied config.cpp into p3d directory and removed it before packing model as pbo. Of course that approach has it problems as well, if for some reason script failed to remove config.cpp you sometimes ended up with multiple versions of same config in different pbos and it was bit random which one got loaded first...

For OFP/Resistance MLODs there was limitation of 32 characters for texture path which was one reason why OFP addon directory structures tended to be pretty shallow (and nondescriptive). Is this limitation still there in Oxygen 2.0? Alternatively, do P3D's, rvmat's and textures have to be in same PBO? Would it be possible to have structure where config, P3D and rvmat's were stored in single PBO and textures in another, as textures tend to be most space consuming part of addon (especially more so in ArmA). At least for sounds I don't see why they should be in same pbo as p3d's or configs...

Arma.rpt doesn't get emptied between crashes, single .rpt file might have data for ~100 crashes or so.

Next thing to do is to agree on repository structure, in my opinion it should be same as PBO file structure will be. As what the PBO structure will be, I'd propose structuring it in so that every vehicle type has their models and textures in one pbo (tracked, wheeled, characters, everon.pbo), sounds in another (sounds.pbo) and configurations in separate .pbo. That way each part of a team can do their changes in one specific directory and test their parts only by rebuilding single .pbo at time.

Yep, for me going from Nvidia 6800GS to 7900GS was like playing completely different game. 6800GS wouldn't simply be playable in anything higher than 800x600 and since I have TFT display, it would look just horrible due to display scaling it to its native resolution.

How much OFP:Elite has common with ArmA in P3D and WRP structures? Lot of graphical features of ArmA were already in Xbox (fairly impressive IMO considering hardware Xbox has) and models might be fairly easily portable since they probably have proper shadow LODs. My experience with internals of Xbox version is mostly limited to snooping around PBO structure, config.bins and seeing how normal map textures were implemented but what I saw was identical to how things are done in ArmA...

deleteVehicle was very very dangerous command at least in OFP multiplayer - if you used it on unit that was already deleted you got instant crash. Now since init line is run on all clients when they start the mission, think what happens when they lag slightly at mission loading and server has already deleted that object...

At the moment it seems not too many addon makers are going to go with JAM in ArmA since main problem why JAM was invented originally was to solve magazine incompatibility between weapons. Now with cfgMagazines, such problem doesn't exist anymore. Instead of making things more complicated than they should be, I'd rather see addon makers base damage values on existing ArmA ammo classes or use existing cfgAmmo and cfgMagazines classes when applicable (30Rnd_556x45_Stanag, 30Rnd_545x39_AK etc). When it comes to small arms, default values are just fine - it was tanks is where biggest balance problems between addons were and JAM never solved that problem (nor it really can).

As Wiki says: "Variables _id and _name are set.". If onPlayerConnected is set on init.sqs, it will be run on client as well and simple check like "if (name player == _name)" will let you identify if script is being run on connecting client. As almost all scripting functions that require object as a parameter have to be run on client where object is local, I don't think this is much of an issue.

It doesn't really change things that much and some things are a lot easier to do in ArmA than in OFP. For those special cases, onPlayerConnected does the job just fine.

It is more than a sound bug. When it happens, you can't see flash, recoil or smoke either, it is as if only bullet event is transmitted but not actual shooting event. And it happens to every player in that MP game, actual sound card hardware has nothing to do with it.

If your PC reboots/blue screens, it's always driver or operating system bug. Games can at worst cause crash to desktop, but reboot/bluescreen is either hardware problem (overheating) or driver bug.

I posted same link in your other thread as well but here we go http://community.bistudio.com/wiki/SQF

Yes. Though I would recommend doing everything with SQF scripting syntax as SQS scripts are being phased away. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">while (1 == 1) do { skipTime 0.5; sleep 5; } Read more at http://community.bistudio.com/wiki/SQF

Put it into separate file, for example "weatherthingy.sqf". Then put into init.sqs line <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">spawn compile preprocessFile "weatherthingy.sqf"; As for last line, you can add it into beginning of "weatherthingy.sqf" or directly into "init.sqs". It doesn't really matter where you put those scripts as long as they get executed at mission start.

I think performance hit is negligible, especially as SQF scripts are precompiled instead of parsing during runtime. You have to run setOvercast on server anyway as I think during rain you get more fog than on sunny weather and it may affect AI.

What you need to do is to have script that is launched on every PC at mission start. That script is fairly simple loop that check state of signal variable and if it has changed it acts according to contents of signal variable. Note that I'm writing this on work PC, so scripts may not work fully as I cannot test them . You get the general idea though. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> signalWeatherChange = -1; // you need to have gamelogic called "server" to make this work if (local server) { // store initial weather to serverWeather variable serverWeather = overcast; } // loop forever while mission runs while {1 == 1} do { // when signal variable is zero or greater, it means someone activated the action and publicVariable has been broadcast if (signalWeatherChange >= 0) { // fade new weather in 10 seconds 10 setOvercast signalWeatherChange; signalWeatherChange = -1; } // if script is running on server, store weather setup so we can broadcast it when new player joins if (local server) { serverWeather = signalWeatherChange; } // only check it every 10 second or so sleep 10; } and on your action you run following script <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> signalWeatherChange = 1.0; // or 0.0 if you want it to set sunny weather publicVariable "signalWeatherChange"; To make newly joined players get proper weather, also have following thing on run on server <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (local server) { // when new player joins, broadcast weather state again onPlayerConnected { signalWeatherChange = serverWeather; publicVariable "signalWeatherChange"; } }; Funny fact: OFP/ArmA multiplayer scripting is only time ever I've had to put stuff I learned in concurrent programming course at university into practice. edit: fixed syntax

Old scripts should work apart from few special cases, but whenever possible, you should write in your scripts are SQF instead of old SQS syntax.

My recommendation is http://gamesindustry.biz/

I'm not sure you can discuss US politics without bringing Iraq into it, just as US domestic politics affect everyone globally, situation in Iraq affects US domestic politics as last election proved.