Speed

Squadron dedicated server mission. It runs all day long, and is re-used for months. It requires highly randomized enemies and a huge target area so people always feel like they are playing on a "fresh" playground. Not possible without A LOT of units.

Not true, last I checked MP clients will be unable to get into an aircraft until that aircraft's start time has passed. Unfortunately, there is no way to speed up or slow down this start time for MP clients. :cry:

That's a separate issue I think, at least it is if you're talking about how missions occasionally stop playing all pre-recorded sounds and you have to re-assign them again from scratch in the mission editor. I haven't figured out what that issue is related to or how to reproduce it.

Would it be possible to describe? I'd like to imagine it :) Youtube videos don't do it justice at all, I'm afraid. Eight giant propellers going supersonic at the tips must be a very unique sound.

Sounds like an amazing airshow. I'd love to see a pass by a Tu-95. Are they really as loud as they say?

In that mission, maybe so, but in the first mission where I encountered the problem, the magic number was approximately 770 units, IIRC. One person even reported to me that he got 1200 units in the mission before he had the problem affect him. I did not confirm that unit count myself, however, so that would be a second-hand source.

Nice try, but you've got the patch numbers all wrong! FC1 used two patch numbers to designate a version; BS/FC2 used three numbers; A-10C/BS2 uses four numbers; it only stands to reason that by the time your hypothetical "DCS F-14" module came along, we'd be using five numbers, like, 1.3.1.5.2 or something easy to remember like that. :D

Don't worry, my avatar will switch back to the AU logo once the real men's football season starts again. :) You'll just have to use trial and error to find out what the required number of units is that breaks the mission. I donno if this is a bug that could be fixed or just a current, known game engine limitation. I haven't investigated the matter, though I plan to eventually. Unfortunately, I have too much stuff to do right now to take up the issue, however.

The "gun sight" mode makes your Skhval look at the predicted impact point of your weapons. IIRC, it is indeed supposed to make the Shkval turn on when you turn on "GS" mode, but I could be wrong about that.

!!!!!!!!!!! Good find!

I wouldn't draw too many lessons from the Gulf War, we are not simulating the A-10A, and we are not simulating the Iraqi army. Different aircraft, different enemy, different tactics. Most significantly,the A-10C allows much better night operation of the A-10 than the A-10A does, and furthermore, it also allows much more effective operation from high altitudes, where the aircraft is safe from AAA/IR SAMs. Further, as this is a video game that does not fully simulate the level of ground clutter/IR contrast variations/camouflage/sneaky tactics real enemy forces would use, it is very easy to find targets from high altitudes. Even if you want to simulate exactly like real life, the information we have available to us indicates that the USAF has A-10s fly at high altitudes IRL when significant low altitude enemy air defenses are expected.

It's working fine for me... make sure you unpause the game. Apparently, mission start happens at t = 0+ (or at least, the F10 map is not updated until t = 0+) :) So if you leave the game paused at t = 0, you won't see any units appear. RUN 1: RUN 2: RUN 3:

:huh: Please, upload the mission. :smilewink:

It does work... I'm using over a hundred randomly spawned groups in mission I'm currently working on. Please, upload your mission so we can see what it is that's going wrong with it.

Yes, I know this behavior well. You have more units in the mission than the game is currently capable of supporting, unfortunately. You need to remove some. Maybe making some of them deactivated will help, but I haven't tested that in detail. The number of units that triggers this problem appears to be somewhere in the neighborhood of 600 to 1200. Your results may vary.

They work in multiplayer- for the host only. If you want the equivalent functionality in multiplayer for clients too, you need Slmod. Slmod doesn't work through the radio menu, however, it uses chat message commands.

Turn off invincibility? :D Yea, the "hit by explosion" sound is probably what you're hearing; I think the problem is that there is only ONE "hit by explosion" sound, and it does not scale in volume proportionally to how badly you were hit.

Here, this works: http://forums.eagle.ru/attachment.php?attachmentid=66170&stc=1&d=1337421261 Basically, you just use a "ground attack" mission, the "bombing" task as a waypoint or triggered action, select weapon type as "bombs", and expend to "expend all". Though, if left on "auto", they may expend all anyway. Not sure. Better to specify and tell the AI exactly what you want them to do if you're not sure. B-52 bombing.miz

Haha... I ended up buying it too. And it is a terrible time sink- thankfully they added a clock to the upper right hand corner so you know when it's time to stop and get back to work... at least, it helps me- I'm only level 13 :) Is there really zero character customization apart from items and which skills you put on your skill bar? I was expecting, at the least, talent trees and a respec cost; I really like that system. Not sure I'm liking this all-characters-are-equal system. Anyway, if you want, PM me your bnet contact info and I'll add you :)

Thanks for the report. There were/are some known issues with indirect fire accuracy, I plan to test them all in detail when I get the chance.

Thanks for the test. I'm busy enough testing other things that any assistance testing Slmod is greatly appreciated! (Slmod has now slipped to a secondary priority for me- thankfully, due to my last-second push to finish it over the previous few weeks, even as a secondary priority, it will still be done very soon). That's a good idea. Perhaps the flag variable could be overloaded to also accept a table that contains group name and triggered action id number. I'll think about it. I can think of one technical challenge right off the bat, but that should be solvable. If I decide I can implement this, I can't promise when it might be ready. Just about every function that has a flag output would need to be changed... and that's a lot of functions. Slmodv6 is kinda on "feature freeze" while I finish off the last tidbits (fixing a small bug in weapons detection logic, finishing the reference manual, finish testing a few functions, final implementations of a few functions).

Well, how big of a deal it is depends on how many problems you've had with TARS and Teamspeak server reliability :D So with moving it all inside one application, there would probably be less that could go wrong (both user error and code error, and TS3 server problems), and it would probably be easier for the users to understand/use. At least in theory. It would a heck of a lot simpler and easier to keep track of, that's for sure. You also wouldn't be subject to the random whims of the TS3 creators.

Could you upload the mission where you had this happen? If this is really happening, a strong suspicion of mine would be that it could be related to the ME not correctly saving the aircraft start type. What happens when DCS GUI is restarted and the mission is reloaded? Does the aircraft you were having a problem with now show "ramp start" instead of "runway start"?

Yea... that's not going to work... for a couple of reasons... I'm trying to get it straight in my head what you want to do this for, chromium. You're trying to do this to save yourself the trouble of creating a bunch of triggers to call group stop and group resume? I do think you're out of luck with any flags higher than 100 for IS USER. However, there is an alternate method I think. If you need more than 100 start/stop conditions, examine the entry on "CONDITION(LUA EXPRESSION)" in the GUI manual. According to the GUI manual, I believe the way it works (it has been a very long time since I messed around with Lua start/stop conditions myself... which reminds me, I should probably test them out!) is that you create a chunk of Lua code whose last statement is "return <some value>". If that value evaluates as true, then the this start/stop condition is true. (false and nil evaluate as false in Lua, everything else evaluates as true.) So, in theory, you could do something like this: create a global table variable named "stop_condition" or something like that with a triggered action: stop_condition = {} In the "CONDITION(LUA EXPRESSION)" box for the AI action you want to control, you would put something like: return stop_condition['group1'] So now, when you want this "CONDITION(LUA EXPRESSION)" to evaluate as true, and in this example, stop the AI action, you can run this script using a triggered action: stop_condition['group1'] = true

Well, in multiplayer, "runway" starts are always supposed to start on the ramp, but with the engine running. At least, that's the way it's always been. You're never supposed to start on the runway, not in multiplayer. This applies to BOTH AI AND human players, and both "player" and "client" slots. Think of the ramifications if people spawned on the runway itself in multiplayer... That shouldn't have been necessary, because players always become clients when the mission is run in multiplayer. In fact, I always have a "client" slot that is in fact a "player" slot, so I can test the mission easily in single player.