Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Colonel_Klink @ Oct. 19 2002,13:11)</td></tr><tr><td id="QUOTE">Excellent discussion, guys. Does anyone  know how to make the animation run indefinite (foreaver), or a tleast until a command to stop is given. Then perhaps another command to start again from the last stop point. Just a thought.<span id='postcolor'> Yes, I'll try to post the code later today (I'll base it on rads - you can always change it to mils if this turns out to be incorrect). Right in the middle of some addAction stuff right now. Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Colonel_Klink @ Oct. 19 2002,13:11)</td></tr><tr><td id="QUOTE">Excellent discussion, guys. Does anyone  know how to make the animation run indefinite (foreaver), or a tleast until a command to stop is given. Then perhaps another command to start again from the last stop point. Just a thought.<span id='postcolor'> Yes, I'll try to post the code later today (I'll base it on rads - you can always change it to mils if this turns out to be incorrect). Right in the middle of some addAction stuff right now. Prospero

Yup, what I was getting at is this: Say, for example, I want to rotate something by 180 degrees using the Animate command... If I think it's expecting radians, I'll specify a value of 3.14 (pi) If I think it's expecting mils(/1000), I'll specify a value of 3.2 Problem is... which is it? They're relatively close... so it's hard to tell. I know that the various sample configs available make it look like mils, but elsewhere BIS seem to have used radians. So, my question still stands. I'll pray that someone from BIS can spare one word - "mils" or "radians" Otherwise I'll have to conduct an in-game experiment that'll probably take me half a day;) Hey I'm a perfectionist... I don't care;) Prospero PS: And by the way, there are 6400 mils to 360 degrees, not 64000 mils.

Yup, what I was getting at is this: Say, for example, I want to rotate something by 180 degrees using the Animate command... If I think it's expecting radians, I'll specify a value of 3.14 (pi) If I think it's expecting mils(/1000), I'll specify a value of 3.2 Problem is... which is it? They're relatively close... so it's hard to tell. I know that the various sample configs available make it look like mils, but elsewhere BIS seem to have used radians. So, my question still stands. I'll pray that someone from BIS can spare one word - "mils" or "radians" Otherwise I'll have to conduct an in-game experiment that'll probably take me half a day;) Hey I'm a perfectionist... I don't care;) Prospero PS: And by the way, there are 6400 mils to 360 degrees, not 64000 mils.

Spitfire said: "If Prospero's ProSphere can do even half of what he is promising, I'll definitely make it use keyboard as the controller." Believe me, this isn't vapourware:) I think I may have to give myself an extra week though to polish it. Right now the axes all work perfectly (and identically, regardless of your PC's performance), but it needs a 3D graphical setup mode, so that you can have visual feedback on exactly how the axes are responding - looking at a set of rapidly changing numbers and the incessant beeping of the Hint command run at a high rate aren't.. well.. cricket. The other thing I need to do is to get the Player MoveLock toggle (the E key - when ProSphere is enabled) working on the press of the key, rather than the release. It's little things which make a big difference. So, I'm going to be generous to myself and say NEXT Sunday, not this coming Sunday. Prospero

Hi all, This is for you chaps who get excited about the issue of timing in OFP. I know I do, since it's so fundamental to the sort of stuff I like doing (upcoming ProSphere script included). From my experiments, I suspect that if sufficient load is not being placed on your processor by OFP - and yes, this can happen, especially if you're just tinkering around with your scripts on the Desert Island - it can play hell with your timing / physics. Why? Well, put this case: You have a script that uses a fast loop - and I'm talking about a fast loop, because, let's face it, invariably we'll be trying to do things as fast as possible. So, let's say that we therefore specify a very small delay like ~0.001 or even no delay whatsoever. Now, if OFP hasn't got a lot to do at the time, it can be that OFP will run your loop several times registering no increase in the value returned by the Time function within that loop. This is a bit of a nightmare if you're performing a physics calculation based on a calculated time interval (which we'll call "dt") because, in such cases, your dt will be 0 (zero). This means that your dx/dt, dy/dt, dz/dt etc all suffer from divide by zero errors. Now even it it were possible, I wouldn't want to stuff conditions in to prevent errors (very slow), and besides it's bloody ugly. Ideas, chaps? Prospero

Many thanks Suma. That's what I will use from now:) It's so hard to know from an outsider's POV what one should do in this sort of case. Thanks for the response. Prospero

I'm sure that this must be on BIS's list of improvements. Certainly I would say it would be the single most influentual development for both single and multiplayer OFP. Right now, (with v1.85) you can do velocity matching via script, which is theoretically very easy, but there are lots of other scripting issues you have to overcome to carry this out invisibly - which is why most people dislike scripts - they simply don't do complex stuff really "well". This of course would improve with the ability to precompile scripts, which seems to be something BIS _are_ thinking of doing, bless their cotton socks;) Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Bart.Jan @ Oct. 18 2002,17:13)</td></tr><tr><td id="QUOTE"></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #start ~0.001 ?_change==time:goto "start" ;your calculations _change=time goto "start"<span id='postcolor'><span id='postcolor'> Bart's first example is what I currently use. I rationalize this by saying that although I am adding a condition, I am also removing one (by specifying no delay like ~0.001 - which is itself a condition). That's the way I rationalize it, anyway. Dinger - I'm really not sure. But I do know for certain that simply inserting a Goto between two successive Time function calls isn't by itself sufficient to ensure that they will not produce identical times, and hence you cannot ensure that dt will not be zero. Edit: Well, Bart's example isn't exactly what I use. I believe this is possibly slightly better (after extensive testing): _ot = Time #lp _nt = Time _dt = _nt - _ot ?(_dt == 0): goto "lp" ; Calculation here based on the timestep _dt. _ot = _nt goto "lp" Further edit: Heheh this has got a bug in it too, but at least it's not in the loop. The bug is that the first time _dt is calculated, it could be 0. But it's outside the loop, and won't ever be used as a divisor. Prospero

Hi - a quick note regarding the v1.85 patch. setVelocity takes a vector! i.e: myplane setVelocity [10, 20, 30] Now carrier takeoffs and landings are possible;) As is throwing things, as is jumping! Hell, loads... Also, for example: _myvector = getVelocity myplane Edit: Awwwwwww it doesn't appear to work on men... I guess jumping's out then:( Prospero

Scroll down to "Proxy objects - and interaction" (on this very board... on this very page...) Prospero

Scroll down to "Proxy objects - and interaction" (on this very board... on this very page...) Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Prospero @ Oct. 16 2002,23:29)</td></tr><tr><td id="QUOTE">Well, what I was getting at is this (I should have explained it better): Say I want to round a number (let's say to three decimal places). I could just use: _x = (_x + 0.0005 - ((_x + 0.0005) % 0.001)) This rounds _x up perfectly well if _x is positive. But instead, let's say _x is negative. Now, I really want to round down rather than up (for the sake of symmetry), so I use this: _x = (_x - 0.0005 - ((_x - 0.0005) % 0.001)) The problem is I have to test _x first (with a condition) to see if it is positive or negative, and conditions are very slow in OFP. I'm trying to do it without using a condition - in order to speed things up. Any ideas, chaps? Prospero<span id='postcolor'> To answer my own question: Yes there is a way to do this - you simply avoid rounding a variable when it goes negative in the first place! Just add an integer value to it large enough that the variable will always be positive. Now do the rounding. Then subtract the same integer from it to return to the original negative value. Nice eh? Now you can round symmetrically without an extra (slow) condition. The controller script should be ready Sunday. I have one further question: Here's a typical cameraEffect command: mycamera cameraEffect ["internal", "back"] Can the cameraEffect command be used with options like "gunner" and "driver" though? I've tried, but the game seems to like crashing;) If I do something like this (where aP is the name of a soldier)... aP cameraEffect ["internal", "back"] ... the camera is placed at the soldier's feet. That's no good! Prospero

Edit: :counts on his fingers:.... But if you rotate something by 3.14 radians, it is rotated by 180 degrees (approx to 1 dp) by very definition... How does that prove this? Prospero

Edit: :counts on his fingers:.... But if you rotate something by 3.14 radians, it is rotated by 180 degrees (approx to 1 dp) by very definition... How does that prove this? Prospero

Well, what I was getting at is this (I should have explained it better): Say I want to round a number (let's say to three decimal places). I could just use: _x = (_x + 0.0005 - ((_x + 0.0005) % 0.001)) This rounds _x up perfectly well if _x is positive. But instead, let's say _x is negative. Now, I really want to round down rather than up (for the sake of symmetry), so I use this: _x = (_x - 0.0005 - ((_x - 0.0005) % 0.001)) The problem is I have to test _x first (with a condition) to see if it is positive or negative, and conditions are very slow in OFP. I'm trying to do it without using a condition - in order to speed things up. Any ideas, chaps? Prospero

The controller script uses slight rounding of numbers to smooth things along. At the moment, I use this sort of thing: _x = (_x + 0.0005 - ((_x + 0.0005) % 0.001)) But it isn't perfect. Anyone got something better? Really would help speed things along... Prospero

The Osprey looks very nice. Well done. I look forward to flying it:) My controller script is being tweaked to take advantage of the new features in v1.85. But I'm not going to promise anything before the weekend. I want it to be absolutely bullet-proof and as efficient as possible. Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Suma @ Oct. 16 2002,12:15)</td></tr><tr><td id="QUOTE">LoadFile is slightly faster, but both of them can be considered slow, as both of them require file access (which is also true for exec).<span id='postcolor'> I always suspected this from my empirical tests, but many thanks for confirming it, Suma. That's very helpful. I suspect I am correct in saying that calling scripts from the Drop command also depends on file access, and is therefore similarly relatively slow. Thanks again Suma. Prospero

This may be something to do with the car going "inactive". Try staying in the car (you, as the player driver) - this will keep the car "active". If this doesn't work, well, I'm not sure because I haven't tried this yet. Only done lifting platforms with setPos so far. In fact I'm sure animate will work for this. Anyway, try the above first. Prospero

This may be something to do with the car going "inactive". Try staying in the car (you, as the player driver) - this will keep the car "active". If this doesn't work, well, I'm not sure because I haven't tried this yet. Only done lifting platforms with setPos so far. In fact I'm sure animate will work for this. Anyway, try the above first. Prospero

Any idea which is faster? Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Dinger @ Oct. 15 2002,19:58)</td></tr><tr><td id="QUOTE">but I can't get "Dammaged" to work,<span id='postcolor'> Me neither. Hit and Killed are ok though. Prospero

Hi chaps, Well, I suspect that I'll have to figure this one out myself, but anyway... Proxy objects - how much interaction do they have with the game - geo collison detection / fire geo collison detection? Are they destroyable separately from the object to which they are a proxy? Post all you know. That includes those of you jealous of the very little knowledge you have managed to acquire. Prospero

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (GAMEER_77 @ Oct. 15 2002,21:18)</td></tr><tr><td id="QUOTE">So Prospero, is the "ProSphere" an application? Or is it using code from OFP itself? Please tell us more because im racking my brains as to how your doing this. Â <span id='postcolor'> It's embarrassingly simple. When you see it, you'll kick yourself. I don't mean to be a tease, but I just want to get it as good as possible before releasing it. It's simply a script, well, set of scripts. It is not a hack. Prospero