olli_

is there a way to introduce a delay between the player releasing a missile or bomb and actually releasing it? like i want the player to click shoot, and then 1 second later the missile fires. kind of like initTime for class MissileBase, except i dont want the missile/bomb to release before the delay is up.

Im using the fbx 2010 exporter for 3ds max 2014. Ive also tried the 2014 fbx exporter but i had trouble with that earlier with other things so ive stuck with 2010 since then. I have triangulate ticked in the export options, and ive checked the FBX in a variety of programs and it is triangulated everywhere except O2, which leads me to beleive that O2 runs some sort of quadify algorithm when importing fbx files. The .3ds importer has the option to turn quadify off (its on by default for who knows what reason) but the fbx importer does not have this function. A macro texture is the 3rd stage map for the super shader. Basically what it does is overlays another texture on to the diffuse using the alpha layer. Its mostly used for either prebaked lightmaps (or AO) or in my case im using it to overlay small text and logos on to my diffuse which would be unreadable if i just put them in the diffuse texture. Also from the tests ive done in bulldozer/O2 ive noticed that the UV area where i get the least errors (usually) is actually -0.5 to 0.5, although the glitches seem quite arbitrary as sometimes if i move the UV element 3 tiles to the left it might come out looking less warped than it does within 0-1 UV space. Generally the results are more reliable the closer the UV verts are to 0,0

Here's some WIPs of the textures: www.imgur.com/a/HUSz2 edit: heres also a night time shot

alright i managed to get multiple UV's by importing as .3ds and copying the UVs over. BUT now my macro texture is warped on it. The UV is totally fine in the O2 UV editor, and the texturegrid renders on it fine in O2 dx viewport mode, but in bulldozer with my macro texture its like all wobbly and adjusting the UV in the o2 UV editor has arbitrary effects on it. (moving a face just a tiny bit on the UV might make the macro texture stretch all crazy)

Thats just how the cockpit looks.. im guessing its not much of a problem with the real version with the DAS so you can just see through the whole cockpit. I did some ambient occlusion tweaking in an effort to make add some depth to the cockpit, the changes are very subtle but i think its going in the right direction: http://i.imgur.com/gnR4d0I.jpg (155 kB) also most of the album pictures were taken with the zoomed out view (i was holding -) so you can see more of the cockpit with less pictures. This picture is taken with the default FOV.

ive defined my wheels with driveOnComponent[] = {"wheel_1","wheel_2","wheel_3"}; but this makes my wheels completely frictionless. they slide on slanted ground and steering doesnt work (pretty sure thats related) anyone know whats up?

The cockpit is moving on to the not-quite-yet-done but good-enough-to-post-pictures-of phase, so without further ado, heres an album of a test flight i just did: http://imgur.com/a/tdB6x

Im getting this error... im wondering if its the cause of binarise crashing when packing a .p3d with a shadowvolume (resolution != 1000) pufus link is dead... wondering if anyone can help?

Im trying to get my normal maps to look good in in buldozer but the normal space is really weird. My normals look fine in 3ds max, but in bulldozer it doesnt render out properly. http://i.imgur.com/AKTcLnH.png (left is 3ds max and right is buldozer) some info: model is exported as fbx 2010 normal map is 32 bit tga (tried 24bit as well) with _NOHQ suffix ive tried all output options in handplane with an object space normal but none of them worked in arma. source engine was closest i think but still noticably off) have tried triangulate / and triangulate \ in O2. neither worked. have triangulated my fbx before i exported but for some reason in the O2 fbx importer makes it back in to quads edit: is there some way to import explicit vertex normals? that might help

Im getting really tired of this engine's shenanigans. Saving completely wrecks the shading.. seriously what the hell am i supposed to do?

alright i did some testing and ive outlined my results on polycount.. might as well copy the wall of text here if anyone finds any help in it:

Ill be streaming some cockpit work today... http://www.twitch.tv/saippua2 Just trying it on for size, any suggestions are welcome

Hey are there any rules in RV4 with regards to splitting a model in to materials? I read somewhere that each moving part should have its own material, but im able to apply a single material to my whole model with lots of moving parts just fine. also is there a connection between selections and materials? something like 1 selection = 1 material?

There must be some way for variables ive calculated in a script to be used in my config? I cant find any docs on the subject

What im trying to do is get the camera direction vector and use it in various HUD elements in class MFD. the existing HUD functionality is extremely limited considering modern technology (not to mention FUTURE technology in 2035) and the only way i can see of expanding that is scripting, and even that wont be possible if i cant use scripted variables in the MFD class..

ive looked at a few sample assets, and the mass values in geometry LOD look a lot like theyre in pounds. Now everything else as far as i know is in metric units, so can someone confirm? is the mass value in geometry LOD in pounds or kg?

Its a GBU-32 so 1000lb.

Finished the last bomb (for now) http://i.imgur.com/RTc59Aw.png (899 kB)

no they dont. I was hoping to add some but guess thats not going to happen

the "Throttle" animation source doesnt seem to be working for airplanes. is this a bug or am i doing something wrong? https://community.bistudio.com/wiki/Model_Config#Animation_sources (near the bottom)

sure why not

K i think i understand. .kju it seems that the distiction is between "your mod works with mod X" and "your mod requires mod X to work"

So the rules seem to say that any addon submission must work 100% with just a basic Arma 3 installation (im interpreting that as it cant require other 3rd party addons) Does this mean that i cannot have any connection to 3rd party mods without being disqualified, or can i have "additional" features that require a 3rd party addon but that are not integral to my addon. for example i have a midair refueling nozzle on my plane, and it would be cool to make it compatible with some 3rd party flying tanker if people wanted to use it.

im trying to build a test which i made from the plane sample. Ive replaced my own model and edited the scripts/cpp's a bit. i try to compile the folder but the addon builder is just instantly crashing with no messages or anything (just windows message AddonBuilder has stopped working) I also tried projectPBO which was suggested somewhere but with that i get the error "In File projects\f35\cfgHUD.hpp: Line 314 No Token" (i havnt touched that file, its straight from the plane sample folder. Ive tried putting my source and destination folders in the P drive too, but that didnt help either.

alright thanks for all the help guys, ive managed to solve the problem. for any future generations struggling with this: it seems that the ground contact points in LandContact LOD cannot be named the same as the wheels themsleves (despite me reading from MULTIPLE sources on these forums that the LandContact LOD does NOTHING and has NO EFFECT on ANYTHING), so if your wheels are wheel_1, wheel_2, and wheel_3, the landcontact points have to be something else. I named mine wheel_1_stabil_1, wheel_2_stabil and wheel_3_stabil. Thats what they are named in the sample plane but im not sure if they absolutely must be named that, and some other community mods seem have the landcontact points named differently so go figure. I also moved all the LODs in my p3d so the plane's center of gravity is closer to the 0,0,0 point of the scene. I dont know if this has any effect but the sample plane is set up like this so im just going with the flow. Originally i had the plane's wheels aligned with the Z = 0 plane (which seems only logical for a vehicle that moves on the ground, but i should already have learned that logic is worth jack shit when dealing with this engine.) my theory on why this works: I have absolutely no idea