Speed

Not if they do it slowly. The internet is one of the greatest forces bringing the world together and helping to promote freedom... so of course some governments are against it.

vGzUKRoTII0 I need to get back to work... lol

FC3 includes in new single player mission for it, at least.

I replicated your problem in current 1.2.2. version, but it looks like this problem is already fixed in internal test versions... so don't sweat it.

How to un-protect the mission scripting environment so you can write files, load modules, etc. To ensure your safety, several "dangerous" Lua modules are removed, aka "sanitized", from the mission scripting Lua environment. These modules are the io library (read/write files), the os library (command prompt access), the lfs library (Lua File System- creation of folders, folder location, files in folders, etc.) and the require and loadlib functions. This prevents someone from making a mission that will install viruses/format your C: drive, etc when you run it. Several patches back, "Saint" (Святой) helpfully moved this "sanitization" code from C++ into the ./Scripts/MissionScripting.lua file. This allows you to optionally un-protect the mission scripting Lua environment and have access to the FULL set of Lua libraries. So, you could for example, output mission data to a file for use in Excel, load Lua socket and send mission data over the network- whatever you desire! So, to un-protect the mission scripting Lua environment, you simply need to comment out lines 33 through 39 of ./Scripts/MissionScripting.lua: I would not recommend this as a permanent mod, not if you ever run missions/tracks from untrustworthy sources, but this SURE comes in useful from time to time!

Are you certain the AI had the same fuel as you did? It is possible that he started out with fuel tanks and you did not, or you started out with 75% fuel and he started with 100%? What mission was it? It could have been a mission design error. Personally, I often like to take wing tanks on my Su-25T flights- ESPECIALLY if I am carrying Vikhrs. Oh and please don't act on your plan to kill Ethereal... I'm sure he didn't mean to make his reply sound "condescending" to your ears. It IS the honest truth that A LOT of players do not have very good fuel management. Even if their other skills are quite good, few players take the time to sit down and figure out what speeds/power settings yield the best fuel economy, and then ACT on that information (because it generally means flying slower). Myself, I only have a general idea, and that could be wrong too (80% to 90% RPM? Depends on a lot of other factors too). Oh and another question- is it possible you took a small hit and had some kind of fuel leak? I've had that happen before... you are in luck if you can make it back to base, usually! Really could use the track, but if it was single player, the track is probably already gone I would guess. Edit: Oh I see, I was getting confused. Need to be asking these questions to lxsapper, not you!

That's the ejection switch cover.

Yes

Yea, I noticed some time ago it was harder/impossible to move stuff inside of buildings. Now, they just stand on top. As far as I know, it's not a bug. Mission builders often do want to make infantry stand on top of buildings. The best way to detect destroyed map objects in DCS World is to use the scripting engine- it can detect the actual destruction of the map object.

Not really... slmod.chat_cmd has four input variables- 2 required, 2 optional. slmod.add_option has three input variables, all three are required. The biggest "issue" is keeping track of your option id numbers. Maybe that does make them a little more complex to use include into your mission, but keeping track of your option id numbers is not any harder than keeping track of your flag numbers. However, consider that slmod.chat_cmd is harder for clients to use- they have to read the briefing to know what the commands are. POS options are always viewed with "-sol", they are not case-sensitive (so, "-Sol" or "-sOL" also work), and they are always activated by saying "-op#", where # is the option number. So overall, they are a lot easier for the clients to use- you don't even have to read the briefing to know how to use them (though, maybe that's actually a BAD thing :D).

Here's a stupid but fun one: fire guns in the attached mission to launch a "nuclear missile". Just make sure no other units are within 3 km of you when you do! :D F-15 vs Su-27 WITH NUKES.miz

Perhaps not the most flattering representation of Russian/Soviet ingenuity, but I like it :D Here's an example of British ingenuity- early aircraft early warning systems:

:lol: Some people never learn :D

Like I said, the main problem with weapons impacting in zone is the fact that the Unit.getTypeName is not fully implemented for weapons. In fact, it was probably never even intended to be used on weapons at all, but it works... a lot of the time, at least. Anyway, since it's relavent to what I'm about to post, this is what a shot event looks like: { ["subPlace"] = 0, ["time"] = 43228.691, ["initiator"] = { ["id_"] = 16778752, }, ["target"] = { ["id_"] = 0, }, ["id"] = 1, ["place"] = { ["id_"] = 0, }, ["weapon"] = { ["id_"] = 33554688, }, } See the "weapon" field? That's an Object, and while it's not a Unit, you can treat (or cast) the weapon as a Unit, and many of the Unit functions will or sometimes work. One that always works is Object.getPosition (Unit is a child class of Object, so it inherits Object.getPosition). Anyway, I'm attaching a mission, "Weapons Impacting on Runway Demo.miz". Here's the script it uses. This script has three main parts: THE EVENT HANDLER: Using mist.addEventHandler, we create an event handler that does the following: if a "shot" type event occurs (world.event.S_EVENT_SHOT), it captures each weapon's object and stores it in a table named "tracked_weapons"- but only if Unit.getTypeName returns a string typeName for that weapon that includes "BetAB_500"! So basically, it only stores BetAB-500 type bombs. Finally, in "tracked_weapons", the event handler also stores the name of the unit that shot the weapon, the initial position of the weapon, and the initial direction the weapon's nose is pointed (Pos3.x) as well. THE WEAPONS TRACKING FUNCTION: Using mist.scheduleFunction, we create a function that runs 20 times a second. This function looks inside the "tracked_weapons" table. For each entry in the tracked_weapons table, it first determines if that weapon is still alive. If that weapon is still alive, it updates the weapon's position, and updates the direction that the weapon's nose is pointed. However, if the weapon is no longer alive, then we assume that the weapon impacted somewhere (you couldn't make this assumption for missiles, however!). First, we erase this weapon from the "tracked_weapons" table. Next, using land.getIP, we get the point on the ground that the weapon was pointed at- BUT ONLY IF THAT POINT IS WITHIN 40 METERS OF THE WEAPON. If land.getIP gave us a probable impact point of the weapon with these parameters, then that's where we assume the weapon impacted. If not, then we use the last known position of the weapon. Finally, we compare this probable weapon impact point to five different polygon zones representing five different runway "segments". We make this comparison using mist.pointInPolygon. The polygon zones are created by the waypoints of five different aircraft groups (that are never activated). If the point is in one of the polygon zones, we store which polygon zone the weapon impacted inside, and who dropped the bomb, in the "runwayHits" table. Later, we will use this data for mission scoring and debrief. The runway "segments": MISSION SCORING: Finally, we run a scoring and debrief function that gives you positive points for hits made on the runway segments (each sequential hit on the SAME runway segment is worth 70% as much as the previous hit on that segment), subtracted by a "deathPenalty". The deathPenalty subtracts 175 points from your mission score for each aircraft lost. Dead aircraft are counted using mist.DBs.deadObjects. If your final score is above 200 points, you "win" the mission, otherwise you lose. A "two page" debrief is provided, the first page of which details your mission score, and the second page of which tells you which multiplayer clients hit which runway segments, and how many times they did so. Anyway, to see this all in action, run the attached mission. Bomb the runway. Now, select the "Ready for Debrief" option from the F10 "Other" radio menu. So to those who know Lua, we can already track weapons in zones (however, there will be some weapons types you will not be able to get the names of with Unit.getTypeName). I would indeed suggest, now that the scripting engine is incorporated officially into DCS, that it would be a good idea to start learning the Lua language if you haven't already. That said, we will, OF COURSE, continue to add to the selection of Mist Lua functions that are usable by persons without detailed knowledge of the Lua language, and we hope that this one day includes specialized Mist Lua functions for detecting weapons impacting in zones. Not everyone has the time (or desire) to learn programming, and that's what Mist is about- trying to save people time, and making mission creation easier :thumbup: Weapons Impacting On Runway Demo.miz

Mist can only eliminate the need for Slmod in some missions, unfortunately. There's a lot of things mission scripting just can't do.

Yes, both are possible. Grimes was already telling me he think it would be a good idea to have further refined categories. I am planning on investigating it. As far as flag off/unit outside zone/etc- they will probably be created one day, maybe a day not too far away from now.

Mission Lua scripts can't detect chat, but it should be possible to direct artillery fire (or AI aircraft) with smoke rockets- the only obstacle is whether Unit.getTypeName will work on smoke rockets... I THINK it does. If not, a fix might come in a patch. Because mission Lua scripts can't detect chat, what about this: Every time you put down a smoke rocket, its impact position is stored in memory and a timer begins. Every subsequent smoke rocket impact overwrites that position, and resets that timer. If the timer reaches like, 90 seconds, only THEN does the attack command (with the position of the last impacting smoke rocket) get sent to the AI. This would allow you some time to get the smoke mark correct before the AI tried to attack it. Who knows, it might also be that one day, mission scripts can detect chat and then the above logic is no longer necessary. Anyway, other weapons tracking functions would be a higher priority than this smoke marking script- I would probably need to include mist.weaponsShotBy, mist.flagFunc.weapons_shot_by, etc. And I would want to port all the Slmod weapons_impacting_in_zone functions in to Mist too. After all that, then we might get to smoke rockets for marking targets...

Damn... possibly something I want more than a chainsaw bayonet!!!!

Yes, the best work-around is to use a server-side mod to replicate similar functionality to the F10 "other" menu by using multiplayer chat :smilewink: As I understand it- this could be wrong though- the "create other radio menu/menu item" commands only occur once, if you're not around to "see" it, you won't get it. So this command would have to be stored somewhere/somehow. This info is also not communicated over the network to clients. And finally, there's a design decision- how exactly should these menus work for clients- should clients be allowed unrestricted access to these? If that were to happen, it would actually break a feature I'm sure SOMEONE out there is using- right now, the host has his own private set of menus to control mission trigger logic, that clients cannot interfere with. So, do we need to be able to specify WHO can use these menu items? So anyway, it's definitely a non-trivial design/programming challenge. No, it's probably not difficult, just time consuming.

trigger.action.outTextForGroup- and all the outTextFor functions- got broken during the process of building one of the patches (I think it was 1.2.1). Group.getByName(string groupName):getID() is indeed the correct way to get a group's ID for this function (though- you wouldn't want to use EXACTLY that code for an ACTUAL mission- you'd generate a Lua error if that group was not alive. So first, you'd want to make sure that Group.getByName actually returned a group before you tried using getID). Anyway, they should be fixed in a future DCS version. :)

Mist only has access to a portion of the game's Lua API that Slmod has access to. Mist is limited to only ONE DCS Lua environment; Slmod uses FOUR. Unfortunately, mission scripting has no info on the multiplayer client environment. Even if we had all the info on who were the clients, what they said in chat, what mission slots they were in, etc, we'd still need some kind of callback that was equivalent to server.on_chat, and also, we'd need an equivalent to net.send_chat (so that you could communicate privately to Combined Arms players and spectators). Basically, it is impossible to replicate SlmodMenu objects (POS, PTS, AdminMenu, Coordinate converter, ...) in mission scripting Lua, and it's unlikely that the necessary changes to the game's code to do so will be made in the near future (if ever).

I thought that perhaps it could have to do with having two copies of the DCS ME open at the same time, editing the same mission, but when I tried to reproduce it with this method, it didn't work. I'll try your method! Currently, the way to get information about weapons firing is to use an event handler. If the event is a shot event (world.event.S_EVENT_SHOT), then you treat the event.weapon table as a Unit, and use Unit.getTypeName on it- theoretically, this should give you the name of the weapon. However, currently, Unit.getTypeName does not work on all weapon types. For some, it will give you the name of the weapon; for others, it will give you nil. We hope this will be fixed in future versions of DCS, but as long as this problem exists, I cannot port the weapons_firing Slmod functionality into Mist. Or... perhaps I can, if we are OK with a mist.flagFunc.units_firing function that does not work for some weapon types?

Yes, this is part of why I prefer using DO SCRIPT instead of DO SCRIPT FILE. Also, you're probably aware of the rare "crap, my mission lost all its attachments" bug. DO SCRIPT FILE may also be affected by this bug; DO SCRIPT is immune to it. So yea, I like using DO SCRIPT instead. However, Grimes often prefers using DO SCRIPT FILE... to each his own, I guess. Yes, the Lua file is included in the zipped .miz archive, just like any sounds or pictures your mission might also use.

Yes Yes Anywhere the mission editor lets you put Lua, that Lua will run in the global environment, where it will "see" Mist.

Here's the mist.demos.printFlightData function applied to weapons fired. For example, load the attached mission "Mist Weapon Flight Data.miz", select an F-15, and fire an AMRAAM- the mist.demos.printFlightData will output real-time flight data for the weapon: When applied to player aircraft, there's still some shakiness in the acceleration-based values that I need to sort out, but angular data and velocity works very well- "Mist Player Flight Data.miz" is mist.demos.printFlightData applied to the player aircraft. mist.demos.printFlightData isn't really useful for mission scripting, that's why we put it in the "demos" table- it demonstrates some of the power of the Simulator Scripting Engine for collecting data about the game environment. You can embed Tacview-like data collecting into your mission itself, base mission logic off of it if you want, and if you "unsanitize" the io and lfs libraries in MissionScripting.lua, then you can even output your data to a file and graph it using like Excel or something. Mist Weapon Flight Data.miz Mist Player Flight Data.miz