Dangerzone

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.

Oh wow - I don't know how I missed this. I'm assuming this is only Open Beta - or was this done before and included in the last Stable Release as well?

On the contrary - as someone who doesn't really use combined arms myself - I love being online when the opposition has players using combined arms. The difference going after ground forces controlled by players vs AI is a whole new level of experience. The more people that could be attracted to using combined arms in a multiplayer environment for more people to share these kinds of experiences the better, so you have my support. The main concern I have with your dream is the asset packs. CA works because only players needing combined arms need purchase. The rest of the players online don't need. However once you get into asset packs (like the WW2 asset pack) - this starts excluding many players from even being able to access to the server which can be counter-productive. If the asset packs were such that the units were visible to all, and could be added in the mission editor (or script of course), but only controllable by players - this could work. A bit like our aircraft. People could buy an Abrams, or Sam site, etc like they buy a FA18 module - and 'jump in it' like they do aircraft. The only difference is it would be great if they could populate pre-existing AI units and take over (like they currently can with combined arms) - but have that full fidelity control of the unit.

This would be a fantastic idea. I'm not sure - but I figure the ground textures are pre-loaded so this may be more difficult to do than not. Although with the changes made to the dynamic lighting on Persia - maybe there's a chance that it could be simpler than first thought - but I suspect that the lighting is a combination of ground textures plus dynamic lighting so it's probably more involved than I realise. Either way - I'm very glad the team is considering this. The Apache is built for night ops - and IIRC the F15 has a similar HUD to the AV-8B night attack HUD too.

The question has been asked numerous times and still ignored. "How far do we go with this?". No wise designer starts something without first considering the cost. And the question is - what is the true cost to this in that how far does this need to go until people would be satisfied that things are 'fair' and there's no cheats involved? If this was serious - I would have thought that the conversation would have included answers to these questions raised, which has otherwise fallen on deaf ears, which is a convincing indication that this isn't really about being genuine about unfair advantages, but just wanting to win an argument. Otherwise these questions about how far do we need to go to ensure fair game play would have had serious consideration and responses instead of being mocked as excuses or otherwise just ignored. I personally think that this would be anti-beneficial, but I'm open to being proven wrong. So, my suggestion is this: Before ED goes considering this too much may I suggest ED talks to the server owners they already have regular contact with out there to see their point of view first. (From what I've read I have doubts that these requests are even coming from invested contributors who would use this feature, but rather just players who think it's a good idea and want to argue a point, and wouldn't really get use - but I could be wrong). From a personal perspective - if this thing gets traction I think it'd actually be a slap in the face to many server operators and contributors. Especially after those waiting for significant times for the things we've asked for. (I have the recent announcement by rurounijones's in my head when considering this). His complying with ED's request to get a list - take the time to survey many and provide these requests that would benefit far more players, server hosters and campaign makers alike - which gained what appears to be unanimous support for his requests by script writers (including many with MOOSE) and many server owners seem to have fallen on deaf ears to a point where we're losing good contributors- this would just be adding insult to injury unless they were first approached to see where this fits on the list of priorities. If this feature is to be seriously considered by ED - please talk to those who are actually putting hundreds, if not thousands of hours into supporting DCS multiplayer and don't fall for the mistake of just greasing the loudest squeak on this board. There's no point implementing an option to use a function if it's not a real benefit. If I am proven wrong, and this is a serious consideration - I will be the first to admit I am wrong.

If I recall correctly - I thought that the creators mentioned a few months ago with a podcast or similar that vehicles would be able to be carried. The only restriction would be if they could physically fit inside the aircraft. Interesting option regarding assigning vehicles as troops. This is something I haven't considered before. Will be interesting to see how well it works. Does it add weight automatically?

I'm intrigued why shadows have become a big issue. VR is an advantage over 2D with it's 1:1 tracking - especially in dogfights... I'm sure the user with multiple monitors has a better advantage too over single monitor players. We don't have enforcement settings for these, or are you suggesting we should for these too? There's also an advantage by reducing the forestry count - much easier to see units with less tree's around. Same goes for detail factors, and even grass. Should we have enforcement for minimum limits on these implemented too? It's already been said - and I agree - if you want a more level playing field - the only real solution is to get a console. PC gaming has always had variety - and with that there has always been the compromise of some with advantages over others.