codarl

Eden update fixed the problem: Disambarking above 100m no longer puts you into a neverending skydive. Thanks Bohemia!

Making the sword is definately the easiest part. I can imagine swordfighting could work a lot smoother compared to DayZ if you dont mind it looking and feeling like Legend of Zelda: 1. Probably controller based, though SHIFT+LMB could possibly work 2. Have a button to "lock on" to the nearest target. (I'd probably go for the SHIFT key, or perhaps the ALT key, since it also enables freelook) 3. Have the options to strike (LMB), optionally you can seporate left, right and stabbing (Q+LMB, E+LMB) 4. Likewise with the defence (RMB): either a one-button for all, or seporate Left, right or frontal defence. So for you to hit at all you'll need to lock on to someone, and attack. If he is A) within reach and B) not defending (properly), you will hit and he will play a animation like... uh i dunno, like it hurts like hell. Then again, if a melee system was this easy, someone would've scripted this already, I think. I hope someone with experience on the subject reports here.

didn't you forget the file extension? beepbeep.ogg? And since we're on that subject: The file IS mono and in OGG format, right?

You could try to unpack the original worlds and fiddle around with the "Clutterdist" and/or "Fulldetaildist" parameters in the configuration. If that works out for you, maybe you can make a small config to "patch" these values for others. I cannot help you any further, as I myself just started learning how to edit ArmA :). Be warned however, that there is a very good reason that the grass limit is in place. I think BIS handles the concealment problem at longer ranges by not completely rendering units. (not the lower half)

Does look pretty hysterical, just release it saying it's a feature ;)

cant you use "SetPosASL" in the 2D editor for this? Also, you could spawn them manned, but without fuel , and fill them up via a script so they can fly off when you need them to.

Today was a good day. Paths still dont work when completely replaced with BIS's path LOD. Bullets suddenly didn't collide with my model anymore, had to make a fire geometry to get it back ArmA suddenly takes noticable longer to start up, probably did something in the config. The object no longer spawns horizntal but terrain conformal, as NOT per the instructions in the config <.< But on the plus side I learned about property naming vs selection naming, which improved the behaviour of the object when placed via the map editor... yey~!

Right now they are about 20 centimeters above the geometry LOD. I think i'm going to try copying the entire "demo" pathway LOD, see if it works, and try to expand it. I still wonder why the A3 models have "wavers" as entry points, whilst A2 models and OFP models dont. Is there an improvement in how they work? Also on an unrelated note: What determines what LOD's the engine looks for? the fact that it's in CFGVehicles? or is it written somewhere in the inheritance? like "Simulation="house";" ?

No use, building positions dont show up either when I want to make the AI walk over it. everything is split up into smaller sections and triangulated. The pathway LOD starts c.a. 2 meter outside of the geometry LOD.

Well, one thing that has changed since OFP 1.96 is that BIS has seemingly released samples! *applause* Sadly, no much help there: The units that resemble my project the most (PMC bridge) dont have a path LOD, only a Roadway LOD which is identical to my setup. There is also no info as to why pathways sometimes have "big triangels" as entrypoint and sometimes just "start" somewhere, why 9 out of ten faces are quared, but not all of them, etc etc.

I would try tricking the physX engine by making an (one!) invisible pole with a diameter of around 20 centimeters(2/3 foot) and a length of about a meter, and stick that (three foot) perpendicular to the edge of one rotor. That should have the highest probability of causing a deadly collision.

I'm building a construction wich large building blocks. I'm having trouble getting AI to properly navigate them. They seem to move at around half-pace. The blocks are 50^2 in size. Geometry works, Roadway works, Paths (essentially one 50X50 face with all the polygons named "IN1-4" ) do not seem to work. I've noticed in Bis's configuration in Structures_F , that they seem to have seporated the path LOD from the model itself in large structures. class CfgVehicles { class Building; class Bridge_PathLod_base_F: Building { mapSize = 52.96; author = "$STR_A3_Bohemia_Interactive"; _generalMacro = "Bridge_PathLod_base_F"; scope = 0; scopeCurator = 0; displayName = ""; model = "\A3\Weapons_F\empty.p3d"; vehicleClass = "Structures_Infrastructure"; destrType = "DestructNo"; simulation = "house"; armor = 500; cost = 0; }; and further on... class CfgNonAIVehicles { class Bridge_base_F { scope = 0; scopeCurator = 0; displayName = "$STR_A3_CfgNonAIVehicles_Land_Bridge_01_F0"; model = "\A3\Weapons_F\empty.p3d"; destrType = "DestructNo"; simulation = "road"; armor = 500; cost = 30000; class Destruction { animations[] = {}; }; }; Can anyone tell me what I'm missing that has changed since OFP 1.96? Best regards, Dennis

Shame. I'm still looking trough all the configuratons. Does anyone have any idea what the "access = " value means? I've seen 0, 1 and 2, but no-one comments on them :/ EDIT: Access = has to do with the engine allowing modifications to that class. Still dont know much more though.

By any chance, do you have a Landcontact LOD? You might need to rip that out (though I dont know how that will affect other workings)

You'd be suprised to know that there are more then one ways off a plane ;). But on a serious note: I'm looking into a way to get big structures with deep basements working. With the automatic skydiving that occurs now, it's setting limitations, and/or risk of bugging up gameplay. Regards, Dennis