Matrix Games Forums

When making a scenario using "unlimited Magazines" is not realistic, however placing each individual weapon in a certain quantity takes a lot of work.

So how about an "add to" button (From the ready screen) , where you can highlight then click and automatically add all the weapons in that loadout to your magazine/s ?

So for an A10-A, CBU-52/B CB loadout. Highlight the loadout then Click "ADD to" 3 times and 3 of that entire loadout is added to the magazine/s.

Be much faster.

I _think_ we already have something like this...? When adding weapon records to a an airbase/carrier's magazines?

I see the ability to add weapons.
Tried selecting both the airbase and the individual magazine.
You would still need to know exactly what weapons - /bombs/missiles/pods etc. and their exact models your aircraft needs for the Country it's used by.

If there is an easier way to add an entire aircrafts payload to a magazine for your Country with one click I'm not sure how to do it.

ParachuteProne wrote: Sat Dec 24, 2022 1:51 am When making a scenario using "unlimited Magazines" is not realistic, however placing each individual weapon in a certain quantity takes a lot of work.

One thing to realize is that there isn't always an integer number of loadouts of each type available. It's completely possible that you might be forced to choose, for example, between filling your DCA caps and equipping your strikers with self defense missiles.

The other problem at work is that the database of aircraft loads isn't completely realistic. There are usually more (often lighter) safe loadouts on an aircraft than the database depicts. That tends to push towards an overconsumption of some weapons. Over time, I'm seeing more and more aircraft with less than "full combat load," because it's a way of managing one's consumption of munitions. Some of that is helped by making certain weapons "optional." If I was going to revamp the database, I'd probably be a lot more liberal with my optionalities. Targeting pods? Optional. Self defense missiles? Optional? I generally like the guys' guideline that if you want to have a given aircraft configuration added to the database you need to send them a photograph of it. I think that's very smart. It's probably overly strict, but given the hundreds (or in some cases THOUSANDS) of possible ways of configuring a given aircraft, it's probably a wise decision to keep the database size reasonable and the amount of labor for maintaining it under control.

Ya, guess we never know what munitions are ever at a base anyways
Another option is to add to the "unlimited weapons" choice by having player choose the number of sorties that can be flown. Even that isn't accurate but might be better than just choosing unlimited and slinging missiles until the target can no longer defend itself.
After the plane does "x" sorties it cannot rearm

SeaQueen wrote: Wed Dec 28, 2022 1:01 pm The other problem at work is that the database of aircraft loads isn't completely realistic. There are usually more (often lighter) safe loadouts on an aircraft than the database depicts. That tends to push towards an overconsumption of some weapons. Over time, I'm seeing more and more aircraft with less than "full combat load," because it's a way of managing one's consumption of munitions. Some of that is helped by making certain weapons "optional." If I was going to revamp the database, I'd probably be a lot more liberal with my optionalities. Targeting pods? Optional. Self defense missiles? Optional? I generally like the guys' guideline that if you want to have a given aircraft configuration added to the database you need to send them a photograph of it. I think that's very smart. It's probably overly strict, but given the hundreds (or in some cases THOUSANDS) of possible ways of configuring a given aircraft, it's probably a wise decision to keep the database size reasonable and the amount of labor for maintaining it under control.

Makes sense. Just added a request to the DB update page to make sure the DB team sees it. Please do comment if I missed something important. I just typed stuff.

https://github.com/PygmalionOfCyprus/cm ... ssues/2713

Mike

FYI
There is a Lua method that adds a number of loadouts to a magazine.

ScenEdit_FillMagsForLoadout({unit='RAF Lakenheath', loadoutid=45162, quantity=12})

I would love a checkbox on "edit sides" that let a scenario designer mark a side as unlimited magazines. Handy to mark the AI side as unlimited while manually setting magazines for the player side.

Craigkn wrote: Mon Jan 02, 2023 1:03 am I would love a checkbox on "edit sides" that let a scenario designer mark a side as unlimited magazines. Handy to mark the AI side as unlimited while manually setting magazines for the player side.

As would I as part of side setting or side doctrine (having the scene-feature remain for backward compat), but lord only knows how much code has to be touched to accommodate it in a fully backward compatible way. Juice vs. Squeeze issue will come up no doubt.

I've have used the Lua function michaelm mentioned to help me fill stuff, it's handy for initially filling. Between it other automated mag manipulation you can basically do it for the ai side via Lua, on schedule\triggering of your own choosing. It's not necessarily for the uninitiated but one can give the ai unlimited weapons by refilling existing entries in the mag tables for lists of specified units\bases (or wiping them and using that function to refill them), though big scenes doing that can get challenging to manage and test, it was kinda problematic in earlier versions but builds 1147.(~2x+) contain improvements and bug fixes in being able to manipulate mag entries better in this regard via automation. Just wanted to mention the plumbing is there for those that want to invest time in setting something like that up.

I want to mention something that ties into this and the other discussion on lua and wargaming. It seems like a lot of players think wargamers some in two distinct groups: either programming savants or complete avoiders of lua. I would bet that there is a middle group that is larger than the savants and at least as big as the avoiders. That middle group doesn't write full code nor does it sit around pining for wanted features. This group uses the console in the editor or writes simple statements for events/triggers/actions. lua is generally a basic one or two statement endeavor to provide some simple automation through the console or its a statement to help the AI deal with a complex problem.

I know I fall into that middle group. I never write more than two lines. I do look longingly at some of the more complex code I see people like Knighthawk doing. But I specifically minimize lua in my scenarios to avoid overly complex scenario maintenance. One pf my pet frustrations is the overuse of lua that makes the scenario very fragile and susceptible to issues when the core program changes. The hardest part of being in the middle group is knowing what functions are available, usable, and the details on how they work. For that, better descriptions and a lot more examples in the github docs are a wish. But reading over the CMO lua legion subforum helps a lot also.

I would rather the devs spend more time on lua help docs over built in CMO capabilities that need UI and dev time to build out. Such as this specific request.

Amen

thewood1 wrote: Mon Jan 02, 2023 3:00 pm I would rather the devs spend more time on lua help docs over built in CMO capabilities that need UI and dev time to build out. Such as this specific request.

I tend to agree, found some more things missing from doc tonight (will post shortly so they get added, thankfully I remember reading the release notes so I knew they existed).

Also just cause some of us can write some more "involved" stuff often you are right 'good enough' in a dozen lines or less here or there gets the job done for what someone wants when it's relatively simple or straight forward. But sometimes super simple is not what is needed, or the 6 lines solution has it's own bugs that the user didn't think about covering the case for or maybe doesn't work in all possible situations that have not been thought about. For instance in relation to op, just from memory like the loadout mag filler function getting adjusted recently to work even when it would otherwise cap-out, great addition from michealm there to let it succeed and over-run the mag caps anyway. I also tend to disagree longer lua code leads to breakage with time, not that it doesn't happen, but quite the contrary I'm often writing, and seen others write lots of extra code such that things that will work independent of some of the ground changing below or fixes additions getting made,at least to the extent possible. Most of the "involved" parts aren't often the meat, it's validity checking and error trapping, logging, providing more obvious hints to where things went wrong. imho the 2 liners are more apt to break then the same code taking 8 with some checking and logging done. Thing is few want to, or know to add the extra lines say for nil checking, wrapping things in pcalls, checking the results so execution can continue and such. I GET that, they're not programmers and they don't want to be any more than they absolutely have to, their just trying to make things work as best they can. The breakage with time is often one of two things, sometimes its on the game developer (with-in reason, obviously major milestones or entirely new version can require some loss of backward compat. or minor reworking) breaking something that was working, fixing it in following build, and then problem comes back again some build later - that's not me moaning about that, it's just been a reality. There isn't much the author can do about that, they report it an either wait while their scene is broken, or try another way to code around the problem till it's resolved at some point in the future. The second I mentioned already peeps not making there code resilient to what if's. Like what happens when the unit object your getting and doing something to does not exist, or is missing the mount you expect to be there, cause it unexpectedly got destroyed or maybe wiped out during a rebuild or something. Did the author write a couple extra lines to handle that case gracefully, maybe log it if its important? Many don't, or don't know how, and that's fine in my book too, I do my best to help\teach those that ask. A little can go a long way. It's a habit and skill I do not expect most authors to have, though I've noticed the community at large getting better at it over time. Ok.. I've seriously digressed and need to shut up.

Anyway back toward topic and op and craig who may want to automate parts of what they want to do, like AI side to have nearly unlimited mags.

Craigkn wrote: Mon Jan 02, 2023 1:03 am I would love a checkbox on "edit sides" that let a scenario designer mark a side as unlimited magazines. Handy to mark the AI side as unlimited while manually setting magazines for the player side.

I'm gonna try and help you there, at least with the automation part, I can't really help people build the lists of what they want\need, but I can help with the once they know what they want to do and too what and script it, either for doing it once, or reoccurring in the game at intervals, without becoming a programmer or having to understand too much about lua (but you will have to edit\add some lines of text to table\list).
In relation to that this thread prompted me to throw this up for helping with loadout filling of unit mags, and for mag-topping up overall say on an somewhat unlimited ai-side: https://www.matrixgames.com/forums/view ... 6&t=391594

We added a GUI way for adding a loadout's weapons to onboard magazines in Build 1301.1 . Have a look.