Jump to content
Bohemia Interactive Forums

Prospero

Member
 View Profile  See their activity

  • Content Count

    478

  • Joined

  • Last visited

  • Medals

Posts posted by Prospero

  1. Posted

    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"wink.gif 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.

  2. Posted

    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

  4. Posted

    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

  5. Posted

    </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

  6. Posted

    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

  9. Posted

    </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!smile.gif

    Prospero

  12. Posted

    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

  17. Posted

    </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

  18. Posted

    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

  19. Posted

    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

  22. Posted

    </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.  sad.gif<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

  23. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Spitfire @ Oct. 15 2002,20:00)</td></tr><tr><td id="QUOTE">Still, I would kill for setPitch/setRoll -functions wink.gif<span id='postcolor'>

    I've been banging on about that for about a year;)

    From (old) ProSphere readme:

    ; ProSphere Controller v1.0 for Bohemia Interactive Software's (BIS's) battlefield simulation "Operation Flashpoint" (OFP) & related software.

    ; What is ProSphere Controller?

    ; ProSphere Controller (or just "ProSphere") is a "tool" for OFP gamers, mission editors, and add-on creators. Simply put, it allows you to interact with the OFP Game World in ways that were previously impossible.

    ; ProSphere exploits a number of "tricks" within OFP to SIMULTANEOUSLY provide FIVE(*) fully independent, configurable, high-bandwidth, high-resolution, REAL-TIME axes of keyboard control input using the "main" game key assignments, and ALL DIRECTLY ACCESSIBLE to your OFP scripts via global variables. ProSphere therefore obviates the problem of very slow control input associated with laboriously selecting actions from the Action Menu (which is slow even when using automated macros, as is, albeit to a lesser extent, the Dialog method of input introduced in OFP v1.75). You can of course still use the Action Menu in the normal way for control input that does not require speed & resolution. Furthermore, you can combine ProSphere input with Action Menu input and / or Dialog input. The result can be very powerful.

    ; Applications of ProSphere can be anything from simple interactions, like being able to walk up to a wounded squad-mate and quickly heal him / rearm him / share equipment & data with him, to manipulating multi-axis in-game 3D switches, to locking / unlocking / positioning doors, to throwing objects from vehicles, to controlling a real-time safe-cracking puzzle, to implementing complex in-game 3D menus, to placement systems for setting and planting explosives, and even to advanced concepts such as controlling your own real-time (scripted) physics models. This, in fact, is why I developed the software in the first place - to provide a means of controlling a helicopter UAV flight maths-model I had implemented in OFP's scripting language, and which I had "attached" to an object in the OFP Game World. I needed at least four script-accessible REAL-TIME ANALOG axes to control the helicopter UAV effectively - and an early version of the ProSphere concept proved the answer to this somewhat thorny problem. I then realised that the interface I had devised could be developed further to provide a rather nice feature for other OFP enthusiasts. ProSphere Controller v1.0 was the result.

    ; (*) In fact, ProSphere provides not FIVE axes, but SIX. However, a limitation is placed upon the use of the sixth axis (the ProSphere C-Axis), which is this: Manipulating the C-Axis at the same time as attempting to manipulate the X-Axis will have the effect that manipulation of the X-Axis is overridden. Practically speaking, it is unlikely that this will matter in the majority of cases, but do bear it in mind. This limitation is simply a consequence of what can / cannot be achieved in OFP scripting - but of course, in a perfect world I'd still like to find a work-around for this.

    ; ProSphere provides in-game 3D graphical "Items" to facilitate user interactions. A separate readme file is included with this distribution which explains what ProSphere "Items" are and how to use them. A demonstration mission is also included, and I highly recommend you take a look at it to start with.

    ; If you are using the default OFP key assignments, the ProSphere Axes are controlled as follows. If you have changed the default keys, then you use whatever you have assigned instead:

    ; OFP Command Key(s) ProSphere Axis Global Variable Name

    ; ------------- ------ -------------- --------------------

    ; Strafe right Right Arrow or D X-Axis + PSX

    ; Strafe left Left Arrow or A X-Axis - PSX

    ; Forwards Up Arrow or W Y-Axis + PSY

    ; Backwards Down Arrow or S Y-Axis - PSY

    ; Up Page Up or Q Z-Axis + PSZ

    ; Down Page Down or Z Z-Axis - PSZ

    ; Look right Keypad 6 A-Axis + PSA

    ; Look left Keypad 4 A-Axis - PSA

    ; Look up Keypad 8 B-Axis + PSB

    ; Look down Keypad 2 B-Axis - PSB

    ; Turn right C C-Axis + PSC

    ; Turn left X C-Axis - PSC

    ; Fast forwards E Toggle MoveLock PSplayermovelock

    ; In DIGITAL Mode, a ProSphere Axis provides the specific values -1, +1 or 0 as the centre point.

    ; In ANALOG Mode, a ProSphere Axis provides a floating point number in the range -1 to +1 with 0 being the centre point.

    ; Note that for a straightforward _immediate_ DIGITAL response, set the desired ProSphere axis mode to DIGITAL, and its deflection speed to 1.

    ; PSplayermovelock is either 0 for OFF or 1 for ON.

    ; ProSphere Axes may also be controlled by using a SUITABLE PROGRAMMABLE mouse. I am hoping to include a suitable freeware / shareware programmable mouse driver with this distribution at some stage in the future. It must offer driver-level keyboard emulation to work with OFP. If the demand is there, I may write one myself.

    ; ProSphere Axes may also be controlled by using a SUITABLE PROGRAMMABLE joystick such as the new ThrustMaster Cougar.

    ; You will need to create / load an appropriate profile into your particular joystick / joystick driver. I am hoping to include a suitable profile with this distribution at some stage in the future. PLEASE NOTE that this version of ProSphere is NOT really suitable for "absolute" modes of operation via joystick. This is high on my list of things to address, but I will first have to wait until I have a Cougar with which to test.

    ; The response of each ProSphere Axis is fully configurable (see below).

    ; ProSphere's response is identical regardless of which vehicle (if any) the vehicle player happens to be occupying.

    ; ProSphere's performance is unaffected by the pace of Game World Time (the setAccTime function etc).

    ; ProSphere adds one (and only one) action to the player's Action Menu - the ProSphere ON / ProSphere OFF action (toggle). It will always be the first action in the Action Menu list. Once you toggle ProSphere ON, you'll get access to the ProSphere sub-menus. Toggle ProSphere OFF at any time to return to the standard Action Menu.

    Prospero

    (Please bear in mind that this is an old version).

  24. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (TYsiEK @ Oct. 15 2002,19:18)</td></tr><tr><td id="QUOTE">Can i use some rotate vehicle action in your script ? I think about rotation of helicopter when i press "X" and "C" . It's very needed for flying in helicopter mode.<span id='postcolor'>

    Yes, you can use X & C - they form one of the axes. What you choose to tie to them is up to you. So if you use an accurately timed setDir loop on your Osprey, this will probably give you what you want (rudder/yaw).

    Be aware that setDir will set pitch and roll to zero by default.

    The other axes are (with default key assignments):

    W/S

    A/D

    Q/Z

    PAD4/PAD6

    PAD2/PAD8

    E - special toggle key.

    ... and perhaps some other fun stuff.

    Edit: Oh, and of course the Cursor/Arrow Keys also work instead of W/S and A/D. In fact this works better, as OFP has trouble with three keys pressed simultaneously if they are all "alphabetical" keys.

    Prospero

×