@Cloud:
Not sure where you’re getting your definition of things. I know how the DB works and I know how the .cam files work. I know the relationship between the two.
I have built theaters and a ton of campaign files, not only for third party theaters but for an organized Falcon team, to include Korea, Israel, Kurile, and on and on.
You speak of things like “Object” and “Templates”? Where are you getting these terms. No theater developer I have ever known and I myself have never used these terms when it comes to the supply of weapons for a given aircraft.
There’s only one place that determines what weapons any given aircraft has, and that is in the DB in the SSD(Squardron Stores). It has nothing to do with Resupply. It is “the” Supply that the aircraft gets. Period, that’s it.
For a given aircraft to get any of the weapons that are contained in the SSD, those weapons must be assigned to the aircraft in the DB via the Hardpoints. If the two things are accomplished correctly, the SSD and the Hardpoint assignments, then the aircraft has said weapon(s).
Not sure where you came up with your definitions and explanations of it but it’s pretty far out there and the terminology is cluttered with words that just beg to confuse.
I have no idea what you mean when you say “Object”. The only objects in Falcon are the cities, towns, villages, junctions, army bases, air bases, factories, chemical plants, forts, depots, bridges, ports, power plants, HQ’s, refineries, radars, radio towers…etc.
And as far as dough and cookies and all that…???
C9
You’re not the only one who reads these threads. I know full well they aren’t called “Objects” in the database. But for people who just want a general understanding how it all works together, “Object” is just as good as “Unit” when describing a Squadron, or Flight, or Aircraft, which all fall under Unit inside the database, but “Object” is less likely to make someone think of something singular, such as a specific Aircraft, or to assume that each individual unit is somehow contained in the database after a campaign starts.
They ARE templates, because it is abstract in the database. They may not be CALLED templates in the database, but everything in the database is a template. When you open the DB you don’t see the 1234th Fighter Squadron at Kunsan Airbase. You see a generic TEMPLATE of an F16x-xx squadron which says how many of what kind of aircraft, what the Squadron Stores are, how many pilots, what kind of mission specialty they do, what kind of missions they are allowed to do, etc… which is then used to generate a squadron in the CAM file, or populate what Mission Types are allowed in the Package window. If you change the properties of the Generic F16x-xx squadron in the DB, it will effect ALL the F16x-xx squadrons you then create in the CAM file based on that Generic Squadron, because it’s a template for that specific TYPE of aircraft. Hence for people who don’t go hunting through the DB and wouldn’t know that if I said unit in one context it means flight, or in another it means an aircraft, or in another it means squadron, I use the cookie cutter analogy so people who just want a broad understanding would know that what’s in the database is a collection of TEMPLATES, that are used to populate the CAM file.
My original point, however, was that you can limit what stores are available to a particular type of aircraft in more than one way. Removing a weapon from all the possible hardpoints will NOT prevent the game from delivering those weapons to the squadron during supply. It simply removes them from the loadout screen. Conversely, removing the weapon from the Squadron Supply and NOT from the hardpoints, just makes them show up as OUT on the loadout screen and prevents delivery when the Squadron is resupplied. To do it correctly, you should be doing both (Especially if big picture inventory is shared across the entire campaign, and other aircraft are able to use the weapons you are removing from the hardpoints), but either approach will achieve the desired result Fieters was asking about.
You’re talking specific implementation and terms, I’m describing big picture theory, because the same concept applies to EVERYTHING in the database, not just Squadron Stores and Hardpoints. The theory behind it can help someone trying to change what Units appear in a ground formation, or how many aircraft appear in a new squadron, or why changing a hardpoint called INBD 1 or HDPT 3 (Or F15C Wing Rail or whatever they are called) on one variant of an F16 or a bomber, also changed what weapons were available on a different variant or completely other aircraft type which uses the same hardpoint abstract OBJECT. As an example, the passage from your quote I highlighted is only partially correct. The weapons get assigned to the specific type of HARDPOINT, then that type of HARDPOINT is assigned to an aircraft type. But that same hardpoint TYPE could very well be used on another aircraft inside the DB. So changing the weapons available to that HARDPOINT, changes the weapons available to ALL aircraft types that use that kind of HARDPOINT, not just the specific Aircraft you may have intended to change. That idea of abstraction and shared resources (Or OBJECTS in a generic term) is the whole point of my post, and good for someone who is just starting to modify a database to understand. As I said, not everyone knows every in an out like people who have built their own campaigns or theaters before.