Speed

Nope. And it would be a very bad idea to make it work that way, too- what if you were running units_LOS (or any other similar function like units_firing) on a humanable unit that might spawn or despawn at any random time in the mission? No, these functions only stop looping themselves if you set the stopflag to true.

Not that surprising, ED sometimes drops hints :) Of course, nothing is official until it's announced. Everyone should keep in mind that this could be another side project, or a military product, and/or it may prove not to work out. Personally, I think Yo-Yo just has too much time on his hands. That's a good thing, BTW. The guy is a flight modeling maniac.

This already exists. It's a game called "Dangerous Waters". It's a modern naval sim, and a very deep and complex one, too: http://en.wikipedia.org/wiki/Dangerous_Waters Unfortunately, the fan base for it is even smaller than for DCS, so I've never really gotten into it much, other than do a few missions in the Los Angeles or Seawolf boats (which themselves are very little changed from the previous games of the series). Having played Jane's 688(i) Hunter-Killer and Sub Command (two previous games from this developer), I didn't have to delve into Dangerous Waters' 600 page manual to operate these boats :) Oh yea, I did fire the MANPAD out of the top of the Kilo sub on a few aircraft, it was good fun to finally get revenge on the ASW helos that have haunted me since 1997.

Hmmm... don't you think that perhaps Diablo III is a little too old-school? Modern RPG gamers I think are going to want more. It's kinda hypocritical for me to ask this question, since I defend Starcraft II as NOT being too old school. However, I view the original Starcraft as being nearly the perfect refinement of its genre of RTS (WC III made some improvements). I don't really see much to improve on. Even then, SCII came out with some major improvements in single player campaign mode, match-making, and even more complex and varied strategies and combat mechanics. But the core was essentially the same. However, the original Diablo II had lots to improve on. Skill trees lead to overwhelming reliance on single spells (or just a couple), the simplicity of combat mechanics made it too prone to cookie-cutter builds, there was an over-reliance on gear, the end-game content was almost non-existent, and then all the hacking and duping that ruined multiplayer. The intervening years have seen vast improvments in the RPG genre, with games coming out with far more dependence on skill, FAR more complex combat mechanics, very open-ended quests, large, explorable worlds, etc. Diablo III looks like nothing more than a graphically upgraded Diablo II. I hope I'm wrong about this, but if not, it will be Blizzard's first major failure.

Actually, I think the problem is more that ED does not do a very good job modeling camouflage yet. We don't have enough ground clutter for targets to get lost in. It's a simple graphics engine limitation. You view this as an excuse to limit the resolution of your eyes to a level that is mathematically proven to be unrealistically bad? I don't. Sometimes, targets are truly against a background where they stand out well (even tanks), and they will be EASILY spotted from more than 6000' away- such as vehicles on roads, out in the middle of fields with no camo, driving, etc. But yes, if the enemy has time to prepare and camouflage themselves in a stationary position- yes, it's unrealistic to expect them to be able to be spotted visually from more than a mile away. Sure. I can agree with that much. A good mission designer with a lot of patience (STP Dragon is very good at this) will still find spots to put targets, however, where they are very well camouflaged, and even with zoom, you'll have to get really close to see them.

So you find all your targets with the targeting pod? I find many of mine with the Mk1 eyeball (maybe 30%). Really depends on the situation though- sometimes, I use only the TGP, and sometimes, I will use almost exclusively the eyeball. Your vision must not be very good though, because math can quite easily prove that if you're not using zoom, then you're not seeing nearly as much as a real pilot would (real AIR FORCE pilots have excellent vision). But if you rely solely on the TGP for acquiring targets, it is true- zoom is much less important.

Yes, you can't talk about megapixels and the human eye. It doesn't work that way. Our central area of vision is highly detailed, but only a few degrees across. We possess a pretty good short term visual memory that helps to fill in the blanks, however. My rule of thumb is that the best human eyes can resolve details about 1 arc minute across (1') - that is 1/60 of a degree. 20/20 vision probably has a resolution of like 1.5' or 2'. So the point is, in the simulation, we need to magnify to the point where we can at least achieve this resolution of the game world with our own eyes. Let’s just take ONE example- assuming you have good enough vision and are sitting close enough to your computer to resolve each pixel on your monitor, and that ED’s LODs and graphics engine exactly reproduces how a scene would look except for the limitations caused by sampling (it doesn’t), then a 1920 monitor where the horizontal span is 40 virtual degrees means that each pixel spans 1.25 arc minutes of the virtual world ( (40 degrees/1920 pixels)*60 arcminutes per degree = 1.25’). However, this is actually under-sampling if your goal is to produce 1.25' resolution. Applying the Nyquist criterion, then at this zoom level, the widest angular spacing that can be resolved will be 2*1.25’, or 2.5’. This is worse than what someone with 20/20 vision can do. Suddenly, the default max zoom level of 20 degrees looks pretty good, huh? (not sure which dimension this is applied to, however). I don’t have enough time to go into the mechanics of the other factors- How far are YOU sitting away from your monitor? How good is YOUR vision? How good are ED’s LODs for this object?- this is a rather old topic and I get tired of discussing and defending zoom. In the end, zooming in all the way on the HUD isn't unrealistic at all. In fact, not using zoom at all is VERY unrealistic- when you don’t use zoom, it’s like you’re simulating someone who is nearly legally blind flying an A-10. Furthermore, the times that I have flow with pilots who admit to not using zoom- not a single one has been any good at A-10- I have to find all the targets for them. And furthermore, with a small edit of the game’s Lua files, you can simulate binoculars by allowing yourself to zoom in even further. Real A-10 pilots carry binoculars. So, if you want to simulate what would happen if a legally blind pilot flew an A-10, and you want to suck at the game, then don't use zoom. However, if you want to have a more realistic simulation, and you want to not suck a the game, then use zoom. Your choice. I don't think it's a very hard one ;)

The reason for the flag loop is to make sure that the units_LOS functions are always called at the correct time, such as in the example: Once-> Flag is true (17), Time Since Flag (101, 17 sec) -> AI TASK (Run Script(Blue 17 units_LOS)) Actually, it's not all that important- what is most important is that you make sure that the units_LOS calculations are spread out over time. Using a flag loop is one way to help ensure that. But if you activate all the random groups you are going to use at mission start, it's unnecessary. For example, if you activate all your groups at mission start, then you only need to spread out your units_LOS calls with the TIME MORE condition. Here's a complete example: Blue random variables for group activation: MISSION START(random variable for blue 1)->RANDOM (15)->SET FLAG (301), ACTIVATE GROUP('blue 1') MISSION START(random variable for blue 2)->RANDOM(15)->SET FLAG (302), ACTIVATE GROUP('blue 2') … … … MISSION START(random variable for blue 50)->RANDOM(15)->SET FLAG(350), ACTIVATE GROUP('blue 50') Red random variables for group activation: MISSION START(random variable for red 1)->RANDOM(15)->SET FLAG (401), ACTIVATE GROUP('red 1') MISSION START(random variable for red 2)->RANDOM(15)->SET FLAG (402), ACTIVATE GROUP('red 2') … … … MISSION START(random variable for red 50)->RANDOM(15)->SET FLAG(450), ACTIVATE GROUP('red 50') Start LOS scripts for blue ONCE->TIME MORE(1) AND FLAG IS TRUE(301)->AI TASK(Run Script(blue 1 units_LOS function call)) ONCE->TIME MORE(2) AND FLAG IS TRUE(302)->AI TASK(Run Script(blue 2 units_LOS function call)) … … … ONCE->TIME MORE(50) AND FLAG IS TRUE(350)->AI TASK(Run Script(blue 50 units_LOS function call)) Start LOS scripts for red ONCE->TIME MORE(1) AND FLAG IS TRUE(401)->AI TASK(Run Script(red 1 units_LOS function call)) ONCE->TIME MORE(2) AND FLAG IS TRUE(402)->AI TASK(Run Script(red 2 units_LOS function call)) … … … ONCE->TIME MORE(50) AND FLAG IS TRUE(450)->AI TASK(Run Script(red 50 units_LOS function call)) This would do the trick too, if you’re activating all your groups that will EVER be activated at mission start. The flag loop was only there to help ensure that the units_LOS calls were spread out over time, and it’s only useful if you’re activating groups randomly, at different times. Even then, if your activation times are random enough, it won’t matter much, as the probability of getting like five or six “overlapping” units_LOS calls is pretty unlikely. I'm just kinda obsessive-compulsive about covering all possibilities and leaving no possible logical holes/problems. Code I write probably tends to be more reliable, but slower to execute, due to all of the checking and double-checking I do.

Well, it seems that the most vital and useful security we need is to just make sure that it will always be possible to identify people via UCID and IP, and ban them. The number of folks out there that actually hack the game like this is very small- 1 person, seemingly. So long as the security of the UCID holds, and servers can always kick them, then they won't be a problem but once for each server. Banning by IP will be less useful, due to proxy servers, but it will add one degree of complication to the efforts of a hacking loser.

Looks like humans aren't the only denizens of Earth guilty of hosting animal fighting rings: WQd9kuXpUYU

Looks like you need to create 100 units_LOS calls then, each with #unitset1 = 8 and #unitset2 = 400 ("#" is the table size operator). Set the interval variable to 50, and the checks variable to 50 or 75. Create a flag loop: Once-> Time More (1) -> Set flag (101) Switched->Time Since Flag (101, 51 sec) ->Clear Flag (101), Set Flag(101) Now, when you randomly activate each group, also set a flag, such as this: (Random Activation Conditions True) -> Activate Group (Blue 17), Set Flag (17) To run each units_LOS function, do something like this: Once-> Flag is true (17), Time Since Flag (101, 17 sec) -> AI TASK (Run Script(Blue 17 units_LOS)) Also, set a stopflag for each group. For example, make the stopflag for Blue 17's units_LOS function be flag 217. Now, when the group Blue 17 is dead, set the stopflag, to make sure that the units_LOS function for Blue 17 is still not wastefully looping: Once->Group Dead("Blue 17")->Set Flag (217) With all these tricks, you ought to get acceptable performance even in the current version of Slmod. You are only running units_LOS for groups that are actually active, and when those groups die, the stopflag for the corresponding units_LOS function is being set true, and stopping that units_LOS loop from looping any more.

Also, you can see some time-staggered units_LOS calls in the LOS-based tasking example mission, http://forums.eagle.ru/attachment.php?attachmentid=60051&d=1323598989

Yea, that sounds like you could quickly get into the realm where you start noticing micro-pauses when the scripts run. This is where you want to utilize the "interval" and "checks" variables properly. For one thing, say you want to do LOS checking between 60 vs. 300 units (so the size of "unitset1" is 60, and the nominal size of unitset2 is 300). You can split this up, divide this task, so instead of making like a 150ms stutter, you get a very slightly lower frame rate. Here's how: 1) Divide the LOS task into fifteen separate calls. Each call does 60 vs 20 (20 out of the total of 300) 2) For each units_LOS function call, set the interval to 15 seconds. 3) Now stagger the calling of each of these units_LOS function calls, like this: Once->Time More (1) -> AI TASK (Run Script(units LOS for unitset1 and 1-20 out of 300 of unitset2)) Once->Time More (2) -> AI TASK (Run Script(units LOS for unitset1 and 21-40 out of 300 of unitset2)) Once->Time More (3) -> AI TASK (Run Script(units LOS for unitset1 and 41-60 out of 300 of unitset2)) ... ... Once->Time More (15) -> AI TASK (Run Script(units LOS for unitset1 and 281-300 out of 300 of unitset2)) So now, instead of one big 150ms pause every 15 seconds, you divide the computations into fifteen parts and get fifteen undetectable 10ms pauses, with one "pause" occurring every second. :thumbup: Also, for just 10km max range, you can probably use a checks variable value of 50. That's, at worse, one terrain height check every 200 meters. That will usually be sufficient. Anyway, the next version of Slmod will make significant performance improvements to many functions, and units_LOS will benefit more than most functions from these performance improvements, in fact.

It does seem like rocket motor smoke and dust clouds don't linger long enough. Dust falls so quickly in game! I suppose it's a trade-off with performance though... if you have a ton of lingering smoke/dust trails, you're going to have one hell of a frame rate hit.

I like the sound of this! :thumbup:

Right, well, like I said, you will have this problem regardless of whether my mod is installed or not. The code that has the error is ED's code, not mine. This mod makes only very minimal changes to NATO.lua. What I had to do was to define a new radio sound that could be played ("delimiter", a pause), and tell the alphanumeric phrase constructor to play a pause in speech ("delimiter.wav") when it sees a space in an alphanumeric phrase. This really only required the addition of a single line of Lua IIRC. The code that is having the problem deals with creating the threats briefing in the nine line remarks.... in other words, this error is on ED. I think it may be caused by specific ground unit type, but I honestly haven't investigated it fully.

Yes, it is annoying to have to test in multiplayer. That said, Slmod functions that detect a certain condition or event simply set a flag to true. So you can test your mission trigger logic in single player by just manually setting the proper flag to true at the proper time by using the F10 other radio options menu. So you can still test most everything. Another thing that isn't mentioned is that Slmod functions will not run in tracks, as replays and tracks are run in single player- heck, you can't even see chat messages in tracks. So Slmod missions will not replay correctly, not if you had some mission trigger logic that was dependent on the flags being set by Slmod. This is a small price to pay though, IMO, as tracks rarely work for more than 30 minutes even with NO mods. For some basic information on how to use it, I created a few youtube videos: Also, you will find the quick reference guide will tell you almost everything you need to know, and give you programming examples. I also have example missions. See the link in my signature.

The only thing that will allow you to do this is using Slmod's units_firing function. Then you will be able to set a flag based on when a specific unit or set of units fires a weapon. You can optionally specify the weapon type, too. Note that this will only work when the game is run in multiplayer, but there's no reason why you can't make a single player mission and run it by yourself in multiplayer.

Guess what? Now I hear people saying ED can't make an air to ground radar. I'm glad to hear it, because that means we'll be getting an F-18 or F-16 or F-15E next then :)

No, not at this time, sorry. For now, you'll have to add every single unit that could hit them to the table. Next version, things will be much more simple, you'll just be able to specify something like '[red]' and it will add all red units to the table automatically. But for now, only the hard way works.

This problem has nothing to do with the mod, it's the same problem as reported here: http://forums.eagle.ru/showpost.php?p=1376482&postcount=5 I know how to fix this issue. Hopefully sometime soon, I will be creating a radio bug fixes mod, and this one is one of the bug fixes I intend to make.

No, of course not! Just use the mission editor to place the necessary vehicles and static objects. If you need to learn how to use the mission editor, there are a hundred or two hundred pages devoted to it in the GUI manual.

At waypoint 0, set the F-15s reaction to threat to "evade fire". He'll try to spoof the missiles (unsuccessfully).

Just use an orbit action at an altitude of zero and a speed of 0, and you get the right effect. The problem with having the land would be you can't make them take off again. Really what would be better is if they just had a helicopter "land on terrain" waypoint/triggered action.

Because I've been looking through the game's Lua files for the past 18 months. I remembered that there was what appeared to be a listing of FARP service vehicles inside the file FARP.lua. FARP command posts, FARP ammo dumps, FARP tents- you can find them under the static objects list too (select "Structures" instead of "Heliports"). Find the necessary vehicles, like M-818, under the lists of units you can place after you place a vehicle group. JUST BE CAREFUL- do NOT get you vehicles from the "Ground vehicles" list of static objects- otherwise, they will be just static objects, not vehicles.