Romolus

Yes those are the config lines I was refering to. Nope, not as far as I know. From what I can see, mission makers who are used to be able to do some AI scripting in their missions will have massive problems with those new FSMs in addons.

to access these settings and change them. but then again I'm pretty new to this and maybe what is set in the cfg cannot be changed this way at all? Have a look at the FSMs included in the character.pbo, then you'll see the differences. With those FSMs every type of unit can have its own specific behavior, so there isn't some kind of special civilian behavior that the engine would know as such. For the engine it's just a different FSM that it's running for those civilians. As far as I can see there's no way to get around this beside creating a civilian addon with the same FSM that soldier units use, or even a new FSM where this behavior can be switched or altered by mission scripts.

I don't think there's an easy fix for this problem since civilians have a completely different behavior set in their config than other units. Especially the formation behavior isn't affected by the side, but the FSM that it is set to in the config.

@djfrogstar: I think you missed my point. My point was that those who are serious enough to put down 500$ for zbrush, (which is a sculpting tool not a general modeling tool,) already know about it because they own one of the big 3D packages. At least I guess that if you're that serious about your hobby to be willing to spend 500$ on a sculpture tool, then you probably would have done some research in that area even if you're just starting out. For those who don't know it, I think it's only fair to tell them what the tools cost that you're waving in front of their faces unless you're suggesting that they should just go and grab it "somewhere" which I don't think you intended to. Also I'm sure that there are people who would like to be able to buy all those tools but just can't afford them or can't justify such expenses because they have kids, a wife and maybe a house to pay. That doesn't mean they are less serious about their hobby just because of that. Also when coming from OFP, people are used to be able to create quality addons with the free tools that were provided by BIS and some rather cheap or even free tools for textures. In a thread like this where people are obviously not that deep into the topic, I think it would be more adequate to try to come up with a possible solution that doesn't involve having to put down hundreds of $ for the latest tools. Especially people like you who have a much better knowledge about those things, could help there a great deal. And if there isn't any alternative then people should at least be told what those things cost in my opinion. I don't agree with your suggestion about Modo, but I'd rather turn this thread not into a discussion about 3D tools and instead stay on topic. Maybe we could even come up with a wider range of suggestions about how those new map types can be created. And when it comes to hobbies, I don't really think time equals money I don't want to get things done as fast as possible, I want to enjoy doing them. No one is paying me for the time I spend on a hobby and I don't intend to do more paid work, just because I can get my hobby done faster If I count together the time I've spend working with (and against) the OFP engine, in that time I could have coded my own small engine even as a one man team. But I enjoyed working on OFP, so that's what I did

@djfrogstar: Maybe you should also mention that it's a commercial tool for about 500$. I bet that most people who start out with OFP and ArmA modeling are happy that they can get O2 for free and don't have to shell out some major cash for a legal license of one of the main 3D tools. I also bet that those who really have a legal license for such a tool already know zbrush more than enough. The trick is to come up with a solution to create normal maps that doesn't cost more than ten times the price of the game. Everything else is more advertising piracy in my eyes.

@Messiah: What you're looking for is normal maps, specular maps, ambient occlusion, or ambient shadow map and detail maps. Those are common terms so you might find something for other game engines and if not, then have a look at general 3D CG. Once you have a clear picture of what those maps are used for and how they're usually created, it'll be easy to apply this to ArmA. @xnodunitx: It's hard to judge from pictures whether the ambient occlusion is baked into the color textures or whether it's a separate map that properly gets affected by lights. I had to check it out myself and found that both ways are used in the current ArmA models. So baked or separate map, it's all in there. @blackjack[VS]: What you're looking for in the wiki is basically just this page: http://community.bistudio.com/wiki/Armed_Assault:_Texture_Naming_Rules On that page there are the suffixes listed for all possible texture maps. Those suffixes are added to the texture file name, so once you know what you're looking for it's easy to spot the right file. Basically every addon pbo in ArmA has all those files. For the example of the team leader unit, open up the us_soldier_teamlead.p3d in a hex-editor or even a simple text editor and search for "rvmat" and you'll get the file names of the rvmats used on that model. (You can also search for .paa and you'll get the texture names) The rvmat I refered to was the ca\characters\data\us_teamlead_equip.rvmat. Have a look in the data subfolder of the characters pbo and you'll find that file. Rvmat files are raPified files which means you have to unRap them first like config.bin files for example. One tool for that is unRap which you can also find on the Community Tools page in the wiki. After unRaping the rvmat file you should be able to open it in a text editor. When you open the rvmat file, you'll see that this file basically contains what is sent to the shaders. Matching the suffixes from the Texture Naming Rules page in the wiki should get you the texture file that you're looking for and by looking at the model in game it should be visible how they're applied to the model with the help of the rvmat files. The way texturing and UV mapping is handled and whether there will be the possibility of several UV sets will have to be seen when the new O2 becomes available. Although the mentioning of an "uvSource" parameter inside the rvmat files suggests that there's support or planed support for more than one UV set. PS detail maps can be found in the vehicle pbos (air, wheeled, tracked)

Ofcourse, but that's trivial to arrange in a mission, which seems to be what he's trying to do here. Without changing the mission it'll be a bit tricky to activate the server side script anyway. It's not really that trivial with JIP now. For someone not used to MP scripting setVehicleInit/processInit should be easier to accomplish. Of course this all depends on what he actually wants to do.

At a certain level of scripting, pretty much everything is more or less a "hack", so better get used to it It's just about knowing what hack is best to apply to a given problem.

The plugin works fine here with 9.0.2. Put it into the Plug-Ins\File Formats and it should show up as PAAplug in the file open dialog and under Help -> About Plug-In -> PAAplug...

Yes, the _AS maps are just greyscale textures like the specular map. The _detail maps are also greyscale for the Harrier but from the wiki it looks like also color detail maps are possible. For the UV coordinates have a look at the .rvmat files. This is where the material settings are stored. From what it looks like UV transformations are supported as well as several UV sets. But without having the proper tools it's hard to say to what extend those are supported and what impact it has on performance. You can find out what textures and rvmats a model is using by looking into the p3d files and then going through the rvmat files to see what other texture maps are used. Looking at the textures and the model in game should make their effect obvious. The _AS maps can be a bit tricky to see in game because the effect is subtle and our eyes are used to those shadows so you don't really notice them when they're there. It's easier to notice when they're missing or wrong. One place where you can observe an _AS texture map is the camelbak of the team leader unit. When in shadow, there's a faulty shadow seen as a dark triangle right below it's handle which is clearly identifiable in the _AS texture map. This triangle disappears when the camelbak is in direct sunlight. Once you know what to look for, you might also notice the other subtle shadows of the equipment. So far the methods are pretty much state of the art and used for most games now, so I'm sure you there are some tutorials or descriptions on the net about those methods. Although I'm a bit surprised that all those texture maps are used even in the lowest shader and texture settings. Looks like there are no real fallback-shaders for low-performance graphics cards. So everyone should be careful what maps he's using on an addon as this might give quite a performance hit on lower-end graphics cards.

You do like to start right at the top of the difficulty scale, don't you? In fact there's no easy, reliable and streamlined way to do this in ArmA. In OFP this already bordered to black art scripting and with JIP it just got up a notch in ArmA. Maybe you can explain a bit more what exactly you're trying to do and what scope you are aiming at for the solution.

ArmA already seems to use high resolution timer, so using that tool wouldn't help at all.

Actually, there's another type of texture that handles the shadows which is different to what I would call "weathering". This is sometimes called "ambient occlusion" or "ambient shadows". In ArmA, it's the _AS texture that does exactly what you mean Messiah. It adds soft shadows on the texture where it's not directly lit by the sun. Only a few models have separate _AS textures like houses or characters, the others seem to have the ambient shadows baked into the _CO textures or lacking them. Depending on how the shaders are implemented, baking the ambient shadows might save a texture lookup and therefor is better for performance, but having a separate _AS texture is definitely more realistic as it gets faded out in direct sunlight. One of the more obvious examples where you can see the disadvantages of baked ambient shadows is the T72, where the soft shadows that are cast by the turret onto the hull are clearly visible in direct sunlight. Especially the shadow towards the rear when the turret is turned. The lack of ambient shadows can also be seen quite nicely on the lower part of the T72 hull which could be quite a bit darker. If this would have been done with an _AS texture, it would even be lit well when the tank is flipped over and lit by direct sun light. So I would at least keep ambient shadows as a separate layer in Photoshop, so that you have the option of going with a separate _AS texture or baking it into the _CO texture. A third kind of texture is the specular map which defines the shininess of a surface. In ArmA this is either a separate _SM / _SMDI texture, or as the alpha channel of a combined normal+specular map in a _NS texture. From what I've seen all three variants are used on current ArmA models. Personally I would rate this map type even more important than a normal map since it adds very visible and noticeable details especially for metal surfaces on vehicles. And it's even visible at the lowest shading and texture detail settings, which the normal maps are not. And last but not least, there are _detail textures that add details like the scratches on the Harrier when you get close. From what I've seen, Specular (_SM/_SMDI), ambient shadows (_AS) and detail (_detail) maps are always used no matter what your shading or texture settings are, while normal maps are only used when your shading details and texture details are set to low or above. Hope this sheds a bit more light into what kind of texture maps are needed or used on ArmA models.

Looks like execVM can't be called directly in the editor since the syntax check doesn't recognize it properly. You would either have to use exec to call a script that itself can use execVM, or Structure your script in the way that was described by the others and call it directly with the exec command in the editor. Using execVM in a script and not in the editor works fine here.

MoveinCargo won't work for what he's trying to do. The moveinTurret command works fine here. You have to be careful about how the turrets are done in the vehicle config. Since turrets can also have (sub-)turrets, you need to specify the path to the turret you want. For example the M1A1 tank has the following turret config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Turrets : Turrets { class MainTurret : MainTurret { class Turrets : Turrets { class CommanderOptics : CommanderOptics { }; }; }; }; So to get a gunner in you need to use the following turret path: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">man1 moveinTurret [tank,[0]](First turret is the main turret.) And to get the commander into his turret: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">man1 moveinTurret [tank,[0,0]](First turret on the main turret is the commander's.) Now the Blackhawk has a different turret structure in the config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Turrets : Turrets { class MainTurret : MainTurret { }; class RightDoorGun : MainTurret { }; }; So to get the first gunner in you need: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">man1 moveinTurret [helo,[0]](First turret on the helo.) And to get the second gunner in you need: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">man1 moveinTurret [helo,[1]](second turret on the helo.) The RHIB boat with the two turrets has the same structure than the Blackhawk. If you try to specify a turret that's not there in the config (eg. trying man1 moveinTurret [helo,[0,0]] for the Blackhawk), the game will instantly crash.

Personally, I think we are still right on the topic of this thread. people were asking and suggesting optimal numbers for various things and I think we established that it's not easy to come up with such easy guidelines if they really need to have a meaning, because performance problems can be the result of lots of different things. So how do we find meaningfull numbers or establish whether our addons are well on track? Right, by testing them. That's how we got there Then we discussed testing and found that it's not even easy to test things properly with all the mess of addon making and the little knowledge we have about the OFP engine. The whole point of this excercise was to show that we need to be carefull with any number floating around about poly count and texture size and question the reasons behind them. That instead of just blindly following some number paradigm, we should rather try to get behind how things work to determin ourself how accurate those paradigms are. I also think you pretty much nailed it with your comment about testing when you say that it doesn't really happen like that. I'm also not "arranging deck chairs on the Titanic" here. (I allmost fell off my chair from laughing, when I read it and pictured it in my mind, thanks for that ) The reason why I didn't do those test myself yet is because I'm too lazy to do it while I don't really think that creating more addons will bring this game any further. At least not anymore. So I'm not actually trying to get people to do extensive testing on their addons and come up with a new standard for addons that everyone agrees on. But there's no other way to show poeple that the numbers and guidelines are not more than just rough guesstimates without going into such a lengthy discussion like we just did. I actually do think that most people are willing to trade in some polygons and high-resolition textures for more playability and better gameplay, because that's probably why most of us bought OFP in the first place! When OFP came out, it wasn't the prettiest game. What really made the difference was the gameplay it offered. Right after the demo was released and people found out how much could actually be done with is by editing, many saw how much potential this game had. I don't know whether it was on purpose that BIS released this demo with editable files, but I think beside offering an amazing gameplay for those times, it was one of the main reasons why OFP became so popular. It was just wonderfull to see how everyone was running around like kids on christmas in Lustypoohs forum and getting excited with every new thing that was found to be editable. Not for the sake of editing just another game, but because people could imagine what could be done with that dimond of a game. Then after playing the campaign and getting over the fact that OFP wasn't really editable anymore with the pbos that were in the final game, the first addons were created and if you can remember, those were pretty crappy at that time But they were made to make the missions that everyone was trying to do since the demo but couldn't do because there were units and other things missing. Addons were made because people wanted to have them for specific missions and missions were at the top of their time back then. But soon people found out that creating addons was more rewarding than making missions. If you're making a high quality mission then chances are quite low that you are going to play it yourself after you're finished. So you're making such high quality mission mainly for others than for yourself. Also addons are much easier to comment on than missions and while many people played those missions that were made by others, the makers didn't really get that much feedback. While if you made addons there was a ton of feedback and recognition and after all you could even play with your own addon when it was finished without instantly getting bored. (And I dare to say that from my own experience, making high quality missions and campaigns that offer a wealth of gameplay is harder than creating similar quality addons) That was where I think the turning point for OFP was. It was actually quite early when those effects set in, and it took quite a while to get to such extremes than we have today, but it was noticable. Today we have still alot of addon makers, but there are verry few left who create high-quality missions. The majority of people in the forums are either making addons themself or are here to spend their time toying around with new addons and taking screenshots. There are still a few who actually play the game, but you don't see them posting that much. Anyone remember the last "war story" thread that was posted for example? Instead there's tons of things going on in the addon related forums and the screenshot threads. From my point of view the discussion about optimising addons is quite a bit academic these days, as I think it would have much more effect if the creating community would more focus on missions and gameplay than creating even more addons in even higher quality that allmost no one uses. I personally know not a single person that isn't making addons but is still playing OFP. Everyone I know was pretty much excited when playing the campaign, but they got fewer and fewer when missions also got fewer and fewer. And lets not kid ourself here. The few of us in the addon making community are not the reason why BIS is still working on Arma and Game2, but because they think that other people would like to buy such a game for playing it. Maybe one of the admins can post some numbers of how much visitors they have on the OFP site and the forums compared to the number of people regularely posting here. It hink there's a huge difference in numbers. Another indicator for why I think people would like to trade in some poly count and texture resolution for gameplay is that I had the impression that it wasn't nescessary the addons with the highest quality that were a huge success, but the ones that offered more and better gameplay. Nam Pack, FDF, CSLA,...(sorry for everyone I missed, but you get the point) they all offered more than just addons. Other addons were better or equal in quality, but they weren't really that successfull. Why are config replacements so popular? Because they let you play existing mission with better addons. People could just download the addons and make missions themself, but they seem to prefer to download the same addons with a config mod where they can play all the old missions. A ton of typing, just to show that there might indeed be a chance that addons aren't really that important and that many people who are more lurking around than posting in the forums might actually prefer to trade in some polygons and textures for actual gameplay. So my impression is that it's not just me who is arranging deck chairs on the Titanic Arma poses a great chance to change things for the better, but we have to do somehting to make that happen. I personally saw with the VBS community that if addon maker just continue as they are used to, nothing changes and in no time you're exactly at the same point with tons of addons and no one left to play. Don't get me wrong, I think optimising addons is important, but as shown in this thread it's either based on more or less inaccurate assumptions or it requires quite an ammount of work to do it right which not many of us are ready to do in their free time just for fun. So my plea is to think more about gameplay and less about how to cram more polygons and more textures into addons But coming back to optimising addons, what I would like to see is some more discussions about how to create decent models for people (soldiers, civilians,...) that don't just fold when run with the original animations. That's one major area where I think huge improovements could be done in terms of quality. There are some nice efforts from DMA with creating new animations, but it's allways both the model and the animation that makes the quality. And models generally seem to be the worse part so far. (I promise to make shorter posts from now on )

The reason why I would prefer dummy assets is to eliminate unknown variables. If you take BIS vehicles or other addons, you would have to examine those first to be able to judge what factors they are adding to your tests. As we established in this thread, it's not a single reason why an addon can cause performance problems, but a whole bunch of possible things that can go wrong. By using dummy assets you know exactly what you're dealing with and therefor your results will be more accurate. Setting up those dummys shouldn't take longer than examining existing assets. That's exactly the reason why people do proof of concept with dummies rather than using finished assets. Because they're faster to do and limit the variables for testing.

I thought I'll explain a bit more about what I meant, since after reading my post again, I think I didn't get my point across well. I'm not doing this for the sake of having a personal argument with you Rock, but because I think it can add to the overall discussion of this thread. So please don't get me wrong here. My point is actually that it doesn't make much sense to set a new standard for parts of OFP without taking an overall look at it. I'm not denying that people have better hardware now than they had a year or two before and that it's possible to have higher vertex/poly counts and higher resolution textures today. Neither am I argumenting about where exactly this new limits are! My argument is only about what methods to use to determin a new standard that isn't flawed. Let's take the case where one addon maker is doing some in depth tests for a new addon he is planing to determin what poly count or texture size is possible with todays hardware in OFP. For those tests he is using the highest quality addons available today and finds out that there is still headroom to push the limits. Therefor he decides to take those results and create his addons according to his findings. Another addon maker, inspired by the work of the first one, is doing exactly the same with the same in-depth tests and obviously gets to the same conclusion as the first one. He then also creates his addon according to his findings. A third one does exactly the same and if everyone is doing all those in-depth tests and create their addons to fill out the headroom they found while testing, then we have a problem. Because suddenly we have vehicles, units, islands and config mods that even if they were done with really good effort in testing things, won't work together properly and cause performance problems. Because each of those addons was build with its own standard that completely filled up the previously existing headroom. Therefor any attemp to create a new standard for poly count or texture size limits that is tested to meassure out the headroom with current addons is definately flawed if you don't take the results and distribute the headroom to everything in OFP. For establishing a new standard you have to take the same approach as if you would create a new game. Look at the available hardware and then judge what poly counts and texture size would be reasonable for each asset you are having and not just concentrating on one single part of the whole thing. Only then you will come up with with a new standard that works. Now the other problem is to make others accept this new standard. Which I think might even be the bigger problem. One (rather easy) method to counter this is to leave enough headroom in your own work for others to use so that things don's get screwed up too fast A sacrifice of your own quality for the sake of future playability.

Actually you're contradicting yourself a bit when you first state that you did your testing in a realistic environment by using 2 year old addons to determin a top end for addons and then you say that it's easier to run "prettier" addons en masse. Why not use a test environment that reflects exactly that? Even if there aren't any addons of that quality around now, it's easy to add some more polys and higher resolution textures to existing addons or even setup some quick dummy addons for the tests. But as you said, we probably won't agree there and I don't want to drag this any further. Thanks for mentioning the circumstances of your tests as this makes it much better to draw conclusions from the results you mentioned. The main reason why I mentioned realistic test environments is that most times, addon makers don't seem to borther about testing performance at all or choose unrealistic scenarios where they end up with unrealistic results, so I thought it would be worth mentioning it in this thread. PS I know that Tonal is "lagging", but if I remember right then it was the first project of that dimension at that time, so it's only natural that it has flaws. No excuse there What Tonal doesn't have is a huge ammount of high resolution textures, which would be more of a limiting factor when it comes to testing texture sizes for new addons.

Testing should allways be done in a realistic environment. If you just throw several instances of the same model on a default BIS island, then that's not what I call a realistic environment. If you are using several high resolution textures, then you should expect others to do the same and then you might end up with several different addons with high resolution textures as a realistic environment for testing. And that test will probably look a bit different than when you only test several instances of the same model (like I explained above in response to Nephilims original post). Also to determin the maximal verttice/poly count or the maximum size of textures for an addon it's not sufficent to test your addon in a 'clean' environment. It might be easier to see what parts make more difference in a 'clean' environment, but things can look verry different when the other factors also play in. Test your addons on a custom island with other units and vehicles that have comparable quality in vertices, faces, textures and scripts, in a mission that uses scripts and everything that you would expect and with a config modification that is commonly used. Also don't make the mistake and only use mid-end addons, because if you push the limits with your addon, I will guarantee you that other will too, so in the end you will have much more to deal with than just your single addon that allready pushes the limits. In the end it's the playability that matters and not how pretty an addon is. There's not much use for a pretty addon if you can't do more with it than just looking at it or taking screenshots. And there are allready more than enough of such addons. It's not the screenshot threads or addon makers that keep this community alive, but the people who actually play the game! And those get fewer and fewer with every addon they can't use.

As much as we all want to have simple rules for optimising models, it's really not that easy to come up with such simple rules. The reason for this is that the process of rendering depends on many things and it's all those things together that make it run smooth or not. Take the discussion about whether vertice or face count is more important. On one hand it seems that most of the calculations need to be done on vertices, but on the other hand this work is mostly done in the GPU which normally has enough power to handle this. As Vectorboson pointed out, usually the fragment/pixel shaders are the bottleneck. But then OFP isn't really using fragment shaders that could make up a bottleneck. In addition, it's not just the GPU that needs to deal with vertices as it's the CPU that needs to grab them and send them to the GPU. So if you have many vertices it could either be the CPU not being able to send them fast enough to the GPU, it could be the bandwith of your graphics port that doesn't let enough vertices throug or it could be the vertex shaders of the GPU that can't cope with the ammount of vertices to process. To setup a test that isolates those factors is hard to do just by throwing some models into OFP, because you don't see what is really going on with your CPU, bandwith and GPU with all the other work that those parts need to cope with. Now lets look at polygons. Polygons aren't that easy to handle either. As Kegetys explained, there is a penalty in switching textures, so what you want to do is to sort your faces according to what texture they're using and then render them all out in one go. In addition you need to sort your faces for transparency as some of them need to be drawn before others to not screw things up. In many cases there is no optimal way to render faces if you have several textures and transparency on your model. So just looking at the poly count doesn't help much there. Textures. Those aren't that easy either. First you have the mentioned penalty for switching textures so you might want to have less textures. But then comes the transparency and for smoe models it might be better to have the transparent parts on a different texture, because of problems with visibility (I think Suma explained those problems some time ago), so you might be better off having the transparent parts on a seperate texture. In addition, the different texture formats with their different bit depths for the color channels pose another difficulty to decide whether to use one texture with transparency or split things up. And if that wouldn't be enough, there's the problem with mapping, when sometimes your faces fit better on a single texture while the other time you have more texture space wasted that way. The conclusion of all this is that trying to come up with simple tests that lead to simple rules for vertices, polygons and textures are flawed from the beginning. The only way to handle this is to really understand all the parameters that are influencing your performance and then try to see which one is the bottleneck in a particular case. But there's one single and really simple rule that should be allways valid: Too much of anything is never a good thing.

Take 4 squads of different units that use the same ammount of different high resolution textures together with a few vehicles that also use a huge ammount of high resolution textures on an island that has high resolution ground textures and objects that use many high resolution textures with a config that uses high resolution replacements for dust, smoke, fire and sky and then tell me how well OFP runs then. Many people forget the big pictue when they're working on a single addon and testing it on desert island. If everyone keeps pushing the performance limits on their own small addons then things get messy pretty fast when everything is put together.

Well if you specify which part(s) you have problems with, then I might be able to help you out there. I just don't have the time to write and test the whole script myself. You're right that the fastroping is similar to what you need. Most of the BAS addons rely on the animation technique I described above (we call such an animation a 'switch' ). But since the init EH was only fixed in the last patch, the fastrope scripts still rely on constantly looping scripts that run on all clients, as far as I can remember. Unfortunately you got a quite advanced MP problem there, so I fear there are no alternatives that are easier to handle if you want to get it done right. Some resources to look at: <ul>[*]addAction/removeAction by uiox [*]Event Handlers by Igor Drukov [*]Object Animations by Planck I can't seem to find the tutorial about dyamic variables on OFPEC, but the basics are just this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call format ["injuredUnitVar%1 = -1",_myNumber]

What you can do to get the MP issues sorted is the following: As this is a bit complicated I'll just describe the idea and then how to do it in detail. What you need is a way to run a script on every client to move the units into your drag-vehicle and a way how to associate both units with the dragging action and the vehicle across the network. An easy way to send variables with units across the network is the publicVariable command, but since you want more than one unit be dragged at one time you can't allways use the same variable. To make a variable unique you add a number to its name via the call command (create a dynamic variable). Check if the variable allready exists before you create it and if it does then just increase the number. You also should do that allways on the server to make sure you don't use the same var for two different draggings due to network delays with the publicVariable command. Since you're creating an addon, a rather easy way to get scripts run on all clients and the server is to createVehicle a special object that runs the script with its init eventhandler (EH). With the last patch the init EH is run everywhere. Unfortunately you can just run a script with the EH when you createVehicle the object from inside another script, but you can't pass variables to it directly. That's why you ned to define a (fast) animation in your special object. By setting the animationPhase of the animation to a number that can be associated with the number of your dynamic variable, the number gets transfered across the network and can be read inside the init script of your object. Number -> animationPhase (for 3 digit numbers) 1 -> 0.001 53 -> 0.053 724 -> 0.724 So how does this all fit together? To make the dragging work with existing adons I would add a hit EH to the units you want the dragging enabled via the init.sqs or the init line in the mission editor. This makes sure that the hit EH is added on every client and the server. With the hit EH you detect when a unit is injured enough to be dragged. (The hit EH is only run where the unit that got hit is local.) With the hit EH you run a script that uses createVehicle to create your special object with the animation and the init EH. Pause this init script on every client but not on the server and wait for the animationPhase of the object to be set. On the server you generate a dynamic variable and initialise it with a special value (set it to -1 or 0 or whatever). Then publicVariable it. In your hit EH script where you created your special vehicle you wait until the animationPhase of the special object is set (by the server) and then read out the animaionPhase and get the number of the created variable from it. (AnimationPhase 0.001 -> 1). Check if the variable were initialised by the server and then put the injured unit into the variable and publicVariable it again. When the animationPhase is set by the server the init scripts of the special objects resume on every client. Extract the number from the animationPhase (wait until the animation settled). Then wait until the variable contains a unit and not the initialised value. Once that has happened, get the injured unit form the variable and add the drag action to it. Now the unit has the drag action assigned to on every client. After all is done, you delete the variable by seting it to nil on every client and the server. When the drag action is activated by another unit it runs a script that creates the drag-vehicle. The drag vehicle also has an init EH and an animation. Like before you create 2 dynamic variables with the init script on the server, publicVariable them and set the animation phase to the number you used for the variables. You need two variables: One for the injured unit and one for the dragging one. The drag action script was paused until the animationPhase of the created vehicle is set. Then it puts the injured unit and the dragging one into the variables and publicVariables them again. The paused init scripts on the server and the clients continue and read the units from the variables. If one or both of the units are local, then they are put into the drag-vehicle. When both units are in the vehicle you delete the two variables on every clien and he server by setting them to nil. Should work in MP with multiple units dragging someone without having a constantly looping script on every client and the server. (sorry no souce examples as I'm away from my OFP editing PC)

Since much guessing still seems to be around when it comes to OFP texture formats, I thought it can't harm to post some info about the OFP texture formats. I know it's a bit technical, so feel free to ask if something isn't clear. The difference you see from the tga to the pac/paa texture is mainly due to the difference in bits per color channel for tga and pac/paa. When you open PAATool, you see some numbers behind the format options. Those numbers show how many bits are used ber channel to encode the color information of your texture. For example, the tga format is a RGBA 8:8:8:8 format (R=red, G=green, B=blue, A=alpha channel), wich means the format stores its color and alpha values in 8 bits per channel (wich makes the 32bits total for tga with alpha channel). ( bits per channel means that is can store 2^8=256 different color values per channel. This is also the what you are used to from your paint program, where you can choose values from 0 to 255 (=256) for every channel. Now the numbers that are shown in PAATool are different than 8:8:8:8. We'll start from the bottom, as those formats are easier. IA 8:8 The format is special in the way that it only has two channels: I for intensity and A for alpha channel. This means that the IA 8:8 format is a greyscale format as it only stores the intensity of a grey pixel. The numbers 8:8 tell that it is using full 8 bits for both the intensity and the alpha value. Wich means that you can have 256 different greys in your texture and a smooth alpha channel. this format should be identical to the greyscale formats you are used to from your paint program. Now the problem is that all the converting tools only take 32bit tgas. So to get a 8bit greyscale texure, you first need to convert your texture into 8bit greyscale (or make sure that you really loose all the color information in another way), then convert it back to 24 bit and save it as 32 bit tga. The main reason for not getting your texture converted correctly into the IA 8:8 format is that there's still color somewhere in your texture. RGBA 4:4:4:4 This one looks similar to our tga (RGBA 8:8:8:8) format. Well, at least the first part. The different numbers mean that instead of being able to store 256 different values per channel this format can only store 4bits per channel. Wich translates into only 2^4=16 (!!) different values. This means that while you can use 256 different shades of, let's say blue, to go from black to bright blue in your tga, this will be converted into only 16 shades of blue in your OFP texture. This is the reason why most textures look that pixelated or banded. Same applies to the alpha channel of this format: Only 16 shades of grey to define the alpha value. Note that apart fron the IA 8:8 greyscale format, this is the highest you can get for a color format in OFP. RGBA 5:5:5:1 As you can see, with this texture format, the bits from the alpha channel have been traded in to get an additional bit for the color channels. This means that for the alpha channel you now only have 1 bit, wich is either transparent or non-transparent. So no smooth alpha channel here. Therefor you get an additional bit in the color channels. This translates to 2^5=32 values per channel, wich is allready twice the value of the RGBA 4:4:4:4 format, but still nothing near the 256 different values of a normal tga texture. So this again leads to pixelation and banding in the converted texture compared to the original tga one. For both the RGBA 4:4:4:1 and the RGBA 5:5:5:1 format I recommend using the dithering option in PAATool. What this basically does is to simulate a specific color (that can't be displayed due to the small number of available bits) across several pixels. This doesn't help for pixelation, but if you look at the texture form a bit further away, it'll look allmost identical to the tga. No more false colors there. DXT1 5:6:5 and DXT1 5:5:5:1 Those two texture formats are a bit special as the DXT1 part suggests. Basically both formats are using RGB 5:6:5 to store their color information. (So the naming of the DXT1 5:5:5:1 is really misleading as it's really RGB 5:6:5 and using a trick to store the 1 bit alpha channel). So what we got here are formats that can store 2^5=32 values for their red and blue channels and 2^6=64 values for their green channel. This means that shades of green will show much less banding than shades of other colors or greyscales. But that's not the whole truth of the DXT1 formats. To save space those formats aren't really saving a 16 bit color for every pixel. Instead they take a so calles "texel" of 4x4 pixels, do some guessing and store just 2 16 bit colors and get 2 colors between those 2 stored ones with a certain calculation (wich is allways the same). Then the pixels are marked wich one of those 4 colors (2 stored + 2 calculated) they should get. If you look closely at converted textures, you can see this effect of 4x4 pixel blocks that have a different color than the sourrounding ones, while in your tga texture all was smooth. The big advantage of this compression method is that most graphics cards understand this compression and therefor it saves RAM on the graphics card as well as bandwidth. Also this compression works quite well with photos as those are much more noisy and non-uniform than hand painted textures. That's the reason why adding noise to a texture might help for a DXT1 convertion. Look closely at the different colors of the pixels in a photo to see the difference to your hand painted texture. Here's also the difference between TexView and PAATool: TexView uses a different algorithm to determine the 2 stored colors of a texel than PAATool. If you know what texture format you want to get, I would allways advise to use PAATool and set the specific texture format you want (not Autodetect!). TexView only uses the Autodetection method and sometimes just refuses to take the texture format you want to have as the exact way how TexView decides isn't known (afaIk). At least I don't know a way to get TexView to convert textures into the RGBA 5:5:5:1 format. You can easily check the texture format by opening the texture in a hex-editor and looking at the first 2 bytes: 80 80 -> IA 8:8 44 44 -> RGBA 4:4:4:4 55 15 -> RGBA 5:5:5:1 01 FF -> DXT1 Some general guidelines what texture format to use: Allways try to use DXT1 without any alpha channel (DXT1 5:6:5 in PAATool or if you're using TexView, make sure that the alpha channel of your tga is really all pure white). From a performance point of view this is the best format as it doesn't use any alpha channel and its compression is understood by the graphics card, so it saves bandwidth and ram. Try to get close to the noise and color variation of a photo with your hand painted texture as the compression works much better then and isn't really obvious. If you need an alpha channel, try to see if you get away with a 1 bit black/white alpha channel that doesn't have smooth transitions (but make sure that your alpha channel is really all pure white or pure black). This way you can still use the DXT1 texture format (DXT1 5:5:5:1 in PAATool) wich will help the performance. If you really need a smoother alpha channel, then it depends on whether you have a greyscale texture or a colored one. For greyscale ones use IA 8:8 and for colored ones RGBA 4:4:4:4. When using TexView, make sure that your texture really doesn't have any colors if you want to get IA 8:8 and check the resulting file with the hex-editor to make sure. Using IA 8:8 for greyscale textures that doesn't need a smooth alpha channel results in a better looking texture, but be well aware that it taxes the system more than a DXT1 texture. Also the face order in your model might cause problems in combination with other textures that use alpha channels. Same for the RGBA 5:5:5:1 texture format. Especially with Dithering enabled in PAATool, it might look better, but it taxes the system more than a DXT1 texture. Trying PAATool instead of TexView (or the other way round), might help to get a better looking DXT1 texture Also the same problems in combination with transparent textures as above apply. Only ever use the RGBA 4:4:4:4 format if you really need a smooth alpha channel in combination with a colored texture, as the banding and pixelation will really get worse than with all the other formats. Another thing is how those different texture formats translate into .paa and .pac: In general, .paa can be everything, while .pac needs to be a DXT1 texture format. If you try to rename a non-DXT1 texture from .paa to .pac, OFP gets confused and can't find the mipmamps, wich explains the error message you're getting then. If a texture is named as .paa, OFP seems to examine further what exact texture format it is, while with .pac it just assumes that it's a DXT1 format.