Speed

Oh my god, I think I'm going to be sick :D Looks great though. I guess my question would be- how does this affect ship aiming? Does CWIS/SAMs/TLAMs/etc become unusable at some point? Or does the AI keep trying to fire it, but the weapons are ineffective? I'm wondering about a few possible complications.

Hmm... that one does look like a step up. At least, like most others, they don't say "EQUIVALENT TO A 50" TV!!!! seen from 100 feet.". They just go right out and tell you- 45 degree diagonal FOV. As far as using one of these for DCS... how would you see your keyboard/cockpit/etc? Personally, I'm waiting for wider FOVs and lower prices. But won't that still leave the major problem: how to see your computer/keyboard/HOTAS/switches/etc. with this big thing blocking all your forward vision?

If it's not a feature of the real aircraft, they aren't going to model it, sorry. Still not quite sure what you're talking about. I assume the Ka-50... it sounds like you are not using the trim correctly, regardless. It's not the "correct" way to fly, but maybe you could try using the Flight Director mode (FD AP blue button near the AP channels). Lots of people use it. Personally, I'm a fan of trim-trim-trim, and then trim again. Also, when using the trimmer correctly, you hold down the trimmer button ("T") while making a maneuver, and only release it after you are done maneuvering.

Meh, without a radar, you have to use the F10 map too much, which spoils the "immersion" :D: (watch in 720p if you're going to watch it).

I'm afraid that Diablo 3 might be a little too... old school for my tastes. I'm going to wait a few days after release and check out some reviews. I love Starcraft II, and how "old-school" it is, because I think it is the best ever collect-resources-and-build-a-base-and-army style RTS. Basically, I think that WC I, WC II, SC I, WC III etc. defined the essentials of this style of game, and that this style of game is conceptually "complete". There are no, or few, further innovations that can be made to basic gameplay. It is a mature game concept. However... Diablo III- well it's an RPG. I'm not sure the same applies here. Look how far we've come in the RPG genre since Diablo II was released. I'm scared Blizzard learned the wrong lesson from Starcraft II. So I guess my question is.. What is the Diablo III end-game content? Diablo II's end game was awful. Does gameplay consist of more than using the same spell over and over and over again? After playing WoW, where I had like 6-12 spells/skills I would commonly use (this was back before any expansion packs), and then a little bit of SWTOR for about a month and a half (I quit because it was taking time away from DCS), where I actually had like 15-20 skills I would commonly use (I played a very complex class), I'm afraid an RPG where I just spam the same one or two skills over and over and over again forever won't appeal much to me anymore.

Thank you! That looks awesome. I had no idea how to do what you did with Excel. Well, maybe I did at one time. But then, along came MS Office 2007, and I had to get help from someone else just to save a file. Five years later, I still struggle with MS office 2007. Anyway, maybe I can use your file as a "programming example", and eventually make an Excel file that will assemble any Slmod function call. ANYWAY... I spent a lot of time working on the weapons impacting in zones functions this weekend. I now have slmod.weapons_impacting_in_zones and slmod.weapons_impacting_in_moving_zones working. The functions slmod.weapons_in_zones and slmod.weapons_in_moving_zones are almost complete too (the difference is that the "weapons_in_zones" functions detect the presence of weapons in zones, regardless of whether those weapons impact, or just fly through). Anyway, I had some good fun laying down smoke and having the AI run in on the targets I marked with smoke this evening. Maybe I'll set up a human Ka-50, AI Su-25 co-op mission and upload a youtube of it tomorrow or the next day. The problem is, I really suck at naming things. If I ever have a kid, the wife will definitely have to name him/her, otherwise they'll just end up being named "Human Child" or something like that. So right now, the problem is that these function names are ridiculously long: slmod.weapons_impacting_in_zones slmod.weapons_impacting_in_moving_zones slmod.weapons_in_zones not so bad slmod.weapons_in_moving_zones I've been trying to think of a shorter name for them that still encapsulates what they do, and that follows the naming conventions I've used for other functions, but I can't think of one. I suppose I could abbreviate weapons with like wpns, but that doesn't really help all that much... maybe they will just have to keep these ridiculously long names.

As I understand it, the only ties with Ubisoft that remain is a contractual obligation that requires any "Flaming Cliffs" series game to require that the original LockOn be already installed during the Flaming Cliffs installation process. Once you are done installing Flaming Cliffs 1/2/(3?), LockOn can be removed from your system.

Moderators also have a "delete" button, you know :smilewink:

Sure, there's lots of online pilots who are black. The demographic is a little under-represented, but it's significant. I've met several online over the years. The first squad I was in back in Falcon 4, the CO was black.

Just admiring some of the weather effects.

Maybe a case of the AI actually being smarter than you? Maybe those T-80 drivers took one look at that bridge and said "NO EFFIN WAY that thing can support 18 of us!". Of course I guess would imply they're still too dumb to know how to take turns :)

Your tax dollars hard at work- the Pentagon commissions a study of the study on studies: http://news.yahoo.com/not-joke-government-issues-study-study-studies-170249434--abc-news-politics.html

Reproduce this problem, then immediately upload 1) dcs.log 2) me.log 3) the mission 4) give us your computer's rough specs dcs.log and me.log can be found in C:\Users\<your account name>\Saved Games\DCS Warthog\Logs. They must be uploaded immediately after you get the problem, as they are erased and re-written in subsequent sessions of DCS. This might be enough to identify what the issue is.

Such a thing has been discussed recently on here. I don't remember where. You're basically talking about distributed processing over a LAN/broadband connection? Maybe it's possible, but ED would probably be better off increasing the amount of distributed processing across multiple cores on a single computer first. And also, I doubt the number of users who would actually utilize something like this would make it worth the development time/cost. I've never even heard of a game that does anything like this.

Ok, I did the searches, because this is a topic I've seen discussed several times, here is some info about modifying labels into simple, small dots: http://forums.eagle.ru/showthread.php?t=72095&highlight=modified+labels And specifically, maybe try this one out: http://forums.eagle.ru/showpost.php?p=1174693&postcount=8 Probably by studying how these guys did their labels mod, you can make your own labels work however you want them to. Personally, vastly prefer zooming over even the modified labels. IRL, A-10 pilots use binoculars, and also have much better vision than what a monitor is able to reproduce, so zooming isn't unrealistic. Besides... if you go into multiplayer, you will find your labels taken away from you very quickly. Better not to learn any bad labels habits :) But it's a personal taste. If you never plan to do multiplayer in an online squad, or don't mind having to unlearn any bad habits you might pick up, then by all means, use whatever you want.

Meh... still better than the Mass Effect 3 ending.

Yes, sorry, I should have been more clear about this: What I mean by this is that once weapons_impacting_in_zone and its related functions are complete, it should be very easy to use it and mission editor triggers to create logic like this: IF weapons_impacting_in_moving_zone( weapons = smoke rockets, launcher aircraft = human clients, zone units = ground unit group, zone radius = 1000) THEN OUTPUT MESSAGE("Player: Mark is on the deck") WAIT 15 SECONDS THEN OUTPUT MESSAGE ("AI aircraft group: Contact the mark, engaging enemy") AI TASK(AI aircraft group attack ground unit group) END

Yup... Amazon is pretty good. A potentiometer on my X-65 wore out, and Amazon replaced it for free. When the new X-65 arrived, and the throttle was not quite right on it, they replaced it for free again.

Excellent news on weapons impacting in zone! Instead of doing what I was supposed to be doing tonight, I instead wrote some dirty, inefficient code as a quick test of the weapons impacting in zone concept. I had before tested individual concepts but never had put them together into something that works. Well... it is indeed quite possible detect weapons impacting in zone! In fact, it's not even as hard as I thought. Even with very dirty, unoptimized code, while simultaneously tracking 1130 GAU-8 rounds, each round being checked ten times a second (where the check involves getting the round's positional and orientational data and doing some basic trig calculations), the computer didn't even noticeably slow down! So I reloaded with FRAPS to benchmark it, and did comparisons of 1100 GAU-8 projectiles airborne with and without the weapons impacting in zone code (I went to external views on a distant ground object). With the code: 110 FPS Without the code: 135 FPS That's a difference of 1.7 ms. That's like a drop of 1.5 FPS at more typical frame rate of 30 FPS. So with unoptimized code under a near worst-case scenario, we're talking about 1.5 FPS drop (with one zone- tracking weapons impacting into two zones will probably increase the calculation time by a few percent). Conclusion: once this code is optimized, when invoked by a mission creator, there will be no detectable frame rate loss or at most, a barely detectable frame rate loss, for the host under almost all practical uses and conditions. Start practicing with smoke rockets... you're going to need to be able to use them to direct AI aircraft very soon :)

Ok, but I haven't yet tested the units_LOS function in DCS: World, so let me know if it works for you. In fact, just about any function could be broken, as almost everything was modified to some degree or another. Slmodv6 WIP/Beta for non-Servman DCS:W 1.1.2.1 and DCS:BS/WH 1.1.1.1 (does Servman even work for DCS: World?): 0) Download and extract this file: http://forums.eagle.ru/attachment.php?attachmentid=65732&stc=1&d=1336692828 Inside the "Slmod v6 WIP" folder you should have two folders, one contains the files for DCS: World, 1.1.2.1, the other contains the files for DCS: BS/WH 1.1.1.1. Select the appropriate one. Inside each of these, there are two files and a folder: "MissionScripting.lua" - lua file "server.lua" - lua file "Slmodv035" -folder 1) In <DCS directory>/Scripts, rename "MissionScripting.lua" to "MissionScripting_original.lua". Paste the appropriate "MissionScripting.lua" file you just downloaded and extracted here. 2) In <DCS directory>/Scripts/net, rename "server.lua" to "server_original.lua". Paste in the appropriate "server.lua" file you just downloaded and extracted here. 3) Paste the "Slmodv035" folder into <DCS directory>/Scripts/net as well. Let me know if you find anything that doesn't work. I have yet to go through the full testing cycle so many features are only partially tested, even in DCS 1.1.1.1. Slmod v6 WIP.zip

Update: Ok, I had to fix numerous bugs with the new menu system. But it looks like the parallel tasking system and parallel options system are now fully integrated into it. As the options list showing, task list showing, and task showing are now private text-to-group, the default output mode is now trigger text. This can be very easily changed, however, as the defaults are set in the SlmodConfig.lua file. I'm now very close to being ready to release a beta version- if anyone is actually interested in a beta version. If not, the full version will be ready soon enough. This is a list of some of the things that have already been implemented: Changes (those I can remember): -DCS: World compatibility -Fixed a problem with units_hitting that prevented filtering of the optional output message by coalition. -Fixed a problem with units_hitting that would sometimes cause the function to detect hitting events that occurred before the function was invoked -Fixed a bug with units exporting that could cause unit exporting and various slmod functions to not work with a mission with a very low unit count. -Fixed a bug with the daemon where it wouldn’t open correctly if the .vbs file extension was not defaulted to open with wscript.exe. -In addition to human flyable A-10Cs and Ka-50s, Slmod now supports a much larger list of human flyable aircraft (part of the DCS World compatibility). -Implemented new function calling method- You can specify Slmod function variables the normal way, or put them in a table. An example: -Implemented new units table short cuts. Instead of having to specify like hundreds of units in some unit tables, you can now just use the following short cuts: -Implemented the "Slmod debugger"- see previous posts on this. Basically, any Lua syntax errors in triggered actions (waypoint actions not supported at this time) will trigger a pop-up text message at the beginning of the multiplayer mission, plus an error report will be output to Saved Game\whatever\Logs. Configurable with SlmodConfig.lua configuration file. -Implemented the coordinate conversion utility. See previous posts on this. Basically, it's a chat-based and text-based coordinate conversion utility that allows you to rapidly convert coordinates between L/L, MGRS, Bullseye, and bearing/range coordinate systems. Type "-conv" in chat to see the help menu for the coordinate conversion utility, and "-conv help" to get even more detailed help. The coordinate conversion utility was intended mainly to help non-A-10 aircraft interpret coordinates easier. This has some significant applications for cooperative game play between the different DCS modules. For example, a Lat/Long coordinate given by a mission trigger/Slmod function/multiplayer client can be quickly converted into a bearing and range by someone flying an FC3 Su-25. Or a Ka-50 can convert some lat/long coordinates into MGRS for the benefit of A-10s or a battle commander who are using MGRS. -Parallel Options System (POS) and Parallel Tasking System (PTS) re-written from scratch in the new OO menu system format. This has implications in that the POS and PTS are now almost instantly responsive (In fact, the response was so fast, I had to deliberately slow it down). Additionally, requests and responses to/from the PTS and POS are now private (except for a "Player selected option X" message in the POS). -FEATURE REMOVAL: Support for Slmod functions in config, server, export, and net environments removed (Slmod remains usable in the mission scripting and mission Lua environments, where is all anyone uses it from anyway). This was done to help clean up the global namespaces. Also support in the "config" and "net" environments was really a pretty silly feature in the first place, and support in the "export" and "server" (aka "main simulation") environments was a pretty useless feature no one was using. Anyway, if anyone actually was using it in any of the removed environments (and I very highly doubt it), I will add it back. -Enhancement: functions that formerly had "prefacemsg" variables, such as msg_MGRS, msg_LL, msg_lead, add_task, etc.- the "prefacemsg" variable can now have a %s character sequence in it. If this character sequence is present, then the coordinates are inserted in its place. -Changed lat/long messages with tasks/msgs to output leading zeros, as some people don't realize that 41 2.7'E should be entered as 041027 (or 04102.7) in the CDU. -Improved response time and efficiency of msg_MGRS, msg_LL, msg_leading functions -Improved efficiency of units_LOS code -Improved code efficiency overall -Numerous other improvements to code. -When calling functions, Slmod. now works in addition to slmod. New functions: -Slmod.units_killed_by(dead_units, killer_units, flag, stopflag, last_to_hit, time_limit) -Slmod.pilots_dead(units, flag, stopflag) -Slmod.units_crashed(units, flag, stopflag) -Slmod.units_ejected(units, flag, stopflag) Known problems: -Only Caucuses theater supported. Some Slmod functions, specifically those dealing with coordinates, and also the Coordinate Conversion Utility, are likely to malfunction in say, Nevada. I will have a small nightmare on my hands making everything compatible once Nevada is actually released. -Coordinate converter does not correct for North axis error in BR and BULL formats. Still to do Slmod.units_in_moving_zones function is mostly complete. Slmod.units_ejected_in_zone? I might do this one. It's useful for determining of someone ejected in friendly or enemy teritory. Weapons in zones functions: I am beginning to code these. I am reasonably certain I can make these work well. I would guess when detecting gun fire from rapid fire systems, they will be the most computationally exspensive functions in Slmod. So intelligent usage by the mission maker is a must. For example, monitoring weapon impacts from Mk-82s or rockets from four aircraft should almost certainly not slow down the computer; however, if you're trying to monitor cannon fire from a bunch of units, and several of them open up with long bursts of extremely rapid fire weapons (like the GAU-8 or M61 Vulcan) you could end up reducing the host to single digit frame rates. Also, intelligent use of the stopflag variable to stop function evaluation when no longer needed is important. It's all dependent on how much I can maximize the efficiency of code evaluation for these functions. I expect weapons impacting in/weapons inside zones to be useful in certain situations, such as: Weapons impacting in zones: -CAS -Runway bombing ("you must hit each segment of the runway with a Mk-84 to knock it out") -Simulating bombing a "suspected truck park" (watch Flight of the Intruder if you want to get this one ;)) -Simulating "suppressing fire" -Giving shift fire directives Weapons in zones funcitons (impacting or not) will be slightly less useful, but still have some cool capabilities: -Firing "shots off the bow" of enemies- for example, make a TU-95 return to base after you fire some guns near it. -Making pilots scream "SAM! ENGAGED DEFENSIVE!!!" when a SAM passes within a certain zone of them (especially useful once we get the radio message on unit that is included with DCS world) Anyway, does anyone have any feedback on the following functions? Now is the chance. It looks like I can do them, but they will be moderately challenging and could delay Slmodv6 release by an extra week or more. Notably absent: The AFAC and SAR function set to control AI aircraft. While this remains one of my top desires, I am waiting for something before I continue to work on them. Sorry but I cannot be more specific. Anyway, I thought with all my broken promises about when I'd release the next version I'd just give this update. Also, much of this update was already written or needed for the documentation I am beginning to prepare.

Yea, but apparently, a lot of folks are still using them. Just have a look at the bugs/problems boards. Maybe if we weren't in a world-wide recession... :(

Asking it as a question does help, but your question above is not asking why we don't have this feature. Your question above is asking why the developers lacked the imagination to realize we need a feature. Thus, it's only slightly better than the original that claimed that DCS was "very badly" designed, and coded in a hap-hazard way. No, a better way of asking the question is: "Why doesn't DCS have the ability to adjust control settings while in the 3D world? Other games have this. It is a very useful feature. <You could list reasons why it is a useful feature here>. Is there any possibility we can get this feature in a future release, please?" Now, instead of insulting the ED developers, which is a very unkind thing (as they actually do read posts on here) and also incurring the wrath of the "ED Zealots", you asked the question in a respectful enough manner that you should get a respectful enough reply.

So you don't travel to remove locations to observe? I gave up observing in my backyard several years ago... about 7 or 8 years. That was back when I actually had a backyard, since I moved to Austin, even that possibility was erased :( Right now, my most common observation site is a two hour drive away. I have darker observation sites 5 and 9 hours away. Back when I lived in Alabama, my most common observation site was 3.5-4 hours away. To me, it's worth it; I'm not interested in planets (3 planets worth looking at vs. like 1 million observable galaxies with a 25" scope? Planets are overrated.), I'd seen all the bright stuff a decade ago, so now, if I want to make any real "progress" I must go somewhere very dark. Also, everything looks just so much better from a dark sky site. Besides, it takes an hour to set up the scope anyway, plus an hour to tear it down, plus half an hour to pack it and half an hour to unpack it. Also, I tend to observe all night long. So in the end, it's worth it. The downside is- I only get to observe like an average of once a month.

I wonder if it can be applied to J-7s too?