rocket

If you place the BIS Functions Module, you can then use: [["song1", "song2", "song3", "song4"], 2] spawn BIS_fnc_music; Where the first parameter is the songs, and the second is the delay between songs :)

playActionNow is syncronized to all clients, but you need to use the action name (not the animation name). Otherwise you can use the Multiplayer Framework, specificially rPlayMove:

Also, because the script will be itterating through many, many locations and indexing the whole map - you might want to consider some optimizations. Specifically, you could situate the command between startLoadingScreen ... and endLoadingScreen so that the engine is dedicated to running the scripts and does not do any simulation processing or rendering. A good page to read is Code Optimization on the wiki. - Binary array addition is significantly slower than using set: - Position is much slower that getPosATL or getPosASL. Furthermore, if you want ALL the locations on the map, it might be far more practical and cost much less performance to read the locations from the config file directly, rather than use nearestLocations as this has to search the map for them. In fact, depending on what you are doing with the values, you could possibly read them directly from the config without having to store them as an array. The config is already loaded memory anyway, so it's there to use for "free".

You can use the Multiplayer Framework to use the say command on all clients: Example: [nil,UnitToSpeak,rSAY,["NameOfSound", 50]] call RE;

Absolutely no idea :) It's been quite a long time! And it doesn't matter anyway :) I simply offering the source files, they might be some use - it appears you have some tri-edges turned incorrectly in the initial picture that cause some corruptions.

Pretty sure they're my ones. It looks like they're an unbinarized version - I have the max source files, p3d's, and PSD's that might be considerably easier to edit. You PM'd me waaay back in 2009 about them! Flick me a PM if you want the source and I can send you the mediafire link to the actual source files.

Nope, TexView2 is the tool. As Gnat noted, TexView2 has a "personality" and requires the file to be correctly prepared. Many people batch convert their tga/png files to paa or get O2 to do that for them. If TexView2 doesn't handle your file, then it probably means something is wrong with the file and is something you should investigate.

You're welcome :)

Most of the "look" of your model will come from the shader, i.e. the combination of the normal, specular, and fresnel. You need to give careful thought as to how you will create these. For most models, the appropriate way to generate this is to make a high resolution (in the order of 100k - 1000k polygons) model and then "bake" it onto your low resolution model. This helps with generating the diffuse, ambient, specular, and normal maps - essentially leaving you with touching up the textures once baked. You're blob would then be exported into something like Mudbox, with the details carved out into a million polygon model. This is then baked into the normal map, and the ambient map. In OFP times, you could get away with generating the model directly and painting the diffuse/normal yourself - but with the modern shaders it becomes increasingly obvious and can result in a very problematic look. Your 3D object essentially just provides the basic shape, with the actual detail being provided through the normal/spec/fresnel combination. Once you get this high -> (bake) -> low workflow working, the whole process becomes quite straightforward and it is a good way to model, even for low-poly simple objects. Your high-poly model is generated any way you want, with no regard to UV space or polygon limits. You make the object "look how it does" in real life. This then allows you an excellent starting point as to where/how to generate your low-poly model. You can then assign you polygon budget more effectively, as you can see where you need to commit polygons. The further benefit is consolidating your textures and materials. You can lay your UV's out all at once, get the scale correctly assigned, and split parts out into appropriate materials, balance and adjust it all, THEN generate the textures. This efficiency really helps when assigning UV space. Oxygen is then your "final step" in the addon development process, where you configure the parts, assign materials, test-and-adjust as necessary - bring it all together into your final addon.

The edge of your texture contains black/green, and when mip-mapped, the sides of this texture are bleeding onto the rendered output due to the texel calculation during compression. To prevent this, increase the padding area of your texture, and try to use the most common color for the background of your texture, rather than (say) black. At each mipmap scaling, each square set of 4 texels becomes 1 texel (average of the four), and the texture becomes more and more filtered. What you don't want is for that filtering to bleed color between each seperate UV island. Subdividing the texture using the above rule minimizes such inter-island bleeding. On the other hand, efficient use of the texture is as important as minimizing mipmap artifacts. And such mipmap bleeding is only noticeable if the colors of the inter-bleeding islands are different. Things on neighboring islands that will have similar texturing, therefore, can ignore the above rule, specially if they are continuous on the mesh itself - as in, the two islands being just the result of a seam separation.

Be careful with ditching the mip-maps, they are there to provide a performance improvement. The extra ~100kb in HD space the texture takes up is more than compensated by the reduction in the size of the texture loaded on to the GPU/texture atlas when the object is rendered. Mip-mapping is an important part of the GPU rendering process, and you should be careful about removing mip-maps simply to save a few kb in HD space taken up.

Depending on the unit's configuration and state, doMove or moveTo together with getPosATL work best. So long as the unit is able to pathfind effectively to that position. Some buildings are difficult for the unit to work out an effective path (taller it is the harder it can be), but many are fine. Using getPosATL/getPosASL is preferred anyway over getPos or position as they offer a performance benefit, so you should always try to use these where possible by default.

Ah yes! it is a locality issue just as I thought, hence why I asked about addWeaponCargoGlobal. In multiplayer, you must use this command if you want it syncronized across all clients. addMagazine and addWeapon ARE syncronized, so you won't see the issues with that. But the cargo commands require you to use a different command in a networked environment. Let us know if there are any problems! Try this code: clearMagazineCargo (unitBackpack this);(unitBackpack this) addMagazineCargoGlobal ["UKF_5Rnd_338_Mag",6];this addMagazine "Laserbatteries";(unitBackpack this) addMagazineCargoGlobal ["SmokeShell",2];

Just confirm, you're using addWeaponCargoGlobal? Would you be able to post the code, or at least some of it, here? It will be much easier to help you solve the problem if we can see this :) To explain a bit more, the fact that you can see it and others can't, and the other way around, sounds like an issue of locality. Some script commands only work on the client they are issued on, such as addWeaponCargo. A new command, addWeaponCargoGlobal, was created that ensures it is issued on all clients.

Hey there! Are you using addWeaponCargo or addWeaponCargoGlobal?

+1 for that method! binary addition is a depreciated method of adding to an array, due to the performance impact.

The !isServer waitUntil will lock up, as ArmA2 will be waiting until the player's computer is not the server (which will never happen, unless they were not to begin with). Player==player is good for checking, as player will not return correctly until their client has initialized. For the initial cutscene, off the top of my head, you could try: if(!isDedicated and player == player) then { myMission_cutscene = { if (player in list _this) then { disableUserInput true; }; //Insert rest of custscene disableUserInput false; }; disableUserInput true; //Insert rest of custscene disableUserInput false; }; Then in your trigger, spawn the code block with the following command: null = thisList spawn myMission_cutscene; Haven't tested that, but should work :) Good luck!

Hi there. The wound texture is a special texture, called a macro texture (MC). This is applied over top of the existing model texture by the engine. If you study the MC texture you will note the majority of it is an Alpha'd, with a red background. You could change the wound texture configuration in the config so the healthy state is actually using the normal wound texture, but this would require you to make and distribute an addon. An alternative would be to either simply setdamage "0.8" the unit (activating the damage texture) and then disable simulation on it. Or you could make your own texture with the MC as an overlay on the original diffuse texture.

Do you have script errors on? private ["_blah","_animVal",[b]""[/b],"_bl"]; Should throw an error regarding global variable in local namespace, or something similar, as you have "" in the private definitions.

You can export grayscale heightmaps using MicroDEM (I think as a GeoTIFF, but its been a while since I used MicroDEM). Have you tried importing into Visitor with a grayscale map? I wouldn't have a pipeline direct from MicroDEM to Visitor as the image will need some cropping, levels editing, etc... to get it correct. It will probably require some cleanup also. A second option is to create the terrain in L3DT and then export as a grayscale image, couple with the correct details in a pbl file, and then import directly into Visitor that way. To achieve the exact effects I wanted, I once was importing/exporting between Global Mapper, L3DT, photoshop, back to L3DT, then into visitor (for my Aoraki map). As always I think the easiest thing is to start simple, then make small steps. See if you can get a very simple, small, grayscale heightmap imported into visitor no problems. Then try something a little bigger once you've got a good feel for the process.

Have you tried Global Mapper? I think they have a trial version. I used it in conjuction with L3DT on several occasions. Also, Aaron at L3DT is a great guy and very easy to deal with if you have questions. This makes exporting in different projections (to grayscale and XYZ) extremely easy straight to Visitor 3. It might be worth a shot, I found it much easier to use than MicroDEM and used it at my old work alot.

Actually, for best results I force a physics update by giving the car a small velocity down; this setVelocity [0,0,1]; Always does the trick for me :) Setpos I generally find doesn't work, because a new vehicle with no-one in it doesn't receive a physics update.

A standalone component of the USEC Revolution system is being released. The USEC LHA AI Airboss, is a series of controllers who provide Air Traffic Control to player aircraft in and around a spawned LHA. A mission maker simply places a single game logic and the scripts take care of the rest. Functions are quite extensive, the gameplay video gives a pretty good overview. Vectoring to mission-set waypoints/ship Controlled takeoff, landing, and patterns Deck management and vehicle spawning/servicing Integration with land requests (CAS, Gunship, Transport) from players on the ground Dedicated server and singleplayer tested and compatable Fully ACE compatable XkvJmjYRvO4 Mission makers who are interested, contact me to receive download links. Will need to wait for final build before release (October 2011).

simulation="shotRocket";

Are you adding the value every revolution? In your original code, you are just setting it initially to 1 (one animation). You need to continually set the animation to a higher value per the code I pasted above.