rocket

I'm not suggesting any way in particular. This is a topic that has been discussed many, many times in the past. The problem is - when people (not yourself) who are new to 3d modeling and/or ArmA addons come to the forum, and see that someone says it is easy to import an [insert any library/game] model into ArmA - that is what they do and they have this expectation of "easy". They disheartened and leave, post questions here, and so on and so forth. I'm not saying that your workflow does not work, nor that it is not the best, also not saying that your UH1 isn't the most amazing thing since sliced bread. I'm not saying that you can't make an amazing addon this way, nor that it will solve global warming and cure cancer. But what I am saying, is that it is not easy.

I'm being high and mighty, because you keep saying the same thing: That it is easy to get FSX/FS9 models into ArmA. That is absolutely not true, and it is misleading to people like Myke (the OP) and others coming into ArmA from outside modding communities where such statements ARE true. Where is the Geometry LOD? The shadow LOD? All the animations need to be setup. You need to remap the UV's, rebake/paint the textures to new co-ordinates Setup the configs Define all the animations Create the different resolution lods View/Fire Geometry LODs Not too mention... the interior views! All of the above, are easier and more consistent if you use good reference and good modeling practice in the creation of your models. Taking a model from Tubrosquid and/or FSX and saying "right, now I'm plopping it in-game" is a recipe for disappointment that has been dished out here time and again. My point: there is no magic bullet, no script or plugin, no substitute for good modeling practice. What you're saying, is that you choose models specifically that are close to being "acceptable" to load within ArmA. That's very different from it being easy to rip/port from FSX/FS9 and is precisely what Gnat already stated. He searched around and found the Piper which was one of a few prospects that offered any hope of a successful port. If we go down this route, all we are going to end up with is addons that don't work properly.

What you have asked for requires some rather complex scripting. Anyone responding would literally have to write the entire thing themselves to answer your questions with sample code. The biki contains all the information you need on addEventHandler, as a place to start. Experiment with that. Are you possibly a small cat that has finished eating cheese burgers and moved onto sample code? :P

texture verts, and sections/drawcalls are your biggest concern for performance - esp if you are using a complex shader in game such as the "super" shader

Procedurally generated textures. The DT refers to the type of texture (in that case, detail texture). Can also produce Macro textures I believe (MC). Present in ArmA also, but not often used outside the BIS models.

How's your scripting? I have some good scripts you can use for multiplayer helo insertion and pickup. ---------- Post added at 11:09 AM ---------- Previous post was at 10:54 AM ---------- 1. I created a helicopter called "helo3", controlled by AI and not playable with HeloGroup3 = group this; in its init line. 2. I then created my playable units (s1 to s6), and added "this assignAsCargo helo3;this moveInCargo helo3;" to each of their init lines. This puts them in the helicopter 3. I created a "MOVE" waypoint for helo3, with helo3 land "GET OUT"; to be executed on completion, activation radius set at 5 meters. 4. I created an invisible H pad near the move waypoint, where I want it to land. 5. I created an empty waypoint where I wanted the helicopter to return to, and called it "end_helo3"; 6. I created a script, that gets activated upon mission start (could just put it in an init.sqf file): //Wait till landed _end = markerpos "end_helo3"; waitUntil {((position helo3 select 2) < 1)}; //Wait until boarded, time expired, or units near _timelanded = time; waituntil {(helo3 emptypositions "cargo" == 7) OR (time - _timelanded > 120 )}; _wp = HeloGroup3 addWaypoint [_end, 10]; _wp setWaypointStatements ["true", "deletevehicle helo3;"]; _wp setWaypointType "MOVE"; What does this do? It causes the helicopter to fly in, land, and then remain landed but with the engine running until all the people get out (but only if it is a UH1Y, as that has seven cargo slots when empty... change this value for other helicopters!), or two minutes have passed. If either of those occur, the helicopter flies merrily away off into the sunset and then gets deleted for its trouble.

So how do you go from 60,000 polys and 10 textures, into 15,000 polys and 4 textures easily, and produce a "good" model with "decent" performance easily? On a side note, you should aim for one texture, not four. I'd quite like to know, as would the entire gaming industry, because then I can lay off most of the art team at work and employ a couple of students/vagrants. In my humble opinion, unless you are optimizing a sphere, polygon reduction is never easy, and it is only in the hands of someone very skillful that it produces good results. You have MAJOR UV cleanup, and potential for severe polygon distortion. Even if you manage to write a script, or use the new Max functions, that magically reduce polygon counts... on complex and weird models like Aircraft the results are less than pleasant. Automated polygon reduction or unrestrained vertex merging as a method of good optimizing is laughable. Assuming you manage to optimize the model, you can bake the old uv's onto a new uv set, but that is not easy... generally requiring an experienced artist. Many artists I know and work with, do not know how to do this. I know how to do it, because I do that for IRIS. It takes many hours of careful UV manipulation and cautious baking, piecing it all together, sometimes with severe heartache and completely creating components from scratch, handpainting/cloning texture parts to cleanup. It is very expensive, and not easy.

If the are in the editor, they are synchronized objects. Using createVehicleLocal means the object is not synchronized and is ONLY local. That means that each client has their own local copy, and its contents can be different than every other one. I presume there are plenty of scripts out there that do manage to stock crates sync'd across multiplayer, but the only reliable method I have used... is to create the crate locally, and stock it locally, not to have it a synchronized object.

Animations must be activated AFTER the game has been initialized. Init parameters get processed BEFORE the game is initialized, hence the name. Name the unit (in my case below, its called UnitName), create an init.sqf file, and in that put: sleep 0.1; UnitName switchMove "AinvPknlMstpSlayWrflDnon_medic"; UnitName disableAI "ANIM"; It's quick and dirty but it works. Remember: if you're doing a multiplayer mission... animations are generally local only when called with switchMove/playMove. That means you need to call them on each client (and putting them in init.sqf will do that)

Ignore the above, not only is he wrong - but he is also rude. I use the following to get a helo to land and completely stop. If you do "GET OUT" then have a tendency to take off when under fire: helo1 land "LAND"; at the completion of my waypoints, to ensure the helicopter makes a fullstop landing, then I use a waitUntil within script to ensure that everyone is out of the helo, then I script in the creation of waypoints after that. I have found this ensures the helicopter remains on the ground even when under heavy fire. You should add a condition to the next waypoint, such that the helo cannot move there until the helo no longer has the units you want out in it. If the helicopter has its engine off, and has no active waypoints, I haven't seen them take off under fire. They will, however, get out if they get damaged to badly (adding in a trigger/script to reset the helicopters health to 100% when it gets damaged fixes this). You could try using disableAI "TARGET" but I have had mixed results with that.

Its a multiplayer synchronicity issue. Addition of equipment using "addweapon" and "addmagazine" is reliable LOCAL ONLY as far as I recall. That's not a bug, its been that way for a long time. You may see the equipment on other clients, but you will not be able to grab it. And if each client add's weapons and magazines it gets pretty funky and doesn't work reliably. For weapons crates I use createVehicleLocal to create the crate locally, then populate it locally for that client. This can be done in the init.sqf.

Try adding a radio command with: hint format ["%1",tank1]; In the on activate line. Then run the radio trigger in game. You'll note the different outputs you see when the tank exists or not. I'm at work, so I can't recall what the "it doesn't exist" output is (something like "null undefined" or etc...), but basically write that down exactly (case sensitive), wrap it in quotes, and then try and detect it in game, i.e.: (!(alive tank1) or (format ["%1",tank1] == "<insert null text>")) P.S. You can then delete the radio command, thats just for testing :)

Sounds like a decent workflow, however - the issue with ArmA/ArmA2 (and someone correct me if I'm wrong but this is my experience) is not just the number of verts themselves, but also the texture verts. Doing your process above does not remove the fact that you end up with craploads of textures, with potentially quite a high number of texture verts. FSX/FS9 are all about the one aircraft. It is not uncommon for an exterior of an aircraft to have over 60,000 polys (that's quite a few triangles...). I once got a 1,000,000 triangle International Space Station into FSX just for a few giggles. They are all about rendering the aircraft, with scant polys for anything else. ArmA/ArmA2, this is not the case. What I do is use any high resolution models to trace over (such as those from FSX, MeshFactory, Turbosquid, MilViz or etc...), and then for baking into diffuse and normal textures. The point I'm trying to labor here... is "horses for courses"... I'm trying to shift my focus to making good models that are designed specifically for ArmA2 rather than just getting something in there really quick. It's the only way to create something really useful rather than end up with our addon sites full of crappy models that are performance dogs with loads of bugs.

Not entirely sure what you're asking but I'll try... 3ds Max isn't really part of the asset pipeline for ArmA/ArmA2. While you can (and I do) use it for creating models, you import from 3ds. I am not aware that *.3ds files store what you are specifying, and I'm not aware that Oxygen brings over any material from a 3ds file anyway (other than texture name). Also, ArmA doesn't use Bump mapping, it uses Normal mapping. And its own somewhat customized variant of that. Materials are defined in seperate files (*.rvmat) that are assigned using the provided editor (Oxygen).

Unfortunately, that would cause the FPS to drop to next to nothing. Modelling those interactions is extremely costly on CPU time.

Yes, but I grouped the activated code in an "if" statement that means it only gets activated if a certain unit is detected within that trigger. Using MEMBER activation is probably best, but I'm not familiar at all with how that works.

I know a number of the Alphasim products quite well, I do contract work for IRIS Simulations (one of their competitors). Standard flight simulators models have a first LOD of at least 20,000 polygons. They also have many, many more textures because FSX has a default limitation of a texture size of 1024 x 1024. This means you will have to remap the textures, otherwise you will end up with many, many textures. In FSX, it is not uncommon to have 10 textures for the external aircraft. A 20k polygon model, with 10 seperate maps equals a huge amount of texture verts (probably over 50k). That will not load in ArmA1 or ArmA2, and anywhere close to that limit will not run without a massive impact on performance. The best advice I can give, use such models for reference, and recreate it by extruding geometry over the top. This gives you maximum control over the level of detail you want to show, as FSX models were designed for entirely different purposes. I use this method when taking extremely high resolution assets and creating ArmA variants from them. While many people say it is "easy" to port something ripped using a 3d render ripping programme, I have yet to see an even semi-decent ripped addon completed "easily". Gnat's piper, I would argue, is relatively bug free but I best many days of work went into that. How 3d Ripping programmes work is they take what is in memory for use by the Video card in rendering a scene, and dumps it all into a 3ds file. This means you are receiving the file progressed by the programme and the video card. The video card breaks the model up based on materials, smoothing, and textures. Welding the verts will help you somewhat, but not completely. As Gnat noted, you video card does extremely funky stuff with models and textures to render a scene. Comments that it is "easy" are misleading and represent a gross, complete, misunderstanding of the process used by videocards to render scenes and what a 3d ripper actually does. If you want to make good addons, use such rips as reference, stick to polygon budgets, and re-create the models to best support the engine you are developing them on.

In a script: _arrayCheck = list trigger1; if ((truck_1 in _arrayCheck) or (truck_2 in _arrayCheck) or (truck_3 in _arrayCheck)) then {hint 'success!'}; In the editor: 1. In the activation of the trigger, create TWO triggers. One containing WEST (or other side if trucks other side), PRESENT, etc... with no actions on activation. Make sure it is recurring. Name that trigger (eg. Trigger1). 2. Then place a SECOND trigger that activates the winning condition, replace the "this" with: ((truck_1 in (list trigger1)) || (truck_2 in (list trigger1)) || (truck_3 in (list trigger1)))

Try something like: _trgMHQSpawn=createTrigger["EmptyDetector",getPos forwardFarpGL]; Trigger1 = _trgMHQSpawn; _trgMHQSpawn setTriggerArea[40,40,0,false]; _trgMHQSpawn setTriggerActivation["WEST","PRESENT",false]; _trgMHQSpawn setTriggerStatements["this","if ((leader mygrp) in list Trigger1) then {hint 'Your MHQ will now respawn at the Forward FARP';forwardFarpSpawn = 1;publicVariable 'forwardFarpSpawn'};",""]; I don't entirely understand what you are trying to do, but what I would do is create a trigger that gets activated by any WEST units, then detect if the unit you are looking for is in the list of units activating that trigger. Mind you, I didn't realise there was a MEMBER activation, so possibly my solution isn't the ideal way.

For guaranteed results, with two actors whom I needed to be placed in strict positions, I got them to walk to a position using a waypoint, then setpos'd them to ensure they were exactly where I wanted them, then scripted their movement based on calling "playMove" animation calls with the walking animations etc... This allowed me to ensure the same output occurred properly and reliably in multiplayer.

could try: _lhaPos = position _lha; _objectsOnTop = _lhaPos nearObjects ["All",20]; {_x AttachTo [_lha,[0,0,1]];} forEach _objectsOnTop; As a good starting point. That will attach everything within 20 meters to the object. Might need to play with offsets a bit, mind you.

try using "units group _leader;" I believe, from the wiki, it works based on a unit. But I would go with deriving the units from the group, not from the leader. Also, post the whole script. Very little can be deduced from this without all the rest of it.

If you want to get someone out of a vehicle, use the "unassignVehicle DriverName;" where DriverName is the driver (or cargo) of the vehicle you want them to exit. For example, you create a waypoint where you want the driver to go. In the "On Activate" section you have "unassignVehicle DriverName;" in there, and hey presto... when the vehicle arrives... they get out! One tip, for waypoint activations with big vehicles (such as helicopters), I have found it pays to have an activation radius of more than zero (like about 5 meters).

Try setting the groups behavior to "CARELESS", that should probably work. Hello fellow Australasian by the way :)

As stated above, I would probably have the following occur in script: 1. Record the original body's world vector, direction, position, altitude, etc... 2. Spawn a "pink mist" and/or explosion effect to hide switch-a-roo 3. Delete the original body 4. Place a new "dismembered" body, with the body broken into chunks, with chunks starting all together in a normal body pose 5. Animate the dismembering of the body using custom RTM animation(s)... any volunteers for the mocap? :D BIS use multiple RTM's for different death states, I'd do the same thing, and use different various RTM's for different methods of dismemberment. If you want to go the "dev" method of hiding selections, that won't really work. Your option there would be to replace the texture on the fly with an invisible texture. Each selection needs to be setup in the model.cfg, the p3d, and the config.cpp file. If you do manage to remove the texture on a selection - two things will happen: - Animations can be a bit screwy on selections that are subject to SetObjectTexture calls. - Any selection with no texture set, will become invisible. On a standard BIS model this means that you will see through the model in those parts. For example, hiding an arm means you can see through the body. My advice, for what it is worth... 1. Start small. I have been modding ArmA since it came out, and I've now opted to devote the next few months to stock-ArmA2 mission making to really get to grips with ArmA2 before getting into addon modding. Mission making, with detailed scripting, allows you to get real personal with issues such as performance, multiplayer synchronization, scripting, as well as intimate with all the stock BIS models. 2. Start simple. For the first dismemberment addon, pick simple functionality first. Come up with the animated RTM exploding body first, get that working. 3. Itterate. Get the simplest part working first, release it, bath in the worldwide acclaim and universal praise that all addon-makers receive. Then get suggestions and improve it.