Jump to content
Bohemia Interactive Forums

Spitfire

Member
 View Profile  See their activity

  • Content Count

    461

  • Joined

  • Last visited

  • Medals

Posts posted by Spitfire

  2. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (sgtvor @ Jan. 26 2003,02:39)</td></tr><tr><td id="QUOTE">Now that we have a lot more civilian addons, and computers a quite a bit more powerful than when OFP first came out, missions are becoming more and more populated and dynamic. This unfortunatly creates a tangled MESS of waypoints across the editor screen.<span id='postcolor'>

    That's exactly the reason I nowadays use dynamic waypoints made of markers and not the normal waypoints - at least in my bigger missions. Right now I'm doing a huge mission where waypoints (markers) are created, moved, deleted and reassigned to different units on the fly. The best part is that you can actually hide markers in the editor so they do not get in your way. The downside is that every action occurring at waypoints has to be scripted by hand, but I like to script things anyway - call me a control freak but I like to hold all the strings myself! smile.gif

  3. Posted

    In addition, some suppressors further suppress the sound by raising the remaining gas venting noise to ultrasound by the last whistle-like baffles in the end of the suppressor. So, no point in shooting dogs with this suppressor, eh? wink.gif

  4. Posted

    A silencer is designed to do two things. First of all, as mentioned above, it slows down the bullet to subsonic speeds. Secondly and more importantly, it slows down the exhaust velocity of the gases created when the gunpowder burns. Basically it gives the gases a larger chamber to burst into before they are let outside the barrel. Without a silencer, the gas pressure at the nose of the barrel is thousands of psi's, but a silencer can reduce the pressure to - say - less than 100 psi before the gases are outside the silencer.

  6. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (theavonlady @ Jan. 26 2003,15:13)</td></tr><tr><td id="QUOTE">Does it make a difference whether I enter the trigger area in a vehicle (which I did) or on foot? Either should have triggered this, correct?<span id='postcolor'>

    So, let's say the trigger is set to "present" and "west". Any vehicle a western soldier enters will turn to west side too, thus activating the trigger.

  8. Posted

    Make a trigger with this in it's condition-field:

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">getDammage vehicleName > 0.75<span id='postcolor'>

    The trigger activates whenever vehicle's damage is greater than 75%.

    1 is full damage, 0 is no damage.

  11. Posted

    Yes, by "grabbing" your bullet with nearestObject -command at the instant of firing and checking it's coordinates before its alive-status changed to negative, that is, when it ceased to exist.

    It's something like this:

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_bullet = nearestObject [player, "bullet"];

    #loop

    _coords = getPos _bullet;

    ?!(alive _bullet) : goto "bulletDead";

    goto "loop";

    #bulletDead

    hint format ["The bullet ceased to exist at %1",_coords];<span id='postcolor'>

    That was all off the top of my head. I'm not sure if the object is "bullet". Remember that bullet doesn't fly longer than 3 secs in any case, so it may stop in the air. If this is the case, you will notice that the z-coordinate of the bullet is more than 0 when it "dies".

    edit:

    there could be a problem that the bulled dies between the last alive-status detection and the next getPos, in which case the coordinates will be [0,0,0]. Replace the line </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_coords = getPos _bullet;<span id='postcolor'> with </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">?!((getPos _bullet) == [0,0,0]) : _coords = getPos _bullet;<span id='postcolor'>

    I don't really know if this will work, I haven't tested any of it, but this is the general idea to follow.

  12. Posted

    OK, I came up with a workaround. It uses your hide.sqs as such, but instead of a looping trigger it has a more cpu friendly script:

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_deadArray = [];

    #reScan

    ~1

    _obj = nearestObject [((getpos player select 0) + 2*(sin getDir player)), ((getpos player select 1) + 2*(cos getdir player)), getpos player select 2];

    ; --- if the object is alive, do nothing ---

    ?(alive _obj) : goto "reScan";

    ; --- if the object is already in the _deadArray, do nothing ---

    ?(_obj in _deadArray): goto "rescan";

    ; --- if the object is not a "Man", do nothing ---

    ?("Man" countType [_obj] < 1) : goto "rescan";

    ; --- Add the dead in _deadArray and add the Hide Body -action ---

    _deadArray = _deadArray + [_obj];

    _obj addaction["Hide Body","Hide.sqs"];

    goto "reScan";<span id='postcolor'>

    It takes the nearest object at a point 2 m in front of the player, checks if the object is dead, a man and not already added to the _deadArray. Only then it adds the hide body -action.

    Should work OK in all situations.

  13. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Dschulle @ Jan. 24 2003,14:58)</td></tr><tr><td id="QUOTE">Maybe you have to test what happens if people leave their vehicles...<span id='postcolor'>

    Already did. People out of their cars don't activate the trigger. Now it gets more complicated. Seems that a looping script of some kind is required, but it can only be done by maintaining an array of dead units already having the "hide body" -action defined. Otherwise the loop would cause dead people to get a new "hide body" -action at every loop.

  15. Posted

    Let's see if I can translate some of this.

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">if player sits (cost (stand)s, lies) , occurs an action.<span id='postcolor'>How can I make a trigger to detect if the player is sitting, standing or crawling and triggering some event to happen when he sits down?

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">if player peers into the sight (on the screen a sight of weapon), occurs an action.<span id='postcolor'>How can I trigger an event when the player is looking through the ironsights of a weapon?

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">if beside the player a weapon behind (in hands), occurs an action.<span id='postcolor'>This one's a little cryptic. My best guess is: How can I detect whether or not the player is being aimed with a weapon?

    Or: How can I detect the situation when an enemy right next to the player draws his weapon?

    biggrin.gif

  16. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote ()=Obi=( @ Jan. 21 2003,05:16)</td></tr><tr><td id="QUOTE"></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (PC. @ Jan. 17 2003,12:59)</td></tr><tr><td id="QUOTE">in Czech..

    poplach = alarm

    presunout = move over (teleport?)

    konec = end<span id='postcolor'>

    Here's the light !

    Thanks PC.<span id='postcolor'>

    Which is exactly the reason I always name my variables and scripts in English though I could name them in very cryptic Finnish wink.gif

  18. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Dschulle @ Jan. 20 2003,15:12)</td></tr><tr><td id="QUOTE">Another test would be a addon which defines two new axis and using the animphase command. But I haven't tried this.<span id='postcolor'>

    Hmm... if it's done that way it means that the behaviour of the plane will be totally independent of the "animated" roll since the flight model takes account only the "real" roll & pitch. Visually it could give nice effects but is no good for vehicles. And not to mention that you actually have to make new models for it.

  19. Posted

    biggrin.gif James Bond in For your eyes only, anyone? smile.gif

    Finally we've got some real use for the Walther PPK -addon wink.gif. Does anyone know of a good tux-addon holding a Martini, perhaps?

    edit: D'OH! It's the Spy who loved me, not For your eyes only, of course!

  21. Posted

    ... but still some questions without answers!

    Knowsabout, engage at will, hold fire, open fire and their effect to AI behaviour are probably the most controversial issues when it comes to mission makers' experiences about them. I decided to take the bull by the horns and do some experiments, in order to finally understand the AI. I did some research around it since I'd like to know how the AI will respond to different situations in different combat modes so I don't always have to do complex time-consuming scripting in order to make AI behave the way I want.

    Especially when deciding when to fire and when to hold fire the AI seems to be very complex and seems to use higher mathematics than any of the above.

    There are a couple of things I've found out for sure. Behaviour (safe, aware, combat etc) and unit skill level are both affecting AI's ability to determine the knowsabout-level at different ranges. And of course another factor is the stance of the target (prone, crouch, stand).

    So far so good. Another fact is that knowsabout of 1.5 is a magical treshold value when any AI with "safe" behaviour WILL ALWAYS draw his weapon (ie, change the behaviour to combat) when confronting the enemy. What happens after that, I don't know for sure. If the AI is allowed to open fire, he will do it immediately after knowsabout reaches 1.5 and the weapon is drawn. Even if the weapon is drawn already the AI will hold fire until the knowsabout rises to 1.5. Only the combat mode of "Never Fire", of course, causes the AI to... eh... never fire. wink.gif.

    However, if the AI is ordered to Hold Fire, neither the knowsabout level nor the distance seem to bear no importance whatsoever.

    I've stared at the wrong end of an AK-47 at 10 m distance with enemy knowing everything about me (knowsabout=4) but still not firing, only pointing the gun at me. However, during the next experiment the same enemy with the very same behaviour opened fire at me when the knowsabout level was only 2.5 and the distance being more than 50 m. I found out that a combination of "Hold Fire" and "Engage at Will" results in drawing the weapon at knowsabout 1.5 but not firing until I pose a threat too big for the AI, whenever that might be. When only "Hold Fire" without "Engage at Will" is issued, the weapon is not drawn until the AI is ready to pull the trigger, so it may still be holstered even at 10m with a knowsabout level of 4.

    So, the only mystery about AI behaviour hides in the "Hold Fire" -command. What are the factors that the AI uses to determine when to break the command and change their GREEN combat mode to YELLOW? I guess BIS's input is needed again smile.gif

    After reading all that I'm written above I really feel like I'm splitting hairs here wink.gif. Knowing these things about AI behaviour has really bugged me for quite some time now but I hope all this aimless sleuthing I've done is of help for someone.

  23. Posted

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (benu @ Jan. 13 2003,14:34)</td></tr><tr><td id="QUOTE">I trained the Voice SDK only shortly and had great success with shoot. The only thing i dislike is that it doesn't seem to share my mic with other voice apps so it's useless in MP where i prefer voicecom with fellow players to a program to control the ai (which doesn't happen that often in mp).<span id='postcolor'>

    It's supposed to work with voice comms. This is a quote from Shoot website:

    </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I want to run Shoot and Roger Wilco (or some other voice chat program) but Shoot complains that it can't access the sound device.

    Both Shoot and Roger Wilco, as well as other voice chat programs, need to access the audio input device (microphone) to operate. Some older sound drivers don't allow simultaneous by more than one program, though. In general, you should be able to get around this limitation by configuring both programs to only use audio input when a key or joystick button is pressed (e.g, Shoot's push-to-talk in "hold to enable" mode). Of course, the voice chat program must also have a similar PTT feature for this solution to work.

    Unfortunately, although RW has a PTT mode, it does not behave "nicely" and does not relinquish control of the microphone when voice is not being transmitted. Upgrading your sound drivers to the latest version might help solve the problem. <span id='postcolor'>

  24. Posted

    There's a better way, too. You can actually teach it new words individually, and re-teach words it already knows so they suit your pronounciation. Just use the "add word" -feature and pronounce the word like you usually do. That way it'll know how you pronounce the word and recognizes it every time.

    Normally you don't have to teach words to the SAPI engine, but when it makes mistakes between two words it's good to re-teach both words so it knows the difference in your pronounciation.

×