Pikey

fwiw (this will get lost in about 2hrs) getCategory() was fixed after many years, maybe never worked since 1.2. This will break scritps because people will have learned how to use it over time and copy paste does the rest. If you have scripts with examples like: category = event.initiator:getCategory() if category == Object.Category.UNIT then This will fail because the return has changed to depend what the function was called on, for example it returns now; Unit.Category = { AIRPLANE = 0, HELICOPTER = 1, GROUND_UNIT = 2, SHIP = 3, STRUCTURE = 4 } Airbase.Category = { AIRDROME = 0, HELIPAD = 1, SHIP = 2, } Weapon.Category { SHELL = 0, MISSILE = 1, ROCKET = 2, BOMB = 3, } Beforehand it used to be fixed to this: {UNIT = 1, WEAPON = 2, STATIC = 3, BASE = 4, SCENERY = 5, CARGO = 6,} Moose is fine (if you immediately update) and SpecialK has updated a bunch of things but I expect here and there people will bump into this.

Can confirm pretense current version is not compatible, Pretense uses this and other warehouse scripting commands available with only 2.9. Good for Dzsekeb, the mission is cutting edge, and having tried it, very impressive work.

https://metro.co.uk/2023/03/15/one-in-six-people-cant-tell-the-time-on-a-normal-clock-18445913/ It's probably personal, but gauges with needles do offer advantages for brains where the speed of the needle, its peripheral motion and its distance between markers and shapes can paint all sorts of clues at a glance. Unfortunatley glancing and eye flicking is badly affected by VR sweetspots and lack of screen space for sims The movement of needles is super important to help with awareness, since your periphery is more attuned to movement. Now cockpits are adhering to text rules like "whitespace". Cockpit development is so amazing.

I asked about this also, just FYI. The "depends on" line in the unit lua states the requirement for a specific search radar unit to be in the group, when in reality a vast number of combinations were possible. I actually wanted to propose removing it entirely and using the entire sides radar view as the search authority to provide az/el for the tracking radar. That would need more behaviour change for tracking radars to adapt to, but it would also mean the birth of IADS. CUrrent system is like a foolproof way of telling people it has to work in one configuration only. Makes sense from a casual gamer pov, but anyone who knows anything will want the flexibility to have more. Maybe one day.

Mig-29A or a later red peer fighter. This is for everyone that likes a duel. All The Good Things that were started, to be finished. This is for common sense. Things like Clouds, weather, modules. For myself; in the order, of an FRS.1 circa 1982, an FRS.2 with Blue Vixen circa 1993, and failing that, a Harrier II + with aim-120 and harpoon or penguin (use the Spanish one if there's issues) A Sheffield class type42 AI.

This isn't down to the 0 to 1 waypoint not following the On Road is it?

Never tried it, just read it. Look slike it runs for each of the clients, doesnt look like AI

if it's working, and keeps doing the same thing, I'd suggest the script hasn't been updated in the miz file / remains unchanged. Drop a trk file of what happens and tag me if you do that and it remains the same.

I had to have a quick test again to see where large ground AI failed, to be fair its much improved over the years where my cynical answer would have been to not bother. Ground AI is really basic, without an "attack group" command its really unsatisfying to place groups next to each other and see them move only along the line of the route whilst firing, quite unnatural. I can't offer anything about scaling without coming up with a huge test, the feedback from servers is that you can put more units down than you used to. Here is what I think about company sized groups: "Don't". The ED formation procedure takes ages, and cant form up in woods or tight spaces - stick to small groups. Instead invest time building a class that puts platoons following a lead platoon, using bounding tactics, in order to slow down combat. Ground AI is so simplified that we have to do the thinking for it. We need some FSM's - "under fire", "covering", "bounding", "suppressed" using events and tasks. We need to attach platoons to lead platoons to make company elements and move them in a more realistic way, but keeping that 3-4 group count. Similar to how the "follow" task works but better. Then I might get interested in large scale combat again. Otherwise its just chaos.

none taken. the Net methods in the API that are placed in the saved games\dcs\scripts\hooks directory had an API written 2015 that was at the time, server only. In late 2021 ED allowed the net class to be reached from the client side so server code coudl be executed, which was pretty cool, but I think it was a quiet thing that didn't get announced. I convinced Thomas to write the wrapper the following year: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Net.html Not many people are aware of this, I was just helping out. I also did a blocking scripting form the mission environment that using the net class to ckick to spectators all from mission scripting. https://github.com/thebgpikester/MPSG So, hope none is taken but this is the part where MOOSE and the SSE isn't solely client side, it can be run from the server and executed as the server all from the Misison environment without a single addon or hook.. If you need any help understanding the scope of the client environment when run as a server I'd be happy to explain it. Edit: (addition) I did pick up that you were talking about restarting the entire sim because these are enumerated during start up. This is why its annoying and using mission takes much less to debug. The only limitaiton is that you need to run as a server (but that option was added to the Misson Editor about the same time)

Any unit, any static. A house static you spawn in a neutral airbase 2km zone will capture it. A portable tacan or an RAF firetruck will capture a red airbase and turn it blue null

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.

Worth adding that lists can go out of date, Grimes' tool he's not updated since 2.7 but here are two alternatives: 1. https://github.com/Quaggles/dcs-lua-datamine 2. https://wiki.hoggitworld.com/view/DCS_func_getInventory The second you need to write something that prints a table to file but will give you the bonus of all the weapons too.