Jump to content

Speed

Members
  • Posts

    4139
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by Speed

  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. Try world.searchObjects http://wiki.hoggit.us/view/Part_1#world
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. I think that issues with dynamically spawned units are fixed in internal DCS versions. At least, right now.
  14. 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.
  15. Did you ever play Falcon 4? Did you ever look at how incredibly simple the ground unit simulation was? DCS's ground unit simulation is good enough to make a game out of it (CA). Falcon 4's ground unit simulation is ridiculously basic. Ground units have very simple weapons and engagement logic; they can cross any terrain at all- water, mountains, etc. Their AI is super-basic. They only can exist in one formation (a long straight line), though that formation will break up a bit when they are moving. They aggregate into a single object when you get further than like 20 NM away from them. DCS does a massively better job simulating ground units than any flavor of Falcon 4. They could do such an awful job on ground units in Falcon 4 because you were flying an F-16 at like 25k feet most of the time, and ground units and ground battles were just flashes of light, tiny specs, and little blips on your radar. Ground units did not behave in a rational, real-life manner like they do in DCS. In other words, the makers of Falcon 4 did only what they needed to do to make a good enough ground war simulation from the perspective of a Viper driver. Falcon 4's ground simulation would NEVER even be CLOSE to good enough for anything like Combined Arms, and it would be severely lacking from the perspective of a Warthog or Apache driver. It comes down to the fact that DCS is a smaller scale, vastly more detailed, general simulation engine, while Falcon 4 was extremely specialized for a high speed multi-role fighter.
  16. Events are automatically triggered. Every time a world event happens, all event handlers are run. If you're asking where you run the Lua script itself, then you run it anywhere in the mission scripting environment. You can do it on mission start, on a once trigger, etc. You can use the DO SCRIPT trigger action, DO SCRIPT FILE, you can do the DO SCRIPT AI triggered action or waypoint action, etc. I prefer the DO SCRIPT trigger action.
  17. Maybe... but you run the risk of over-complicating and the AI and running into all sorts of problems related to things like situations you didn't think of or anticipate, or the wrong behavior or the behavior always being the same, or the behavior logic getting stuck, etc. A much more elegant solution is to try to find the simplest logic that will achieve your goals. For example, while testing the ability to order ground unit AI through Lua scripts, I made a "Unit diffusion test". Basically, I give the ground AI offroad waypoints in random directions and for random durations, and I watch them "diffuse" across the map at high rates of time compression. Now, what if you add a slight bias to the diffusion direction? Now you have units that randomly diffuse across the map, but there is an overall preference to one direction. Just through random, dumb luck, these units will find their way around obstacles, the mission will never play the same twice, and all sorts of unexpected stuff will happen. Players of the mission, if they are unaware of how the logic actually works, will even confuse some of the random actions for intelligent actions like counter-attacks or retreats. Humans are always trying to imbue random, mindless things and phenomenon with reason and intent, and you as a programmer can use this against them to make them think your logic is even better than it really is :D Anyway, the point is, simpler is better, as long as the simpler solution is not hugely less capable. I think it's not about trying to program in every single situation the AI could face and how the AI should react; it's about trying to find a set of simple logical rules that each can deal with a lot of varied situations.
  18. I'm sending my response as a PM. We need to discuss dynamic campaigns here, and I don't want to get in trouble :). If you want to, open a topic about this in the off topic discussion forum. However, it's dangerously close to a religious discussion. It basically boils down to without there being a God, MI is certainly possible and there's no reason to believe we won't achieve it barring that human civilization doesn't collapse first. With a God, then all bets are off, on, well, pretty much everything, but machine intelligence, especially.
  19. Well, I've done some serious stuff, where I was a human ground commander, facing off against another human ground commander, and calling in air support from humans flying overhead in Ka-50s and A-10Cs, who were also calling in artillery fire missions. That was really fun! But I've also done really dumb stuff like this, which was also really fun! FcgJkqWHSJk
  20. Going off-topic a bit, but evolutionary systems do a pretty good job of optimizing a system, at least around a certain equilibrium point. So our brains are probably pretty well optimized, at least for the types of neurons and neural structures that we use. So it stands to reason (discounting the religious argument that the laws of physics are violated inside the human brain) that once we have computers with the equivalent processing power of the human brain, then AI is possible, and it becomes "just" a software problem. The fact of the matter is, at least one of the reasons we have not solved the AI problem yet and made true machine intelligence is simply because it is only very recently that we began to create supercomputers that rival the human brain in equivalent computing power. Last I checked, the Chinese government had created a super computer with about the power of a human brain; if I remember correctly, it requires like a few dozen MEGAWATTs to operate at full power. Anyway, part of the problem lies in trying to accurately calculate the computing power of the human brain. A recent study I read suggested that we might have underestimated it by a factor of 10 or 100. But, given the growth of computing power, there's no reason to believe we won't be able to reach that threshold. By the end of this decade, we should have several supercomputers that exceed the processing power of the human brain, unless the study I mentioned above in true, in which case, you will probably need to wait an extra decade or two to achieve that higher threshold. So the point is, assuming that the human brain is just an electro-chemical computer, then OF COURSE true machine intelligence hasn't been invented yet. It's impossible, we simply don't have the hardware to make it possible. But what happens when every university has a computer that does more calculations per second than a human brain does, and people really start trying to tackle the software problem? We'll certainly reach that point, at least. And if trends have anything to say about it, a decade after that, you'll be able to go to the store and buy a computer that does more calculations per second than your brain does. There will be a lot of people running AI research, on systems that are truly capable of being sapient, with just the right software. Whether it is through evolutionary algorithms, deliberate design (or more likely) some combination thereof, it will happen eventually, as long as the assumptions about the human brain being an electro-chemical computer, and the continued growth of computing power are correct. And both of those assumptions are things that most scientists agree on.
  21. 29, single, electrical engineer, job status: graduate student Started simming in '96 at age 12 with MSFS 95 and then I moved to Jane's USNF when I realized I couldn't blow up anything in MSFS except myself :(
  22. When I Googled the name you provided, I couldn't find a single relevant page in English, so I don't know what this is about, really. Sorry; I don't speak German. Did you win some kind of trip with Virgin Galactic or something?
  23. Generally, the X-52 is considered the minimum "good" stick. But any joystick at all is better than none. You're looking for a joystick that includes a lot of buttons and hats switches, and a throttle control. Anyway, it does sound like the game was stuck on pause.
  24. The point was, this speculation does nothing except entertain (some of) us. I agree entirely with you that we shouldn't speculate and make up fantasy tales about the MiG-21 dev team. I just "took offense" that you said that fantasy, fairy tales, and fiction are useless... they make very good novels :) I guess you didn't realize that my post linked to an Amazon wish list of science fiction and fantasy novels... the point being, that's where we should be going if we want fantasy ;)
×
×
  • Create New...