Jump to content

arno54

Members
  • Posts

    318
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by arno54

  1. Blend files can be created/edited/saved in 2.5 then reopened in 2.49 for *.py exportation. The scripts are not compatible with 2.5 simply because 2.5 requires python 3.0 whereas 2.49 requires python 2.4.

    There's no real advantage to model with 2.5 as the real progresss is about sculpt modeling and a better (faster) treatment for baking, but in the other hand, animations are far easier to set in 2.49 than in 2.5.

    2.49, to date, is by far the best choice for xplane devs. 2.5 is to be considered first bt 2D specialists for textures creation (2D being much more difficult than 3D)

    As for the "Xpfr model", there is a misunderstanding here. There'd be a lot to say about this but basically, I'd like to stress on the fact that there are very few redundant skills : each one has a field of skills, flight model / texturing / obj animation / lightings / photographs etc... and the worst IMHO in a group of devs is to have competitors in a definite field of skills (e;g. everyone wants to deal with building structs)

  2. @Steven

    I read this and I feel very frustrated, because either I don't respond (and one thinks there are flaws and nothing really new in the Trojan) or I speak ( and one thinks I fight to sell more).

    So, having thought of it, here is my deal, Steven Winslow :

    - Get the Trojan. Then you'll experience what really is a plane with custom sound engine (not custom sounds, but a whole custom sound engine).

    IF you have ONE good reason, only ONE (And I would not argue it in anyway) to claim this is not 100x best than defaut engine + custom tracks

    OR if you find any flaw in the flight model relative to official doc,

    OR if you find less than 10 never-seen before functions,

    then I'll give back money from my own paypal account in the following hour, including XA comission and Khamsin's part - I'll personnaly give 100% money back. And I even won't try to check you've deleted the fle - that'll be my gift.

    I take for granted that you're honest and will say "ok, that's really as good as it gets - no refund required".

    I'm quite confident this will not happen. How many devs would dare to offer so? None. Obviously, i'm gonna be hanged on by my colleagues for this.

  3. If I dare have a word on this matter... (well... I dare),

    there is a common misunderstanding here I assume.

    First, the initial quality of the recording is the clue, not the freqs. I mean, if the sound is poor and cracking, playing it 88Khz will simply give us high-quality cracks. So, it's probably better to have well-recorded sounds played 11Khz than poor sounds played 44khz.

    Second, let's face a simple fact : I bet 99% of the users don't have a hardware that's able to restitute true high-freq sounds. Even if the sound is actually well-recorded and really 44khz, in the final headset of most users (not to speak of laptop speakers) these sounds won't play with the quality they are supposed to.

    Third and last, there is an obvious, huge difference between 8 and 11khz. This difference is very noticeable but less important between 11 and 22. It's not really significant between 22 and 44, simply because the difference would require high-quality harware to be properly restituted.

    Xplane is simply not intended for sound processing. We can do lots of things to improve the flight experience, but multiplying the weight of the sound files is probably not what comes first - even if I'm definitely convinced this is important (see T28 specs sheet).

  4. You have to use

    if acf.getIAS() > V1 then do your stuff and flip the marker end

    Don't use

    if acf.getIAS() == V1

    because as acf.get.IAS returns a value with numerous decimals, your condition is likely never to come true.

    And you MUST flip your marker within the same condition that plays your sound, or your sound will get called tenths of times, resulting in a scratchy noise instead of a wav file. Obviously, each condition/sound MUST drive its OWN marker.

    In your case, you would probably be clever to use a table so that each marker can only be flipped is the previous was :



    TableMySoundMarker={-1,-1,-1}

    if
    acf.getIAS() > V1
    then
    sound.play(V1_snd)
    TableMySoundMarker[1] = TableMySoundMarker[1] * - 1
    end


    if
    acf.getIAS() > V2
    and
    TableMySoundMarker[1] ==1
    then
    sound.play(V2_snd)
    TableMySoundMarker[2] = TableMySoundMarker[2] * - 1
    end

    this would prevent V2_snd to be played when your plane is on final and V2 is not supposed to be alarmed.

  5. This should be usefull for Gizmo rookies.

    TUTORIAL-sound2event.function.zip

    That's a complete and very comment-detailled working example of a "Sound2Event" function : Any time you toggle the gear handle, a siren sounds.

    Simply unzip in a fresh plane and study the code.

    it details the four basic steps to have a sound linked to an event :

    1) load a sound

    2) create a marker and set it in the right state

    3) monitor your event, and if it occurs, play sound

    4) reset your marker so as to get your functiun ready to trigger again.

    NB : this does NOT use dataref_HOOKS, but a custom flipping marker. There are better ways to achieve this, but this example is only intended to provide a working, reliable, basic script. The code itself is less than 20 lines long, most of the content of the zip is comments.

    Hope this will help.

  6. Well, that's probably the result of an unexpected situation :

    the jeep appears randomly, but it's tested whether it's on ground or not. If not, a new spawn point is choosen.

    If you load this situation, there's probably no ground at all in the allowed perimeter so the plane "hangs on", trying to place the jeep again and again and again...

    Simple solution, choose Fighter before you load the situation. Anyway, one is not supposed to carrier land loaded.

    I'm gonna find a fix for this shortly.

  7. I've done many crosses with multiprop of my own (imaginary or historical), old fashion way.

    Including one real-time West-East via the North Road with a MD312 (was achieved IRL, once), and several direct come-and-go with our B17 (that's is REALLY challenging because of fuel load)

    I could write a whole book on this subject - as long as we speak of piloting.

    If you are not a FMS-GPS maniac, that's really a great adventure.

    If you are, it's only a 10hours electricity bill over endless water, you set up your start during your morning coffe, and witness landing when you're bacj home after work. It has absolutely no interest at all with a modern plane.

    Times are exact (the xplane world is actually spherical) and orthodromy is definitely reliable. With a map, a ruler, a timer, and a lot of calculations, it's pure art of piloting.

    • Upvote 1
  8. Well, I honestly strongly doubt this comes directly from the plane. It seems you have a very stretch screen, something above 16/9, which makes me thing you probably have "non proportionnal field of view" set to "on".

    The plugin doesn't deal with vertical field of view, at all, that's 100% under Xplane's control. I'm gonna try and reproduce this to be able to give you a precise workaround.

    EDIT :

    Or : conversely, it's not set to "on" whereas it shoud be...

  9. It's randomly placed within a 250 meters radius (800ft) around the spawn point of the Bomber.acf.

    If you select the "I'm learning" mode, the VFI will tell you how far away it is, so flying around and checking you're closing, you should find it.

    A jeep when seen at 500ft high is barely more than a spot.

    Finding it is part of the challenge :-)

    EDIT :

    if you use a scenery with lotd of objects, the jeep can spawn out INSIDE an scenery object. Reload the plane to generate a new spawn point for it.

  10. @Ben :

    Roger that loud and clear :-)

    @Pete :

    Actually, that's what I did. But

    camera_i = xp.getFloat(xp.getDataref("sim/graphics/view/view_i")), 3 times, is simply much more heavy to handle ; as Ben spent time to create handles for this, I try to use them :-)

    Currently the sound.say() says "0", what shows the function runs, but returns nothing.

    Furthermore, even though I don't have the smallest idea of how Ben did the communication between Gizmo vs the sdk, I'm now pretty sure that most of the readings/calculations are made when gizmo's core run, be the api function called or not, what makes me assume that code execution (not to speak of code typing) with api function is slightly faster than with the equivallent function coded all along. But that a guess due to some feelings and unreliable measurements - so, it's an open subject and is probably worth enlightement.

  11. I tried this under different circumstances / shunks, but basically this is the idea :

    function TellMe_CameraHeading()

    camera_p, camera_r, camera_h = camera.getAttitude()

    if I_want_to then sound.say(camera_h ) end

    end

    I_want_to => returns sound.say("0") , always.

    So, either I did not understand what camera.getAttitude() is supposed to return (presumably, 3 sets of decimal degrees) or there is something wrong with this function.

    Any idea welcome. :-)

    Arnaud

×
×
  • Create New...