chris330

Nice idea. Sounds like the basic beginnings of a GTA type concept. Something you could take as far as you wanted to I think. As for the issue who knows. In mp things normally work well on the host machine but not the clients. I am aware of a command called 'local'. Now if you go back to your original method using the 'player' syntax and then try (I'm making no promises) the following syntax in the script the trigger calls: if not local player then exit which I think in code translates to: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?!(local player):exit; Now one would think that the player would be local to the machine running the script client or otherwise. So this bit should cause all machines to run a copy of the script with their local player as the subject unit. Those machines where their local player has a rating above zero will simply exit, but the one where the local player has been naughty will activate the script. I have some more advice but I'd make sure this is working before you look at the next idea I have. Suggested Improvement: If I were you I'd have two triggers. One which is aimed at being run by the host machine and causes the reaction, and the other as the sensor. In the first trigger have its condition field activated by a global variable being made true such as 'alarmvariable' for example. In the activation field run the script causing the police to react to the player's misadventures. In the second (sensor) trigger run the above syntax (assuming it works ok after you've tested it) where the machine checks to see if the local player's rating is below zero. If it is, then make the variable 'alarmvariable' become true. Try to avoid using 1's and 0's in place of true and false as I've had scripts react badly to this before. They seem to prefer typical boolean state strings rather than 1's and 0's. There is a command which I can't remember that broadcasts the state of this variable to all machines on the network and overrides the value of this variable stored on all other machines with the one you broadcast. This command can originate in the host or client it doesn't matter. Even if this originates from a client it will set the 'alarmvariable' to true on the host's machine. Now if you start to have problems with duplicate scripts executing on client machines that you dont want do the following. Make a game logic and call it 'server'. IIRC game logics are always local to the host never the client. In the script which causes the reactions have the following syntax at the top: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?!(local server):exit; To be ultra-clean you might be able to remove the () brackets but I'm not sure. This should stop duplicate scripts running on client machines where this is perceived to be a problem (it often isn't so I hear). So the concept is to use a sensor script to broadcast the variable value to true from any machine when the player is naughty, then have the reaction script execute only on the host machine. Should stand a much better chance of working *Edit* The broadcast command is publicvariable. Example: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">publicvariable "alarmvariable" Include the inverted commas.

Almost right mate. The foreach operator then expects an array to follow. Looks like by using the syntax: foreach this you're trying to run the code line on an object. Try: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"_x flyinheight 50" foreach units group player or <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"_x flyinheight 50" foreach units mygroup

Good idea, I might just do that! Thanks

Hi a lad in the OFP scripting forum gave me an idea for making an injured man camera script. It's a camera script which simulates the viewpoint of an injured man being carried fireman's lift style on the back of another unit. It uses a sin function to get the back and forth motion offsets for the camera. It's complete and released. Have a read of the script and check out the demo mission and have a play with the input parameters. Any questions, drop me a line

Hmm.... there might be a detector command that allows you to look-up the damage level of a unit. To do what you want to do then you'll need to have an animation scripted into your building's .p3d file. Sounds perfectly possible and a rather good idea too. *Edit* There is. I think it's getdammage. Look it up pal.

That information is likely contained within their config files. You'd have to depbo them, alter the info and wrap them back up again. Note that the start-up time might be generic to the helicopter class. In which case you'll need to know its corresponding variable name (data member ID for C++ heads) which might mean you'll need to scan through the commented config released by BIS and look through the helicopter class.

We need a bit more information to help you mate.

You'd have to change the relevant data in its config file. If you're not sure how to do that goto over to OFPEC and have a look at some of their tutorials. Great place to start.

You could temporarily move the wounded unit way off the map and then place a substitute there in his place with no Geometry LOD. Even just an object that was crafted to look like a soldier would do this well enough. Then run a camera script on the client (assuming the wounded soldier is the client) machine with the camera pointing backwards behind the carrier and pointing towards the ground. Easily done with a camsetrelpos command targetted at a game logic unit which follows the carrier on the ground. If you're really clever you could script a bounce effect using a time update loop to make the camsetrelpos offset magnitude oscillate. If I've got some time (unlikely) I might have a go at this myself. As for AI units not firing on the carried 'object' you might be able to get around this somehow by making the object from an infantry class of the relevant side but make sure it has no Geometry LOD, just a Fire Geometry LOD. Wouldn't cause any collisions and the AI would still shoot at it. When ready to unload the casualty simply delete the dummy unit and swap him for your real guy using a setpos command back to where you want him. Note you may experience some issues in mp with camera scripts, make sure it only executes on the right machine.

I would have thought there is, which weapon are you talking about? I'll have a look through the config file associated with it. I'm fishing tonight so it won't be till tomorrow.

Quite possibly. It sounds to me just from reading this post that you have an enquiring enough mind to need to start to learn to script. I would have thought you could get a good response by using a script that reveals an enemy and instructs the unit to fire on them using the dofire command. Operation Flashpoint is very unreliable when it comes to AI units behaving as if they have common sense. Often we have to hold its hand the whole way to our intended goals.

This might not be news to some of you but it's news to me. This may already have been documented but I'm not sure so here goes. I've been trying to find out how this worked for some years now and I finally got to the bottom of it. I would well imagine this will be of good use to someone in the future who comes searching through looking for help on this issue. For those who have no idea what I'm talking about the problem arises when you want to set an object at a specific point in relation to another vehicle's frame. You'd think that the getpos command would return the [0,0,0] reference of the vehicle's frame. Well unfortunately it doesn't. It returns a totally different point indeed, and it makes accurate setting of an object relative to a vehicle's frame nigh on impossible when it starts to pitch. It's a well known issue amongst veteran scripters and programmers. I'm not sure but I would imagine the guys who've made hitching scripts in the past with rope addons might have had this trouble. Anyways what happens is the getpos command returns a value which has something to do with the vehicle's land contact points I think although I've yet to confirm this. It does not return a position that has anything to do with the origin point [0,0,0] in Oxygen as I've checked that with the BIS Cobra. If you took a vehicle and placed a logic unit at the getpos points using the following command: _logic setpos getpos _vehicle; it will be placed near the base of the vehicle in question. Now you'd think that if you ran the distance command using the following code: _logic distance _vehicle; it would return a value of zero. It doesn't. It returns a significant value normally a couple of meters or more. The same also happens if you use the drop command to drop a particle at the [0,0,0] position. Say you called a drop command on a vehicle to drop a particle at [0,0,0] on the vehicle and then returned to co-ordinates of the particle to a script, then compared those coordinates to those returned by the getpos command. You'd again get a value way above zero. Infact if you use the drop method and place a logic at the drop's coordinates and then compare it to the returned getpos coordinates, you will get the same distance as you do when you perform the distance command run from the vehicle to the getpos coordinates. In short, the reference point for a [0,0,0] particle drop and the distance command's starting point are at the same place on a vehicle's frame. The only thing I could possibly think of was that this was it's Centre Of Mass/Centre Of Gravity. I proved that it was using a simple box in O2 with some mass attached to it. I predicted what the distance between the object and getpos coordinates would be and the results matched the predictions perfectly. So the COG point on a vehicle's frame is very different from the returned coordinates from the getpos command. I used the stock BIS models to check it and found that when on a level surface such as a runway or over water the distance between the COG point and the getpos point is constant regardless of the vehicle's pitch. The displacement also only ever occurs in the 'z' direction. It has a finite value which is different for each vehicle and doesn't change. Incidentally for the stock BIS AH1 Cobra the value is 1.94123 meters. You can see this in the demo mission provided below. Download the file and place the two cylinder addons in your Res/Addons folder. They're needed to prove the point. Demo Mission So what's the point of all this? Basically it means you can now get a reference directly to the vehicle's COG which means you can reliably set other objects in relation to the vehicle's frame regardless of pitch by using some trigonometry. You could actually do this anyway by using the drop command but the results are quite unstable and very unsmooth which you can see if you try it, because any objects you set with this method will start to warp when the target vehicle builds up speed. I think this is caused by lag due to the fact that the commands are not all kept in one place. You have to bounce back and forth between two scripts to get coordinates from the drop command. Anyway this is an easier and much more reliable method too. It opens the gate to being able to script extra things stuck onto the side of existing vehicles. For example you could make an object with an animation phase which rotated it 360 degrees in the pitch direction. Then set it a desired point in relation to a target vehicle (the underneath or side of a helicopter for example), get the target vehicle's pitch, set the stuck on object to the correct animation phase to match the target vehicle's pitch, and then using this new data place it correctly in relation to the target vehicle's frame/COG. The stuck on object would appear to be perfectly fixed to the target vehicle. That's just one use. I'm going to do some more work over the weekend on it. I once discovered that with a fast enough update time and some neat code geometrical interactions between objects' geometry LOD's are quite accurate. You can see this for yourself by placing a heli on the map and then scripting a custom made object with a simple geometry LOD to rise into its tail by small distance increments at a fast update time per execution cycle. The results are very believable. This could potentially mean that vehicles and such like could be held in mid-air by lots of tiny spheres or rods placed in relation to their frame so they were all just touching their geometry LOD. Basically it is potentially the birth of reasonably sophisticated setpitch function for OFP, something which has eluded us for years. To be frank I wonder why I'm doing this because you can simply buy ArmA for less than 20 quid now and use the setvector command to do the same thing with much less hassle. I think it might still yield something interesting though which could possibly have ripples into even ArmA's engine as it shares much with OFP. Anyway if nothing else it could at least be used to make hitching scripts look more realistic by having their rope addons stay at the right point on the lifting vehicle's frame as it pitches. Apologies if this has been done before, but I hope it helps someone

Incase anyone's interested this is the closest I could get to making this a reality. Rising increments have to be kept very low. Anything above 0.001 is very unstable. Here's a demo mission anyway Lifting Demo Mission

Lol done a load of work on this, this weekend and there's no chance of using even this to create setpitch function in OFP. The collision resolution and interpenetration resolution is far too chunky. When I placed a cylinder with an identical geometry LOD to its 0.000 LOD beneath a Cobra and raised it slowly the heli did indeed respond but not gently. It responded with ever increasing magnitude due to over penetration into the cylinder as it was being raised. It began to bounce. Attempting to place other cylinders around the aircraft to stabilise it simply produced more magnified bouncing effects and some seriously unstable behaviour. It appears the game engine is rendering the appearance and position of the vehicle frames far more frequently than it is resolving collisions and interpenetrations. This I believe includes things such as velocities and accelerations which makes matching geometrical changes to physics in a believable way nigh on impossible even by my own tediously detailed standards. It behaves a bit like the stiff spring problem common to all normal frame-rate simulations that you can realistically run on a home machine but much more exaggerated. In simple terms vehicles are being given velocities and position changes much more often than collisions are being checked for. I suppose it's possible that Bohemia couldn't even have made OFP back in 2001 if they'd built in a very accurate and high resolution physics engine with high resolution collision detection and interpenetration resolution. Given the size of the maps each run of the game loads, and the amount of vehicles present on each map, it probably would have slowed down to a crawl even a very fast machine for the day. I proved this to myself by watching the rear end of the cobra bounce up and down off the cylinder with gradually increasing magnitude and interpenetration. I suppose that's why when the game first came out we could run through walls and such things when playing infantry although Bohemia seemed to greatly improve that when they released the resistance patch. Setpitch without hacking the engine code? Forget it. Even if, like me you still love playing around with old engines to boost your general coding understanding and physics skills (and to just generally see how far you can take something) you're still far better off expending your efforts on something more fruitful than this. Now I can go and have a nice cup of tea and begin thinking of the next thing to have a look at

Thanks for the replies that will have saved me alot of time indeed. I suspected OFP might not like the method and would not behave as one would expect so thanks for confirming that as I would have spent god knows how much time learning that for myself. Lol great minds think alike, as I read your point about using the drop command to properly place the spheres it is something that I have just written down in my notes only this morning! I'll go for doing it in ArmA instead then, sounds like a far better solution indeed. @GB, that is indeed what I was thinking of doing. Using a plane or helicopter derived from the base class with as much turned off as possible. I've tried using commands on static objects and I don't think it reacted too well. Great replies, many thanks to you all. *Edit* Thanks vektorboson for the info about the inertia tesnor too and its relation to the COG that's helped alot.

Dear All, Hi just need some advice on a basic physics engine type question for something I'm making in OFP and might port to ArmA. Firstly I will point out this is not an attempt to try and be clever or show you how smart I am or anything like that I just genuinely need some help on a physics concept. I don't want to say what it's for, or the thread will attract replies that will send it O/T. So here goes: I want to simulate applying a force to an object. Obviously there is no way of doing this directly in either engine with the commands we have access to as private editors. I know ArmA has a new vector command and the like but I want to get the principle functioning in OFP first before looking at ways it could be done in ArmA. I'm going to try a method I thought of which uses what I call impact spheres. I make a small sphere in O2 and give it a mass. Then I place it very near to the object I want to apply a force to, say a stationary truck for example. Then I time the execution time of one cycle of the script I'm going to use. This would have to be done on another occasion. Then I work out the force I want to apply to the truck, whether it be acquired by calculation or just some arbitrary value for testing purposes. So I now have: 1)My desired force to apply to the truck. 2)The time interval between code executions. 3)The distance of the impact sphere from the truck. 4)The initial velocity of the impact sphere which is zero. If I use the desired force and the sphere's mass placed into the f=m*a formula then I can acquire the required acceleration I'd have to give the impact sphere to simulate the application of the desired force. That's all very nice but it means nothing because there's no way to apply an acceleration directly to an object in OFP. So if I take the time interval between execution times (or script frame-rate to give it a different term) and then input the relevant known information for acceleration, initial velocity and time into the following equation of motion: a=(v-u)/t ..then I can re-arrange it to give me the value for v. This would be the final velocity after time t if an acceleration of magnitude a had been applied. So if I work out the required end velocity I think that means I can give the impact sphere a setvelocity push that will mean it arrives at the truck's geometry LOD with exactly or almost the correct final velocity value v. This would mean that mathematically speaking the force I'd simulated giving to the impact sphere would now be transferred to the truck. I know some of it would be lost due to equations relating to drag in the game's engine but if the distance were small this would have a negligible effect. So in theory it's sound. But I could do with someone with a better grasp of physics to confirm this for me. Will it work in the OFP/ArmA engine though? Essentially I'm imparting momentum to the truck by giving something with a known mass (the sphere) a velocity and then colliding it with an existing vehicle. Odd engine behaviour could be worked around however by using experimental tests to alter the applied setvelocity push to the sphere to give the correct results. It would need the engine to perform reliably though, even if it doesn't perform realistically, which I suspect might be the case. As I said I'm not trying to be a smartass I just think this is a really good idea but I want someone to back me up in my theory assumptions before I go on a wild goose chase. If anyone can offer a bit of help with the above question please do so as this is a bit of a new area for me. Many thanks

A rotation is exactly what I'm after mate. I can simulate lift, drag and thrust using the setvelocity command. The game physics engine book I'm reading taught me how it's done by the engine. Basically all the forces are calculated by the engine and turned into an acceleration depending upon the object's mass ('m sure you guys prob already know this). Then they integrate to get a velocity and then use the frame-rate time measured from the last frame inputted into the speed, distance and time equation to get the object's new position. It's updated in either the current or next frame. So basically an applied force simply drops out as a positional update which the general game engine renders. Obviously I can't get that close to the OFP engine so I'll have to settle for turning a force into a velocity and applying it to an impact sphere. This instantaneous applied velocity gives the impact sphere the exact momentum that it would receive due to the acceleration caused by the applied force. Then if all holds well the impact sphere hits the object (read aircraft) and transfers all that gained momentum to the object being hit, thus simulating the direct application of the applied force to the target object. Looking ahead I can see the following issues and notes arising: 1)Given that the impact sphere will have to travel a short distance before hitting the target object, it will obviously lose some of the applied velocity from the setvelocity command before hitting the target object (t/o) due to drag applied by the OFP engine. This will cause slightly less force than desired to be imparted to the t/o. Not such a bad thing, infact it will probably help with stability - and I'll need plenty of that with this comedy circus of a method. 2)Simulating an applied force due to a control surface such as an elevator attempting to change the t/o's pitch could be more easily simulated by applying the impact sphere force somewhere else on the t/o's body. For example an elevator on the wing trying to pitch the t/o up could be more easily modelled by using a very small force underneath the aircraft's (I'll stop beating about the bush now) cockpit right at the nose. Given the greater distance from the Centre Of Gravity at the nose compared to the wing a much smaller force could be applied to give the same turning force due to the increased distance from the COG. This would bring impact sphere velocities right down and reduce potential issues of the aircraft sustaining damage from the collision. 3)Point 2) could be further improved by having two impact spheres operating in tandem to further reduce impact velocities. 4)The time interval had me scratching my head to begin with. I mean what did it actually represent? Obviously it had to be there but what was it all about? Well the applied force basically as already stated results in an applied acceleration to the impact sphere. Naturally the best time interval to choose between updates is the length of time it takes the script/function to complete which I hope will be small. Great so I now have a time interval, but still couldn't figure out what it meant. The time interval is obviously used to predict the size of the setvelocity push to apply and it dawned on me in the end that the time interval represents the length of time the force is applied for and thus the amount of momentum the impact sphere accrues before hitting the t/o. Force is what's being applied but momentum is the stuff that's actually moving around. The longer the predicted and calculated time interval the force acts for, the greater the change in accrued momentum and thus the larger the calculated setvelocity push and the larger the magnitude of reaction that eventually occurs in the t/o when the impact sphere hits it. I suppose you could think of this time interval as the script's 'resolution'. Obviously in the real world this time interval is infinitely small but in the realm of computer's and frame-rates and script execution times it starts to get potentially problematically big. If it became too large then the behaviour of this script and the resultant changes in the t/o's behaviour could get very chunky indeed so it needs to be kept as small as possible. I eventually decided to think of the time interval and setvelocity magnitude as the final velocity the impact sphere would accelerate to over this time interval with the desired applied force. Put another way: if the script executed too slowly the simulated applied force would act for too long and the momentum build up would become too big and the behaviour of the t/o would become too dramatic. So there's the idea anyway. Lift, drag, gravity and thrust can be done by using aerodynamic calculations to work out what force to apply then turning this force into an acceleration and then finally a velocity which can be applied using the setvelocity command in the correct resultant direction. Rotations can be effected using this impact sphere method which will in turn alter the pitch and bank of the main active parts of the aircraft (the wing and the engine) through calculations performed by the OFP engine upon the occurrence of these mini collisions. Then the next update simply looks at the orientation of the aircraft after the OFP engine has done its rotational magic on it and then re-evaluates lift, drag, gravity and thrust forces again as a result of these orientation changes. User inputs are checked and if present applied again by using the impact sphere method to apply the required rotation forces caused by aileron, elevator and rudder movement plus any inputs to the turbines. Bugger if I can get it to work I can even simulate jolt forces caused by firing cannons at ground targets. I also thought that if a stable working version of it can be made (I'm really not sure how likely that is?) then a more advanced drag force could be applied by relating the aircraft's orientation to its velocity vector and computing how much of its surface area is perpendicular to its velocity and thus altering drag accordingly. Naturally there is no way a generalised version of this could be made. A separate tailored version would have to be made per aircraft and it will involve detailed analysis of the aircraft in O2 with regards to its COG location and the starting point of impact sphere location. Furthermore it's possible that a very accurately distributed weight model might be needed in O2 rather than simply selecting every vertice and simply applying a portion of the total mass to each which I think it what probably happens with most addons including the default Bohemia ones. With this firmly in mind I need a really well known and freely documented aircraft to start work on for which an addon has already been made for in OFP. I was thinking of going with the A-10 unless anyone has a better suggestion? The first task will be to work out the aircraft's weight distribution and build something in O2 which is fairly close to it. Thing's such as changes in COG due to emptying fuel tanks will simply have to not be modelled as I doubt COG changes are modelled by OFP/ArmA's engine due to such things. The next thing will be to acquire a reasonable set of equations (even if somewhat simplified) relating velocity to lift force for the wing profiles of the chosen aircraft, and also for the thrust it puts out and the drag and turning forces caused by aileron and elevator and rudder deflection. Then I'd have a pretty good mathematical flight model coupled to a reasonably good physical game engine .p3d model of the chosen aircraft. I've put a lot of thought into the initial theory behind this and the work in that department is pretty much done now. All that remains is to see if the impact sphere method will work in practice. Potential snags of doing this in OFP include: 1)Some general engine problem/limitation which rejects or makes otherwise impossible the impact sphere method such as varying degrees of accuracy due to integration problems or badly implemented collision detection/resolution. Perfectly possible with the OFP engine from what I hear. 2)Unwanted interference from the general game engine such as that which causes helicopters to gain height often unwantedly when flying over varying terrain heights. Should issues of this nature occur they could probably be overcome by some crafty manipulation of the vehicle class instance. So yes to be honest I'm building a flight simulator in OFP. Reason being is I have a very big project lined up in coming years for a personal game adventure (not OFP/ArmA related) and I want to learn as much as I can about building my own flight simulator on a platform I'm familiar with to facilitate doing it in my future game. For those who are curious I'm going to use Kegety's FWatch to take user inputs to make the aircraft's behaviour completely customizable so there's no nasty interferences with the default game inputs for planes. If this method really does work then it could be used for helicopters too and potentially lots of other things. I'm going to stick with the simple truck on runway test to start with though and learn all I can about the impact sphere method before applying it to something this complex. I'll simply fire impact spheres at it until I can get predictable results. Thought I'd share it with you especially seeing as I know the two people who have replied in this thread so far very well and I know you're good people who have a genuine interest in learning about this kind of stuff and helping others. As I said I'm not trying to be a smartass I've just had what I think is potentially a really good idea. If anything I've said doesn't make sense and you want a better or different explanation please ask and I'll respond again. I'm going to need quite a bit of help with a few things before this is over (if it ever is). Thanks

No matter guys I figured it out last night at work

Completed the Silverstone Half Marathon on Sunday just gone in 2:07:39. Here's a pic of me crossing the line: It weighs 10 kilos all in. Still taking donations here for Cancer Research, and I've yet to reach my target: Fundraising Link Many thanks to anyone who donates

That's a very good idea. I thought using the webbing would be better than a rucsac for me because it would hold the weight all around my body not just on my back. Sounds like your weighted vest does a similar thing

Hi, Not really to be honest I did loads of training without weights and then just a couple of runs wearing it to make sure I could do it on the day. Was buggered by the end though. Everything was fine but the last 3 miles were purgatory. There was a guy there running with a 30kg fridge on his back, now that's insanely heavy!! Spoke to an ex-army chap who said running with a rucsac and adding sugar bags to it is a good way of building tolerance to running with weights. I've got some webbing so I'm going to start doing that and gradually build it up as I've got more crazy stuff planned in the future of this nature!!

They are killable. They are undead and they can be killed with flashbangs. Two should be enough Found this out when running from one of them for the second time and I flashbanged him again. Suddenly realised I wasn't being pursued anymore and when I turned round he was flat out on the floor face down Mine would be: Thief Deus Ex System Shock 2 Fear Hitman (the jungle level) FarCry Rogue Spear (multiplayer) Aliens Versus Predator (having to confront facehuggers as a marine) Operation Stealth (Amiga) Darkseed (Amiga) Another World (Amiga) Wings (Amiga) Flames of Freedom (Amiga - a brilliant ArmA/OFP mod of this could be made) The list goes on, and on, and on

Oh dear, it is really that bad? Are you sure you shouldn't give it a second chance?

Hi lads, I've long since decided I will never be a programmer but I did have some succes with Flashpoint scripting and I was wondering how good ArmA's collision detection and AI routing is as I might buy it and get back into the scripting scene if it's any good. Couldn't get on with things in flashpoint like AI not running upstairs and the like, so how does ArmA fair in comparison? Is the AI easier to maniuplate, even if it has to be done directly with scripts? Or is ArmA bascially Flashpoint but prettier? Thanks in advance for any help offered, pm me if you want

Looks amazing! How the hell does it work? I assume all that M stuff is matrix multiplication? Could you explain it a little more if you can please? Sorry to ask but it really does look the business and I'd like to know more about it