Dangerzone

Update on this: Apparently Pikey says that this has been requested, so hopefully we'll see this in the next patch. So, it seems as though the change is intentional, and by request of Closed Beta testers / other dev's, so it's not a bug. (Just an 'undocumented feature ... no I'm being serious this time - this is a case of it really being an undocumented feature). Apparently having FARPS with unlimited by default was causing issues with people being able to load nukes or similar, so it was decided it's best to have them empty and then either switched by code if the mission designer wants them to be unlimited, or otherwise hauled I guess by Chinooks, and the warehouse transport function. For more info on this:

Does a civy-sim allow you to do airdrops / cargo that actually impacts other players, and have the risk of needing countermeasures though? I see the 'new' civy sim allows for a lot more activity - which will be interesting, but still - the ability to work with others in multiplayer (more than just sharing the same skies, but having an impact to others) I think will be quite enticing. Anyway - we'll know soon enough.

Thanks for the clarification on Jonesing... Yes - I hear you. The idea of flying for the sake of flying, but having that additional hositle environment where you have to be careful, and also where you're not just flying dog manure out of Hong Kong like other FS, but what we do actually has an impact to others in the game as far as CTLD is very enticing for me too! I'm also wondering how many flight-sim guys these two modules could entice from general flight simulators to DCS given DCS unique nature. Good times ahead.

"Jonesing"? Is that anything like "Don't panic Mr Mainwering"? Aaah - the C-130 - yes extremely excited about that one! I'm more looking at the CH-47 as an 'interim' module before the C-130 is released, so I'm waiting to see just what the C-130 in EA is capable of before I buy it to make sure it's going to meet that criteria. But yeah - dang if those OH-58 video's weren't released crazy fast. I felt like if I went away for 4 days, I had a lot of 'catching up' to do.

So - to confirm (I'm guessing you have some 'inside knowledge'?) - this isn't a photoshop job, but an actual screenshot of a branch of DCS that hasn't been publicly released yet, but is indeed 'in the making'? When I saw it, I just thought 'photoshop', so if this is indeed a real screenshot, that is exciting!

You got a little too used to the frequency of the Kiowa video's I think. They were super fast at being released.

Hi Pikey, So it's your fault - and this was a feature request!?! What were you thinking? Nah - the amount that you and the other guys put in to make scripting available to us - I trust that the change then is in the wider communities best interest. I'm constantly grateful for all the resources and support that you guys do, so I'll defer to your better judgement. But thank you for requesting the ability for dynamic spawns to have limited/unlimited switches to cater for us who think... 'differently'.. This will be perfect, to allow for backwards compatibility and give everyone what they need. Hopefully this will be in the next DCS patch so I don't have to wait too long for my older missions/scripts to work again. Is there any chance that including dynamic spawn as a switch/option to turn on and off in the API was also requested? If I feel burned out, I can only imagine how much more challenging it must be for you - especially with so many more people relying on you than me! Once again, thank you very much for the work you do and for taking the time to explain the bigger picture behind these changes, and for requesting a limited/unlimited switch! Take care, and have a great weekend! DZ

Did you have any particular settings tweaked in OpenXR Toolkit prior to the update? Take what I'm about to say with a big grain of salt, but I had a strange issue with mine where I too lost performance. I found that in the registry for OpenXR Toolkit there were 2 entries. One for DCS and one for DCS World. It appeared as though my existing entries had been removed, but I was able to copy them from DCS to DCS World. I'm not saying that's definitely the case, because I was playing with some other stuff at the time as well, however I did have performance issues, and after restoring my OpenXR Toolkit I am back to experiencing the same performance as pre-patch. I'm running OpenXR / HP Reverb / 4090 / Win 11. It may not be the issue at all - but it might be worth just checking, especially if you tweaked settings in OpenXR and they're no longer there.

Takeoff and landing events reported as a bug and seen by Bignewy in this thread yesterday...

Confirmed as an issue by vsTerminus. Reported here: https://forum.dcs.world/topic/353933-s_event_land-not-firing/

Interesting. I haven't gotten to play too much yet with dynamic spawning, as other things in the script are broken - but I thought that you wouldn't be able to spawn at airfields unless it was with that coalition as well? Or does Dynamic Spawn allow you to spawn at an enemy airfield?

Thanks. If you weren't getting that message, then it sounds like it could be an issue with 'on landing' not being recognized, or similar. There's a number of event functions no longer working that used to. Until we know whether or not these are intentional and aren't going to be fixed moving forward, or whether they're an accident/bug and will be fixed in a future patch, I'm not sure there's much more that can be done at the moment. Might be worth just waiting to the next patch to see if it starts working again?

Also - to add to my previous post, you may be able to use Airbase.setCoalition to capture the airbase without putting down a unit now: DCS func setCoalition - DCS World Wiki - Hoggitworld.com Or in MOOSE: AB = AIRBASE:FindByName(AIRBASE.PersianGulf[airbasename]) AB:SetAutoCaptureOFF() AB:SetCoalition(1) Replace airbasename with constant of airbase. Coalition 1 for Red, 2 for Blue. It will save dropping unnecessary units down to capture airbases, but will also mean that they can't be captured except through lua code - so keep that as a consideration. CFrag's method is better if you want units from the other side to be able to re-capture the airbase by overtaking the forces there. The above is better if you want to control it yourself using scripting.

I haven't had time to debug - but I'm suspicious that ... if event.id ~=4 then return end -- not 'landing' ... is not triggering as expected. I haven't been logging stuff down (I need to start) - but I've got the feeling that there's numerous events that are broken, or are undocumented removals of functions in the latest patch. I don't have access to DCS at the moment to test, but if you modify the script to add the following, you should be able to see if it makes it past this line or not: trigger.action.outText("DEBUG: EventID 4 recognised!", 30) ie: grabber = {} grabber.version = "1.0.0" grabber.uuid = 0 function grabber.getUUID() grabber.uuid = grabber.uuid + 1 return grabber.uuid end -- -- script to "grab" an airfield after landing a plane -- function grabber.getClosestAirbase(theUnit) local p = theUnit:getPoint() local all = world.getAirbases() local dist = math.huge local closest = nil for idx, theBase in pairs(all) do local ap = theBase:getPoint() local dx = ap.x - p.x local dz = ap.z - p.z local d = math.sqrt(dx * dx + dz * dz) if d < dist then dist = d closest = theBase end end return closest end function grabber:onEvent(event) if not event then return end if not event.initiator then return end if event.id == 10 then trigger.action.outText("Airfield " .. event.place:getName() .. " was captured by " .. event.initiator:getName(), 30) return end if event.id ~=4 then return end -- not 'landing' trigger.action.outText("DEBUG: EventID 4 recognised!", 30) local theUnit = event.initiator if not theUnit then return end local theField = grabber.getClosestAirbase(theUnit) -- player landed on 'theField' local coa = theUnit:getCoalition() if coa == theField:getCoalition() then return end -- belongs to us -- drop a SoldierM4 slightly away from out landing pos local p = theUnit:getPoint() local groupData = {} groupData.name = "grabby-"..grabber.getUUID() groupData.task = "Ground Nothing" groupData.units = {} local gUnit = {} gUnit.x = p.x + 100 gUnit.y = p.z + 100 gUnit.name = groupData.name gUnit.type = "Soldier M4" table.insert(groupData.units, gUnit) -- spawn it coalition.addGroup(theUnit:getCountry(), Group.Category.GROUND, groupData) trigger.action.outText("Attempting to grab airfield " .. theField:getName(), 30) end -- -- start up -- world.addEventHandler(grabber) CFrag is no doubty flat out in spare time trying to solve a bunch of other broken things (as are a lot of us as well), so any debugging you're willing to help with would be greatly appreciated.

And if not - is it possible please to give us access to a call to toggle the FARP from being unlimited (which was the original default), or not unlimited. I'm aware that there are some who would welcome the change for the FARP to have unlimited turned off because they want to do more with warehousing - but it does break existing script for many others. If switching it back is not an option, giving us access to toggle unlimited on the FARPs via script would be the quickest and easiest solution that would accommodate both sides.

Thanks Flappie - confirming too that I only tested cold, not hot.

Hi MarcosR - I haven't tested this yet TBH in that scenario. I only tested it on my client install. I'm hoping that it's only server side, but even so - I would be pushing for us to have ED fix this natively so we don't need to hack our way through.

Dear ED & DCS Community Members, Firstly, to ED - thank you for all the work that you have put in for such a big update. Dynamic Spawn slots are something that many of us have been waiting on for quite some time, as well as the ability to change graphic settings without first loading in game. It's exciting to see these features getting implemented into DCS. I can only imagine how large of a job this would have been and how big this release truly was. The update however has unfortunately not been smooth for many of us, and has created game breaking issues with missions, not to mention the bugs that have not been picked up by the closed beta team. With such a big release I guess this is to be expected, however I do believe that there may be opportunity to reduce this for future large releases in a way that will be beneficial to all. I would like to put a suggestions out there for both community feedback, and for ED to consider with the hope that we can look at having future big updates roll out more smoothly. Firstly, I would like to throw out for consideration the option for a different type of Open Beta testing. I am well aware (and appreciate) why the Open Beta version has been discontinued (in part I think I may have had a part to play in it with a previous suggestion ), and I am not suggesting that we have that return. However, it is possible that the current Closed Beta testing is not picking up on all the bugs, and many are slipping through - some with significant consequences to gameplay. I'm also aware that recruiting more people to the closed beta team to cover this is not a desired option. So, as an alternative, for special situations such as large updates, I wonder if it would be worth announcing to the community a special custom open beta update for testing on the odd occasion when there are large releases like this. The way I envisage how this would have worked in this situation is this (I will use the last update as an example): It would be situation as normal, with the only exception being that last week, 2.9.6.57650 would not have been released on the release cycle. Instead, an announcement (maybe in a "Open Beta thread here?") saying "Open Beta Version 2.9.6.57650 is available for testing" could be announced. Those of us that wish to update to this version for testing could do so by using the custom dcs_update.exe update dcs_updater.exe update 2.9.6.57650. This differs from the 'old' way in the following: General users would not have a prompt that a new update is available, thus the majority of DCS players would not even be aware of it's existence. This would not be used for every release - it would only be used for large releases like this one, that have the potential for numerous breaking features. It would give mission designers and community members time to test, and provide bug reports, as well as feedback for possible missing functionality. It would give mission designers and server hosters the opportunity to identify undocumented changes that cause problems. (Such as changing FARPS from being unlimited by default to nothing by default - which is breaking a lot of scripting at the moment) It would give mission designers and server hosters prep-time to make changes to their server's missions in advance so that when the actual version is built there is far less downtime for servers after such big updates. It would allow a larger pool of true Beta testers to test and identify bugs before it reaches a production release. Once the bugs are ironed out, another Open Beta release could be issued, and if that went smoothly, that build could be then added to the official release cycle where normal DCS users would then get a prompt to update. This would bypass the current buggy build. Given that this would be a custom command to execute, and it wouldn't be a common thing, I believe it would avoid the previous trap of the community defaulting to Open Beta as their default for general gameplay, servers, etc thus avoiding the risk of any Open Beta becoming the 'main game' and allowing for true Open Beta testing. And for the few community members who would use it as their 'play game' - there would be no recourse for complaint that things aren't working because the only way to update is to obtain the build information from a thread that specifically says it's for beta testing only. I would imagine that the functionality to support this is already embedded in DCS now. We have the ability to update to custom builds, so if this build was released, but not updated into the "Current Version" variable on your website and update API - this may well be able to work without any programming changes necessary at all, just a slight change in procedure and a tick of approval from upper management. There may well be a better way to handle this than I have suggested, so I welcome constructive criticism on my suggestion, however I do believe that something needs to change because dealing with constant breaking bugs on releases is not good for any of us, ED included. I would also welcome the opportunity to be able to provide feedback and requests prior to an actual release. Besides the bugs, there are a few features desperately missing with the current version (such as the ability to set a FARP to have unlimited resource through script) that if we had the opportunity to give this feedback I envisage the release of this new feature would have been smoother and more welcomed by all. Thanks for your consideration DZ

Actually, it seems DCS does scan new dynamic FARPS to see if they should be on the list. The problem is that there’s a function it calls (dynamicSpawnAvailable) to see if the FARP has DynSpawn enabled and as it doesn’t (no way at present to set it via lua code and its false by default) it bypasses those FARPS. I’ve managed to get this to work by modifying one of the lua files in the DCS install directory, but it is a hack. It works when running a local MP mission on the client, but I have not yet tested at a dedicated server side level. But it does provide proof of concept. DCS does include new FARPs in its scan, so DCS can handle it, if they gave us the option to set the variable that we set in the mission editor for DynSpawn via LUA. Maybe there is already an option but they’re not telling us what the function is called yet. We also would need the option to set the stores. I’ve used a script that dynamically created FARPS previous for rearming and refueling that’s worked fine up until this release that is now broken since this patch. For some reason they’ve changed new FARP creations from unlimited to empty by default. If you want to know how to get a slot to show up on dynamically created FARPS, here’s how. I haven’t persisted with going further than that for now. TBH, I’m quite discouraged at the moment from mission design in DCS. When it finally seemed like what I’ve been dreaming of achieving for years is almost within reach, not only is it not, but it’s one step forward, 2 back with more things that used to work are broken (and talking to some others, it seems this change for default FARP parameters is intentional). So, just like the event_dead on cows that was working and has been removed for 2 years, (and I’m now told “it’s intentional to not have it anymore on cows”), the impression I’m getting lately is that nothing is safe. What other work I’ve done is next on the chopping block to be permanently removed at some stage in the future, by intentional design, with no plans to give it back- or at the least take a long time before those features are made available again? Bugs are one thing, but removals of previous functionality of change of design, while leaving no simple options for us to have backwards compatibility to still maintain existing functionality is another. (Why would they change FARP from defaulting to unlimited to not without giving us an option to switch it back to unlimited via lua?) Maybe it’s my fault, wanting to design a complex dynamic MP mission/server campaign that ‘s up there with the big ones. I see the potential DCS has and want to get there. I keep finding ways to overcome DCSs limitations which gives me hope, but then see intentional changes made in newer releases that breaks themis disheartening. So is having no feedback on whether ED has any intention of allowing us DynSpawn on DynFarps. I sometimes think that the CB team get more info on the direction things are going, so they have time to prepare their missions and servers in advance before release, which is why they can maintain their missions easier and prepare for things that break, and the only way to succeed in having a complex 24/7 MP server is to be in the inner circle. But then seeing Enigma’s video of why he left and identifying with his struggles, has me realising while it’s probably somewhat helpful and would solve some of the issues, there is still a lot to deal with even then. I’m not sure if I’m being rational with my thinking, or I just had some bad nights sleep, but I do feel like I need a lifeline atm to restore my enthusiasm in mission design. Has me wondering how other designers are going, and if it’s just me that’s struggling.

Having the same experience as you. Seems to slide around in a small circle but in the same location - not constantly in one until it falls off the ship. Looking encouraging!

Strongly suggest sticking with Skatezillaz DCS Updater for launching DCS still. It’s been doing a terrific job at launching DCS with different configurations for ages and it’s pretty solid/reliable.

lol. Sorry, I meant ED. Typo. Crazy, since I haven’t purchased an EA title in over a decade.

OK - I've found one way for this to be successful - but it requires 'hacking' the DCS install. I'm not sure whether this is just a server side thing (if so, it may mean that us mission hosters may be able to have dynamic spawning on dynamically spawned FARPS moving forward)! It involves editing the Scripts\ui\MultiplayerSelectRoleMap\MultiplayerSelectDynamicDialog.lua file, and commenting out certain IF statements so that the dynamic spawn will spawn regardless. (Note: This has the sideeffect that dynamic spawn will always be available for all airfields, as it ignores the dynamic spawn true/false in the mission file). I'm hoping there's a more eloquent way of achieving this that doesn't involve modifying (hacking) the .lua file on the server. function getAllDynamicsAirdromes() airdromes = Terrain.GetTerrainConfig("Airdromes") local dynamicsAirdromes = {} for i, v in pairs(airdromes) do local settings = DCS.getDynamicSpawnSettings(i, true) --if settings.dynamicSpawnAvailable == true then base.table.insert(dynamicsAirdromes, i) --end end return dynamicsAirdromes end function isDynamicSpawnAllowForAirbase(airbaseId, isAirdrome) -- local settings = DCS.getDynamicSpawnSettings(airbaseId, isAirdrome) -- if settings and settings.dynamicSpawnAvailable == true then return true -- end -- return false end function getDynamicsAirdromes(coalition) local dynamicsAirdromes = {} airdromes = Terrain.GetTerrainConfig("Airdromes") for i, value in pairs(DCS.getAirdromesCoalition()) do airdromesCoalitions[value.airdromeId] = coalitionIndices[value.coalition] end for i, v in pairs(airdromes) do local settings = DCS.getDynamicSpawnSettings(i, true) --if settings and settings.dynamicSpawnAvailable == true and coalition == airdromesCoalitions[i] then if settings and coalition == airdromesCoalitions[i] then v.airdromeId = i v.airbaseType = _('Airfield') base.table.insert(dynamicsAirdromes, v) end end return dynamicsAirdromes end function getDynamicsFarpsAndCarriers(coalition) local farpsAndCarriersData = {} local addFunc = function(data, airbaseType) for i, v in pairs(data) do local settings = DCS.getDynamicSpawnSettings(i, false) --if settings and settings.dynamicSpawnAvailable == true and coalition == v.coalition then if settings and coalition == v.coalition then v.unitId = i v.airbaseType = airbaseType base.table.insert(farpsAndCarriersData, v) end end end local farpsAndCarriers = DCS.getFarpsAndCarriersMissionData() addFunc(farpsAndCarriers.farps, _('Heliport')) addFunc(farpsAndCarriers.carriers, _('Aircraft carrier')) return farpsAndCarriersData end

I've managed to find a 'hack' to do this, but not sure if there's a more elegant way. By changing the 'warehouse' file within the .miz file I can replace all references of: ["dynamicSpawn"] = false, with ["dynamicSpawn"] = true, Likewise, it might also pay to replace ["unlimitedAircrafts"] = false, with ["unlimitedAircrafts"] = true,

Hi, Just wondering if there's a quick way to enable Dynamic spawning at all airbases and FARPS or if we need to go through individually and assign them. I couldn't find anything in the ME. Just wondering if there's a way to enable it through LUA/script?