Jump to content

tklama

Member
  • Content Count

    4
  • Joined

  • Last visited

  • Medals

Community Reputation

10 Good

About tklama

  • Rank
    Rookie
  1. Thanks a lot to everyone, it works splendidly. I was wondering if there is any command that would get rid of the audio attenuation while sitting inside vehicles in 1PP when using 3D sounds. I currently use a "vehicle radio script" that uses Say3D to play music based on the driver´s choice but, as expected, it only works proper for people who are outside of the vehicle, or are sitting in a vehicle that is "open", such as at the back of a Hilux, etc. People sitting "inside" can barely hear anything. playSound3D and createSoundSource suffer from the same issue. I assumed that triggering Say3D as speech will have gotten rid of it, since that is how I understood the wiki article, but perhaps the "vehicle interior filter" refers to something else. I assume playsound or playmusic would probably get around this, but they are not usable as part of a car radio script due to not being 3D sounds with a range limitation. Nothing game breaking, but I personally ran out of ideas.
  2. Hello, I will check it out. I very faintly remember using this command at some point in the past, and I think I had some issues with getting it to work in an MP setting. But that could also be related to an incorrect script. Will this function correctly in an MP mission if I include if (isServer) then.. ? That is, it will only be play "once", and not once per each client? Thanks a lot!
  3. So, the code I have is inside init.sqf is this: (this should be MP compatible btw, 60 players or thereabouts) What is it supposed to be doing? This is supposed to be playing an advertisment on loop out of a radio (R2) in a small radius (30) around it inside a gun "store" What are the issues? Now, when I tested it the loop worked fine only if I spawned within the hearing distance of the Say3D (30 whatever units), and never left the hearing range. In this case the sound got correctly looped after 155 seconds. Problems start to occur in the following cases: 1, If I spawn outside of the hearing range of the Say3D, the playback of the sound does not get triggered until I walk into the (30) range. But the sleep part does get triggered right at the start of the mission (since this is in the init.sqf anyway). Which means the loop does not work correctly, due to the playback of the sound being offset by whatever amount of seconds it takes me to get into the (30) range to trigger the start of the playback. 2, If I spawn inside of the hearing range of the Say3D and trigger the playback of the sound, and then TP outside of the hearing range, the playback gets put on "hold", or gets "paused", if you will. That means for example if I TP away from the radio for 30 seconds and then TP back in, then the playback of the sound resumes from the point at which it got paused due to me TPing away from it. This obviously breaks the loop again, due to the duration of one "loop" of the audio gets increased by whatever amount of seconds I spent outside of hearing range. I haven´t even begun to think how these issues would this tie in with a 60 player MP mission, and what sort of a mess I would end up with. So, what the hell do I even want? I want the playback of the sound to get triggered right at the start of the mission, no matter the distance of the player(s), and I want it to keep playing the sound no matter the location and distance of the players for the duration of the mission. The loop script should also be only executed once, I assume on the server, so that people dont get earraped by 60 sounds playing at the same time. Been there, done that. Am I using the wrong script command? Do I need to use cfgSFX and createSoundSource? My sqf knowledge is very basic, so excuse and stupid mistakes there might be in the code. Thank you
  4. tklama

    3CB BAF Weapons

    Hello, I have serious doubts so as to the accuracy of the M6 integrated range table. At least trying to use it the same way as any other mortar, that is, treating the altitude difference values as mils to adjust the mortar elevation. They for sure are not mils, since it is impossible to have a 60mil difference for 100m elevation change when firing at 1750 meters for example. What units are these values in? They look more like meters to me. If I treat them as meters then the mortar seems to work okay when firing uphills, but downhills it remains inaccurate. Tested on Takistan, usually around 300m altitude difference
×