Evil_Echo

I have the kb system working now. With eventhandlers and fsms! My problem was due to trying to converse with a vehicle, switching to an individual soldier did the trick. Back to CG's quality question. Think you are correct that you need to preprocess any sounds that will be used for Cfg* in order to degrade them to radio-quality. It's not hard work with Audacity, but can see the annoyance factor if you have to process a lot of files.

I've seen that idium used inside a loop to force termination. Some other elements processed various cases and established the condition that was then used to decide whether to continue cycling through the loop.

TY CG. Appreciate that. Also the code snippets - that is useful, AZCoder.

Did you have the line #include "ECHO\Includes\Paths.hpp" in that script? That is where the variable that is being complained about is defined.

Thank you CG. The ideas do help some. Already was reading the bikb thread. I had been trying eventhandler and fsm, perhaps too much for starters. Will try some simpler techniques. May I take a look at your Domino mission for ideas?

You're welcome, Manzilla. Sorry for the slow response. Have tested the package with the new 1.55 patch update - seemed to work fine. Good to see that after the grief some had with the betas leading up to this. How is the 2.0 package working for the rest of you folk? Hoping there are no major issues since it's been kind of quiet here. If there are no big problems then I can start planning for the next set of improvements and features.

Best I can tell old-style sounds are played as-is. So you would need to preprocess them to fit your needs. In one mission I needed an alert message for a PA system, the raw recording sounded TOO good - so put it through a pass filter and added some echo for a more outdoor ambience nature. Still trying out the kb system without any luck, no messages, no sounds, no errors. Hopefully will get the correct clue sometime on how to get that working, it'd be perfect for the dialog I wish to have. Would not mind any ideas on what to do, CG.

Congrats on your new release, ACE. Wishing you all the best.

Try to increase the sound level in the .ogg file itself.

wrong place - ignore

I wrote a significant chunk of the documentation for a popular mod at one time, a number of guides for different topics, and then an entire wiki for that same mod. That work was done despite of the opinion of a number of people who did not place any value on documenting their work nor spending much time providing support. Often hours were spend tearing into PBO's to find answers for the user base. Meanwhile the old guard who wrote the code, made the models in question, etc. did not take too kindly to sharing what they knew. They were too elite or too stressed out to deal with such menial matters. I've seen good people like CarlGustaffa take on the mantle of providing support for products. CG's passion is the Domination mission - a huge product that was suddenly abandoned when the original developer had a temper tantrum. Without CG, Domination might have died off. And without the helpful postings by him and others like him BIF would a sterile forum, barely any help at all to A2 players and new developers. What was done in the days of OFP means nothing to A2/OA. Either you're currently active and helping or you're just resting on your laurels expecting to be worshipped. That kind of stagnation is the death knell of A2. So those that don't want to help, make threats/demands without giving back ( new models, software, documentation, answering questions, etc )- just leave and we'll be much better off without you.

To me, sqf feels like C with a healthy dose of Perl stirred in. If you know either it's not too hard to get used to this game scripting language. The primary quirk is how arrays are managed - using commands vs being built into the grammar.

Osprey and Russian choppers anyone?

F2 is for dumping fire data into the cut/paste buffer, no?

It would be nice to see a larger range of blast effects. But at some point you can't use config-based solutions - they just can't do all the actions you'd like. So off to scripts and micro-managing every detail. Which is part of the reason only a few have dabbled in this arena. Nukes can be a huge FPS hit, optimizing the look is an art form. But also concider that along with the blast cloud you are also damaging a lot of other stuff at the same time - causing those item's special effects to kick off. In my testing, it's the damage side of the nuke that causes the bulk of the FPS hit. Spreading out the effect over time with some small random sleeps helped a great deal.

RKSL got the points on IP exactly. Now let's all move onward using that as a common point of reference. I agree about closing the window as well. But in this case that window in not in ArmA, you need to involve Microsoft to change that.

One thing to note, you need the functions module in your mission. Otherwise the record and playback routines will not work.

1. It's already been stated that locking mechanisms can be bypassed by tools that access the data in memory. So the model makers would enjoy zero protection from the method they keep wanting. Why pick the door lock when the owner of the house has left a window open? 2. The debate about IP ownership, especially the part referencing using the design of a car like the VW Golf. That argument is nonsense. If you hacked into the company database and stole the CAD file, that's theft. If you make your own model based on published photos and technical data then it's not. That's why companies go to such lengths to protect so-called trade secrets, knowing there is no legal recourse to prevent duplication of the work if the info enters the public arena. If you disagree with that statement, then answer this. How many model makers get written permission from arms manufacturers? Would like to see the letter from Eurofighter GmbH granting RKSL permission to duplicate their jet in such detail. Surely if the model makers truly believed IP rules behaved in the manner described they'd spend the effort and money to get permission ( i.e. a license ). 3. The claim there is no dark side of restricted access to models. Look at the ACE tickets. How many problems in there blocked due to no access to BIS MLOD files? Are the ACE team a bunch of thieves for wanting to fix a problem in BI models? Is BI wrong to protect their designs? I'd say "no" to both questions - it's just sad that the situation exists. Lilewise it's sad when people take your work and claim it for their own, regardless of profit. But the bulk of the discussion here is not doing anything useful to protect developer's efforts. So are we going to step back and look at this from a broader perspective or continue the schoolyard squabble?

Hmmm. Don't doubt your statement Inko, but would like some numbers on that. Wonder how many servers are that badly set up if true. Are the default numbers that far off?

If your mission allows for JIP the idea of forcing everyone to wait becomes futile since you never can predict when someone to join. If you don't allow JIP, then you could use a set of publicVariables to signal "ready" and wait for for all those before moving on with the mission.

I know of no way to change the colors dynamically on the existing PAPI. The best you could do is to replace the item with a new one configured with the colors you like. Those colors are defined in the config, vasiRed and vasiWhite. Otherwise - you could script the whole thing, basically make your own simulation and change the light source dynamically in whatever manner you wish via the usual setLightAmbient, setLightBrightness, setLightColor.

I was trying to answer that.... Checking the configuration ( Community Modder's Bible on devheaven, very handy ) shows the PAPI is a sub-class of Land_VASICore, which has it's own simulation type of "vasi". Each light in the PAPI is assigned it's own angle via a vasiSlope entry. So it's quite evident the simulation calculates the vertical angle from your player to the PAPI and uses that to switch a given light between red or white.

Nukes huh? - No smiley, guess he's serious. If so, welcome to the club of serious nuclear devs.

Addendum/Erratum for the pdf document.... Mando SCUD (OA required) The fired missile is detectable and interceptable by MMA anti-missile systems, and can be loaded with conventional or nuclear warheads. By default the warhead is conventional. To set a different type of warhead you need to set a vehicle variable named mando_scud_type. <- NEW scud_launcher setVariable ["mando_scud_type", 0]; // <- Conventional scud_launcher setVariable ["mando_scud_type", 1]; // <- Nuclear - Gigan detonation scud_launcher setVariable ["mando_scud_type", 2]; // <- Nuclear - Echo/Mando ground burst scud_launcher setVariable ["mando_scud_type", 3]; // <- Nuclear - Echo/Mando air burst There is also a script to fire SCUD from AI launchers: mando_missiles\units\mando_ai_scud.sqf <- NEW Syntax: [scud_vehicle, warhead_type, target_position] execVM "mando_missiles\units\mando_ai_scud.sqf"; scud_vehicle: scud vehicle with an alive driver warhead_type: 0 -> conventional, 1 -> Gigan nuclear, 2 -> E.Echo/Mando ground burst, 3 -> E.Echo/Mando air burst target_position: target position Example: if (local my_scud2) then { [my_scud2, 2, getMarkerPos "mk_target"] execVM "mando_missiles\units\mando_ai_scud.sqf"; }; E.Echo/Mando Nuclear Warhead Features The warhead supports a number of burst modes and incorporates detailed physics effects. Ground burst detonations are at/near ground level and will generate the familiar mushroom cloud as well as considerable fallout. Airburst detonations occur well above ground, resulting in negligable fallout. Burst effects in the air and over water have a different appearance due to the influence of the local environment. Damage caused by this weapon is based on typical effects for a tactical weapon and are scaled by the defined yield. Blast, thermal, prompt neutron/gamma effects are present and scale appropriately by distance and the type of unit. Vehicles afford some protection to their passengers and crew, the amount depending on the type of vehicle. Additionally, the shock wave can cause significant displacement in position, resulting in secondary injuries. The amount of time before fallout comes to ground varies on the yield of a weapon. For a 5 kiloton weapon the 'safe' time is about 30 minutes. The area of contamination will vary with yield and its location/dimensions are influenced by winds during the interval between burst and falling-out. The fallout zone represents a region so contaminated that radiation sickness will render a soldier combat-ineffective in a relatively short period of time - about 10 minutes. Certain vehicles will protect you from the effects of fallout.

It might be governed by the light cone, which is fairly close to how a real PAPI works.