Editing availiable weapons in Squadrons with Tacedit
-
Ain’t this: http://tactical.nekromantix.com/wiki/doku.php?id=falcon4:database:files&s[]=squadron&s[]=stores the deal?
Via F4Browse:
Falcon4.ucd
SSD index = This applies to squadron unit data only and links weapon squadron supply storesFalcon4.ssd
Squadron stores data file.This gets linked from Squadron Unit data (UCD) .
Lists all the weapons and count for this squadron (need values for weapons for resupply in campaign .
As I see it it’s ok in Units-> Aircraft-> SSD Ind?
-
Sq. stores are partially are mistery to me. Even you set 0 weapons both in sq. store entry in DB and set 0 in cam file from some weapons can have minimal qty. I have no idea why. Pls. if anybody ever make any doc which can help upderstand the logic of Falcon and helps modding and developing do not treat as some kind of secret…
Easy one …
First of - “Squadron store” in tacedit is “passive” as it only reads the DB entry. It´s not for “active” editing. Changes made in tacedit do not apply to the DB. Many data fields in Tacedit are just stats, which is very good as it gives real stats oversight for autosaves.cam files i.e. (compare stats of save0.cam file with same campaign just started and saved after 3-4 seconds). This way you can get the real stats for you save0.cam file (initiated and loaded).
Next - If “hardpoint data” for a weapon exists under “vehicle data” in the DB (min count 1), then even if that same weapon is NULL-ed in the “squadron store”, it still will/can be present aka “auto-load” it with minimal count of “1” in the campaign anyways as what pylon or weapon is put on what hardpoint is defined in DB under “hardpoint data” for each plane type.
In other words, first define your pylons (positions/hardpoints) for EACH PLANE - what weapons they are allowed to carry -then define the amount of those weapons for the whole squadron in the SQAUDRON (not plane) STORE.
Note: The amount of weapons for specific weapons in the squadron store might differ from the actual real number of available weapons as it depends on how many planes you have per squadron and the “rarity” of that weapon. You can test that by creating x number of packages with max number of desired weapon till you run out of that weapons. Having mastered this, you know are able to give each squadron more “realistic” amounts of weapons per squadron (not minimal, not unlimited)… so there will be a natural somewhat realistic wepaons attrition - till an Airlift arrives and that airbase and fills the virtual squadron stores up again.
-
First of - “Squadron store” in tacedit is “passive” as it only reads the DB entry. It´s not for active editing.
As for starter file of campaigns but later can be edited. Of course as defining thing in 0 hour this is right.
Next - If hardpoint data for a weapons exists under vehicle data in the DB (min count 1), then even if that same weapon is 0 in the squadron-store, it will/can be present aka “auto-load” it with minimal count 1 in the campaign anyways as what pylon or weapon is put on what hardpoint is defined in DB under “hardpoint data”.
The problem is that in some cases this happen in some cases not even considering the next quoted part.
In other words, first define your pylons (positions) for EACH PLANE - what weapons they are allowed to carry -then define the amount of those weapons for the whole squadron in the SQAUDRON (not plane) STORE.
For ex for one AC type I disabled AIM-9P and M and allowed only L. Only L is available. I did the same with some AG weapon but some strike weapons have minimal qty. in 0 hour while the other disabled not available. Every settings are the same and even considering the upper part the result is different… This is why was not possible to get functional squadrons and AC by only disabling weapons by sq. stores in my '80s campaigns. Many cases I had to delete the weapon itself and this is not possible to set 100% good DB for '90s and later eras with '80s campaign. Some still have AIM-120 or later weapons because sq. stores limitation works but in cases where does not…
-
As for starter file of campaigns but later can be edited. Of course as defining thing in 0 hour this is right.
Correct. The initial true squdron store is defined in DB. The save0.cam then loads it to know how much weapons are available in total for a squadron.
Later in autosave.cam files this number will change because of the usage of some weapons. Here one can edit (fool or fake) the “squadron store” value (with Mission Commander ie.) in autosave.cam files (remember it is still NOT a DB EDIT, but just a .cam-file STATS edit)… to simulate “resupply” of weapons i.e.For ex for one AC type I disabled AIM-9P and M and allowed only L. Only L is available.
Disabled WHERE and how? Removed weapon from “hardpoint data” or removed “hardpoint” aswell? Or just removed in SSD?
I did the same with some AG weapon but some strike weapons have minimal qty. in 0 hour while the other disabled not available. Every settings are the same and even considering the upper part the result is different… This is why was not possible to get functional squadrons and AC by only disabling weapons by sq. stores in my '80s campaigns. Many cases I had to delete the weapon itself and this is not possible to set 100% good DB for '90s and later eras with '80s campaign. Some still have AIM-120 or later weapons because sq. stores limitation works but in cases where does not…
Check the RF4 DB (only the planes, which are used in campaign!). I think this will give you an idea how it can be managed. I somewhat understand you - as i ran into the same quesitons back in days.
Remember:
The actual weapons shown on a plane are defined in “harpoint data” …“weapons” AND “hardpoint”.
Remove “hardpoint” or “weapon” from “hardpoint” and an un-desired weapon will not show with 0 SSD count in the payload screen anymore.
“Squadron Store” is only a VIRTUAL number (like resupply quantity with an initial set) for the WHOLE squadron and can not be directly used to “eliminate” weapons from certain pylons.
This is why they still load even if NULL-ed in store count.“Hardpoint Data” is an active direct edit (defintion of pylons and weapons later visible (or not) in the payload screen).
“Squadron Stores” are dynamic virtual statistics only, with one initial definition in DB “squadron stores”. -
Sorry to say this… but those are considered obvious stuff… like 1+1=2
Just a clarification here… not remove the hardpoint to remove a weapon but from the hardpoint remove the weapon.
Also in some AC’s they share the same data entries (probably from the addcopy function) and making changes to one will affect the connected ones also.
Like:
F-16C-30 -> F-16C-32/40/42
F-16C-50 -> F-16C-52
F-16C-52+ -> F-16C-52+CFT -
1+1=2 (obvious stuff) for you and for me maybe, …but not for everyone Arty.
I know what problem Molni has (i had the same long time ago). He will be able to fix it.
PS: Yes, remove weapon from hardpoint (as i wrote before)… and yes (IMPORTANT) …some aircrafts also use same data entries.
-
Disabled WHERE and how? Removed weapon from “hardpoint data” or removed “hardpoint” aswell? Or just removed in SSD?
Disable in my term means setting 0 in SSD DB entry. I do not how but as I know if you set 0 in SSD regardless of resupply in campaigns that weapon qty. never will or never should increase. At least this was the case in FF5.x. this is how were limited first the weapons in campaigns to help the ATO+AI. Maybe there is something in the code which checks the stores in 0 hour of campaigns and keeps forever the qty. 0 or disable the resupply forever for weapons which have 0 value in SSD.
This is why they still load even if NULL-ed in store count.
No, this is the problem itself. Some weapons have minimal qty. even if you set 0 in SSD - and as I can remember they never will be resupplied, so if you have used the minimal qty. the issue will be gone - but some do not have. Of course the most simpliest (and too brutal) way is deleting non desired weapons from HP DB entries but this seriously restricts the game in TE too, therefore I do not like this way. Just imagine how would look F-16s in case I delete every weapons which I consider not enogh good for campaigns… F-16A B15 in late '80s would have only Mk-84, AGM-65D, AIM-9M, CBU-71 and maybe smoke rocket pods… I rather allow not always optimal loadouts for 3D world than totally brake the freedom of players.
For human controlled AC the restriction should be smaller but on old, never well modeled old red jets I made very, very serious restrictions. Some of the can carry only 3-4 different type of weapons.
-
Molny maybe cause u set the 0 weapon and according to role and missions the code overrides the 0 and says hey wake up u can carry this weapon go and save me.
So we talk how it should be or how it is and what works 100%?
-
Of course the most simpliest (and too brutal) way is deleting non desired weapons from HP DB entries but this seriously restricts the game in TE too, therefore I do not like this way
Is it how it is Molni… and BMS is not FF (forget FF expirience - will just waste your time). As you are used to different “logic” from FF i can understand the contradicting logic now, but now…
“Hardpoint Data” is an active direct edit (defintion of pylons and weapons later visible (or not) in the payload screen).
“Squadron Stores” are dynamic virtual statistics only, with one initial definition in DB “squadron stores”.“Sqaudron Store” NULL-ing has NO impact on the payload screen results !!; but SSD still applies to the “HIGH”, “MED” and “LOW” inventory counter in the loadout screen.
As long as any weapon is available under “hardpoint data” on a “hardpoint” (or pylon), the sim always loads it with at least ONE weapon on that pylon (like a template), EVEN if SSD data for same weapon is NULL-ed.
You can NOT use SSD to define hardware specs on jets directly, nor is SSD supposed to be a “weapons-count-control-feature” directly on the vehicles (airframes). SSD is only for dynamic virtual STATS… so the sim understand how many weapons the SQUADRONS (on base A or base B) have …and how many will be re-supplied with the next Airlifts i.e. (filling up).I know, if SSD is 0 for weapon type X, then it should not laod it at all, but the code always laods ONE (template) for every available !!! weapon on a hardpoints, as the weapons are linked (attached) to the hardpoints first and do not consider the value in SSD. I agree, the code should only add a weapon to a hardpoint, IF SSD is NOT 0, but that is not the case atm (maybe a fix for 4.33 if possible?)
Look, “squadron store” (as the name says) is for THE WHOLE SQUADRON (like a virtual ammunition depot), but NOT for the definition of what weapons ARE or CAN BE loaded individually on each plane.
Weapons, you don´t wish to have in theater A or B…you need to “kick out” on desired vehicles. Problem is… when you use ONLY ONE database for multiple theaters (1980´and 2010´)… then you need to use different planes instead, with different defintions. I understand the conflict here, completly. Also the limitations with the TE expirience.
I also know, that you would love to preserve all weapons (hardpoints) and just limit (or NULL) their numbers by SSD data, but that is not possible atm, because as long a “weapons-entry” is available, the code automatically assigns ONE weapon of that kind in the payload screen to the pylon - even if not available in SSD at all. Why they made it so…i am not sure… i only can imagine it codewise why.Personally i understood very quickly, that making a “multipurpose-theater” with all options available and making at the same time a “specific theater” with more specific defined structuring (80´i.e) is almost not achieveable using one and the same DB - UNLESS different vehicle-sub-categories from one and the same DB are used in theater A and theater B. Then IT IS possible to use ONE DB with category A vehicles for theater A and category B vehicles for theater B. You can easily create (copy paste) new entities. For example F-16-52(80´) and F-16-52(modern) in your DB… same jet… just different “hardpoints” … one category for theater A (80´)…the other for theater B (modern) - and maybe one category C with ALL weapons available for TEs.
It is just a question of how YOU approach or design the whole thing. In other words… you need to find your own best compromises here how you create your individual squadrons, vehicles etc. etc. and theaters. Molni-theaters are more specific and are not “multi-” or “all purpose” KTO theaters
PS: Creating sub-categories for vehicles in one and the same DB is something we talked about before afair… like for SAMs: Sa-X (mobile) and same SAM Sa-X (non mobile). Same principle applies for different theaters of different time-eras with only one DB available. I only use one set in Redflag (only one theater), but Mystic for example has “old style BFS” and “modern BFS” … thus sub-categories of vehicles (if same airframe i.e is used in both). Just be carefull with shared “HP Usage” (weapons entry “Used By”). Different sub-categories of vehicles have to have different “Hardpoint Entries” in order not to use the same payloads - in other words if you create sub-categories for vehciles do the same for “Hardpoints” ( F-16-52 (harpoint 80)´… F-16-52 (hardpoint modern) )
…rest is up to your creativity
peace
-
As long as any weapon is available under “hardpoint data” on a “hardpoint” (or pylon), the sim always loads it with at least ONE weapon on that pylon (like a template), EVEN if SSD data for same weapon is NULL-ed.
This is simply not true. So far the point all of my post here was that most of weapons are not loaded if the value is 0 in SSD but are some exceptions. The problem that I was not able to find any pattern which weapons why and why on that AC…
-
This is simply not true.
It is for me.
Well… this is what i know from tests and observations and what i am able to proof by replications. I only hoped, that my feedback would help you as you are a dedicated theater maker (not many out there).
What exaclty goes wrong in your work and why it is “not true” for you i can´t tell tbh.
Molnibalage i am not able to re-produce what you are explaining here (the problem), nor do i know how well or how far you tested to get those results??!?.Just keep in mind, that i am not wasing alot of informative “ink” here in order to argue with you. Things work for us as we wish, thus it should for you too - well, that´s what i hope.
PS: I hope you are not using “Instant Action” for tests.
-
I’m jusing and tweak lots of AC what you never used.
First line AC do not suffer from this issue but Tornado, Jaguar and othe less frequently used AC more likels sufferend from this “0 SSD value but sometimes still available” issue. -
I’m jusing and tweak lots of AC what you never used.
Obviously your edits are based on your concept and are not of similar nature to mine as we had (have) different theaters and goals.
First line AC do not suffer from this issue but Tornado, Jaguar and other less frequently used AC more likely suffered from this “0 SSD value but sometimes still available” issue.
I just elaborated my “know-how” and that it works on my (our) end with the explanations of why and in the hope it will help you, but i am not able to help any longer regards your problem as you are “too confident for me” in the errors you obviously produced, nor do i have “insight” into your work to spot the problem on a workbench. Maybe my english is not the best, so you might need to read the whole thing with more “openness”, dunno.
Good luck in finding the problem.
-
I gave up finding the problem. Different kind of AC simply have very different behavior and I was not able to find any factor…
I release the theater. If is good I won’t restrict more if it is not I have to restrict more… -
Molny maybe cause u set the 0 weapon and according to role and missions the code overrides the 0 and says hey wake up u can carry this weapon go and save me.
So we talk how it should be or how it is and what works 100%?
In fact the opposite is the ture. Less used AC type somtimes do not get ANY strike weapons from ATO even many are available. Bigger problem that these AC take off the mission is not cancelled… Lots of AC can be tasked without ARM, they are simply eqipped by the second beast wepaon against unarmored AD units, they get in most of cases CBUs. This is why so different my campaign becase hordes of old J-5/J-6/Su-7/Q-5 can kill the blue AD while in stock BMS4 they just fly suicide and pointless missions.
-
Aaaaaahhhh, you are talking about the weapon selection criterias how and why the code uses weapon “A” or weapon “B” to arm the planes for mission-type A or B instead of using weapon “C” or weapons “D” for the same mission? This has been discussed to looong extent before on the BMS forums long time ago. Even Ed_1 contributed there afair, but it is still a “riddle”
I think there is NO SMART logic (code) here after all and therefore i specified (limited it) or structured the ATO by using or distributing the following wisely: the mission-types (aka DB roles), the hardpoints, the “squadron stores”, mission.dat and the .pri files. For example AI squadron X can do “db role” = CAP 100% (Barcap, Tarcap, Havcap, Escort), but can NOT do “db role” CAS = 0% (Preplaned CAS, On-Call CAS etc etc) at the same time. In other words each squadron has a limited number of mission types (same mission-type category) they can execute instead of being “multi-role” fighters, because
… “Multi-Role” just doesn´t work good enough in BMS in terms of smart weapons selection by AI.
I.e., if a plane-type has A2A-missiles and A2G-bombs (hardpoints) and “CAS” AND “CAP” roles assigned in the DB at the same time and then it is tasked as BARCAP by the ATM (ATO), it still takes bombs on a BARCAP mission, which is stuipid … vise versa. AI (or ATM if you will) is unable to choose weapons for specific missions with the same “smartness” as humans would do. They mostly load everything possible with the ones with the biggest “boom” first in the list, regardless if needed or not (i.e bombs for BARCAP).
The only solution here atm. is to “limit” or DEFINE aka SPECIFY the roles, mission-types and the accordingly required payloads (hardpoints) manually for each individual squadron and thus for the globally desired arming results for each individual mission-type.
In fact the opposite is the ture. Less used AC type somtimes do not get ANY strike weapons from ATO even many are available. Bigger problem that these AC take off the mission is not cancelled… Lots of AC can be tasked without ARM, they are simply eqipped by the second beast wepaon against unarmored AD units, they get in most of cases CBUs. This is why so different my campaign becase hordes of old J-5/J-6/Su-7/Q-5 can kill the blue AD while in stock BMS4 they just fly suicide and pointless missions.
PS: Molni… i have a strange feeling, that something is really “messed up” in your DB or you didn´t “UPDATE” and “RECALCULATE” the DB “from the bottom up” in order to maintain the integrity of the branched, edited and shared values throughout the the whole DB (weapons update, vehicles update, units update etc etc). Remember, if you change a weapons entry i.e, then you need to “update” all vehicles, then units using the same weapon or the DB looses its coherent intergrity and is not read properly anymore. This applies for all related (linked) DB entries such as “Hardpoints” or/and others.
-
Aaaaaahhhh, you are talking about the weapon selection criterias how and why the code uses weapon “A” or weapon “B” to arm the planes for mission-type A or B instead of using weapon “C” or weapons “D” for the same mission?
Besides the other issue yes, but this was not the main point of the previous comments.
PS: Molni… i have a strange feeling, that something is really “messed up” in your DB or you didn´t “UPDATE” and “RECALCULATE” the DB “from the bottom up” in order to maintain the integrity of the branched, edited and shared values throughout the the whole DB (weapons update, vehicles update, units update etc etc). Remember, if you change a weapons entry i.e, then you need to “update” all vehicles, then units using the same weapon or the DB looses its coherent intergrity and is not read properly anymore. This applies for all related (linked) DB entries such as “Hardpoints” or/and others.
Of course I updated everytime and recalculate everytime, these are the first step what ever have to be learned for start just even basic tweaks. As I have said, first line and most commonly used AC - F-15, F-16, F-18 - do not suffer about “tasked on strike mission without AG weapon” while they also got role and loadout changes in some cases.
This is why I’m saying continously that in Falcon world are other AC too. The campaigns are not “one man show” things, “actors” in less attractive positions also deserve attention… This is what so strongly missing currently… I did the best what I could but I’m not magician.
-
@A.S:
I think there is NO SMART logic (code) here after all …
Code is probably much smarter than you guys assume.
-
Code is probably much smarter than you guys assume.
I am sure it is. It is actually even quiete amazing sometimes how “smart” this sim was made, but regards to how the AI decides to load what kind of weapons for various mission-types
(and that is what i refered to), the code is as dumb as a “donkey”. Or can you proof the contrary? -
@A.S:
I am sure it is. It is actually even quiete amazing sometimes how “smart” this sim was made, but regards to how the AI decides to load what kind of weapons for various mission-types
(and that is what i refered to), the code is as dumb as a “donkey”. Or can you proof the contrary?Wait and see.
BTW if you can specify “dumb as a donkey” exactly maybe this can be further improved…Cheers
Biker