Speed

ATTENTION: There was a major problem with Mist v1_0. The mist.addEventHandler function was broken. You know how they always say "if it ain't broke don't fix it"? Well, yea... maybe I should have listened :( Anyway that also broke the mist.DBs.deadObjects database, preventing it from being populated. I've already updated the Mist post to include Mistv1_1, which fixes these problems (never thought we'd see version 1.1 so early...). The only change is the fixing of mist.addEventHandler (and mist.DBs.deadObjects).

OK, I thought this might have been you. I'll be there in about half an hour :)

http://forums.eagle.ru/showthread.php?t=98616 mist.DBs.groupsByName or mist.DBs.groupsById

Reserved

Mission Scripting Tools Expanded Lua Scripting Library for mission scripting by Speed and Grimes What is it? MIssion Scripting Tools (Mist) is a collection of Lua functions and databases that is intended to be a supplement to the standard Lua functions included in the simulator scripting engine. Mist functions and databases provide ready-made solutions to many common scripting tasks and challenges, enabling easier scripting and saving mission scripters time. The table mist.flagFuncs contains a set of Lua functions (that are similar to Slmod functions) that do not require detailed Lua knowledge to use. However, the majority of Mist does require knowledge of the Lua language, and, if you are going to utilize these components of Mist, it is necessary that you read the Simulator Scripting Engine guide on the official ED wiki. Community Contributions The purpose of Mist is to provide a set of scripts for the DCS community, by the DCS community. We are open to people contributing their own scripts into Mist, but we reserve the right to edit your script in any way we see fit before “officially” including it into Mist. Also, feel free to contribute ideas as for what scripts to develop next. Usage Rights Feel free to modify or redistribute Mist in any way you see fit (even including it in paid content is OK by us), AS LONG AS you don’t try claim that our work is your own. How to use it? Mist is not a mod of the game files. You include it into your missions simply by using the DO SCRIPT or DO SCRIPT FILE trigger actions to load Mist at or near mission start. Mist Guide A full .pdf guide for Mist is included in the attached Mist v3_3.rar file. Additionally, documentation is available online here. Example DBs are also included. Current feature overview “Flag functions” – functions that can be used by persons with very little Lua knowledge. Functionally similar to many Slmod functions, these set a flag to true when they detect a certain game condition. “Scripting functions”- intended to be used within a larger Lua script. These require knowledge of the Lua language to use. Databases- databases built for easier mission scripting. (Example DBs included with Mist v3_3.rar file). DOWNLOAD LATEST VERSION HERE

For this kind of thing, the simulator scripting engine is vastly superior. If you use the simulator scripting engine, you can even have your detection based off of line of sight or even a radar detection model! I can provide you with the scripts if you are interested. The only thing you will have to do is give the scripts the name of the units you want the scripts to operate on, and what flags you want to be set true when the detection conditions occur. Keeping in mind that the scripting engine can take into account target radial velocity towards/away from radar, whether or not the target is against a sky background or a terrain background, target above ground level, radar location, line of sight conditions, etc. etc., what do you want the rules to be on your detection script? Most likely, I have a script very similar to what you want already cooked up, or at least, I could make you a script within a few minutes time. And if all you want just 300 feet AGL, I can make that too. You do not have to install a mod, though if you wanted to, Slmod does have an already-cooked-up units_LOS function.

I HAVE GOTTA GET ME ONE OF THESE! 3ljd_hUxCfI

No, the AC generators are not for ground power, they are on board AC generators that convert engine torque into the AC electric power that many avionics systems (such as the Skhval) absolutely require.

I wish I had not reported this scripting engine bug :(

From: http://en.wiki.eagle.ru/wiki/Simulator_Scripting_Engine/DCS:_World_1.2.1/Part_1#trigger Note the bolded part. For now, if you want coalition-specific commands (that also work in multiplayer!) you have to use Slmod.

Actually, it doesn't work. I'm investigating, I'll let you know what I find. Edit: it's a problem with the SA-8. Apparently, guns were the only weapon they had loaded that could engage the SA-8 (give the people some Mavericks!). It could be that the SA-8 search radar mode is not detectable by the AI's Anti-Radiation Missile (ARM)? There was a recent bug fixed where AI were able to engage radars with ARMs that they shouldn't be able to engage with ARMs (apparently, not all radars can be engaged with ARMs- some search radars apparently operate in the wrong band). Who knows, maybe this is related somehow. Switch the SAM to an SA-15 and they will engage it with HARMs. Or give them Mavericks, and they will use those.

No, it's not, but GG's point is- AI is not very smart. AI is a tremendous programming challenge, and you should not expect major improvements in short order. Expect the slow and steady improvements over the past years to continue. As far as guns go: AI has always been WAY too gung-ho with air-to-ground gun use. I am a mission builder too, and long ago I learned to REMOVE ALL GUN AMMO from ALL air-to-ground AI aircraft in high-threat environments, at least in the cases where I am allowing the AI to select their own targets, and I am not specifying which weapons they should use. This is especially true for SEAD aircraft! And like already mentioned, if you use triggered/waypoint actions, you can actually specify which weapons they should use.

Incorrect usage. trigger.action.addOtherSubmenu and trigger.action.addOtherCommand both return menuPath objects. To assign an item to a submenu, you must use the menuPath object returned from the trigger.action.addOtherSubmenu function: do local MLRSMenu = trigger.action.addOtherSubmenu('MLRS Fire Missions') trigger.action.addOtherCommand('Fire on Kutaisi', 101, 'all', MLRSMenu) trigger.action.addOtherCommand('Fire on Senaki', 102, 'all', MLRSMenu) trigger.action.addOtherCommand('Fire on Kobuleti', 103, 'all', MLRSMenu) local artyMenu = trigger.action.addOtherSubmenu('Artillery Fire Missions') trigger.action.addOtherCommand('Fire on Zugdidi', 104, 'all', artyMenu) trigger.action.addOtherCommand('Fire on Gali', 105, 'all', artyMenu) end Also, see attached mission for an example. You also need to use the menuPath item if you want to remove an item. Also, as a reminder: radio menu items are for single player/multiplayer HOST only. add other menu items demo.miz

No, they're really friendly fire hits. Kill events are NOT actual game events, they are derived events from the game's "hit" and "dead"/"crash" events. This is why "killed" events can be so buggy. There is some logic that runs when a unit dies; it looks at the past "hitters" and determines who "killed" that unit. Unfortunately, there are a lot of complications to this and it is not anywhere as simple as it sounds (for example, what happens if there are multiple "hitters"? Who gets credit? Also, what happens to your code if one of the past "hitters" is now dead itself at the time of the damaged unit's death? What if, furthermore, that dead hitter unit's runtime ID is now being reused for a different active, alive unit?!?!). This is possibly why there are scattered reports of Servman randomly banning people who did nothing wrong (though, that is something I've never witnessed myself). I added in the autokick/autoban option because I decided to add a log of friendly fire hits in the chat log. It only took a few dozen extra lines of Lua to add a simple autokick/autoban option, so why not? The count is reset when you disconnect from the server. It is not yet a suitable replacement for Servman's autokick/ban feature. A future Slmod version will replace the current autokick/autoban option with something a lot more intelligent and more customizable. For example, I will probably create my own derived "kill" events (they already exist to some degree for the units_killed_by function), and they can/will be less buggy and much more intelligent than the default, derived "kill" events that exist in the net Lua environment, due to the fact that Slmod spans multiple Lua environments and can access unit health, airborne weapons (and remember who fired those weapons, even if that person is no longer on the server), etc. I will actually start work on that stuff fairly soon, as it will also be needed for the Slmod Stats system.

Last I checked, multiplayer clients have no problem taking off or landing on moving ships. Only single player/host drifts off the deck. Weird, I know.

Back in earlier versions of A-10C, it could happen randomly and rarely, but I haven't seen it in a long long time.

That is simply not true. DCS is extremely unstable with 7570. I've never seen any crashes due to released versions of Slmod, ever. Not once. Whoever is telling you that Slmod was supposedly decreasing their stability just doesn't know what they are talking about. Correct It has lots of new configuration options that allows you select which features to you want to enable.

When I tried loading AGM-88s on my A-10, they would blow up the second I launched them, killing me instantly. It seems that they must have a target or they just explode. I would think that HARMs might work, if you could get the "ETS" HUD mode from the Su-25T on the F-16 and then lock a target up before firing.

Saint, two quick questions: This line: if math.abs(mainLobeSpotRadialVelocity - targetRadialVelocity) < radar.detectionDistancePerRCS then Shouldn't it be this? if math.abs(mainLobeSpotRadialVelocity - targetRadialVelocity) < notchBand then Also, what causes the main lobe spot blind band? It seems like it's a blind band caused by the Doppler shift of the movement of the radar but... doesn't the radar KNOW what direction its moving so it can automatically factor out its own movement towards the target? Anyway, the simple radar model I described at first is working well, but I'd always love to improve it more... I actually have another question though: How realistic is it for fighter jets to be able to "hide" themselves from enemy radar by flying very close to a civilian airliner? That makes for a much more fun and interesting initial phase to the mission, as long as it's not totally off-the-wall unrealistic :) Anyway, as far as RCS goes, I'd like to not worry about it. RCS is not necessary, because this script is (right now) only being used on one type of aircraft, and also, I'm adjusting a fixed detection range value to fit what the gameplay of the mission requires.

Just noticed this thread. Nice list of features... your teamkill kicking is probably better than the Slmod 6.3 autokick/ban for team hitting. And you pause/unpause on clients joining a slot rather than clients joining the server. Good idea. Looking forward to the readme.

Yes, please wait a few days, then check back through the topics on this forum ;)

No

You mean this? e2ay5jOGI0w :D

Actually, it's quite possible that all this different things are just different symptoms of the very same bug.

Water was flashing into steam in a pan full of very hot grease. You mean you don't keep a couple M16s in your kitchen?!