rocket

I've said it once, and I'll say it again... the easy part is the geometry. The hard part is the UV Mapping and then texturing... but in this case... the even harder part is ANIMATING! I've been trying to animate a dog successfully for some time now, and I have a fully skinned and animated model in 3ds Max... but even thought I can export RTM's I still haven't got it working. Definitely get focused on the hard parts of the project, animation is going to be the real problem with this.

What if you save the textures without any mipmaps? I'm pretty sure that you can, when making a paa file.

First, you need to create a resource, something you want to "render" on the screen as an overlay. Normally you define this in the mission's dxt file, but I have put it in my addon config.cpp as follows: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class RscTitles { class ScreenOverlay { idd = 20000; movingEnable = true; duration = 10000; fadein = 0; fadeout = 0; name = "Screen"; class controls { ... class TVDay { x = -0.2; y = -0.12; w = 1.4; h = 1.2; type = 0; idc = -1; style = 48; colorBackground[] = {0, 0, 0, 0}; colorText[] = {1, 1, 1, 1}; font = BitStream; sizeEx = 0; lineSpacing = 0; access = ReadAndWrite; text = "\usec_b1b\textures\b1b_screen_ca.paa"; }; }; }; }; That defines the texture so I can call it using the TitleRsc command I posted earlier. When I call that, I render that resource to the screen, which I used to created a pixelated overlay on the screen (which was black and white from the setaperture command). To use the setaperture command I'd recommend doing the following: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ConsoleStartTime = daytime; skiptime(-ConsoleStartTime ); setaperture 0.02; That will then have set your screen to black and white, with a standardized level of dark and light. Then, create a title resource over the top that has all the channels filtered except red (which has an alpha). Then, presto, you have yourself a rather snazzy looking red screen. If you want, I could probably easily mock one up. You can get even fancier from there and add HUD elements to it, such as I did with my dialog.

If I were you, I'd add a user action that executes an sqf script that: 1. Sets the apeture to 0.02 (or similiar) 2. Stores the current daytime so when they close the view mode, it goes back to normal 3. Sets the time to midnight (so aperture output is consistent) 4. Use a Cut Scene resource to create a HUD overlay I wouldn't go down the "create an object" route as that seems awfully complicated and I'm not sure why you would want too? You can apply textures to the screen as HUD elements very easily using CutRsc or TitleRsc. Â Thats how the pro's did it!

Please note: This is to be the official (and only) USEC forum post in this section. USEC members must check with the Chief of Staff before posting official updates in this thread. ---- http://www.usecforce.com/ SUMMARY If you're an Armed Assault enthusiast, bring your gaming experience to life by starting a virtual career within the premier Virtual Military. Visit the USEC Wiki page on the Bohemia Interactive community wiki for detailed information. USEC was opened on 1 April 2002 as a division of the Unity Virtual Aviation Community. Rather than being a clan, USEC conducts simulated military operations in a role-playing environment for mature players to provide the complete virtual military career. Currently a variety of gaming platforms are catered for across the four military battlespaces, including Flight Simulator 2004, Flight Simulator X, Silent Hunter 4, and Armed Assault. RECRUITING STATUS (at at 21 May 08) Land Force Group ArmA Vacancies: - <span style='color:red'>URGENT: Logistics Specialists</span> (Please note in application desire to serve at UX511) - Infantry Soldiers - M1A1 Crewmen Air Force Group ArmA Vacancies: - <span style='color:red'>URGENT: C130 Pilots</span> (please note in application desire to serve at UX302 as an ArmA C130 pilot) - Helicopter Pilots - A10 Pilots KEY BENEFITS - Staffed by experienced Military Professionals - Persistent Aircraft, book out individual aircraft for your missions - Outstanding, award winning, and unrivaled website system - Signup for mission taskings online - Earn medals and ribbons for your activities - Multiplayer training and operational missions conducted regulary - Diverse range of roles, allowing you to follow a complete military career from Private to General! - Exclusive custom addons for FSX and ArmA such as the USEC OilRig and C130, as well as the USEC Revolution Map system for persistent battlefields.

Time for an official update: * Addon Releases. USEC has continued the process of releasing my private addons, including: - The USEC F117 (Re-released as a Beta) - The USEC C130 (Released as a pre-alpha) - The Alpine Units (Released with Watkins Island) * Revolutions Training Facility. Â The Revolutions addon and map was upgraded to include Warfare models. Â Through our latest operation, we tested the deployment of the Revolutions concept to another map (Watkins Island) with significant success. - The USEC C130 role was expanded to HALO and additional cargo drop types - New buildings were added to logistics - The role of the USEC F117 was expanded - New requestable missions were developed and added. * Operations. Once again, we increased the spots we have on our dedicated server to cope with demand. Â Currently USEC was committed to the following operations over the last month: - Operation WHITE CLOUD (FSX) - Active, 22 missions, 74 personnel-hours - Project SKYBLADE (FSX) - Classified, 15 missions, 30 personnel-hours - Operation TAMMARPOK - Closed, 168 missions, 912 personnel-hours! - Project SHAKER - Classified, 2 missions, 12 personnel-hours * Notes - USEC formally celebrated its six years of operation, with the unveiling of its own theme song, recorded in a studio by one of our members (himself a successful entertainer), titled "Comin' to get ya". - The website was further extended, now offering over 100 medals, badges, and ribbons to earn. - Our persistent world website now tracks the storage of aircraft munitions, and requires transport of them by FlightSim members before operations commence.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> skiptime(-daytime); //this skips the time to midnight, to set stable lighting conditions for Set Apeture setaperture 0.02; //This sets the aperture of the camera I made a FLIR camera using this method, and overlaying the screen with both a dialog (for buttons) and an alpha'd TV screen image (to make it pixelated) and also by using "setfocus" to blur the screen. If you are having trouble, PM me and I will send you the code and files. I can even whip up some textures for you.

Back to the topic at hand... I tried the proxy route, but gave up on that due to desyncing as mentioned. I went for a different route with my turret design. Â Because you can create a turret on a plane and look around fine (just when you fire the projectile heads straight out, I simply took the directions that the player was looking in the turret and took over the delivery of the ammunition via script completely. Â I added an eventhandler to catch the projectile and send it in the new direction. Â I got the direction the player was facing by several means and am currently deciding which is the best. The issue I was having was that in multiplayer under extreme load the ammunition was being very unpredictable. Â Also, the viewdistance was causing me issues where the server was set to 1000 by default (although this was largely with my targeting camera). Edit: No troll food stored on premises

I've created a FLIR laser turret, as have a few others. Its actually quite possible but its heavy with scripting and MP functionality is problematic.

Ummm, nope its not WaitUntil continually checks its status as often as it can. Putting sleep in there makes it less intensive... ie... less of a potential framerate hog.

Well, it's a start. It's like a fat girl who's on a serious diet. Â Sure, she's fat now... but you know in a few months... I really need to cut down on the the amount of coke I drink at work, by the time Friday comes around I'm going nuts. I've been playing with dialogs for another project, and I think I might deal with loading and unloading by making a dialog system for a loadmaster etc... Â I'm almost interested in working some more on the C130 again. Â Thanks to all who have provided bugs and feedback. Until its "released", enjoy the fat girl Edit: I wrote "problem" instead of "project", talk about a Freudian slip!

Would be great to be enable a form of debug to produce memory heap/processor/gpu load information for developing addons and scripts. This would assist in addon and script makers in optimizing their addons and ensure a higher quality for the community. If we were able to output snapshot files of memory/cpu usage of individual spawned scripts that are running, that would be outstanding. Then when one writes an addon that appears to cause performance problems they would be able to easily troubleshoot to specific scripts and/or models.

Well, its official. I love you.

Yes that would be great, I realize that debug tools has been previously requested, but I think we need to be clear and specific about what that means. Because we can't affect the core code, such a debug mode should focus on performance reporting as you mentioned. That way we can benchmark and optimize our assets for ArmA2. I see this as being a major problem for addon makers at present. Currently, the majority are OFP imports. The quality difference is being increasingly marked between addons and in-game assets... witht he significant amount of shaders and power available in ArmA2 comes increasing complexity and much higher demands on addon makers. I'm hoping that when ArmA2 comes, I'll end up ditching most of my existing meshes and creating highly customized models, textures, and shader use that reflects an approach optimized completely to ArmA2.

I was thinking it might be a good idea to adopt a consistent approach to texturing and modelling with a good directory structure, with the aim of having our models with a consistent artistic feel across them all. If we discuss and agree on our pipeline process this can be easily achieved. I'm not sure what the current SVN structure is, but here is my suggestion: 1. Setup a directory in SVN for each object, and for each stage of the process, ie: \Objects\ \objects\CampEast\ model.cfg config.cpp (object config file, can be copied and pasted to master when complete) \Objects\CampEast\Source\ ..CampEast.max ..CampEast_CA.psd \Objects\CampEast\Model\ (or whatever our agreed model folder will be) ..CampEast.p3d \Objects\CampEast\Texture\ ..CampEast.CA.tga 1. Unwrap object UV's manually to maintain the highest standard in texture mapping. 2. Do an initial ambient occlusion render to texture in 3DS Max at 800 samples for 2048^2 and 400 samples for 1024^2. Distance of ray should be between 0 and 5m as appropriate to maintain consistent effect. 3. Use the ambient occlusion as a multiply or overlay layer in PSD. Complete texturing beyond this in Adobe PSD files, that should be committed to SVN 4. Adopt some common colors to use (for example, standard green colors and etc). 5. Agree on poly/texture targets for object types and have an Art Lead/Producer who is a nazi about checking these.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgMagazines { class Default; class PipeBomb; class PipeBombSmall : PipeBomb { Â Â Â Â displayName="Satchel Charge (Small)"; type = WeaponSlotItem; }; class M136; class M136Small: M136 { Â Â Â Â displayName="M136 (Small)"; type = WeaponSlotItem; }; class Javelin; class JavelinSmall: Javelin { Â Â Â Â displayName="Javelin (Small)"; type = WeaponSlotItem; }; }; class cfgWeapons { class Default; Â Â class M136; class M136Small: M136 { displayName="M136 (Small)"; magazines[]={M136Small}; }; Â Â class Javelin; class JavelinSmall: Javelin { Â Â Â Â displayName="Javelin (Small)"; magazines[]={JavelinSmall}; }; };

No problems, I'm a real fan of cockpits and such - so I tend to devote far to much of my time to them. Â Actually, my favorite part of addon editing at the moment is cockpits! No, but you can achieve a HUD without using the inbuild method of making a HUD. I don't use the inbuilt HUD animation method, I use my own through model creation, transparent textures, and such. Â For numbers and the like, I have used the HUD system but for reticules and the like, I use flat planes with alpha. Animation Source Source refers to the "value" generated by the game to move the item you are animating. Â There are defined sources (that you listed above) that can be used, or you can create your own animation sources by using the AnimationSources section in your aircraft's config file. However, the catch is that engine provided sources (such as flap, speed, etc...) are calculated and updated automatically by the engine - whereas your own animation sources are not. Â For this I create a watch script, that checks the values and reports them back appropriately. Pretending there wasn't a source for "speed", you could make a speed source by having a watching script that does the following: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">while {alive player} do { Â _vehicle = vehicle player; Â _speed = speed _vehicle; Â _vehicle animate["speed",_speed]; Â sleep 0.01; }; Approximately each frame, the script would update the animation "speed" to equal the current speed of the vehicle. Animation Type This is HOW you are animating the object. Â Are you rotating it? Â Translating (moving) it? Hiding it? Basically, what are you doing to the object you want to animate. Â These are hardcoded and you can't directly create your own types.

It doesn't matter. HUD is just a level of complexity on top of the existing animation system. He mentioned... You can make your own sources to animate all kinds of gauges on cockpits. I have made my own HUD animations myself quite easily, and I prefer that method as I find the BIS HUD's look cool - but they are not very useful because they are so small on the screen. One can very easily create a script that provides updated source information to run your own custom gauges and HUD detail.

I'd be interested in making these, and it would not be hard to model troopers etc... however it is a complete legal minefield. It's for these reasons that I think many addon developers don't get involved at making addon's for such things. Â If the addon is successful, you can end up with considerable legal battles. Edit: To clarify my position... I think the best option with using licensed material to make a game modification is to make it without infringing any trademarks. For example... call it "Galaxy Wars" or "Galactic Wars" or "Space Opera" or something similar. If there was interest and or others interested in such a project, I would get involved. But only if such a project was significantly different from LucasFilm/LucasArts projects such that it did not use "characters, story elements and/or locations from the Star Wars Universe" and infringe on the "copyright, trademark and other rights relating to Star Wars are the property".

Ummm... config.cpp: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class AnimationSources { class Wing { source = "user"; animPeriod = 5; initPhase = 0; }; }; model.cfg: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class WingL { type="rotation"; source="Wing"; selection="WingL"; axis="WingL_axis"; memory=1; sourceAddress="clamp"; minValue=0.000000; maxValue=1.0; angle0=0; angle1="rad -40"; }; class WingR { type="rotation"; source="Wing"; selection="WingR"; axis="WingR_axis"; memory=1; sourceAddress="clamp"; minValue=0.000000; maxValue=1.0; angle0=0; angle1="rad 40"; }; Then in code I detect when my plane goes higher than a certain speed, and I adjust the wing using: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_vehicle = _this select 0; _speed = _this select 1; while { alive _vehicle; } do { waitUntil { speed _vehicle >= _speed }; _vehicle animate["WingL",1]; _vehicle animate["WingR",1]; waitUntil { speed _vehicle <= _speed }; _vehicle animate["WingL",0]; _vehicle animate["WingR",0]; }; You can define your own customs sources for animation. Ummm, again, you'll find that if you drop something in-game from a STATIONARY object - the angle of said object is irrelevant. Â The only reason the pitch of the aircraft is important is because of the trajectory that it imparts. Â I think you've missed some very basic (and important) aspects of physics in your logic here. Read through Range of a Projectile that I actually posted above. Â Note that there are formula's for taking into account air friction, but this is fairly negligible. From my experiments, I would say ArmA dealings with objects without applying a strict gravity, and this results in objects tending to "float" or "glide" when dropped. Â This works fine for bombs and indeed missiles. Â This is also why MehMan is getting strange gravity effects. In a racing game that I was associate producer on, we faked a lot of the physics in this way too because hard gravity calculations cost significant FPS. Its in the best interests of the gamer for the physics to be culled to what is needed to play the core game, rather than sacrificing FPS. Hence, when you try to do something a little out of the ordinary, you can get odd results. I took the earlier posted OFP script and have gotten it to work fine for the purposes of dropping bombs from a bomber. Â I posted it in it's entirety earlier, so people are welcome to use it. Â I'm currently using that script as a source to animate a custom reticule for my bombers gunner.

What you are trying to achieve by having two magazines in one slot is key to answering this. For example, do you want to increase the amount of ammunition slots that a soldier has, or increase the amount of ammunition? There are probably better ways of dealing with those situations than by what you are suggesting. From my understanding of how ArmA is coded, the idea that two inventory objects could share the same space is manifestly impossible.

Will deal with all issues raised in good time, as there are some bugs in there that I did not know about. This really is "pre-alpha" and I wouldn't say I've released it as such, this is what I would call a proposal for comment... so people can see the direction I headed with this. To get the cargo working, you need to drive a supply truck up to the back and "load" the vehicle. This animates two cargo containers in the back of the aircraft. Instead of using the supply truck (which I think is in the main USEC Mod, which is not publicly available and very non-user friendly), you can directly set the animated state of the C130 by animating: _object animate ["Container_1",0]; _object animate ["Container_2",0]; Then when airborne, you can open the cargo bay door, and drop vehicles and supplies. Much of the cargo features only work as part of the USEC addon, which I'm sure the USEC members can attest is complicated and not user friendly. I'm hoping to take those pieces out and make them work with this c130. But right now, I'm having fun with a project that makes things go "bang"

The source, as I said above, will have to be custom calculated. The answer isn't in the PBO's, it's in MehMan beautiful picture above. Â A good math's equation will provide the solution to the problem using the vectors from the aircraft's current state. Â ArmA provides us with more vector information than OFP did, which is a blessing. You can define your own animation sources as easy as pie, and I think these can be used by the HUD. Â If not, you could easily script in a faux hud using a couple of faces with a transparent texture. Â As I said above, its not the display thats the problem - the problem is we need to come up with a good equation to work out the fallen position of any dropped item. As near as I can tell, ArmA does not calculate air resistance for the FALLING of an object. Â It does however use air resistance for the MANEUVERING of an object. Â Because dumb bombs, by definition, don't maneuver - we can safely ignore that for the purposes of the maths calculation. If I can solve the damn "fire missiles from a memory point" problem I am having, I'll devote some time to coming up with an equation based on the Range of Projectile. So, for example, I think that an object dropped on a straight and level flightpath, at a speed of 360km/h, at an altitude of 100m... should travel a distance of 451.52m before impact (on level ground!. Â However, if the aircraft was heading upwards at a slight angle of 10 degrees, the distance would be 651.94m. I'll put this equation into Armed Assault and see if I can test the result.

Thanks guys that was an awesome explanation, unfortunately I still havent been able to crack my problem. Well I managed to get rockets firing from the memory points, but I could not for the life of me get missiles firing from the memory points. Â The problem is, I need the missile to be able to lock on... I am using Bombs and Missiles so I want to be able to have the bombs as proxy's and the missiles animated by scripting. I tried using "missile_1" and "R Strela" etc... but with no success. Â I tried establishing using: type = WeaponHardMounted; (after defining #define WeaponHardMounted 65536) in the CfgAmmo, the CfgWeapons, and even CfgMagazines. Does anyone have a working configuration of an aircraft using memory points to dispatch missiles (that can lock on?).

The projects not dead, in fact, I've distributed the C130 to a number of people for testing include a few who have PM'd me. Screw it, people have waited long enough. Â If you REALLY need the C130, then you can download it from http://www.dhd.co.nz/files/usec_c130_v0.2.rar. Â This version is from 30 August 2008. Please don't host this file just yet. Â It's not really an alpha and it's been out with USEC and VMA and a select few who have PM'd me so PLEASE DO NOT HOST THIS FILE. Â Don't consider this a release just yet, more a proof of concept. The reason it's delayed is I was so sick of the C130 - that I didn't have the headspace to fix the bugs, so I moved onto another project (fixing the USEC F117) and then onto my secret project until such time as my mind was clear to fix the bugs. Â One needs to be in a good space to produce quality work.