vektorboson

As far as I remember it's either in the class Man or class Soldier; look for the formationX- and formationY-properties.

So I renamed all the Resolution LOD surface files used for decks to "plechprolisXXX" etc ...... but it didnt work Walking, initially you get a ground crunching sound then that disappears and u get silence. If you drive around you get lots of dust Would I need some sort of CfgSurface definition in my config file as well !? I quite don't understand what you mean? In the data.pbo there is a texture called something like plechprolis  (I don't know how exact). You take that texture and you texturize with this texture your Faces in the Roadway LOD. There is no need for an extra config entry.

CfgMaterials gives the surface a metalic reflection ("specular lighting"), whereas CfgSurfaces gives a specific texture a sound. Look in the commented config, which texture makes what sound, and then just give your roadway that texture. What's your problem with binarize? I think it's very easy to setup and to let it work.

That's an example material setting I am using for a URAL truck: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgTextureToMaterial {  class SCF_SR_Metal  {   textures[]=   {    "scfsr\ur\blat.pac","scfsr\ur\blatnew.pac",    "scfsr\ur\front.pac","scfsr\ur\green.pac",    "scfsr\ur\haube.pac","scfsr\ur\kab_b.pac",    "scfsr\ur\kab_s.pac","scfsr\ur\kab_t.pac",    "scfsr\ur\kab_ws.pac","scfsr\ur\opak.pac",    "scfsr\ur\zadek.pac"   };   material=#SCF_SR_Metal;  }; };//class CfgTextureToMaterial class CfgMaterials {  class SCF_SR_Metal  {   ambient[] = {1,1,1,1};   diffuse[] = {1,1,1,1};   forcedDiffuse[] = {0,0,0,0};   specular[] = {0.6,0.6,1,1};   specularPower = 3;   emmisive[] = {0,0,0,0};  }; };//class CfgMaterials You can see here, how textures are referenced. And of course don't forget to binarize your model, otherwise materials won't work. (it's a good idea to binarize anyway!

@Gnat What you are looking for is CfgMaterials and CfgTextureToMaterial. CfgSurfaces is only to define the roughness and dust coming from diverse terrain textures (and the sound for foot soldiers). CfgMaterials defines the shininess of a specific material and CfgTextureToMaterial defines which Texture belongs to which material.

Try it with your Mod's UKF_WMIK.pbo. First take a look with WinPBO at the PBO, it shows nicely how much percent of the original file size every file is. 1. You will notice that almost every second texture in the PBO is bigger than the original file. Now, that's some nice "compression". 2. Compress the compressed UKF_WMIK.pbo, then compress the uncompressed UKF_WMIK.pbo. Results for me (WinRAR, best compression): Compressed PBO: 17.3 MB Uncompressed PBO: 15.5 MB And as Q said already: You can upload the RAR/Zip to your server and extract it on the server. Other thing: Why are you so obsessed with hard drive space? I think memory is much more important (last time I checked, memory was more expensive than hard disk space). You have to remember, when it comes to memory usage, the size of the uncompressed PBO is, what will be in your memory when your addon is used (of course that's not 100% correct, that's only if all models from the PBO are used). So the only true way to reduce file size, memory footprint and increase performance is: Reduce texture size, reduce poly/vertex count, reduce sound size. But it seems that this is not accepted by the community, due to combat photography thread or graphic "whores". Â

That's not correct. 1. You should RAR-compress a compressed PBO and you should RAR-compress an uncompressed PBO. Most of the time, the uncompressed PBOs will come out much better. It's a fact that already compressed data is harder to compress. Just try to ZIP and then RAR and then ZIP and then RAR a file. And look at the resulting file size. 2. Most of the textures are already using compression internally (some the same as PBOs). In some cases the resulting compressed size is bigger than the original file itself. (open some compressed PBOs with WinPBO, you'll find sometimes textures that are 117% (worst case is 125%) of the original size! The physical file size is smaller, yes. But the logical file size is more than twice as big, as you have to reserve memory to decompress the file. That's not theoretically because they have to be decompressed. But once they are decompressed they stay decompressed in memory, so it does not really effect performance at all. All it affects is loading time. (and when loading a model+textures at mission time it does effect performance) That's the only Pro-argument I can think of: Smaller file size on the hard drive. And it seems with todays hard drive capacities and DVD-burners hard drive shouldn't be a problem at all.

I have made some tools a while ago, I never announced here, which were recently improved with very simple version control. I use a special tool I called "Recon", that does the following tasks: Checks the config, binarizes the addon, binarizes the config, PBOs that thing up and copies it to my special addons-directory. In that whole process it creates a file which is named "build.num", it contains the build number (how many times recon was called successfully on this addon) and the according date. You may take a look at Recon (and some config-tools) here: CfgCheck.zip 560 KB I think that would be the quite correct way: Include the version information into the PBO (I think BIS does something like that with their vssver.scc). You could also include the dependencies into PBO; best thing would be, that a tool like Recon created the addon dependencies automatically.

You need Sniping Jacks Textures: Dowload on this page Click on Download Textur-Set - 27 MB

Well, you all guys think in terms of "Island"; let's take FDF East Border "Island" for example: It is meant as a "continental" map, thus not representing an island. I hope you understand what I mean by the concept of "continental" map (that's something like the invisible walls in other games, but in OFP it's just water). In continental maps it makes pretty much sense to have railways, as the map represents a part of a much larger country. And anyway, you have to think of the OFP islands as downscaled "real" islands, just to fit into your computers memory and CPU.

. Using JAM was a bad analogy, I guess. No it wasn't a bad analogy, you misunderstood my sentence here From reading the Description at the ACES page, it deals mostly with weapons standardization.....And what your group is doing for such standardization, I'm asking be done, either individually by the add-on makers who've already done the work, or by the makers getting together, even if only temporarily, in some sort of Unified Aircraft Functions Project; or Combined Aircraft Functions Group. ... The ACES project will indeed sport aircraft functions and scripts, as you stated, but I don't think that most (not all) of your suggestions should be implemented in ACES, but in the addon itself. Well that was one of the intentions when ACES was founded; I don't know the goal right now as I am not an active member. Of course the best'd be if BIS included such functions in ArmA directly (in good old compiled C++). Look, I realize all of this, my posting here, may be tedious to some, and I was content to just let this thread die, but I believe sincerely in how beneficial to other add-on makers, would-be and established, this will be. Of course, some ideas/stuff can be standardized by ACES, some not (but they can be of course parametrized). But as much as I am a "feature-whore", I am also for performance and I am against action menu clutter (therefore I made my afterburner-script in the first place). But there are solutions for many possible actions without to clutter the action menu. And of course, you should ask yourself about some features: Are they really necessary? Are they worth the performance drop? Do they improve gameplay? Do they annoy the player?

You still can animate the texture on the wheel instead the wheel itself, and thus free up the animation for the turning front gear. @Crassus Most of the stuff you demand has to be implemented per addon, as opposed to your JAM-like pack, which btw already exists: It's called ACES Â

OK, I've read the scan, and yes, they have to stream the "6GB texture" (how should it fit into 8MB video memory otherwise?) so it is indeed somehow comparable to terrain streaming. But I don't know what's so different to normal tiles? In this case you have unique tiles as opposed to repeating tiles (you still have to do tiling on the terrain). So, if ArmA does not have the 512 Texture limit, then ArmA already has that MegaTexture-technology, as you already can define physical properties of a texture (as Metal, Sand, Rock, Water, Snow, a.s.o.), and the audio part, too (though vehicle sounds are not affected by the surface). Of course I don't want to sound like someone who codes the MegaTexture on a weekend  I surely am not able to do this (yet...) Â

Hahaha; that "MegaTexture" sounds like plain old CfgSurfaces to me. In CfgSurfaces you can set different sound environment and friction for different textures (with wildcards; ie runways: rw*) OFP had this technology since the beginning. The only thing that sounds different is the texture being unique until the horizon (the horizon is at 100m?). Sounds like a procedural texture to me, which isn't all that new, since games like Black&White already utilized procedural terrain textures. This has nothing to do with terrain streaming; Streaming means that all data is already statically on the hard drive (or elsewhere), and is loaded into memory continuosly and only when needed (like a movie, 6 GB doesn't fit into memory).

Just wanted to state that this is a very nice addon

As I see it, ArmA _could_ be a major war in the 1980s; so we could expect that military equips its soldiers with most recent technology or introduces new technology faster. That's the thing about a fictional conflict: It is fictional and therefore you have to account for fictional decisions regarding equipment. In case of current day: another argument for mixed old/new equipment: You just don't throw away old equipment (or in the hand grenade case, you indeed throw them away...)

I hope that this was the problem also for T80s driving over Mines; place a Mine next to a T80 and the Mine does not trigger; they drive over them as if they did not exist. Anyway, nice Addon. I guess that the T80B is the T80 model, that was used in the 1985 timeline?

Hahaha! Sorry, but in OFP neither I need a CD in my drive, neither do I need a connection, neither do I need to unplug my network cable when I want to play it. This is customer friendly. And I hope that BIS won't punish its customers because others are pirating or cheating. Only the 1.96 patch enabled us to play without a CD in the drive. I suppose they did that on purpose as it's the last patch and it extends the life of the CD's. Yes, I know, but think about it: Isn't it nice? Isn't it nice, to play without all the f**king restrictions companies try to force on us? I rather give those companies my money who are all for fair use, not some obscure distribution- and "spyware"-system. But I stop here, since this will lead to discussions not allowed on this forum.

Hahaha! Sorry, but in OFP neither I need a CD in my drive, neither do I need a connection, neither do I need to unplug my network cable when I want to play it. This is customer friendly. And I hope that BIS won't punish its customers because others are pirating or cheating.

Now that would be original! Don't know if someone remembers Leisure Suit Larry (don't know which part it was), you had to do first a test to prove you're really an adult before you were allowed to play it.

There are several reasons, why one should use the function method instead of the SQS-method: - the function is in memory available as a variable - the function is guaranteed to be executed at once (and is faster because of a stricter syntax) Instead the SQS has to be reread each time, the FIRED-handler is called, and it's possibly more complex to parse and execute (and in some cases the script is not executed at once but it sleeps until the next frame and therefore eating unnecessary CPU-time and memory). Imagine you have a Machine Gun with an extreme high rate of fire. Now every time you fire that MG, your Fired-Handler-script is first read and then executed. With many scripts running this will produce lag.

Huh, are you guys sarcastic or ironic, or am I too tired, to understand this... I think that this request should be very easy... Though hardrock knows, that I've got already a project to work on Â

This sounds like a very nice idea

There're only 10 types of people in this world - those who understand binary and those who not. Â 01001000 01100101 01111001 00101100 00100000 01110100 01101000 01100001 01110100 00100111 01110011 00100000 01101111 01101110 01101100 01111001 00100000 00110010 00101100 00100000 01100100 01110101 01101101 01100010 01100001 01110011 01110011 00100000 00111010 01000100 Sorry, I had to do that!

And if you want the material to shine white instead of yellow, then use this: specular[] = { 0.5, 0.5, 1.0, 0.0 }; I like white specular reflection more than that yellowish BIS thing.