Speed

Kerbal Space Program? :lol:

Well, I wouldn't use DO SCRIPT FILE. I just prefer DO SCRIPT. I usually write my scripts in Notepad++ and just paste them into DCS, but sometimes, I will write them in SciTE (comes with Lua For Windows). With SciTE, you can check for syntax errors. One thing you can do, if you really need to optimizing Lua testing in DCS, is you can modify ./Scripts/MissionScripting.lua so that it has access to the io and lfs libraries. With that change, you can load a new script file during the mission, like this- function doScriptFile(fN) local function log(s) print(tostring(s)) trigger.action.outText(tostring(s), 10) end local f, err = loadfile(fN) if f then local err, errMsg = pcall(f) if not err then log('LUA ERROR- unable to run ' .. fN .. ', reason: ' .. tostring(errMsg)) --catches runtime errors. end else log('LUA ERROR- unable to load ' .. fN .. ', reason: ' .. tostring(err)) --catches syntax errors. end end --[[useage example: if you have the file named "ScriptFile.lua" in Saved Games/DCS. Put this code in a DO SCRIPT action that is triggered by an F10 radio menu selection. ]] do local fName = lfs.writedir() .. [[\ScriptFile.lua]] doScriptFile(fName) end You could set up an F10 radio option to "load script file", for example. So no more restarting DCS, you just have to use the F10 menu option. It will re-load whatever is CURRENTLY in your script file, and try to run it, and report back any problems it encounters. Again though, you have to modify MissionScripting.lua and comment out the two lines where the lfs and io libs are sanitized. Well, technically, you don't need to un-sanitize lfs, but you might as well, since lfs automatically finds the path of Saved Games/DCS for you. And +1 for that tip about seeing dcs.log in real time, that could be very, very useful for me!

Yes, I saw this the other day. It's long overdue. It's due to the fact that they seemed to have discovered water geysers on Europa that shoot water out far enough to be sampled in a flyby. However, I don't understand why in the heck the Galileo spacecraft never spotted these geysers. Didn't it measure Europa's atmosphere? Or was that something else that measured Europa's thin oxygen atmosphere? Did Galileo lack the instruments? Anyway, until I'm sure of the certainty of the Europa geyser discovery, I will keep my excitement guarded. But I sure as HELL don't understand why Europa is not a higher priority. The surface of Europa is NOT old- it has very few impact craters. That means that the ocean must be serving as a source for resurfacing the moon in some manner. Which means, if there are lifeforms in Europa's ocean, getting a (dead) sample of them may be as "easy" as getting a surface sample. Obviously, some parts of Europa's crust are newer than others, and you want to go for one of the newer areas. You might also want to dig down a meter or two below the surface with a drill and get a sample that was less damaged by radiation. We'd want to know if Europan life was related to Earth life, or if it represented a separate genesis. That would require a DNA analysis- if this hypothetical Europan life even uses DNA, that is. DNA is fragile and gets destroyed in harsh radiation environments, so that's why you'd probably want to dig down a few meters if possible. Anyway, I do think that Europan life would probably represent a second genesis. It is much harder for life to hitch a ride on a meteorite from Earth to Europa, or vice-versa. First, the distances are much greater, and secondly, Jupiter's gravity requires a high escape speed on outgoing rocks, and on incoming rocks, it accelerates them to VERY high velocities. Additionally, Europa has no atmosphere to cushion a rock crashing into it, so any life on board a rock would almost certainly be annihilated in the extreme deceleration and heat of the impact. A rock crashing into Europa is subjected to FAR more extreme deceleration and shock than one crashing into Earth, Mars, or Venus. One more exciting thing I heard about Europa is that a few years ago, I read that a planetary scientist predicted that Europa's ocean could in fact be oxygenated. The way this is possible is that basically, Jupiter's harsh radiation environment bombards the surface of Europa with radiation, and the Sun also shines UV light on it. Both of these forms of radiation cause some of the water molecules in the icy crust of Europa to dissociate into hydrogen and oxygen. We already know that Europa has a VERY thin oxygen atmosphere due to this effect. Anyway, the radiation is able to penetrate into the ice a few meters, and some of the oxygen gets trapped there, in the crustal ice. The second step occurs when this oxygenated ice gets subducted into Europa's ocean layer and melts. The oxygen that was trapped in the ice now gets dissolved into Europa's ocean water! So not only could there be simple lifeforms on Europa, there could also be oxygen-breathing lifeforms, possibly even, multicellular oxygen-breathers. IF this researcher's findings are true, that is. I need to look up and see if I can find this paper, and see to what extent this researcher's findings have been rebutted or disputed.

I disagree, though it depends on what you use it for. CA required A LOT of code changes behind the scenes to get it working as well as it is, and it's still requiring changes to the engine here and there. It's not like ED just threw it together in an evening and released it. It's been a lot of work. While the tank sim aspect of CA can be fun (or even silly fun, as I previously posted) CA is most powerful NOT when you play it as like, a tank platoon commander, but when you play it as a combined arms ground commander, interfacing with aircraft, providing a simulation of intelligently-controlled ground forces, friendly or enemy. You're playing a combined arms battlefield simulation then. I've had a tremendous amount of fun in multiplayer being the guy on the ground, calling in airstrikes, handling artillery fire missions, moving forces and reacting to threats, capturing objectives, etc. While it takes a lot of skilled multiplayer pilots and a good ground commander to really make CA shine, when you get them all together, it's AWESOME, and worth many times what CA costs. While you can do this to a limited degree in single player, it's just not as good as in multiplayer- but that applies to everything in DCS, I guess. Unfortunately, most people who get CA just use it to drive around and shoot stuff, taking direct control of just a single unit. While that's fun (and I do it myself sometimes), if you're never playing as a commander on a combined arms battlefield, you're missing the whole point of Combined Arms.

Sorry, I can't tell you how to suck, but researchers at BYU can tell you how to urinate. Keep your ears open, because next week, researchers at the University of Alabama are scheduled to release the results of a 10-year study on how to read.

Try world.searchObjects http://wiki.hoggit.us/view/Part_1#world

For the record, as someone who is knowledgeable on this subject, these statements you are making show a lack of understanding about Lua and programming. Lua is NOT suitable for coding an aircraft. Lua is suitable is a SCRIPTING language. Even the Lua manual itself states that you are not supposed to make complex programs solely out of Lua. Lua is slower, much more difficult to debug, and much less capable than C++. It would be impossible to make a quality MiG-21 module solely using Lua, and also, DCS doesn't have the support for a Lua flight model and avionics, and it shouldn't, because something like that would be ridiculous. You HAVE to convert it over to a real programming language (in DCS's case, C++), and then that necessitates the migration of much of the rest of your code over to C++ as well.

Simulator- not intended for entertainment purposes. Game- intended for entertainment purposes. 99.9% of the people who buy DCS do so for entertainment purposes. Thus, it is a game, and graphics are important as they increase the amount of fun that people have in DCS. If people were buying DCS to learn how to operate an aircraft, they wouldn't care nearly so much about graphics, unless it was critical to what they were trying to simulate. In most cases, it is not.

When you're using triggers, all you're doing is writing Lua, really. The GUI-based triggers get converted into Lua by the mission editor, and the C++ DCS.exe runs that Lua in an embedded Lua environment. So you're already using a bunch of Lua you don't understand. So there is really no difference between using Lua scripting and using triggers, it's just that with triggers, you can't make a spelling, syntax, or runtime error because everything is pre-defined for you (except for when there's a bug in DCS where the triggers DO generate a Lua error). The tradeoff is that triggers are massively less capable. In this case, Mist is a third-party library that in effect, adds extra triggers for you. You don't have to understand how the complex, world events system works, how to tell a map object apart from a static object or unit, how to get the position in x,y,z, etc. Mist packages that all up into a "neat" little package, so you only have to specify the name of the function, and the values of a few variables. Finally, you "want to understand what I am scripting and not only enter some code I don't really understand"? Real-life computer coders have no quibble at all entering massive amounts of code they don't understand. They are called libraries, and without them, modern software would not be possible. For example, when I write #include <string> at the top of C++ file to add the capability to manipulate C++ character strings to the application I'm building, I don't know how the C++ string library works. I don't need to know how it works, that's the whole point- someone else figured out a good implementation of strings, published it years ago, and now everyone uses it so that we don't have to each spend months developing our own (probably buggy) solutions to the same problem. There is no point in re-inventing the wheel. That's the point of Mist. Someone figured out a solution to detecting objects within polygon-shaped zones, dead map objects, etc., and by including Mist, you don't have to understand how those details work behind the scenes. The point is to save you a bunch of work, allowing you to spend more time developing a quality mission instead of re-inventing the wheel.

Graphics or "photo-realism" are only important to a simulation where they intersect with the goals of the simulation. A simulation is supposed to model a real-life process as accurately as possible. Let us confine ourselves to relatively modern combat simulations. Where in real-life is photo-realism important in combat simulating combat situations? The answer is, when you're trying to use some kind of image processing (be it in the human brain or otherwise) to identify targets in a cluttered environment. For example, try simulating jungle warfare on a flat, green plane or even, DCS! Even from a helicopter's perspective, DCS is still insufficient graphically. For example, in Vietnam, scout aircraft would fly low and slow over the jungle, looking for truck tracks, trails through the grass, odd shapes in the jungle, reflections, etc. Even when using an infrared or visible light EO system on ground targets IRL, you still have to be very good about picking out targets. A hot rock can be hard to pick out from a tank, or even, a human body. A human can walk under a tree and hide. Automatic target identification and recognition algorithms, tracking algorithms, and the human and eye all have a difficult time finding and recognizing targets in a cluttered environment. That's why we have camouflage, to make that task even HARDER. So if you're trying to build a combat simulation of something where in real life, target identification in cluttered environments (i.e., the ground) is important, then photo-realism is ABSOLUTELY CRITICAL to having a realistic simulation. Let's take a different example to show where "photo-realism" is unimportant to the simulation. Say you're trying to simulate a fast, high-flying, modern multi-role fighter. As long as you stay away from CAS or interdiction missions, then graphics are relatively unimportant. You're firing at blips on a radar screen. Your typical ground targets are big buildings. Rarely, you might get close enough to another aircraft to be able to tell its shape and visually identify it. You can pretty realistically model combat in a modern multi-role fighter using graphics from Falcon 3 or Flanker 1, though if you go up to Falcon 4 or Janes F-15 level graphics, the job gets a bit easier. You do need to accurately model the cockpit, which those games did not do so well. But DCS level graphics are certainly not required for a realistic multi-role fighter. BUT... DCS is NOT a simulation. It is a game. There is an important distinction- a game is intended for entertainment purposes. A simulation is intended to model a real-life process, and entertainment is NOT a factor. As I said earlier, graphics only matter in a SIMULATION when they intersect with what needs to be simulated. However, a GAME is intended to be fun. Thus, graphics are very important to a GAME, as it allows you to more easily immerse yourself in the virtual world and derive entertainment out of it. That's where much of the fun factor comes from in many games- being able to pretend at some level that you're really there in the game. Anything that makes that leap easier, such as better graphics, makes the game better.

I'm no expert in dynamic spawning, Grimes wrote that part, but why are you modifying the DBs? They exist only for reference, like if you need to write some code that looks up what kinds of units, and how many, are in the mission. You should consider them "read only". You can't expect to modify them and expect something to actually happen as a result of it; that would be similar to making a page about yourself on Wikipedia, saying that you are a billionaire, and then expecting it to come true :) Again, I know little about how Grimes programmed the dynamic spawning, but looking at your code, it is clear you made at least one error. mist.dynAdd('dynGroupsAdded', 'usa', 'plane') should be mist.dynAdd(dynGroupsAdded, 'usa', 'plane') But I doubt that will work, as it doesn't look like the proper format for a group you're trying to add. Didn't Grimes include some examples in the documentation?

Actually Skatezilla, my experiences have been EXACTLY the opposite. To me, computers last longer and cost much less than they did 15, 20 years ago. I just ordered a brand new system with an i7 4820, GTX 760, 480 GB SSD, 16 GB DDR3 RAM, etc. It "only" set me back about $1600. It's to replace the $1300 desktop I bought five years ago. The five year-old system it's replacing still functions, and it can still run the latest games, albeit at reduced settings. I contrast this with the system I got in 1999, which was probably around the same relative quality, at that time, as this system is now. My 550 MHz 1999 computer only lasted me about 3.5 years and cost me over $2500. At the end of that 3.5 years, it was too slow and obsolete to run the latest games. Just think about how much $2500 in 1999 is in TODAY's dollars. $4000? $4500? I just got a similar relative-quality system, that will probably last me longer, for only $1600! Imagine... could you have used a computer that was a "hot" system in 1992 to play the latest games released in 1997?! Of course not! So I completely disagree with the assertion that computers have gotten more expensive; if anything they have gotten much cheaper.

How much study does it take to write a single line of Lua mist.flagFunc.mapobjs_dead_zones{ zones = {'bridge1'}, flag = 51 }? You must have very little time, indeed :D If you insist on doing it with triggers (aka, "the hard way"), try taking out the "on shot" event from your trigger, that will certainly make it not work. The problem with bomb in zone is that I'm sure it's only checked every second, just like the other triggers. Also keep in mind that the zone probably extends in altitude to infinity. If your zone is too large, you will be counting alot of near-miss trajectories that overshoot the target. If your zone is too small, the bomb won't even be inside it long enough to be detected, on average. And it doesn't even tell you if the map object really died in the first place. However, bomb in zone may in fact work well enough, if the map object isn't too small and hte bomb is moving slowly. I've never used bomb in zone myself though, as Lua affords much superior capabilities.

I think that issues with dynamically spawned units are fixed in internal DCS versions. At least, right now.

mist.getDeadMapObjsInZones mist.getDeadMapObjsInPolygonZone mist.flagFunc.mapobjs_dead_zones mist.flagFunc.mapobjs_dead_polygon These should still work, there weren't any changes to the way map objects work to my knowledge.