feersum.endjinn

I think there's some echo "baked" into sound samples themselves but not much. But if there's EAX echo, I agree on point that it should be a lot louder in guns.

repost since other thread got locked: Since ArmA supports some of new fancier features of OpenAL like lowpass occlusion filters, why isn't reverb used? As it is, ArmA gun sounds sound bit "dry", and it would add to immersion a lot especially if it would be location dependent like having more reverb in cities and forests and less in desert. Or if there is supposed to be EAX reverb effects, they aren't working or very noticeable either on my motherboard integrated Realtek or Creative X-Fi.

Since ArmA supports some of new fancier features of OpenAL like lowpass occlusion filters, why isn't reverb used? As it is, ArmA gun sounds sound bit "dry", and it would add to immersion a lot especially if it would be location dependent like having more reverb in cities and forests and less in desert. Or if there is supposed to be EAX reverb effects, they aren't working or very noticeable either on my motherboard integrated Realtek or Creative X-Fi.

These might help. http://community.bistudio.com/wiki/unitReady http://community.bistudio.com/wiki/currentCommand

It's one of those small but annoying things but on bright side at least quick command menu is actually quite useful when you get used to it (which takes a while though).

ArmA cannot read old binarized files from OFP (OFP:Elite ones work though) but if you can get hold of MLOD (from original author or use ODOL Explorer) they'll work just fine.

LUA is pretty sweet if you ask me and it has proven track record with installed base of ~7 million World of Warcraft clients alone.

OpenAL installer just replaces old drivers, no need to delete anything.

Yeah I remember that one from when I was doing Shorinji-ryu karate as a kid. It's one of the earliest katas you do.

ArmA seems to be quite picky about cfgPatches being set up properly, it won't load addon at all if it's not at least somewhat sane.

You don't need /* extern */ necessarily though, it's just comment that my ArmAUnbin added to mark external references more clearly and it just was forgotten in final release. ArmA doesn't use it in any way.

you just need to define parent class like <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class SoldierWB; and that's it.

You still need to get them executed at server, especially triggers though now with publicVariable accepting strings many things are a lot easier (you can for example transmit code as a string for server to execute through compile/spawn commands).

Nah, every 20 seconds is bit excessive. Do it only when player joins via onPlayerConnected, it should work just fine (I'd test it myself but it's bit hard with only one PC capable of running ArmA at all )

No easy way there that I know, it's still dependant on init handler and createVehicle magic. With vectorDir/vectorUp and getVectorDir/getVectorUp scripting commands aligning multiple objects should be a bit easier though.

Is there still maximum size limit for objects, I remember you couldn't have objects bigger than 128x128x128 meters in OFP. For example Kegetys' Kutnetsov carrier (never released) was built from 3 separate objects because of that limitation.

What I am talking about above is directory structure (and PBO prefix system). What classes are called is irrelevant regarding CVS/SVN as it happens completely inside config.cpp. But yes, classes should probably be tagged with CWR_ . If you are talking about PBO names - what actual PBO names are doesn't really matter either as they are not related to in game paths anymore either due to PBO prefix system, all paths used in .cpp's are "virtual paths".

You should not use larger than 2048x2048, bigger textures may be supported by hardware but they aren't really needed and performance won't be good. Single 4096x4096 texture will require 64 to 128 megabytes of memory (including mipmaps), depending on compression used so on average 256MB card you would be able to use only couple of these textures (frame buffers eat some memory as well) and situation isn't much better on 512MB cards.

Your only choice is writing your own using MaxScript (in 3dsmax) or whatever equivalent is used in Maya. File format is documented in: http://community.bistudio.com/wiki/P3D_File_Format_-_MLOD

To get things going forward, I propose following directory structure. It allows us to split things into smaller PBOs in development phase but with option combine everything into single huge .pbo or ~9-14 separate pbo's in release. I'm not sure if Oxygen 2.0 still has 31 character limit for texture names but even then path like "\cwr\units\tracked\common\" leaves 5 characters for texture name, which should be enough for somewhat descriptive name.

Isn't this in as server option already? If you look at main config.cpp there are some options related to this under cfgDifficulty block.

Minimal sound mod to replace lets say helicopter sounds would be: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgPatches { class FDF_soundmod { units[] = {}; weapons[] = {}; requiredVersion = 0.1; requiredAddons[] = {"CAWeapons", "CAAir"}; }; }; class CfgVehicles { class Helicopter; class Mi17_MG : Helicopter { soundEngine[] = {"\fdf_soundmod\vehicles\mi17_engine", db30, 1}; }; class UH60MG : Helicopter { soundEngine[] = {"\fdf_soundmod\vehicles\uh60", db30, 1}; }; class AH1W : Helicopter { soundEngine[] = {"\fdf_soundmod\vehicles\apache_engine", db30, 1}; }; class AH6 : Helicopter { soundEngine[] = {"\fdf_soundmod\vehicles\cobra_engine", db30, 1}; }; }; Pack that with whatever prefix you want to use and put it into yourmod/addons folder and fire up arma with -mod=yourmod parameter as usual. It'll whine about modified config in multiplayer but that's business as usual. You don't need to repack any existing PBO when mod folder thing works just fine. Only reason it is being done for things like editor addon because for whatever the reason, BI made civilian units with access=ReadOnly and they cannot be made available in mission editor with just regular mod config override. (and no, FDFmod is not going to release a sound mod, that is just my personal test stuff)

Ideally object should only use one big texture for external textures (+ normal + specular maps), state changes are pretty expensive operations. In worst case switching texture alone might take as much time as rendering object with 5k faces.

Limit is set by hardware, not ArmA so those values will be different for each graphics adapter.

Sharp edges cause vertexes to be duplicated because in Direct3D internally lighting normals are per vertex and not per face and rendering sharp edge requires two vertex normals that point at differing directions.