Pikey

So as far as I checked this works the same as it always has, but the main things to look at now are how we can break the old limitations. Off the top of my head: - You can use the setItem() on a limited warehouse to set a quantity to 100 and then removeItem() 100 to force the Resource Manager to begin delivering stock from 0. This was a big gripe that the resource manager would never send you more than your initial allocation. This isn't a problem until you realize that all your warehouses have to start with something in stock. This means you either always have very low levels and hit the threshold for restocking too soon or you start with too much stock that it doesn't matter. It was hard to explain to people that it was important, only a few folks in the community played with it. - With scripting you can add or remove stock as you please. Although it sounds like there should be mention of scripting, the API is not related to how the game mechanics work. The Resource Manager hasn't changed its rules as set by the manual. The capture mechanics are unchanged, the affect of coalition ownership is the same. What has changed is how you might use it now that you can script the contents, which is an imagination topic. The actual way scripting is used is not in scope for this topic, which was always about how it works, specifically showing its quirks like the supply chain, the range of airbases. On a related note, the capture mechanics are now also blown right open, giving an additional amount of flexibility:

Wheres the watching progress bars?! I once filmed this and sped it up to music that showed the madness of it.

"SEAD" as an Enroute Task is always a lower level than a Perform Task, task. Enroute tasks exist for the duration of waypoint to waypoint in that the AI will detect and prosecute targets itself autonomously until no more are detected or it runs out of ordnance or its disabled. I suspect the HTS increased the detection and prosecution range. Attack target tasks will sit over that and be executed in a 'battle of preferences' depending on if the enroute task was in progress or popped out. The description of the enroute task being executed immediately and the AI going wild and trying to reset their waypoint is exactly as expected. The AI goes a little mental and various scripting solutions have tried to fight this unpopular behaviour but its as designed. Basically, CAP, CAS and SEAD that you see are propagated to every waypoint are like letting a police dog off a leash. It goes for the first thing it sees and often not to the desired effect. And once off the leash, it it difficult to catch. I can definitely say the description is expected via the limited automation of the ME. Those big enroute tasks are absolutely wild and uncontrollable. What's worse is that the ME actually There's two issues that I think might help to be solved: If enroute tasks could be limited by a polygon zone to keep some degree of leash If AI could try to continue routes where they left off. A third issue is that Enroute Tasks propagate and cannot be removed "in part". I.e you use a drop-down and *CAP is on every waypoint. The most likely reason for it is to stop people from giving the "Nothing" task or even no task to an AI and making it a brain-dead zombie and reducing complaints. Also this is unit-based, so some tasks are forcibly not used (Can't AWACS a Harrier, good, cant CAP a Harrier, bad.) It's also worked around with either incredibly complex and nasty scripting not for beginners or by MOOSE classes that address the lack of ME flexibility and help with Task related actions for controllables. So basically we are at the mercy of the design. It might look bad to get AI doing sillier things in videos, but sometimes you want to be trusted too. null

Yes, there is plenty to look forward to. This allows unlimited imagination to be used. From basic script snippets that anyone can use in a DO SCRIPT, to custom factory checks and complete supply chains, either virtual or real. But the best part will be when the C-130 and Chinook arrive to give the player agency for this entire thing and complement or remove the script requirements.

So there is the STORAGE class in MOOSE that @funkyfranky wrote for Day 1 https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Storage.html but this is the start of what MOOSE might do with it to join things up. I did a warehouse persistance script, just saves your warehouse to file and reloads it: https://forum.dcs.world/topic/332310-script-release-simple-warehouse-saving-sws/ @chromium is writing things now for DSMC https://dsmcfordcs.wordpress.com/ I Chromui He's pinging right now for feedback as he rewrites parts. I presume for all these people there are others doing the same. It's going to take some time to make use of these because everyone is already established in workarounds and years of doing things a certain way. But in terms of using it, its some of the easiest things to use, you can make factories and supply chains that have physical presence.

Addendum 1 - Neutral units can't capture iirc, so that should be `if there are no units of a different, non-neutral, coalition within the 2 kilometre radius`

In the middle of the news about warehouses, these new API functions quietly tiptoed in the back door with 2.8.8.43489. This probably deserves more publicity, its not every day year we get new API functions. https://wiki.hoggitworld.com/view/DCS_func_autoCapture https://wiki.hoggitworld.com/view/DCS_func_autoCaptureIsOn https://wiki.hoggitworld.com/view/DCS_func_setCoalition Sample code: local Airbases = world.getAirbases() for i=1, #(Airbases) do Airbases[i]:autoCapture(false) end for i=1, #(Airbases) do Airbases[i]:setCoalition(1) end for i=1, #(Airbases) do local coa = Airbases[i]:getCoalition() if coa == 0 then env.info(Airbases[i]:getName() .. " is neutral.") elseif coa==1 then env.info(Airbases[i]:getName() .. " is red.") elseif coa==2 then env.info(Airbases[i]:getName() .. " is blue.") elseif coa==3 then env.info(Airbases[i]:getName() .. " is contested." ) end end This turns off autocapture, set all airfields red and prints out the result in the dcs.log. So the point of these new functions are that mission developers are no longer dependant on the existing DCS inbuilt function which determines the coalition owner of an airbase by a set of rules. What are the current system rules? By default, an airbase will revert to its Mission editor defined coalition if there are no units of a different coalition within the 2 kilometre radius (1.08NM) of an airbase center. The API funciton getCoalition() will return the result "3" if there are both coalitions in the 2km radius and on the F10 map, the coalition will show a blank. Statics can also challenge the airbase coalition, oddly, but planes and ships have no effect. i.e a blue static in a red airbase, unchallenged makes the airbase Blue. Until it is destroyed then it releases the airbase back to red. If a coalition remains unopposed in the 2km radius, including statics, but not including planes/ships, then the airbase changes the owning coalition to the presently inhabiting coalition. Players and AI can spawn at the wrong coalition airbase without issue, if the designer has set that to happen, either via scripting, or slots or Late Activation. ATC and rearming stops when the coalition is not the same as the players aircraft. AI planes without an airbase that RTB's will not pick an airbase of a different coalition. These rules have formed the basis of how we've played with DCS base capture since the game began and has been used as the basis of games by pioneers like BlueFlag. What is the new variation using the API? autoCapture() switches off the above system and the map does nothing. setCoalition() allows the Mission designer to force the airbase to adopt a new owner coalition. autoCaptureIsOn() returns the setting per airbase, if autocapture is on, allowing different rules per airbase. What benefit is available to the Mission Designer? Without the forced rules, Designers can use any system logic whatsoever to change the owning coalition to one that suits their design. Some examples (food for thought) include (and are not limited to): Not flipping the airbase owner until a specific threshold of units, time or type are met (maybe type, to prevent your single infantryman changing the map, or quantity, or the passage of time or the presence of specific units like ammo trucks, fuel, ammo etc.) Not flipping the airbase owner until something has been destroyed elsewhere, or certain zones or towns around are occupied. Increasing or decreasing or moving the airbase capture zone, or linking them to a MOOSE class. Using balancing mechanics like CTF rules. Specifically discounting infantry and statics, but including ships, or just adding planes, for example, to allow players to land and self-capture. Locking base capture down to specific player transport vehicles to emphaise those logistics guys Buying it via a menu item. Linking an empty warehouse to setCoalition() in order to force the coalition to Neutral and prevent services if the airbase is empty/neutral. Link capturing to warehousing so that warehouse contents are destroyed on capture Because access to airbase facilities and slots is often (not always) a driving factor in current DCS multiplayer meta play, having control over how a base flips coalition can now require more gameplay hoops to jump through, opening up more diverse gameplay possibilities. It certainly opens up campaign play to become a little deeper, rather than a single infantryman that is difficult to find. My own hope is that with C-130 and CH-47D on the SA page, a new meta can emmerge where logistics becomes pivotal to enabling the virtual fighter pilot gameplay and thus the two can need each other for escorting missiles to forward airbases that now need supplies.

Not true. Its been in MOOSE since 2018 at least and the active runway is what the AI use in DCS and what is given to players through the ATC system, as well as whatever ATIS class and so on uses. There are some rules, like you can't get it for multiple runway airbases and some unique issues like some airbases not having any runways, or fixed ones like Batumi. But what I said was still correct, in general, the wind tells you unless its one of the exceptions. The MOOSE AIRBASE util https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/OPS.FlightControl.html##(FLIGHTCONTROL).GetActiveRunway can help you.

I've updated the first post to include all four of the server persistence scripts I made and use. There was an issue with simple group saving that occurred some time back due to a bug with DCS where a get unit by number (MOOSE GetUnit(x)) no longer worked and only gave the first unit, which meant mixed units in a group would fail. I fixed this 5 months back. Added Warehouse persistence script (SWS) recently. Added a link to Multiplayer Slot Guard which is useful in the same context as an admin tool.

After your next failed attempt, press end mission and then Save Track and attach the track file here and we can review what you did and help. Cheers.

Many servers, few players? Reasons: 1. Folks leave their servers on 24/7, but they go to work, go out, do stuff that isn't just flying. This is hosting. Simple example, a squadron has a permanent server up for use by its 30 European players. They might play at weird times or not, but the server is expected to be on and available, and maybe one person visited quickly to set a binding that week. 2. Another reason is that people do not visit random servers. Source: I leave my server up when testing, sometimes just AI fighting it out for 3 days, to see what breaks. I don't lock it because people don't play spin the bottle in DCS. Why, because of more reasons; - If you invest in joining, starting up, taking off, only to be shot down by something not in the briefing or vulching or the server just switches off, you learn not to join random servers until you know they have some validity. - Server descriptions and the MP list doesn't do a good job of advertising a server with words. You rely on advertising and word of mouth to visit. - Squadrons leave training servers or test servers or specific use servers up all the time, they dont fly all the time. 3. Given the server list is the entire planet for OB or Release, you have 24hrs where a third of people are sleeping, a third are working. At best you have three times the servers that are needed. 4. People fly for short periods and dip in and out. There can be over 3000 unique players across a 24hr period in just one server suppliers visits. But you never see 3000 in just one server. So consider you don't see all the players from all time. Source is 4YA by the way and that data is known. 5. There's so many configurations of DCS its never the same game. You can include mods in that, but that's a tiny part of the issue. There are maps, planes, eras, flavours, mission types and you end up with people picking one dish in the 'all-you-can-eat' buffet. Folks have some idea that communities fragment over mods or maps and I hear this said many times over the years. People hate being confined to one squadron or plane or being told when to fly. Gone are those days. Kids are joining dozens of Discords and being idle, looking for their best option. The reason for fragmentation is the individual will and timing of people and which server they fancied and when, and which group they fly with this week 15 minute show before chasing a butterfly to something else.

it doesn't properly block the sun shine in case anyone wants to try, but the solar and lunar and stellar calendars are all usable for almanacs and accurate at least in the years I tried. sun rises and sets are all within minutes. Moon rises and sets and a bit messed up by the lighting modelling though.

You really should learn how to run scripts in the environment without any of that nonsense. Here is the original video showing how, its over 6 years old now but its had 8000 views now and does what you need to know.

Works for me. Is this a MP issue? burning.trk

This is quite old, since then a few things changed. One is that the net environment was callable from the mission environment. It might spark some ideas for simplification, it might not, but I was goign through posts and thought I'd offer. https://github.com/thebgpikester/MPSG its just 70 lines long, does not need plugin environment and needs no setup, or config.

There is no scripting for determining the active runway. Some are hard coded and the ones that aren't follow a rule of which way the wind is blowing to generate that. SInce you can get wind and you can observe the direction by watching AI, you can determine this like MOOSE scriopting does, but it involves work.

No, tracks are called replay, but they aren't a recording, they are a step by step reincarnation of a mission that was played. When in MP as a client, no tracks will show other players as they aren't there to be replayed. For MP, look for a free mod called Tacview and for servers that allow replays (ones that dont give you a blank track) Some servers withhold tracks but you can download them from the server after some hours. HTH with the reason its a hard no.

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/develop/SPA - Spawning/SPA-016 - Ground Ops - Randomize Zones

omg, you see I never knew that existed!! I was finding them through... I can't explain how i was finding/looking/searching!! Would it help to understand how people use first to be able to fix how they are failing maybe? For me I often want to scan the lot because I am trying to see if there is another function I maybe didn't consider. Not sure if that helps This one threw me, but iirc its the way it was written in the API docs just pasted in. It's weird that no one but Grimes actually updates this, I'm wondering if this is the barrier. I've updated Wikipedia more times than API docs.

Very aware of the limitations of getAmmo(), thanks. It was reported on these forums several years ago, I don't have any info I can give you about that - its been discussed in Moose discord and these forums many times over the years. I'd suggest creating your own thread for your idea on the checkbox so that it doesn't get lost in this warehouse thread, thanks! et

One thing I noticed when looking for a function by name, was, the routing of where to start. I've got about four pages bookmarked, class functions, singleton functions, enums which are always useful https://wiki.hoggitworld.com/view/DCS_enum_weapon_flag and the tasking one. I find that finding things and navigating is hard on the site. So I don't I just try each page for a function not realising their differences. For example. To find getResourceMap() and starting at the home page --> https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation You need to know that getResourceMap() is in the Warehouse class to click --> https://wiki.hoggitworld.com/view/DCS_Class_Warehouse Then this isn't a list of functions, in fact, its not listed as a member function? It's a static function, whatever that means and its lower on the page. For idiots like me at least, a big bucket of functions would make more sense than different pages that don't make sense. Maybe just understanding why they are split could help me to find what I was looking for? It probably makes sense to someone, and I don't have great ideas on a different way of doing it, so I apologise, but I think it's hard to navigate and find things.

the string is weapons.missiles.AIM_9 for the 9M. It's an anomaly for sure. Once you have a look at the print out from the warehouse it should be easy to use. hth.

These, like many API commands aren't mirrored in the Trigger actions. Trigger actions pertain to DCS Worlds standard mission-as-a-session format. With extended missions it reaches beyond your typical one session scenario and I would say this is aimed at long running or multiplayer missions to make the best use of it. For the Airbase API commands that werent mentioned in the change logs, you can use the TRIGGER DO SCRIPT and write the command directly, thereby using the same mechanism of having no script file (albeit, its the same thing) You can also copy scripts into these triggers to make them a trigger, so its a bit of a blurred line. Unit:getAmmo() returns wsTypes() afaik? If so then then the wsTypes is an enumeration that misbehaves and changes so its not good for use. However, may I introduce you to getResourceMap() released today which translates wsType to friendly name and makes your life much easier? If you use getInventory() on the warehouse you will get friendly names like SWS.SimpleWarehouse["Kobuleti"]["weapon"]["weapons.bombs.AB_250_2_SD_10A"] = 100 the wsTypes is a 4 letter code where the last two aren't always the same. That API feature can fix this issue you speak of.

Technically you can add the weapons and fuel at spawn time to keep AI going when there is nothing left in the WH, but really the better option is to granularly handle the players pylon by pylon which has been requested a long time back. I'm hopeful that if we all say thanks, then we might get such a gift again and some sort of pylon checking will eventually come.

Download from https://github.com/thebgpikester/SWS Put it in your mission, Run Once DO SCRIPT - SWS.lua PREREQS Requires lfs and io desanitized from missionscripting.lua. No 3rd party SSE like Mist or Moose required. WHAT IT DOES Gets the contents of all DCS Airbase warehouses in the mission and saves them to file. Reloads from the save every mission. (no prompts) USAGE Load this script at mission start as a DO SCRIPT. By default, DCS sets unlimited warehouses. Set some warehouses to have limited contents by clicking on them in the Mission Editor and unchecking 'Unlimited' next to any of aircraft, fuel and weapons. Set a fixed limit amount. Optionally, setup supply chains as per pg 104 DCS user manual EN 2020.pdf in your main DCS installation\Doc folder. CONFIGURABLE ITEMS SWS.filepath = lfs.writedir().."SimpleWarehouse.lua" You can configure a custom directory for the save file here if needs be. SWS.updateDelaySeconds = 60 You can change the timer interval for the saving of warehouses here. Now the waffle Administrators and mission makers can now consider warehouse contents in their mission creation flow. Previously we only used "unlimited" warehouse resources such as fuel, aIrcraft, and weapons because we had no way to save, persist, add or subtract from the DCS warehouses. Now we do. For a primer on how some of the weirder things work with the DCS Resource Manager, see For the documentation, see pg 104 DCS user manual EN 2020.pdf in your main DCS folder. There really is a lot to this hidden gem. The usecase for the script is that rather than set pacing of how an extended mission that runs for days works out, the AI is restricted by what is in the DCS Warehouse. There's several ways you can accomplish a "logistical win-lose" mini game in DCS mission editor: - Use the existing Resource Manager, set finite limits, no supply chains - first one to empty loses. - Use DCS Supply chains from warehouse to warehouse, empty the enemy coalition warehouse before you are crippled. - Use finite limits and add your own supply chains using the new API functions to add and remove fuel, units, weapons. - Use fantastic mods like the Hercules mod (soon-to-be-a-thing) and just your own plane and inventory to add resources to a warehouse by landing at the desired aifield and releasing control of the airframe and going to spectators. - Use AI to land at the desired airfield and shutdown, which achieves the same thing by adding the fuel, airframe and weapon loadout to the airbase warehouse. As a parting thing, I'd expect to see this used slowly at first because its a major Server design paradigm shift. Most people have their existing methods. You should see mods like DAWS freely embrace this, with hope, MOOSE may pick it up and utilize the new API functions. Its very easy to create a F-16 factory and having realistic bombing targets now. We relaly need bombing, but previously it was kindda pointless. Happy scripting.