feersum.endjinn

Couple of years ago I did some cleaning and found few old hard drives, took backup of their contents before wiping and throwing them into recycling and proceeded to forget about it all. Well, few days ago I started digging through the backups just for sake of curiosity and amongs random crap I found DXDLL source code. With Kegetys' permission, I now cleaned up it a bit and posted it on GitHub under GPL2 license. I don't really know if this was the final version or not or whether it even compiles (or even Visual Studio version you're supposed to use), but it for me it was fun nostalgia trip reading through it up and maybe someone else finds it interesting too. Source code and small writeup from what I remember about it's functionality is now at GitHub: https://github.com/jarkkom/dxdll

- Use version control software (only real non-commercial choice that works well with binary data is SubVersion but it's reaööy gppd). Though I'm still trying to get both my employer and mod team to us it

It doesn't really count, as it is only rendered when weapon is firing. I guess ArmA could in theory have two different index buffers for when weapon is firing and when it's not, but I doubt memory:gpu cycle tradeoff would be worth it

Binarize will triangulate your models anyway and if ArmA works like OFP did, any MLOD model will just get "binarized" on the fly when loaded in game. And on the hardware level it will be split into triangles anyway.

Less sections is always faster. You should merge your small textures into one bigger texture, and smallest LOD should never have more than 1 section (with some special textures like muzzle flashes being exception, as most of time they are not rendered). Technical reason for this is that one section can be rendered using single Direct3D call so there are less usermode<->driver context switches and more work can be offloaded to hardware instead of doing it on CPU. See this graph (batch is same thing as section in this case) for performance comparisons. What this chart means is that if your LOD consists of 1500 faces that are in single section, it would render about 5x faster than having 5 sections that are 300 faces each. And these numbers are for old hardware like Radeon 9800, for newer GPUs differences are even greater.

Norsu told me to post here as apparently some other people have also had problem with their models ending up with waaaay too many sections despite faces sharing same material and texture. This apparently happens often when parts from old OFP MLODs are copied into new O2. And as everyone hopefully already knows, too many sections = baaad for performance. This is our starting situation. Note number of sections in status bar on top of O2. This is waaaay too much for such middle LOD and as such, ingame performance more than halves when there are full squads worth of soldiers with RK95 onscreen compared to if they were equipped with BIS' M4's. http://www.somuchforsubtlety.net/arma/sectionfixing1.jpg Now, to fix that we first select all faces that are supposed to be in same section and hit "E" key to get to face properties dialog. Note that "User value" field is empty instead of having number there, it means faces in selection have different values in there, which causes them to be split into separate sections. We type there "0" and hit Apply. We do same thing for textures and material fields in they contain "..." and make sure that Lighting & Z-bias also have identical values. http://www.somuchforsubtlety.net/arma/sectionfixing3.jpg Now we can see that amount of sections has dropped to 3, but model still contains 1 section for muzzle flash and 2 sections for weapon. It is a lot better, but we want to still get it down to just 2, muzzle flash and weapon. Next step is going to "Face" menu and selecting "Sort" http://www.somuchforsubtlety.net/arma/sectionfixing4.jpg Often after this operation number of sections displayed doesn't want to update right away, so we go into another LOD and then come back to editing same LOD. After this small detour however finally our model is where we want it to be - one section for muzzle flash and one for whole weapon LOD and now ArmA engine can render whole weapon using single Direct3D call which makes modern GPUs very happy. http://www.somuchforsubtlety.net/arma/sectionfixing5.jpg <span style='color:red'>4 hotlinked pictures over 100kb removed.</span>

It doesn't seem to be hardware issue because we've had people with wildly different hardware all having the same issues. Common theme is that longer you stay in server and more people join and leave server, more likely it is that your VOIP will break down. Long running missions where people come and go constantly like Evolution are best way to reproduce the bug. In many ways it resembles old "missing weapon sounds" bug that was in ArmA's release version.

In 2nd prison camp liberation mission, saving game after you've liberated prisoners and loaded them into truck, exiting ArmA and then reloading later gives you some error about 'missing class/' and mission fails immediately as if all prisoners were dead.

Earlier versions of ArmA can't load OFP style .wrp's. With new code added into 1.07 people found out you can just feed old OFP format .wrp's to ArmA and they work just fine if you hex edit textures to point into .rvmat material description files that contain reference to original texture.

I'm not sure if this is specific to latest build, I didn't have chance to test previous 1.7beta. When going inside buildings, I get small "rays" that radiate from center of the screen towards edges. This is using GeForce 7900GS in Windows XP with latest official driver version 93.71. I tested this using Evolution 1.05a multiplayer map, any of huts near spawn point at South Sahrani airport have same exact bug. Inside a building in 1.05: http://img126.imagevenue.com/img.php....7lo.jpg Inside a building in 1.07 build 5157 at same spot: http://img183.imagevenue.com/img.php....2lo.jpg It looks bit like typical glitch that results from overheating, but I tried to eliminate that factor by actually underclocking both GPU and VRAM and testing both 1.05 and 1.07 back to back. When hraphics card is running at same temperature and same Mhz this only happens in 1.07 but not in 1.05.

PaaTool doesn't support new texture formats you can use in ArmA like DXT3/4/5 so I would recommend using PaaPlugin instead.

Show us your proof. Or is it just a matter of believe? Applications link to specific release dll, like in ArmA's case d3d9_29.dll (or whatever it was), which is October 2006 release of DirectX. Newer versions have different DLL's, latest one being _32 I think.

Start regedit, find key "HKEY_CLASSES_ROOT\Folder\shell\Create PBO", right click on it, select delete.

I can write installer program for toolset using "Nullsoft installer", if it is ok with BIS (it's open source "zlib" license so that shouldn't be an issue). Only hard part is finding out what files are actually required for functional installation and what is leftovers from development and maybe reorganizing some like Maya plugin to more descriptive folder names. Generating .bat file with proper subst commands according to what directory user selected at installation is fairly easy too. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"># CWR test script Name "Oxygen 2.0" OutFile "Oxygen2Setup.exe" InstallDir "C:\BIS\" #InstallDir "C:\$PROGRAMFILES\Bohemia Interactive\Mod tools" Page Directory Page InstFiles Section SetOutPath $INSTDIR File /r BinMake File /r TexConvert File /r Oxygen # texViewNEW.inf WriteRegStr HKLM "Software\BIStudio\TextureConvert" "configPath" "$INSTDIR\TexConvert\TexConvert.cfg" # binMakeNEW.inf WriteRegStr HKLM "Software\BIStudio\BinMake" "path" "$INSTDIR\BinMake\" WriteRegStr HKLM "Software\BIStudio\BinMake" "exe" "$INSTDIR\BinMake\BinMake.exe" WriteRegStr HKLM "Software\BIStudio\BinMake" "binarize" "$INSTDIR\BinMake\binMakeRules.txt" ClearErrors FileOpen $0 $INSTDIR\mapDrives.bat w IfErrors doneMapDrives FileWrite $0 "subst p: $INSTDIR\Project$\r$\n" FileWrite $0 "subst u: $INSTDIR\u$\r$\n" FileWrite $0 "subst b: $INSTDIR\b$\r$\n" FileClose $0 doneMapDrives: SectionEnd

This feature is in Armed Assault as well, that's what FSM files are for. Only thing that ArmA doesn't come with is GUI editor for them but there is community made one out already.