Speed

No, if you put it on a continuous trigger, you would end up locking up the game after a very short period, as every second you'd add a duplicate, 100-time-a-second, loop. It just needs to be run once, and then mainLoop will start looping forever. If can you upload the latest version of the mission, I can maybe try spending some time on it.

Yea, but they are bigger than us. Also, our brains grow tremendously as go through childhood, much more than any other creature. So while we might start out helpless we learn and adapt very well. But yes, certain birds (such as magpies, crows, ravens, maybe some parrots), dolphins, elephants, chimpanzees/bonobos, orangutans (but, AFAIK, not gorillas) have been shown to be self aware, sentient creatures. I'm not normally an animal rights activist, but I have a strong bias towards the more intelligent species. It's a travesty that they aren't provided more protections.

Grimes is right, for a good air race mission that has precise timing, a track that is re-transversable, stores best times, etc, you really need to: Don't get me wrong, triggers are great and useful, and when I make missions I still use quite a number of them. But an air race mission just doesn't lend itself to being easily implemented with triggers. Anyway, I don't have time right now to work up any kind of full example, but Grimes speaks of using Lua to achieve more precise timing. The following shows how to get started with this in Mist: function mainLoop() --<Your code> end mist.scheduleFunction(mainLoop, nil, timer.getTime(), 0.01) Any Lua code placed within the mainLoop function will run about 100 times a second- triggers only run 1 time per second. You can get unit positions with Object.getPosition, and check if they are in polygonal zones with mist.pointInPolygon, and get the exact mission time of various events/conditions with timer.getTime - and all this at a rate 100 times faster than triggers could do it. If you are in fact interested in learning the game's Lua scripting engine in more detail, an air race mission is a pretty good place to start- you can start with something fairly simple and scale it up over time as you learn more.

It's generally a bad idea to try to keep your keyboard settings for too many patches in a row.

Unit.getNumber must be called on a object of the Unit class (object, in this term, means the OOP definition of the word "object"). Each in-game unit has a Unit class object associated with it. One way (but not the ONLY way!) to get this Unit object is with Unit.getByName, where you specify the name you gave the unit in the mission editor. So, for example, do local playerUnit = Unit.getByName('Hawg 1-1') if playerUnit then local unitNum = playerUnit:getNumber() --<The rest of your code follows...> end end Unit.getNumber is one of the less-used Lua functions; oh, I can certainly think of examples that make it necessary to use, but in the maybe... 20,000? lines of Lua I have written for DCS since 2010, I can't remember a single time I ever used it, aside from testing it to make sure it really works correctly. Oh you might notice that, instead of using Unit.getNumber, I'm doing playerUnit:getNumber(). For most intents and purposes, playerUnit:getNumber() is identical Unit.getNumber(playerUnit), as you seem to already understand. It's just that playerUnit:getNumber() is easier to write (also, it demonstrates that you understand OOP programming and are using it as it is intended to be used). To understand the minor difference that does exist between Unit.getNumber(playerUnit) and playerUnit:getNumber(), you'd have to understand how Lua metatables work (particularly, __index). Also note that, since Unit.getByName does NOT accept a self variable of type Unit, it CANNOT be used like this <something>:getByName()- that doesn't even make sense. It must ALWAYS be used as Unit.getByName(string name).

This is not correct for hte A-10C. The bombs, when dropped from a high altitude, fall almost straight down. If your target is moving, by using too short of a lasing time, you risk the target (and hence, the laser spot) driving completely outside the bomb's FOV before the laser even turns on. By having a long lasing time, you risk nothing: Your bomb will always hit, whether your target is moving or stationary. Take-away point: ALWAYS use a long laser time, unless you are dropping from a really, really, unrealistically low altitude. See this: In the case of the above drawing, "Manually lased" means that the target was lased from the moment hte bomb dropped, with the laser activated manually. "Auto lased" means that the default auto-lasing time was used (8 seconds or 12 seconds or whatever the too-short time is). Probably, it's generally true that a manually-lased bomb will have a longer guided flight path than an auto-lased one. The drawing should probably be adjusted to say "long lase time" vs. "short lase time" though.

ED doesn't want you singing this the day that 1.2.3 is released: bb_OEaHfWII Just a little more patience, please. It's coming. And NO, you don't want to rush the cook ;) What is important to understand is that every new patch is including new features/engine updates/bug fixes. Those can cause serious unforeseen consequences (even the bug fixes- bug fixes can cause new bugs to surface), and if you were to, say, rush a patch, you'd be very unhappy with the results.

I wonder what their would look like.

Oh and also, AFAIK, if a helicopter is detection range of the radar, it should always be visible on Doppler radar due to their spinning rotors. That may be simplifying things a bit (the helo should probably be more observable when it's flying towards/away from the radar outside of the notch), but you're not trying to develop a detailed radar simulation, are you? Anyway, to check if a unit is a helicopter, you can use Unit.hasAttribute. However, the AI can be decently skillful at autorotations, after which the helicopter unit will be alive but completely shut down and stationary on the terrain, so you would probably also want to make sure the helicopter is actually flying before "detecting" it. To do that, use Unit.inAir. So your script would be blind to helicopters that are spooling up/shutting down on the ramp with blades spinning, which should indeed be quite detectable IRL, but that's a minor issue overall. Anyway, Mist will probably include a simple Doppler radar detection check in one of the next versions.

Your nap of the Earth method is not realistic. The condition for applying the ground clutter notch is whether or not the target is line of sight to the radar, and whether it is against a sky background or terrain background. If against a sky background, you do not apply the ground clutter notch. To check for sky background or terrain background, use land.getIP.

To make others understand your potential bug and your potential problem, you must allow others to replicate it. Thus, for most problems, you must provide a short and simple example mission or track (try to get it as short and simple as possible), and provide steps on how to replicate the bug. Otherwise, don't expect much help. Testers and veteran forum members are far too busy to go chasing around bugs by attempting to replicate them based on vague forum descriptions. And yes, your description was vague, simply because you did not include any kind of track or mission. I don't know anything about the AI's waypoints, tasks, enemy units, triggers, etc. On the other hand, sure, here on the forums, (assuming you do a forum search for the bug first) it's OK to make a quick question basically asking, "hey I just noticed this, is this a known bug?", and if the answer is "no, it's not known", only THEN to take the time to properly report it with a mission/track/whatever.

It's almost certainly not realistic, even by the limited definition of "realistic" as applied to science fiction, to have human-piloted combat aircraft 100+ years in the future. Maybe there would be a manual override mode that would allow you override the AI and fly it remotely, but the AI will probably be much better overall than a human pilot. Assuming continued breakthroughs in microelectronics, it's a good bet to assume that in much less than 100 years our machines will be smarter than us. To those that are skeptical, it is important to understand that our brains are still many times faster than the fastest computer, so it is should be no surprise that true AI has not been developed yet. I also kinda dislike the term AI; once AIs are finally developed, they will probably make us look like the ones that are artificial. "Machine intelligence" is a much better term. Edit: oh, looks like the fastest supercomputers are beginning to approach human brain computing power since I last checked up on the subject. The end is near! :D

http://forums.eagle.ru/showthread.php?p=1659425#post1659425 Maybe we can request that true north be used instead of the map x-axis for radio calls, but the developer in charge of that area of the code is quite busy.

I've posted the answer to this question several times before, but finding those posts can be tough, so you are forgiven for not finding them :) The DCS map is flat, but it has a spherical coordinate system projected onto it (Lat/Lon). Some game code (the ME, and last I checked, radio calls) use the map x-axis as the north direction, while avionics code uses a line of constant longitude as the north direction. It is probably best to consider this line of constant longitude the "true" north/south direction, as in the real world, it is. In the following discussion then, "true north" refers to this line of constant longitude in the direction of increasing latitude. So due to the projection used to map latitude/longitude onto the flatworld DCS map, the x axis only perfectly aligns with true north at the map's central meridian, 33 degrees longitude. If you are off of that central meridian, then "true" north is different than the x-axis. The further you get from 33 degrees longitude, the larger the difference exists between true north and the x-axis. In the areas where we typically fly missions, the x-axis is typically 3-7 degrees to the east of true north. It would probably be best if, for all displays of direction, true north was used, but the problem is relatively minor overall.

I prefer MP missions. I prefer more missions using Combined Arms commanders, or Ka-50, or Su-25/Su-25T. I am sick of the A-10C. F-15C is too easy unless you're flying against human opponents, and even then, I don't enjoy air to air as much as a good old ground war. So I can only vote on one of your choices.

You need to wait till patch 1.2.3. Assuming all goes according to plan, after 1.2.3, we will be releasing a new version of Mist. This new Mist version will provide a Lua function that allows ground units to do an action very similar to the "switch waypoint" airborne group AI command.

Yea, you're probably the first one posting one, good job. GCI would be one system we'd like to incorporate into Mist. However, I'm waiting for certain scripting features that are likely to arrive in future versions of DCS.

It's not possible to deactivate multiplayer client units.

Agreed. Unless there is an official announcement, all this talk about DCS: F-18 is just hearsay.

Try this: do mist.flagFunc.units_in_polygon{ units = {'RB #1'}, zone = {[1] = mist.DBs.unitsByName['G11'].point, -- unit names of the boats at first pylon [2] = mist.DBs.unitsByName['G12'].point, [3] = mist.DBs.unitsByName['G13'].point, [4] = mist.DBs.unitsByName['G14'].point,}, flag = 1001, stopflag = 2001 maxalt = 300, interval = .1 } if trigger.misc.getUserFlag(1001) == true then trigger.action.outText('Gate 1 \n Timer started',5) end end Don't have the time to test it right now though, but the above script has fixes to several of the problems you had in the first script.

Can you trigger a HMS failure? I've never messed with failures before so I don't know. Edit: No. :(

Cukier, for future reference, questions involving the simulator scripting engine belong in the Mission Builder's Corner. ;)

Ok, here's a quick example. At the end of autoexec.lua, add this: --Beginning of TigersharkBAS mod do local missionData -- stores mission data for TigersharkBAS's mod. local oldFunc = {} oldFunc.extractMissionData = debriefing.extractMissionData debriefing.extractMissionData = function(mission) -- redefinition of debriefing.extractMissionData missionData = mission ------------------------------------------------------------------------------------------- --[[ASSUMING that debriefing.extractMissionData only runs one time, at mission start, then you maybe can use it as a "on mission load" event to start your "main" program loop (and kill the old loop).]] if tigershark.mainId then timer.removeFunction(tigershark.mainId) end tigershark.main() -------------------------------------------------------------------------------------------- return oldFunc.extractMissionData(mission) -- now do the old extractMissionData function. end -- do the JTAC 9-line redefinition the same way. -- If you need a "main" program loop, then you can construct one like this: tigershark = {} tigershark.main = function() -- your main code... tigershark.mainId = timer.scheduleFunction(tigershark.main, nil, timer.getTime() + 0.05) -- tigershark.main will run 20 times a second. end end

Tigershark, Sorry for not answering sooner, I just have a lot of stuff going on right now, and what you really need is the kind of detailed answer that will take nearly an hour to make. In the meantime, I can give you an overview. First of all, the phrase, "Getting Mission data from export.lua by accessing Mission environment in RAM" doesn't make much sense, unless I'm interpreting it wrong. export.lua is in the "export" Lua environment. It can't access the "mission" environment. First of all, I would like to know why you think you absolutely need to get mission data through RAM. It only adds between 50 to maybe 1000 milliseconds of simulation load time to get the mission through C: instead, and it can be done easily. After you have found the mission data over C:, then it's forever accessible to you via RAM (because you saved it to a Lua variable) and it takes only nanoseconds to access. Anyway, if it truly is a hard requirement to get it solely through RAM, then you have a few options. - net environment mod: access mission data via net.dostring_in("mission", <lua code>). Drawback: you could interfere with other net environment mods like Slmod or Servman; that said, it wouldn't be hard for me to make Slmod v7 look for your mod and run it. Net can also access the main simulation Lua environment. The problem with net is that if you used it, your mod would only work when you were a multiplayer host. - MissionScripting.lua: mission scripting is passed env.mission, which is all the mission data. You could send this data out of mission scripting via LuaSocket. Drawback: you would interfere with Slmod which also uses MissionScripting.lua, but it wouldn't be hard for me to make Slmod v7 look for your mod and run it if it exists. - main simulation environment mod- this is probably the prefered option. The debriefing module receives the mission table, but it remains a local variable inside functions. You could make it save the mission table to the global environment. - Final option: I created a function that will get you the mission data in any Lua environment that has io and lfs modules available to it, but it goes through C:. ------------------------------------------------------------ The functions that build the 9-line exist in ./Sounds/Speech/NATO.lua. This is part of a module in the main simulation Lua environment. So you would need to modify the appropriate function that generates a 9-line to either save that data to the global environment or send it over UDP via LuaSocket to whatever environment you will use. Anyway, as you can see, I never mentioned export in a single breath. Export is pretty useless for what you want to do, forget about it. Anyway, what you need is obviously a main simulation Lua environment mod. You could base it out of autoexec.lua. You don't need to actually modify the debriefing.lua and NATO.lua files, you merely need to modify the functions that those files create. Redefine them to do your code in addition to ED's code.

You realize all this means is that someone is working on it.