Pikey

It's changed rather than broken, and likely no one at ED anticipates the importance to some people of a seemingly minor ID. (That's actually a trend with the under the hood stuff). They also shuffled the event ID's. The thing is, I have no idea why, on some of these changes, it's not like an Airbase or an event works better if its called an apple or an orange. Crazy stuff. I'd like to have fixed it last night but I just dont have the knowledge of some of the folks, i'm just a guy that started using this stuff a few years ago and began to pick things up. BUt it's important to me and my hobby so I'll keep at it.

No there has never been something that useful provided, maybe this is the first part of an implementation. However that script is easily editable and copyable and can be run from ME, if the idea of scripting puts you off, you hit your ceiling i'm afraid.

Sorry teaching you Lua is beyond the scope of forum work. You have to delete the save file as I said. its in your DCS folder. I've provided you with what you need to know, but I'm not customising the script for you! :)

unfortunately scenery has no heat property that can be used for such a device. A unit could theoretically be abstracted, based on if it were moving and a static lookup table with it's IR signature. Planes currently do have that data. If ED finish the FLIR model and that is usable, I'd be curious as to what a HUD woudl look like flying over a city. We saw it in rural Scotland, it was bad enough there, plenty of jitter and more false positives than valid heat sources. I suspect it's only really useful out at night in the wilderness where you dont expect any heat sources. Anywhere else its likely a completely horrible experience on your HUD.

The day they give us an API for switching lights off I'll have scripted it gleefully and made a power network. Until then it's just for dreaming about.

Are you refering to the old design issues that were a security flaw or something new? AFAIK the old ones were patched in Windows and the new ones dont have it. Even those I benchmarked before and after and made no discernible difference. Unfortunatley marketing folks were all over this and you could read anything you liked ranging from disaster, end of the world scenarios up to no difference. Is there something new you can link though? I have read nothing that shows Ryzen vs Intel favours Ryzen on a price:performance ratio.

Nothing will change, even though the COO said they would look at change: From reddit: I suggested they could achieve that via blocking MP on the OB branch to "Public" servers. BIGNEWY has said it wont happen, and also said the OB is useful as is. The word "misusage" carries a lot of weight. Ed are telling you not to use OB for MP. Servers are not listening, they want the server for the players wishes. The players wishes are to have all the nice new things and it to all be perfect. The three groups are all INCOMPATIBLE. And given the side messages of "it wont change", everything you need to know is said in that reddit post, this post and the suggestion on stopping MP to public post. Which basically means, folks have to learn and the complaints will be given no heed and folks are wasting their breath. I do think that this is entirely created by Multiplayer servers, which are the place where things will break and the source of disappointment when they roll back versions. The best midle ground that can ease this situation is that the DCS World development path and Module development paths diverge more strictly and are more uncoupled. That means If a new module or even a module feature liek TWS on Hornet, is due to arrive, it gets pushed on it's own to OB and verified and moved to Live much faster than currently, because currently, the new features moving to Live are Blocked by bugs in the core game. They shoudl try to rotate between module changes in isolation and core game changes, else forever there is a chokepoint moving things to live. That might help people choose stable/live more readily. But it's not quite good enough imo and unlikely to be executed on.

another post here https://forums.eagle.ru/showthread.php?p=4223767#post4223767 and https://forums.eagle.ru/showthread.php?t=264585 Would be good to have this picked up. The impact to older missions saved as this version could be catastrophic if anyone uses a name via any scripting to identify something. As it is, making new missions you can no longer do anything with scripts that use prefixes to identify the static. Whilst names are somewhat an abstract convention and ME can change triggers based on the ID, for external scripting that collects groups and counts them according to a name convention you setup eg SET_STATIC:New():FilterPrefixes('Ammo') will now pickup all the statics and farps and give you nightmares. I'm sure Mist has a prefix tool. It completely wrecks some things.

and now https://forums.eagle.ru/showthread.php?p=4223767#post4223767

there's two other posts about this https://forums.eagle.ru/showthread.php?t=264356 https://forums.eagle.ru/showthread.php?t=264585 Come join in there, dont think they have been acknowledged yet.

ugh, my money will always be on the CPU, but specifically on the generation of CPU and for Intel still. The Cores is a bit annoying because you dont need the cores, you need the clocks, however they do lock the larger cache sizes behind more cores, so it tends to be that the best cores are still on the large multiple physical core CPU's. Still, a K version of i5 is good. I got more FPS out of a 2500>6600 CPU than I got from a GTX960>1070, and my 1070 to 2080S jump was almost no reasonable difference in 2D until I put it in VR and did streaming on top of that. I'd go as far to say that for 2D it was a huge waste of money, and for VR it was marginal and still capped by the server's FPS which in MP is usually much much worse than Single player. GFX cards don't make the impact on frames unless you do VR, in which case, they most fdefintiely will eat your funds. But you can pick up a 2080Super quite cheap in comparison to a latest model, if you can deal with the terrible cooling and noise comign from it.

Yeah there is defintiely two different views of the missile, noticed that easier in Tomcat as RIO. Tacview agreed with only one of us.

Update: Sierra99 (sorry no finders fee for bugs :P) discovered NTTR is pretty messed up for Airbase ID's Tonopah Airport == Pahute Mesa TTR == Tonopah Airport Pahute mesa Airstrip == North Las Vegas so far, probably more but didnt want to wreck my weekend again with fixing things that might get hotfixed back so Just beware if you use RAT or A2A_Dispatcher and things that use the Airbases by name, things will spawn in unexpected places. that was just for starters. Not sure if ED will fix this

Only with Moose, that's all that is near my clipboard. EventHandler = EVENTHANDLER:New() EventHandler:HandleEvent( EVENTS.Dead ) function EventHandler:OnEventDead( EventData ) if EventData.IniUnitName == 78577701 then MESSAGE:New("Colorado Bridge destroyed",10):ToAll() end end

If you have A-10C presets in the same miz file as the Viper, then the Viper will always use the legacy A-10C folder and load its presets rather than it's own presets contained in the mission table in the miz. Reproduction 1. Create a miz with a Viper at hot start. Setup radio presets to something obvious. In the contained mission I've used the ranges 130-135 and 300-305 for "at a glance" checking. 2. Play the mission and see that your presets are saved OK. You can also check in the mission table that the list of frequencies were the ones you set. 3. Exit the mission and create A-10C legacy presets using the "Prepare mission" method that A-10C's have to use to have presets. For the sake of ease, I've included a mission with the UHF presets set in the 200-205 range for visibility. 4. Load that new mission and look at the Viper presets which have now changed to 200-205. Expected: The Vipers presets shoudl not be affected by an A-10C's Actual: The A-10C presets overwrite the Vipers. viperUHF1test.miz

This isn't about modules in beta, its about the core game in stable and open beta and the recent update to DCSW 2.5.6 that broke statics, lods, airbase ids, events, lots of related scripting, MP performance, mods and textures, internal object textures, lighting on cockpits of more than one module, lots of ME items like static naming and... um ive forgotten, whatever else has been reported that I've missed, this just off the top of my head. Modules are developed with their own beta status independently of the core game. The views on that are valid but different and not in scope for the OP.

Of course folks are against it. And they'll continue to moan about quality of beta. And if you think this will enhance the bugs that get from Beta to Live that already happens, I reported dozens of bugs that get put right onto live. But I've also offered to help Alpha and that wasnt taken up either. This simply prevents Servers running OB and the mass users moaning that they didnt have a choice, when of course everyone did but they ignore the warnings and forget Beta is beta and what that entails, at least from ED's historic standpoint. Predictable reaction. :) So, it matters not what you want, because it's proven time and time again, people can't choose the sensible answer. And then they blame someone else for it! Suggest something better for stability of MP?

(discussion with ED's COO and development manager Kate P on the open beta and dev process) We've no one to blame for this but our own desire for power, greed and fame. MP servers like Blue Flag and others (including my own) exclusively attempt to utilise the OB branch for their public offerings because it has all the new things we like. When they roll back, the backlash is explicitly directed at Eagle Dynamics, when in fact every opportunity to have an early look at OB whilst remaining on the Stable Branch was bypassed and the guarantee of something at least "known" was surrendered in favour of blindly updating to get the new content. Human nature? It matters not. The playerbase needs coaching. I don't like this anymore than others. I would like perfection delivered every time, but the fact is, as history shows us, there is always a high chance something bad happens on a release to Open Beta, yet we still do it (well most of us). It comes to the point then, when we have to be parented to avoid these massive disappointment feedback loops. A proposed suggestion is to stop Mutiplayer, the most fragile of DCS environments, from being able to publically operate on the Open Beta Branch. Things we know: 1. People want the latest release and will gamble. 2. Servers encourage this, they want the same, to meet player expectations 3. Servers on Stable don't get the visibility 4. Open Betas can, and have for as long as I can remember, have bugs that are undesirable. 5. You cannot ask people to remain on Stable branch, they just won't, given the opportunity. 6. This has long become the status quo and the expectation bar is raised on OB, making the entire public testing effort a ridiculous lost point and cycle of update > disappoint > backlash > update > disappoint > backlash. 7. ED need us to test. Nick Grey said their QA couldnt touch the amount of testing required to release a perfectly stable product each update without our help and they need us. (and that's absolutely understandable given the complexity and depth of DCS) 8. The stable branch has lost it's point. People live on OB where they can. What keeps being suggested from us is that we have deeper access to testing. But that is because we don't utilise the stable>OB branches. I don't want to go back to having three builds, I dont even want two builds of DCS, personally, so an "Alpha team" seems a counter productive act of pushing in the wrong direction. I suspect ED gave us what we wanted, but not what we needed. We've asked for this by not supporting or understanding the complexity and limitations of DCS well enough and having completely sky high expectations. So this is the proposal: Remove access to Multiplayer for dedicated servers on Open Beta DCS branch. Drive the player base to the stable branch. Fix the release pattern so that we can get sprints of OB iterations in quick succession, a week or two of stability before any new feature/product lands in order to shorten the wait for new products into the Mulitplayer environment Get used to Beta being a Beta - we shouldnt use it for all purposes and allow it to be available for testing rather than the expectation of live use. The net change is not that much work for ED given these explosive backlashes from some community members, but they don't realise they have propelled this situation themselves. It is what it is, because we allowed human nature to dictate what could have been a workable system of community testing (that's not changing by the way so dismiss any hope you will get perfect releases). I don't like this, I want the new modules first. But I can see how I would adapt. I'd be trying the new releases and going back to the two build process. I'd test my missions and content early and have weeks ahead of the live branch to prepare. I could play private multiplayer with my friends who could do the same and apart from the large popular servers there's not that much change, expept a lot of people wont be up for that and remain on Live/Stable, which is the net outcome we would want. The alternative is either: People change their expectations . (Not going to happen) ED broaden the internal testing group (the scale needed would likely be prohibitive to be useful and create too much erosion of the testers group to be useful) And I'm going to go on record with some negativity here at the end. I don't think the testers team actually targets the right things in terms of multiplayer and under the hood items to date. I offered help as many do, I called out there would be issues and I'm a bit dejected that my fears became reality again. We should not be in a position where we fear an Update and expectations become true, it really shouldn't happen because it shows we don't learn. Thanks for reading, I love DCS!

I dont think we will see the R27 family get much better on the review. The 120 got a little boost but actually I still find it much worse over the years. With Nick Grey saying on Reddit they want to reduce the effectiveness to bring fights in closer, I would say that nothing really will change to increase their effectiveness. But honestly, I dont care, I don't find unstructured PvP much fun, i'd rather PvP my friends, and quite honestly, it's more about guidance which for both the ARH's is rubbish in effectiveness, anyone can kinematically defeat (even accidentally afk) the DCS missiles, the real contest is reducing the initial shot range and awareness of the opponent. Frankly IR missiles are better in most cases, even with the annoying AI. If this is what modern missiles are like then it's no wonder they have BFM schools like Top Gun.

Just do that then. People dont all use it the same. For Moose Have a SET_AIRBASE:New():FilterCoalitions("red"):FilterStart() Count it's members. in a SCHEDULER. If it reaches 0 then os.remove() the SaveUnits.lua file restart the mission. You still need a way to restart the mission though, that's only avialable in the triggers of ME itself. Some people wouldnt like an immediate restart, just saying. MOOSE is easy, come learn Lua on Discord. :)

Ah! Makes more sense. Delete the Save file in your DCS directory, the mission is back to the start.

Flaming cliffs 3 is clearly a different level of detail but I hear complaints over the planes? What is wrong with the planes performance? As for the missile differences. I don't know. but I do wonder how everyone else is so sure, except me? It's like i've missed some public information somewhere....i just can't seem to find it...

Your mods are awesome. I think you misinterpret the direction of the thread. Read the OP, he's complaining that Mods break and drawing a line between the SDK access and that reasoning. What he didnt understand was that it's nothing to do with the SDK's. The support process of licensed products is different and should be! In many cases ED is still trying to improve their communication around that topic but you would expect they talked to their paying third parties first, right? Re exporting due to a texture change has happened before and it will happen again most likely and ED will strive to support their licensed 3rd party devs foremost. So the concept is simple; go for a license and get that support and you'll have that time in advance to make the changes. ED would like more developers to become licensed third parties. But you have to do it by ED's book and rules and that's a product standard. Fairly straightforward. We've all seen script authors disappear and their scripts fall into broken, it is the same with old mods. If a modder wants to commit, then they do it by ED's rules. And that sets the standard for DCS. And that forces the entire point of what at least I was saying about SDK and licensing being a joint benchmark 'gate' that should be protected. A modder is either in, or out, its a committment barrier. If the SDK and the final part of getting a mod to full ED standard is the parts of the SDK that allow interfacing with radios or whatever feature is unobtainable, then it's good its not given away because it allows an easy distinction between what is a public mod and what is part of ED's core game and guarantees ED wont be left trying to figure out someone elses work, which they have had several times now. Obviously this is more about flying plane modules than assets. AI Assets are interesting because there has to be a limit on the number that ED can support. If texture types changes in the game and they have 200 rather than 100 of them, its got to be a sizable chunk of work to take ownership of these. I'm not completely sure, but the China assets pack looks to me like a way of not onboarding too many objects to support, it's clearly a massive support overhead. Consider all that work if the core game changes soemthng that requires each asset updated! Another example could be the WW2 assets pack, which has it's own funding. Terrain is a different kettle of fish completely. I think this is primarily protecting a revenue stream. I understand that, even if I don't like it myself. The folks talking about mods being bad are probably refering to bad mods, in absolute fairness there are many to pick from, despite the obvious effort it takes. But there are good ones too, many I count on absolutely. FWIW, if you think you have everything for a LeClerc, the right team, contacts, the Proof of concept, talk to Wags and do it.

https://forums.eagle.ru/showthread.php?t=264356

2.5.6 hotfix holding firm. I'm adding the 7 new airfields to Normandy as they are absent and this would affect RAT, ATC, any AIRBASE type lookup on the missing airbase and a bunch of possible things. Just waiting for the pushes to go through. Additionally there's been some ATIS fixes from Entropy and Frank to tune ATIS a bit better. Because of the high state of change of MOOSE the 2.5pre release is pending ED's rapid development on OB and we should wait until things settle for the merge to stable. But its stil due whenever we can.