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

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>

Finnish Rapid Deployment Forces soldier and BMP-2 from Armored Brigade take part in joint exercise in a forested area. Soldier is equipped with new M05 camouflage suit, M05 ballistic vest and M05 equipment vest and is carrying modernized version of Russian-manufactured PK machine gun. Stay tuned for more news when modding tools are released, same FDF time, same FDF channel. Screenshot 1 Screenshot 2 FDF Mod web site FDF Mod forums Discuss.

- 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.

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.

First, I have to say big thanks to Rom for all his work with paa/pac file format, this brief description is based on his early work... PAA/PAC file format description: First 2 bytes are texture format, possible values so far seen are: 01 FF - RGBA5551, DXT1 compressed texture 80 80 - IA88, Black&White texture with 8-bit alpha 44 44 - RGBA4444, RGB with alpha, 4 bits per component. If you hex edit flashpoint EXE file, you can find strings hinting at some extra texture format besides these. If anyone has seen other texture types than ones listed above, please let us know! Then comes header data. Header data is composed of 8 byte header tag, 4 byte header length and then header data itself. Note that header names are stored in file backwards, so that OFFSTAGG is stored as "GGATSFFO". Possible header values seen so far are: AVGCTAGG Average color of texture in RGBA8888 format (one DWORD). (?)used with with IA88 type textures(?) OFFSTAGG Offsets to mipmaps in file, one DWORD each. Note that while 16 offsets are always stored, actual number of mipmaps might be smaller. In this case, offset is marked as 0x00000000. FLAGTAGG Marks if texture contains transparency. Value 1 means basic transparency, 2 means alpha channel is not interpolated. After last header, two zero bytes are stored. Next follows mipmap data. For each mipmap, following header data is stored, followed by mipmap data. Mipmap width - 2 bytes Mipmap height - 2 bytes Mipmap length - 3 bytes, length of compressed mipmap data Next comes actual mipmap data: - Texturetypes IA88 and RBGA4444 are compressed using same kind of compression as used in PBO files (LZ with 4k sliding window), followed by 4-byte checksum. I'll probably make compression/decompression source code available as soon as I've cleaned up code and tested them properly. - DXTC1 textures are stored "as is", width*height/2 bytes. Finally, last mipmap is followed by 5 zero bytes. And now, OFP scene needs YOU! Since NVidia DXT converter and Photoshop plugin source code is available on Nvidia developer site for free, anyone can write their own PAC tools and Photoshop plugins... Any volunteers? Â

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.

You can edit FDF mod stuff however you want as long as you don't redistribute whatever changes you made. This is mainly because people would do all kinds of tweaks and then crash dedicated servers when they joined with their homemade mods (especially animation packs were notorious in this regard). And then everyone would email and bitch about it to FDF mod team. So it's just easier for us to forbid all redistribution without explicit permission. If you want to use parts of FDF mod in your own works, just ask and we'll talk. There's lots of cooperation between different addon makers and mod teams as FDF Mod credits can tell.

Patch comes with 1.05 dedicated server, check out arma_server.exe in your ArmA directory.

Looks good! What aircraft have now HUD, is it Harrier exclusive or did AH-1 and Sukhoi get them too?

1.04 fixes A LOT of issues I had with with original 1.0 releases, multiplayer is actually playable now and performance is so much better. This English EU release is what ArmA should've been from the start, but better late than never I guess...

Does it mean it will be present in FDF 2.0? Seeing the number of things uncovered by pple like you and Keg, I expect a second revolution from FDF 2.0, tbh Question is : will there be a FDF 2.0? No, that was just thinking what might be possible in theory (there isn't any way to compile pixel shaders to BIS format yet, even though they look like kinda standard DX shaders with some ArmA specific headers), even though material definitions can be edited as they're standard raP files. There probably will be FDF 2.0 but what features it will have, nobody knows.

It would destroy performance with current hardware. Ask again in couple of years Some features like night vision might be replicated with providing custom pixel shader in NVG goggles optic texture material.

Securom doesn't really care about Daemontools or other virtual CD drives until it detects game is actually running from image. I have running it all the time and of all software I have, only some certain patch of Raven Shield wouldn't run at all with Daemontools present in system (and it got fixed in next patch).

Well, it could be said you haven't really truly posted in Offtopic section unless you have gotten at least one PR...