Dangerzone

You can set the resources at the warehouse in the mission editor (and view the resources at the warehouse by clicking on the airport in the F10 map whilst playing). There should be a RESOURCES button that appears. This will tell you how many resources are available at that location. (It's possible for airports if they're not set to 'unlimited' to have limited resources and to run out of those resources, or not to even have them in the beginning).

Interesting time to be playing with such scripts as I'm wondering if the multi-threading stuff might be impacting what you're doing. Have you thought of setting a global variable that the other routine refers to and won't execute until the first is finished it's LoGetWorldObjects call. ie, something along the lines of: In your first script: if not lastExportTime or (currentTime - lastExportTime) >= 30.0 then lastExportTime = currentTime while script1_is_running do -- do nothing but wait end script2_is_running = true local o = LoGetWorldObjects() script2_is_running = false .... and if not lastExportTime or (currentTime - lastExportTime) >= 30.0 then lastExportTime = currentTime while script2_is_running do -- do nothing end script1_is_running = true local o = LoGetWorldObjects() script1_is_running = false for k,v in pairs(o) do default_output_file:write(string.format("%.1f,%s,%f,%f,%.1f,%.1f,%s\n", t, v.Name, v.LatLongAlt.Lat, v.LatLongAlt.Long, 3.28084*v.LatLongAlt.Alt, 57.2958*v.Heading, v.Coalition)) end ...Or better still maybe even if you just add an extra if condition to only run that code provided the other one isn't running, as it looks like you're just wanting this to run every 30 seconds anyway?

Just wondering if this is going to be accessible outside of the mission editor. This would be very helpful for those of us who make dynamic multiplayer missions/campaigns (or more-so for the players who have to manually key in each time) where they may be doing their own planning as a squadron on a multiplayer server. DTC for missions is great too, but just wondering if clients will have access to this independent of the mission editor / host? null

I feel your pain. I hated it when Microsoft changed their updates to not offer a 'let me do it manually' or 'download updates but install manually' and knew this was going to cause a lot of pain. My workaround has been to create 2 .reg files. The first one sets windows update to go through a local WSUS server, and the second restores this to factory default, so I can run that, reboot and do the updates when I want. I don't know if this will work with Windows Home though. (I've been using Windows professional). Good to know there's other methods. Thanks.

And so much again when you do it a second time and realise the first wasn't a fluke. It's interesting how our bodies or subconsciousness betray us... When first trying - my grip on the stick was so tight I'd get sore knuckles. My shoulders so tense, holding my breath half the time. Now - I'm relaxed, I'm holding the stick only with my thumb and index finger, doing small movements mostly and the occasional larger one when necessary- all which aids a significant amount in making it easier. The awful thing being that I knew all this while trying to learn how to AAR but do you think I could get my body to comply with what my mind knew. Noooooo.

I think we're being trolled. The arrogance of the concept "everyone else shouldn't need any more options available to them than I need - so DCS should be changed to force that on them" beggars belief that it's anything other than trolling.

There's been a number of very informative responses made, but he seems to only focus on those he can argue his point with which is that no matter any of the above - ED should be releasing the current Open Beta as stable now without any other consideration. I think that's the gist of it. It seems to have nothing to do with what he can do right now, or that he has everything he wants. It's just that ED isn't giving it to him in the way that he wants. (Which comes down to him wanting dcs_updater to call @release instead of @openbeta for him to have the current public release and force the rest of us stable users up even though it may not be ready). Summed up very well. The problem isn't a lack of options. The problem appears to be that ED isn't doing it the way some people think it should be done - even though ED has given them all the options to choose how to do things themselves and ED aren't holding them back, and any change to this way would actually reduce the options available. I don't get it. I've seen a number of posts on this forum where people come across more obsessed with what other people have, or how other people do things (and I guess that includes ED) even though it doesn't affect them at all) - rather than focusing on what does affect them, what options are available to them and ignoring what others have or don't have. The suggestions here wouldn't make any difference to what they want - it would just stop other people from having different options. It's a strange way of thinking. I'm not saying that I think the release cycle can't be improved, or that I'd like to see more focus on restoring bugs before releasing new features. But what's been asked for here isn't that - it's only about throwing Stable out quicker regardless of what issues the current public build has.

Sorry - I wasn't sure. I have seen a number of people actually literally believe what you're saying, or otherwise that Stable follows the same path as open beta, but just a few weeks behind. (Which is wrong, but somehow seems to be understood this way by some). The amount of confusion over how Stable and Open Beta operate on this forum has been considerable, so I thought it best to clarify (and probably good I did since the OP took your post literally too when responding to you). I apologize for implying your post as being literal when that wasn't your intention.

Any chance you could record the last heading of lead, and compare again every 5 seconds. If the heading is within certain parameters you know lead is going straight ahead, so you could do tracking then. If the heading of lead is more than 5° out of the position 5 seconds previous then you know lead is in a turn and thus can ignore the tracking. I believe you can also get bearing as well as distance between two units. (I'm assuming you're using something like MOOSE for this)? With those variables (flight heading, separation distance, separation bearing, and whether flight is straight or turning) you could probably achieve what you're chasing. (If my understanding of what you're trying to do is correct). The only way I'd try tackling something like that is in lua script. There may be someone smarter than me that could find a way of doing it in the ME with flags, etc - but that is too hard for my mind.

I think it's a civil traffic issue. One solution would be to turn civil traffic off, and then place on the map just the trains that you want, where you want and use waypoints to do loops, etc. The only issue with this is that cars will disappear on you as well. A possible solution for this would be to request a feature from ED to have a second option for Civil Trains or similar so you can choose between the two maybe.

Congratulations! Successful tanking is very rewarding once you get there. Good news is - it's only going to become easier from now on for you as you become more familiar with it.

What a refreshing post to read someone who gets it. Thanks Raisuli. Just this week I saw a larger server operator closed down one of their servers in the Asia Pacific area. Reason given "every dcs update is a lottery if something brakes or not". To me, this is one of the key reasons to run Stable on a server. Less chasing of things that are breaking, less updates, let others test the changes publicly before we do. I find it a shame more server owners don't see the light in this and how much easier it is to run Stable than Open Beta with less problems and overload themselves to the point where they give up. Stable isn't perfect - but it's a lot less work maintaining than Open Beta.

Because that's actually wrong. Latest stable isn't the last-but one Open Beta. People don't want to truly understand how Stable and Open Beta works, that's up to them. It's not a difficult concept really and it's being explained. People just don't like it so they choose not to understand it I guess. I can only guess you're just trying to win an argument rather than trying to find a solution to your perceived problem. Either that, or you like complaining about nonsense. There is no problem that you have raised that there hasn't been simple solutions that meet your needs. For some reason you seem to be obsessed at whether the game installed on your PC is tagged 'Open Beta' or 'Stable'. You don't care if it's stable enough for Stable. You have stated you just want the current version of Open Beta to be called Stable now, and even though you can have everything you want - (except a title change) -because ED generously gives us many options. You appeared worried about what ED calls the build you want to run on, and nothing more. At the end, that's as far as your concern really seems to go and honestly - it's getting very tiring - especially for those of us who have taken time out to try and help you to understand what you can do - just to later realise this appears to be more closer akin to trolling than it does having a genuine need and we've wasted our time. I too am waiting for stable to be promoted, and at times I find myself getting impatient. The difference is though - I understand the concept an appreciate ED giving us the choice. For us that do get the concept of Open Beta vs Stable releases, and appreciate having a stable release that is promoted less often - I say "leave it as it is". Everyone at the moment has a choice. All your asking for is choices to be taken away from some other people to suit your ideals more. That's it. I primarily choose to use OB for testing, stable for real flights. If I had access to CB, I'd probably use that for testing - because I understand the concept of BETA being a test environment. I don't have CB access but appreciate that I have OB access before it's promoted to Stable... for testing. I get, and appreciate the difference between the two. Otherwise if people really don't see the need for 2 versions, their is a very simple solution. Get rid of Open Beta. Only allow the public access to Stable. Make them wait longer. Only allow people access to Beta that understand the concept clearly and are willing to participate in a BETA program as testers - instead of those who think BETA means 'quicker access - not a test release'. Honestly - I think that solution would suck - as I'm for people having options to choose for themselves. Not being forced to do what someone else wants.

I have great news for you! You do not need both installed! You can make the decision for ED yourself to virtually promote the current open beta to your current version by \simply running... dcs_updater.exe update @openbeta Then you'll have exactly this. This does not create a second install. Just an update. Apart from having to type in those simple commands - what difference does it make to you if ED decides today to do this, or whether they decide to do this next week if you're happy and want the current Open Beta to be promoted to stable? Then when ED does 'catch up' for you, you can run... dcs_updater.exe update @release ...to reset DCS back to only update with future stable is released (as it will be the same version anyway - so it's just a reconfiguration of the update checks) if you prefer to stay on stable after that. You don't need both installed. Those commands will just reconfigure your current install to either download using the openbeta server, or the stable server. Apart from that - your local copy of DCS will not know the difference.

@ac5 Would you be happy if ED promoted the currently available Open Beta to stable today? If they did that, would that solve the issue you currently face?

That's OK. Yes - I too am looking forward to the next Stable Release, but I'm reminded that Multi-threading has been implemented and it's no small change. From what I've been observing, multi-thread hasn't been stablised enough yet to be at a point where it's 'worthy' of being called stable, and that's understandable given the complexities of changing from a single thread to multi-threads, so while I'm looking forward to SR being incremented - I'm happy to wait if it's going to be less stable than what we currently have until it's good. I admit, I would love to see focus more on bugs to get it to stable before introducing new features now. (What I've noticed a bit of a trend on, is incrementing the version number to implement more features when the current version hasn't been developed enough to remove the existing bugs that were introduced since the previous stable release. ie - ED started working on 2.8.2 in January, and then in March instead of finishing off 2.8.2 to be stable, started developing new features in 2.8.3, and then last week it would seem has now started new work on 2.8.4. It would be nice if there was a policy that "No - we're not going to start work on new stuff until we have fixed enough bugs that we've introduced in this version to make DCS more stable". I think this would benefit not only Stable Release players - but also Open Beta players in that introduced 'de-stabling' bugs would be given a higher priority than normal.) However I admit that I say this with the ignorance of not knowing what's going on behind the scenes. It's possible that dev's working on the bug-fixes to Multi-Threading are still going to need significantly more time - but if DCS waited for them to get these bedded down it might hinder other non-multi-thread developers are ready to move on with features that are required to continue the F4, or C130, or Chinook, or who knows what - so an increment in version and implement in features is a necessity even though they haven't managed to get MT where they want it yet. Either way, ED needs more time to get the last round of changes stable. They've been generous enough to give us the option to use either Open Beta or Stable ourselves (or even use a build in-between if we want to choose a build we're happy with). There's really not much more they could do with giving us more options. And changing the way they do things might benefit some people, but would hurt others, so we really have the best options available already in our not-perfect world.

I'm suspicious of that too. I've seen people protest against requests of having an option to remove the rotor blur in the Apache from VR (since the motion reprojection creates all sorts of problems including blurry IHADD numbers as the motion reprojection catches those as well as the rotor and tries to replicate, etc). Objectors outcry about how removing it would be giving VR users a 'cheat' and unfair advantage.

That didn't age well. Or... do you mean 26 October this year.

Thanks Draconus. However that poll will give an indication of how many people want it - not how many people would be upset if it was implemented. A subtle but significant difference. I could put up a poll how many people will use the F4 for instance and have more say no than yes potentially - but you haven't got a bunch of people getting upset that it's being made, on the contrary most who aren't going to buy it are still happy for those who are excited for it. What's surprised me about that poll (and thanks for having the foresight to put that up back then) is that roughly 1/3rd of the voters would be for it, which honestly I didn't expect. I thought there would be far less than that - maybe 10-15% was my guess - which if anything shows that there's actually more need for it than I gave it credit. True that. I guess my incredible idea of how it could be implemented on post 5 of page 2 that I put so much time and effort into will go unnoticed.

I was assuming it was referring to burning units (vehicles) that were critically hit but not technically dead yet until it exploded. Then at that point they triggered the dead event, but were supposed to keep burning for a while for visual effects, and weren't. I don't think it actually has to do with bodies on the ground in agony not yet dying, and then adding burning effects to bodies that were... spontaneously combusting after exploding. And I don't mind ED tweaking things like this. It's good to have tweaks over the whole game. As a developer myself sometimes it's nice to go and have a break from the intensive tasks to go concentrate on something small, but also that gives satisfaction as to perfecting something that wasn't quite right. It's healthy for the developers, and good for DCS. (Provided nothing was breaking in the fixing) I also am suspicious that alternatively this may have been a side-effect/bonus of correcting some of the event_dead events that haven't been working correctly. (Hoping anyway - haven't had a chance to check yet).

Respectfully SB, if adding this in is ED making a statement, then it would seem the statement is already made, so that horse has already bolted. Because we have auto-rudder, auto start/shutdown, labels, padlock, etc, so this actually argues for, and not against considering this as ED have already shown themselves to be thoughtful to people less skilled. As for "upsetting more than half the community", kindly - I reject that assertion. (But I'm open to being proven wrong if you have evidence to back it up). You see, my strong DCS experience has been that the vast majority of the community is accommodating, and inclusive - helping people to learn, taking time out and wanting to see people succeed, and being OK with people using aids as necessary. (OK - with fun banter thrown in their direction , but in kind fun). I certainly didn't see more than half the community upset when Campaign makers added in the option for other people to continue the campaign without air-air refueling such as Raven One. I dare say because most of the community doesn't care. If it doesn't affect them - and helps others - it's seen as a good thing. The more players onboard - the better, and the developers showed that they cared about including more people. DCS thrives on people with passion that help other people enjoy DCS more. There's only one valid reason for not implementing this that I have seen raised so far: It may take resources from ED that could be used in other areas. And as @Ironhandsaid above that's a decision for ED to make. And ED has so far made that decision against this, so it appears not. Personally, while I don't mind this idea - I personally have other areas I'd like to see supported better first too. But it seems far more productive to discuss the pro's and con's of how it could be implemented and the negative or positive effects that those methods might have on the game/sim and players, rather than making assumptions on how many people may or may not get upset over how 'other' people do things.

You can also use Skatezilla’s DCS Updater Utility GUI. Skatezilla's DCS Updater Utility GUI - Flight Sims - Mudspike Forums This gives the ability to do this, and a lot more from a GUI interface. It's worth checking out.

That's a valid question. As for an easy mode that 'assists' you but you're still in control - I think this is the wrong approach. There's been some good points made, in that making it 'easier' is counter-productive in that it could train bad habits, making it harder to actually learn later. Secondly, I (with my limited brain ) can't see a clean way of actually doing this. Instead, have an option in the special section that allows for 'simple air refueling' or similar that simply changes the condition on when fuel flows. So when this option is active, as soon as the player calls "ready precontact" and the basket extends - the fuel starts flowing into the aircraft immediately. There's no need for them to be hooked up to the basket - they just simply need to be behind the tanker within range of when they could call 'ready precontact'. The benefit of this approach is 2 fold: First, I suspect (total assumption here) that it would be much simpler to implement as it's just a change of condition as to when the fuel starts flowing out of tanker and into aircraft. Instead of proximity or connection to basket, it's proximity to tanker of a greater distance. The other bonus is that it allows the player to still attempt to learn to refuel under normal simulator conditions. No bad habits to learn. They also can still try and hook up to the basket, or keep popping out as many times as happens - except it doesn't stop the refueling process. This gives them the benefit to try and learn under real conditions till if they want with no 'easy mode', but also allows them to continue the mission even if they fail or are unable to as they'll still fill up regardles. There's less frustration because they can give this a go during gameplay and still continue on if they fail. If anything - it would probably assist people to actually try more. It would potentially help them to learn to do it for real. They don't have to be scared or excluded on missions that require in flight refueling and can have a go knowing that they can't really fail.

Aah - I wouldn't have noticed the ground shadows because I have them turned off due to VR performance at the moment, so that's handy intel for me to know. Thanks. But yeah - beautiful to fly a huey around the airport.

That's a very good point. Senaki - yes, but I think if you do that in Dubai you may see differently. (Excuse the pun ). I don't recall checking externally, but internally there is differently a difference with parts of the cockpit lighting up as you taxi between lights, etc. The last I was aware ED are actively looking at implementing dynamic lighting into different areas of the map, so the timing of this request could be optimal. Poor ED - so many passionate customers, and some great ideas and not enough hours in a day.