Prospero

Colonel Klink, Damn it, I still get the very same error - new objects - new config... damn! 1) Is there some additional thing I'm missing? Do you have to have the proxies in the Memory LOD, for example? 2) Could you possibly post your entire config for your house? I would be SO grateful:) Edit: 3) And which PBO compiler are you using? How frustrating! Prospero

Colonel Klink, Damn it, I still get the very same error - new objects - new config... damn! 1) Is there some additional thing I'm missing? Do you have to have the proxies in the Memory LOD, for example? 2) Could you possibly post your entire config for your house? I would be SO grateful:) Edit: 3) And which PBO compiler are you using? How frustrating! Prospero

Saturday afternoon and I'm just about to have a go at it again, Col Klink. Thanks for that response. It's odd because that is precisely what I've got too... but I think I know what's wrong... I was playing around with some 'unusual' models... One thing you might try - change the simulation type to "house". Just a thought if you haven't got it working yet. Then again, it may be that proxies must be of sim-type "alwaysshow" as they are part of CfgNonAIVehicles - who knows? Prospero

Saturday afternoon and I'm just about to have a go at it again, Col Klink. Thanks for that response. It's odd because that is precisely what I've got too... but I think I know what's wrong... I was playing around with some 'unusual' models... One thing you might try - change the simulation type to "house". Just a thought if you haven't got it working yet. Then again, it may be that proxies must be of sim-type "alwaysshow" as they are part of CfgNonAIVehicles - who knows? Prospero

Certainly a VTOL class would be a nice addition to OFP. However, if the new setVelocity and getVelocity commands employ a 3D vector, and override the defined simulation model in an elegant fashion, one may be able to produce some reasonably nice results via scripting. I can see all sorts of complications though, but I'm still hopeful (and will be trying this when v1.85 comes out). My really big plea to BIS (and yes, it's an outrageous request, I know), is to develop OFP further (or OFP2) to support user-defined simulation models. The result would be... well I do not have words... Scripts by themselves just aren't fast enough / sufficiently integrated into the game-engine timing structure to implement new flight models. I know. I've tried. With some success, but... I wouldn't release these as public addons. This said, a worthwhile interim compromise would be to support setting pitch and roll via script. Prospero

---------- _clock = Time _oldtime = _clock #loop _nowtime = Time _timestep = _nowtime - _oldtime ; Do physics calculation here, based on the time step. (Edit: There is really nothing very much you can do to adjust for the time it will take for this calculation, but at least the "error" isn't cumulative over multiple loop cycles, and is likely to be pretty "constant"). _clock = _clock + _timestep hint format ["Clock %1\nTime %2\n", _clock, Time] _oldtime = _nowtime ~0.001 goto "loop" ---------- I think this answers my own question. Hehehe I'm so dumb! Prospero

Smooth edges should do it for you... Prospero

Smooth edges should do it for you... Prospero

---------- #loop _timestep = Time - _oldtime _oldtime = Time goto "loop" ---------- Can the middle two lines be reduced to one? And can the interpretation of one single line be interrupted? Edit: I better add why I'm asking this. OK, imagine the following scenario: ---------- #loop _timestep = Time - _oldtime <The OFP game engine now goes off and does something really time consuming> _oldtime = Time goto "loop" ---------- Result is buggered timing for one's scripted physics. Prospero Further edit: Yes, some people may ask, "But since you can't guarantee that a setPos will be carried out directly after the time interval is calculated, what's the point?" Well the point is that although you'll get an "inaccurate" update of your physics setPos due to this unavoidable fact (in terms of timing/velocity), the error will be taken into account next cycle. I.e. the error is not cumulative if this problem can be solved.

Interesting stuff. Any chance of implementing interrupts in scripts? (OK... I'm joking... well... maybe not...). Regarding the loop delay (~0.00001): surely it is largely inconsequential (ok, up to a point), because commands executed within a timed loop have varying priorities? Or... perhaps they all have relatively low priority? I've partcularly noticed this when attempting to implement objects with my own scripted physics models. It would be lovely to get visually "smooth" results, but unless I could perhaps sync to the frame rate via an interrupt, things always jitter a bit. I fully realise that OFP wasn't designed to support this, but hey, I like playing with this stuff. Prospero

Well, today I didn't have a lot of coding time, but I'm still crashing my computer a lot;) Maybe tomorrow.. (as the Eagles once sang) Have you got it to work yet, Col Klink? Prospero

Well, today I didn't have a lot of coding time, but I'm still crashing my computer a lot;) Maybe tomorrow.. (as the Eagles once sang) Have you got it to work yet, Col Klink? Prospero

Regarding LODs, the plan at the moment is to produce two resolution LODs for each .p3d (remember - the carrier is composed of many models). One is full detail, and the second will be suitable for casting shadows and fulfilling geometry/collision detection requirements. Edit - this of course does not count Roadway, Memory LODs etc. Currently the carrier is many objects. However, soon it will be only a few objects and many proxies. It will also be a working ship - not a static. Yes, I know you'll fall off it if it moves too fast, but I am doing this in anticipation of BIS hopefully doing something about adding friction to walkable surfaces. (I'm sure they will - they've gone this far..... so why stop now just when we're having fun?). I suppose I could farm out the .p3d files to the OFP community to produce the lower res LODs, but how many people would actually bother helping...? Then there's quality control... Prospero

Sorry, not me. I haven't played with that yet. Prospero

Sorry, not me. I haven't played with that yet. Prospero

It's a very good question. I have always assumed that they are identical - synonyms for conditions. I try to avoid such statements wherever possible (where a long-hand approach can be achieved), as conditions seem to be executed relatively slowly in OFP. I read with interest that v1.85 has a "preprocess file" widget. Of course, I'm hoping that this means we can compile scripts - if so... awesome. Edit: I doubt very much whether it is polled every cycle (sim rate rather than screen rate?). There seems to be very little difference between ~0.01 and ~0.0000001. Prospero

It is probably also worth pointing out that this method can be extended to setting an object into the world at an absolute height. Let us say that you wish to set the object (which we will call myobject) into the OFP world at an east/west value of _x and a north/south value of _y, and with an absolute height of _z. You must first find the height of the ground at that particular location (in terms of _x and _y). So you do this: mytrigger setPos [_x, _y, 0] _heightofground = -(getPos mytrigger select 2) You then do the following: myobject setPos [_x, _y, (_z - _heightofground)] You can of course reduce this process by substitution to: mytrigger setPos [_x, _y, 0] myobject setPos [_x, _y, (_z + (getPos mytrigger select 2))] Prospero

In O2, the grid squares are 1 meter on a side. When importing .3ds models you usually let O2 scale the .3ds object down by 10 (this is the default setting) for the object to be the correct size in OFP. Prospero

In O2, the grid squares are 1 meter on a side. When importing .3ds models you usually let O2 scale the .3ds object down by 10 (this is the default setting) for the object to be the correct size in OFP. Prospero

Walker, I'll be working on this soon for my carrier. I'll let you know what gives. I suspect (not having looked yet) that the positions are defined by named points in the Memory LOD. At least, this would make some sense... Edit: If this is so, and you want to "switch them off", you may be able to place them below sea level? Prospero

Walker, I'll be working on this soon for my carrier. I'll let you know what gives. I suspect (not having looked yet) that the positions are defined by named points in the Memory LOD. At least, this would make some sense... Edit: If this is so, and you want to "switch them off", you may be able to place them below sea level? Prospero

Thanks for all the help Suma, but I can't get either method working - always crashes out - both methods identically. Must be some problem with extension.p3d. Anyway, I'll pack it in now and try again tomorrow. I'm sure I'll get it working. Thanks again:) PS: If anyone gets it working in the meantime, do please post a simple demo. This makes large objects a real proposition. At the moment, my aircraft carrier is lots of individual objects, rather than one object with lots of proxies. This new method will hopefully mean that I can define it as one bigship (dynamic) instead of several houses (static), for as Fliper has pointed out, roadway LODS work for creating walkable surfaces on dynamic objects - although obviously, objects walking on these surfaces do not follow the movement of the surface. Then again, it'll probably end up a combination of several objects, all with multiple proxies so that multiple turret weapons are possible, but now at least the hull can be "one" object of simulation-type ship (or bigship) - can't remember which. Mind's gone blank. Prospero

Thanks for all the help Suma, but I can't get either method working - always crashes out - both methods identically. Must be some problem with extension.p3d. Anyway, I'll pack it in now and try again tomorrow. I'm sure I'll get it working. Thanks again:) PS: If anyone gets it working in the meantime, do please post a simple demo. This makes large objects a real proposition. At the moment, my aircraft carrier is lots of individual objects, rather than one object with lots of proxies. This new method will hopefully mean that I can define it as one bigship (dynamic) instead of several houses (static), for as Fliper has pointed out, roadway LODS work for creating walkable surfaces on dynamic objects - although obviously, objects walking on these surfaces do not follow the movement of the surface. Then again, it'll probably end up a combination of several objects, all with multiple proxies so that multiple turret weapons are possible, but now at least the hull can be "one" object of simulation-type ship (or bigship) - can't remember which. Mind's gone blank. Prospero

OK, I rewrote the code as follows: ---------- class CfgNonAIVehicles { #define PROXY_BIGHOUSE(x,dir) class Proxy##x { model=\bighouse\dir\x.p3d; autocenter=false; scope=public; reversed=false; simulation="alwaysshow"; }; PROXY_BIGHOUSE(extension,misc) }; ---------- I followed the very same proceedure as detailed before in terms of adding this to the end of bighouse.cpp. OFP crashes to desktop on loading with the error: bighouse\config.cpp/CfgVehicles/CfgNonAIVehicles/:'#' encountered instead of '{' .... I'm desperate to get this working:)!!! Prospero

OK, I rewrote the code as follows: ---------- class CfgNonAIVehicles { #define PROXY_BIGHOUSE(x,dir) class Proxy##x { model=\bighouse\dir\x.p3d; autocenter=false; scope=public; reversed=false; simulation="alwaysshow"; }; PROXY_BIGHOUSE(extension,misc) }; ---------- I followed the very same proceedure as detailed before in terms of adding this to the end of bighouse.cpp. OFP crashes to desktop on loading with the error: bighouse\config.cpp/CfgVehicles/CfgNonAIVehicles/:'#' encountered instead of '{' .... I'm desperate to get this working:)!!! Prospero