UNN

Hi, Thanks for the replies. I think it is worth spending more time on the scripts. I will start a thread on the Addons Discussion Forum. I would very much like more Info Gedis, if you can provide any? Or anyone else, as I do want to use these scripts with all types of transport vehicles. I did think there would be specific formations, when moving in and out of vehicles, during combat. I just don't really know what they are. Cheers

Some troop unload scripts I've been working on: Mi26 Combat Unload (Mpeg 7.5mb) Mi26 Safe Unload (Mpeg 8mb) Cheers P.S Nice real time map display, deano.

It must be possible to get round this problem? From my experience with Roadways and fixed wing aircraft, a roadway only effects the vehicle sections, it's directly under. Could you animate it out of the way when the heli's moving? Or even create a seperate roadway object when it's stationary, and delete that, when it starts moving again?

Hi, The stretcher scripts are based on Alimag's originals. Apart from a couple of fixes, they still stand the test of time. It's all down to his clever use of getRelPos.sqf Stretcher simulation script by Alimag Cheers

Well you can drive in and load cargo now with OFP (OWP's MI26 for one), plus I doubt that was an AI we watched driving into the back. If it was, then I'm very happy But the moving around in vehicles is comming on great, looks a lot slicker than it did in the older VBS demo Â

I was hoping someone else could give you a definitive answer The closest I've come to calculating Air Friction in OFP is with my mortars. That involved a lot of trial and error, but once I found a formula (pseudo drag coefficient), it was easy enough to change for different types of Mortar rounds. But taking around 4 seconds to calculate a trajectroy, I doubt it would be fast enough for what you wanted. I think the best method (and the most abstract from my point of view) might be to use CoC's Neural Network functions. Like I said, I cant really help you there. But it might be worth asking if it's possible, on their forum?

Did you create a config that just defines, say the T80 hull? If that crashes then post that config, will be easier to work out whats going wrong with a simpler example. If it does not crash, try adding the T80 turret as well...and so on. Trial and error is the only way I managed to track down these problems.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">minElev=0; maxElev=0; minTurn=0; maxTurn=0; Can you have min and max Elev set to that? I tried a similar thing with infantry and got a CTD. Why not define just one vehicle at a time, and use the default turret classes. As an initial test?

He sort of did, well at least through omission I think Roadway a Landcontact are not supported in proxy objects. As for collisions: did you try the objects you use for proxies as standalone objects? (One thing that might prevent collisions from working is too low mass, another is some mistake in component definition.) I think the answer is: "No, it will not work", but I am not sure. The full thread is here: http://www.flashpoint1985.com/cgi-bin....0;st=15 But infantry proxies will inherite the Fire Gemoetry and Hit Points from the proxy p3d? To be honest though, reading between the lines when Colonel_Klink's says proxy type objects and my own attempts. I'm probably wasting my time pursuing a pure proxy solution, any further. Cheers

Hi, I experimenting with proxies, I've searched through most of the posts here, the main one I found was: http://www.flashpoint1985.com/cgi-bin....07;st=0 I can add a proxy without any problems, in this case I'm using Vojenska_palanda.p3d (Bunk bed). As I know it's used in regular BIS buildings. The collision gemotery works fine. My problem is with the fire geometry (or at least with firing any weapon), according to the link I posted above, the Fire Gemoetry should work with proxies? but it appears to have some strange effects. As soon as I add the proxy, the geometry seems to go wrong. As you can see in the pic, the bullet hole is no where near the main object or the proxy, but it still registers a hit. Without the proxy the geometry works fine? Any ideas? Cheers

Must have missed that one, when sniffing around the VBS pages Thats just global arrays? Although anything that makes arrays more accesible, has to be a good thing. The VBS object pointer would just open up all the other types to be refferenced efficently, rather than just the handfull you get with OFP, at the moment. Edit: Would also be handy if you can expand on the #IfDef functionality of the config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#IfDef V1.91 Class OFPV191SPECIFCADDON { DisplayName="My OFP Addon"; .............. }; #EndIf #IfDef V2 Class AAV2SPECIFCADDON { DisplayName="My Armed Assualt Addon"; .............. }; #EndIf Also checking to see if other addons are installed, a bit like RequiredAddons section of the config but without the error messages: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#IfDef Class OFPV191SPECIFCADDON class OFPV191SPECIFCADDON_EXTRA { DisplayName="External addons for OFPV191SPECIFCADDON"; ........ }; #EndIf Cheers

Hi, Assuming you probably already have your own custom landing gear. You need to determine the height it sits above ground, it's taxi speed and turning circle. There are three utility missions to that. Then just add those parameters to a function called from the init event of the ATC class. Or you could just send me a copy when your done I have to start looking into adding the ATC stuff straight from the original addon, just to keep the number of pbo's down.

Nice one, looking forward to seeing how far you've taken your original gun cabinet, idea.

Hi, I've added support for some more Mods: Liberation 1941 - 1945 La5 La5bomb La5FN La5FNbomb La5 168IAP La5bomb 168IAP La5 159IAP La5bomb 159IAP PO2 As well as the original mod you will also need ATC LIB Mod CSLA II L-410 UVP T L-410 UVP E L-410 Aeroflot L-410 Sky Diver L-410 UVP spec.ops L-410 UVP T MiG-21 As well as the original mod you will also need ATC CSLA II The Swiss Mod F-5 Tiger II As well as the original mod you will also need ATC Swiss Mod Individual addons: SU-17 by TomiID F117 by TomiID An-72 Coaler by Footmunch F-14 Tomcat by Footmunch & TomiID Pilatus Porter By CSJ Mig 31 by Timamas As well as the original addons you will also need: ATC TMD SU17 ATC TMD F117 ATC RKT An-72 Coaler ATC (RKT&TMD) Tomcat ATC CSJ PPPC6 (Pilatus Porter) ATC MIG31 Cheers

Hi, Yeah it should do I think, normaly thats just for placment? The proxycessnapilot.pbo (for example) is just the view LOD, and nothing else. In game my proxy based geometry is working ok for collision detection with the player, but the Fire Gemoetry is obviously wrong. It's either some setting in O2 I'm missing, bugged or just not supposed to work with anything other than class Man as a cargo proxy? Hard to say, there are still loads of minor variations I have not had chance to test yet. I will setup a basic example, it's difficult to describe how the Fire Gemoetry goes wrong. But when you see it going worng, it's obvious. Yeah this might be the only way, to add the Fire and Gemoetry to the parent objects. Building proxies seem to be used mainly for furniture inside houses, and Fire Gemoetry and houses are sort of modeled in an abstract way. Cheers

Your setpos'ing the barrel to close to your body. It creates a form of perpetual motion, by constantly pushing you out of the way. Im using the same thing to try and find a work round, for the walking on moving vehicles problem.

To expand on the idea of more detailed editor dialogs, so anyone can add just about anything they want? Make Description.ext and Config.cpp the same thing, so a mission designer can include minor addons and re-configure existings ones. It might result in massive missions, but it's up to you if you want to download them? If you did that, you could enhance the mission editor dialogs? Allow editor dialogs to be inherited and expanded, by the addon or mission maker. Anyone could write regular addons or small (mission only) pbo addons (configs\scripts) for things like spawning options, addon specific loadouts, or editor utilities to setpos objects. e.t.c for different types of game. Then the mission designer could choose which ones to include in his description.ext\mission. And the scripts and in game dialogs would automaticaly be packaged with the mission pbo. If the addon did not have a backpack (for example) then no need for the addom maker to include a backpack interface. Plus, if the mission designer wanted a backpack, he could include a user made backpack module straight into the editor? Or at least allow a button to be enabled for certain editor dialogs, that launches a user defined dialog. Oh and allows addons, scripts and Descrition.ext to read the values added by the mission designer? Well, just a thought. Cheers

Yeah, I'd like to see this. Just give AddAction the same parameters you have for user actions in config.cpp. Object oriented would be the ideal solution, but if not. Just adding a simple pointer function for objects, would go a long way. So you can associate data with any object? <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Car01 AddPointer <Pointer> GetPointer Car01 <Pointer> could be anything from another object, an array or another pointer. Line of sight function for combinations of objects, and\or XYZ positions? Cheers

Hi, I started on some example missions, to try and break the problem down further. It does help, and it reveals some unusual behaviour with tides and bridges. UNN Height Test.Noe The mission has two radio commands, the first just positions the guns at a constant height of 19.05686. One gun over water, the other over the bridge. Both are affected by the tides. If you increase 19.05686 by a tiny amount to 19.0569, the gun gets positioned to far above the bridge. So far so good, no surprises here. But it did occur to me that, it did not matter when I ran the scripts. When the tide was at it's highest or lowest, the gun still appears in the same place. Which is odd, as given the tiny threshold of the bridge position I mentioned above. You would have thought that if the script was run when the tide was at it's highest point, the gun would appear above the bridge. But it does not. So I can only assume the guns position relative to the bridge is decided when Setpos is called. Then another chunk of OFP code decides how the tide effects the position, and ignores the bridge rules? This is beginning to explain why, when I try to compensate for the tide with SetPos, I start hitting problems. You can see its possible to compensate for the tide by running the second radio option (no need to restart the mission). The gun is steady as a rock. For the UKF Machine Gun to work, it needs to be positioned roughly 1.44 meters above the ground. In order to do this and compensate for the tide, I end up moving the gun out of the bridge's threshold, and the whole effect is ruined. Thanks to HateR_Kint and Sa8Geko I have the M1A1 to compare my results. It's gun has to be positioned about 2.25 above the ground, and works perfectly. So I tried to re-position it's gun to 1.44m, as soon as I did that the problem returns. So roughly I now know that anything placed between 1 to 2 meters above a bridge is going to cause problems. I will try and determine the actual figures later. It may turn out that unfortunately (as far as bridges are concerned) the UKF mg lies in this bad zone. Obviously you cant change the UKF model to reflect the ideal height, that would just look silly? If I change the pivot point of the MG, that will ruin the effect of the gun being attached to the parent vehicle. So really it's up to you guys how\if you want to proceed. For the trailer scripts, you will have to ensure the pivot point is either above or below this threshold, for it to work on bridges. Which might not be so bad, as the trailer is allowed to moved independently from the towing vehicle, and will not really spoil the effect to much. If anyone can get the MG in my example mission to sit 1.44 meters above the roadway, and remain static please do. @Phil Thanks for the suggestions. There is a function over at OFPEC for detecting when your over water (Overwater.sqf), although it's bugged (will have to see about getting it updated) it does work when you fix the error. But I think the height above sea level is not the problem. I think it's roadways, that are the main cause? I will try and see if I can introduce my own roadway briefly, while setpos'ing the gun. Then try and move it out of the way, before it tips the vehicle. After that, I'm all out of ideas Cheers

I used a similar method to this for aircraft, to get the true height over bridges and buildings\aircraft with roadways. I think it's about the same as Vektorbosons function, CPU wise. As they both call SetPos, but VB's function gets the new ZPos as opposed to getting the distance to the thing you positioned it under. I understand your point, as you won't need to call both functions. But this was part of the process of elmination I started going though, I came to the same conclusion you did at the start. I broke the whole process down, and used VB's function to ensure I was correctly compensating for the tide, before introducing those values into the equation. I will knock a test mission later on today that covers the lot, it should be easier to spot where I'm going wrong and everyone knows whats been tried so far. If you go back a page on this thread, I posted a quick test script that runs two vehicles side by side. It was enough to convince me that a vehicle setpos'ed onto a map will always act differently to one driven. Setpos takes the gradient directly beneath the centre point of the vehicle, and ignores land contact and mass e.t.c Which is different to the way OFP works when you drive a vehicle up a slope. Cheers, I was beging to wonder if I had been staring at the thing to long. For a fleeting moment you do see the MG is the correct position, but then the tide changes and it's gone again. Also it works ok, when driving onto the bridge. But as soon as you go over water the problems start. All this could become obselete when Armed Assault comes out, something as simple as GetPos and SetPos using world coordinates instead of absolue coordinates, might solve all of this. P.S If anyone else is having trouble with the M1A1 link, I've mirrored it here: MCar M1A1 turret test

Yeah I can get it working fine, compensate for the tides e.t.c But only if the gun (pivot point) is positioned something like 0.5 meters lower than it actually is. I suspect the same applies if I raised it above the correct position by a similar amount. I wanted to do more testing and just setup a basic mission to demonstrate the problem, if anyone else fancies taking a look? I don't know if it’s down to Autocentre or just the way bridges and Roadway LOD's work. HateR_Kint and Sa8Geko got there M1A1 working over water: http://xoomer.virgilio.it/sa8gecko/m1_m2turret.rar Again it might be that the height of the M1A1 turret is enough to lift it over the bridges sweet spot. Or I have just missed something. I call it a sweet spot, AFAIK if try to you position something on a bridge that’s say 19 meters high, you start hitting the problem. Setpos it at 15 meters it appears under the bridge ok. Setpos it at 19 meters it appears on the bridge ok. Setpos it at 19.5 meters it appears on the bridge ok. Setpos it at 21.5 (for example) meters it appears 21.5 meters above the bridge That’s a total height above sea level of 40.5 meters. But then add to this the tides, and it starts to look complicated. As soon as you start trying to compensate for the tide it, you keep hitting the magic number, and it appears to far above the bridge. I will to create a basic test mission that clearly shows the effect, so someone else could give it the once over. And I can satisfy myself that I'm not just doing something wrong. I tried adding a Roadway LOD to the vehicle, directly under the point I position the gun, but this appears to have no effect. Which is odd, as Roadways cause enough problems for Aircraft? I tried to position a separate Roadway object under the vehicle, but that just causes the vehicle to tip up. I managed to compensate by reading the Height Above Sea Level using Vektorbosons function, that allows me to position an object over water that does not move with the tides. Yeah that’s my thoughts, all this will come in handy for setpos’ing things around carriers and such. But Lol at the chair, hard to imagine nowadays.

Hi, Lol It would be possible to test for some of these events, any extreme changes in pitch or bank or someone hurling themselves of a cliff You could then shut the turret scripts down. But thats more stuff running in the background? No better news with bridges either ATM. I still want to test somethings out, to get a better idea of the problem.

Hi, Yeah, that was some of the earlier experiments I was involved with, not sure how far Sa8geko progressed with it though. I'm in the process of catching up The lib Mod coarse mg (turret\2nd vehicle) does not conform to the terrain. But it does not need to really, as the turret is invisible and the gun does not move. Yeah, thats easy enough. I don't think he can fire his own weapon, as all his commands go to the gunner and driver of the tank. I doubt there is a perfect solution for OFP, it's just a matter of removing as many glitches as possible...Oh and keeping your fingers crossed for the possibility in Armed Assault

The problem lies within the fact that a vehicle driven by the player acts differently to one placed using SetPos or SetVelocity. With SetVelocity you still have to call SetDir, that is as bad if not worse than SetPos. I knocked up a script to test two identical vehicles, side by side. One driven by the player, the other Setpos'ed along side. [<Players Vehicle>,<AI Vehicle>] Exec "Script.sqs" <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 _Vehicle1=_This Select 1 _Dir=GetDir _Vehicle _Pos=GetPos _Vehicle _Vel=Velocity _Vehicle _XPos=_Pos Select 0 _YPos=_Pos Select 1 _ZPos=_Pos Select 2 _Dir1=_Dir+90 If (_Dir1>360) Then {_Dir1=_Dir1-360} _XPos1=_XPos+((Sin _Dir1)*3) _YPos1=_YPos+((Cos _Dir1)*3) _Vehicle1 SetPos [_XPos1,_YPos1] #L _Dir=GetDir _Vehicle _Pos=GetPos _Vehicle _Vel=Velocity _Vehicle _XPos=_Pos Select 0 _YPos=_Pos Select 1 _ZPos=_Pos Select 2 _Dir1=_Dir+90 If (_Dir1>360) Then {_Dir1=_Dir1-360} _XPos1=_XPos+((Sin _Dir1)*3) _YPos1=_YPos+((Cos _Dir1)*3) _Vehicle1 SetDir _Dir ;_Vehicle1 SetVelocity _Vel ;_Vehicle1 SetPos [_XPos1,_YPos1] ~0.001 goto "L" Just uncomment either SetVelocity or SetPos and compare how each command responds to changes in the terrain.

Well fortunately Game Logics are here to save the day, in the pitch and bank department that is. Most of their idiosyncrasies where unearthed with MCar. Just got to figure out the best way of using them with Autocentre now. But yeah, par for the course with OFP. Multiply the complexity of the initial idea by 10, and your getting close to the final solution