Jump to content

Prospero

Member
  • Content Count

    478
  • Joined

  • Last visited

  • Medals

Everything posted by Prospero

  1. Prospero

    How to make cpp

    Not only can the seagull be created in game - you can also switchCam to it and fly around manually with a bit of editing. Prospero
  2. Prospero

    Scripted rotations

    O2B? Pearls. Swine. Joy. Prospero
  3. Prospero

    Scripted rotations

    O2B? Pearls. Swine. Joy. Prospero
  4. Prospero

    Scripted rotations

    Hi all, Many people have asked whether an object's pitch and roll (as well as yaw, or direction) can be specified using a script. And up till now, although I have been able to determine the yaw, pitch and roll of any object (via script), I have never been able to _set_ an object's pitch and roll. However, now that I've finally got my hands on O2 (I'm a scripter, not a modeller!, I suspect that there may be a way: Firstly, you have to make a "special" version of the object in question. It would be identical to the original, except that you define the object as the "turret" of an invisible base object, this turret being assigned pitch and roll axes. You then use the recently introduced animation phase commands to provide you with the ability to set pitch and roll. Yaw is achieved in the normal fashion via setDir. I have experimented with door position-setting scripts which work very well. I see no reason why this method could not be expanded. Thoughts? Prospero
  5. Prospero

    Scripted rotations

    A follow-up whilst it occurs: Some people have wondered how to do translation animations instead of rotation animations. It is fairly obvious, but I may as well point out that if you displace the axis of rotation away from the object, you can of course achieve a fairly effective translation by a rotation. So, sliding doors etc. Prospero
  6. Prospero

    Scripted rotations

    A follow-up whilst it occurs: Some people have wondered how to do translation animations instead of rotation animations. It is fairly obvious, but I may as well point out that if you displace the axis of rotation away from the object, you can of course achieve a fairly effective translation by a rotation. So, sliding doors etc. Prospero
  7. Prospero

    Scripted rotations

    A follow-up whilst it occurs: Some people have wondered how to do translation animations instead of rotation animations. It is fairly obvious, but I may as well point out that if you displace the axis of rotation away from the object, you can of course achieve a fairly effective translation by a rotation. So, sliding doors etc. Prospero
  8. That's a GOOD mission? Worthy of a thread? Blimey, it's complete and utter sh*te. Topic locked. Prospero
  9. Hi all, I was recently playing about with moving static objects around - like the bridge. I would place, say, a police jeep on the bridge, and then setPos the bridge _smoothly_ up and down and see if the jeep stayed on it - i.e. would the bridge "carry" the jeep as it moved? Well, sometimes it did, and sometimes it didn't. When it didn't, the jeep would simply stay where it was and the bridge would move through it. Not good. The problem was understanding why this happens. Well, I think I do now;) And this potentially provides a way of sensing collisions for script-controlled objects too. Effectively, it seems to be to do with speed. Speed, as in the attribute the game assigns to a certain vehicle's simulation model, and which can be accessed by using the Speed command - as in <speed mycar>. To keep the police jeep moving with the bridge, you have to find a way of preventing the jeep's speed ever becoming EXACTLY zero. Providing the speed's magnitude is greater than exactly zero, you're in business, and the jeep stays on the bridge. The speed doesn't need to be large, it just must not be EXACTLY zero. 0.000001 m/s is fine, for example. If you were to watch an AI-controlled jeep slow and stop, its speed is still non-zero for a few seconds AFTER it _appears_ to be stationary. This initially fooled me when I conducted my tests. You can check this yourself by using the Speed command, of course. The question is therefore, how to go about keeping the speed from ever becoming exactly zero? As it is now, the way I'm getting round this is by shooting the jeep with an M16. Sounds stupid, I know, but this method may lead to an elegant solution. Every time you shoot a stationary (zero speed) vehicle, regardless of whether it's manned or unmanned, you give it some speed. A tiny amount of speed, of course, but all we need is for the speed to be non-zero. Grenades work too of course, but that's a little over the top... So one possible idea is to use a simple looped script to camCreate a bullet onto a vehicle (anyone have a sexy way of doing this?). Then, in the same loop, reset the tiny amount of damage done to the vehicle by the bullet (this is a constant) by using the setDamage command. And bingo, we have a jeep which stays "active", and, importantly, the player won't even notice what's going on - providing this can be done silently... Now, what I really want is a way to give a vehicle some speed WITHOUT damaging it. Any ideas? OK, so what about objects to which you've attached your own physics model? In the config.bin file for such an object, one must first specify a simulation-type of "house" because in-game gravity does not affect this simulation-type, but damage still works fine. Going further then, here's what you do: You would make your object as above and continuously camCreate bullets on it during its lifetime - i.e. once every scripted movement cycle. Even though it's of simulation-type "house", this gives it momentary speed and therefore keeps it "active" - and hence it will be damaged when it contacts / is in contact with another game object, thus allowing you to sense when it collides with something. It's not perfect yet, but I thought I'd mention it on the board for the sake of discussion. Prospero
  10. Prospero

    Cam qustion

    Depending on the effect you're looking for, you'll achieve smoother rendering if you let the position update camCommit's float a bit - say by 0.1 or 0.2 seconds. This is a good trick where you are viewing from cameras which you are manually camSetPos'ing via a fast loop. Prospero
  11. Hi all, Could some kind soul tell me how to camCreate live bullets? I want to setPos a few rounds onto objects to damage/"activate" them (for various boring reasons). Just as if I'd shot the objects myself... Thanks;) Prospero
  12. Prospero

    Download console for ofp:r

    Hi all, Anyone aware of a way to retain player control whilst accessing dialogs? Prospero
  13. Hi Harnu, I've been playing around with various methods to do this for a while now. Sadly, I don't have a "perfect" method yet. But say, for example, you want to tilt the bus - to either flip it onto its side or jack it at an angle: This can be done my placing small walkable objects underneath the relevant wheels, and moving them around (carefully) with SetPos - i.e. set them to raise and lower. You can make the "chocking" objects invisible by modifying the textures (by setting the alpha channel). Be aware that the bus's wheels won't move in X & Y with the walkable "chocking" object unless make a chock with "proper" sides. Prospero
  14. Hi all, Is it possible to produce stationary particles? For example, the following will produce a particle with a very low velocity, but it isn't zero. drop ["cl_water", "", "Billboard", 0.5, 1000000, [0, 0, 0], [0, 0, 0], 0, 1, 0.785, 0, [1, 1], [[1,1,1,1], [1,1,1,1]], [0], 0, 0, "", "", player] What particular combination of mass and volume would produce something stationary? I can't see the logic here at the moment. I'm trying to rewrite a script I did for determining any objects pitch and roll using the Drop command, but for this to work really well, I need to be able to create stationary particles. Prospero
  15. Hi all (and hopefully Suma), Someone asked about the new Drop command at OFPEC. I thought I'd echo bits of my reply here because I'd very much like some feedback... Prospero ---------- Drop is a very powerful command and can be used for many, many things - scheduling, ballistics, physics models, pretty SFX - or just dropping stuff. In our case (we want a tank), we need to invoke it like this: Drop ["<a tank model>", "", "SpaceObject", ..............] (Note: for some very odd reason, it appears that one must specify the "SpaceObject" argument CASE SENSITIVELY, so make sure you do it just like that.) However, at the moment there seem to be a number of problems with the Drop command, not least of which is that the attitude of the created SpaceObject particle seems to be utterly random - and I believe this is something to do with the animation/animation phase settings. Actually, I'm hoping that BIS will add to the Drop command a feature so that the _complete_ attitude of particles can be set easily - in terms of the Euler angles for yaw, pitch and roll. Oh, and there seems to be a bug - SpaceObject particles appear to be rendered improperly. This said, I would still suggest you play around with it. It has huge potential. Prospero
  16. Prospero

    The new drop command

    Hi all (and hopefully Suma), Someone asked about the new Drop command at OFPEC. I thought I'd echo bits of my reply here because I'd very much like some feedback... Prospero ---------- Drop is a very powerful command and can be used for many, many things - scheduling, ballistics, physics models, pretty SFX - or just dropping stuff. In our case (we want a tank), we need to invoke it like this: Drop ["<a tank model>", "", "SpaceObject", ..............] (Note: for some very odd reason, it appears that one must specify the "SpaceObject" argument CASE SENSITIVELY, so make sure you do it just like that.) However, at the moment there seem to be a number of problems with the Drop command, not least of which is that the attitude of the created SpaceObject particle seems to be utterly random - and I believe this is something to do with the animation/animation phase settings. Actually, I'm hoping that BIS will add to the Drop command a feature so that the _complete_ attitude of particles can be set easily - in terms of the Euler angles for yaw, pitch and roll. Oh, and there seems to be a bug - SpaceObject particles appear to be rendered improperly. This said, I would still suggest you play around with it. It has huge potential. Prospero
  17. Prospero

    List of changes in resistance

    Suma, This was mentioned in the list:- 1.56 - Added: function cameraOn I don't think this command made it into the Comref. Any chance of a quick example to show how to use it? Many thanks, Prospero
  18. Hi all, A quick message to ask if anyone knows whether the _apparently_ impotent CamSetDive and CamSetBank commands have been fixed yet (for v1.75) or perhaps stand a chance of being fixed in the future? A couple of things occured to me during the hours and hours of slaveishly trying to figure them out: 1) Changes appear only to be "committed" for vehicles with simulation-type "camera". That is, if, having issued these commands and Camcommit'ed them, one puts in a condition like -- @camcommitted _mycamera-- one will find that script execution is halted if you have used the commands on a vehicle with any other simulation-type. Of course, the commands don't work even with a vehicle of simulation-type "camera", but it's still worth pointing this out, I guess. 2) Using a SetDir on any object, including a camera-type, seems to set all three components of its attitude (yaw, pitch and roll) to zero - not just it's direction (yaw). I imagine this is why there are three separate attitude commands for setting camera attitude, including CamSetDir. Setdir would simply override the whole lot. Of course, it should be pointed out that CamSetDir doesn't work either... 3) Why am I bothering with this? That's a very good question. It's completely my own fault! You see, I am trying to implement something known as the "NASA Minimum Complexity Helicopter Maths Model" within OFP and "attach it" to a gamelogic, or better still, a custom vehicle of simulation-type "static" - as these have little physics associated with them. The idea is to develop a pretty realistic (yet fun!) UAV sim within OFP. I have already flown the maths model in OFP, and have developed a method to gain access to four axes of "simulated analog" keyboard input accessable via script. (You really do need four axes for a helicopter). Alternatively, one can have "proper analog" with a programmable joystick such as the TM Cougar. The one BIG thing missing is any way to assign the pitch and roll values generated by the maths model to either the heli UAV itself, or a camera placed "in" the UAV. Hence my interest in the CamSetDive and CamSetBank commands. If anyone knows something that might help, pls do get in touch. Indeed, I'd be most grateful if some kind soul at BIS could let me know whether these commands... a) Don't work b) Do work, and it's simply my own stupid fault. c) Will never work d) Might work in the future... (Tick one?) Best, Prospero
  19. Prospero

    Shadows

    Hi all, A _very_ minor stylistic point, but I do think the shadows could do with being just a tad darker... Indeed, so could the new sea texture - which is a vast improvement - but just a little darker would help distinguish it from the land. Sometimes "less is more" does not apply;) Bestest, Prospero
  20. Prospero

    Shadows

    Hi all, A _very_ minor stylistic point, but I do think the shadows could do with being just a tad darker... Indeed, so could the new sea texture - which is a vast improvement - but just a little darker would help distinguish it from the land. Sometimes "less is more" does not apply;) Bestest, Prospero
×