olds 15 Posted September 26, 2014 (edited) What Is This? A document/discussion for modders about updating P3D & Config files for vehicles to bring them up to A3 & RAM standards - with an emphasis on IFA3 content. This front page will be updated based on the discussion and maybe moved to the Biki once it achieves some sort of comprehensiveness Yellow text = need to figure out Version 0.2 Still rough, but cleaned up a bit Intro Vehicles (and other game objects obviously) are defined by a combination of their P3D file and their config files There are important links between the two (config files referencing things in the P3D and vice versa) Lots of consistent naming between the two is necessary for these links to function correctly! "Fire Geometry" LOD Naming components: not necessary but niceindividual Component names aren't critical to the engine but they are referenced by hitPart & handleDamage eventhandlers, so it makes troubleshooting/scripting more useful if all components are named [*]Use (bone-)Named Selection sets! This is how the game knows which fire geometry is linked to which bone * All fire geometry linked to a particular bone must be grouped in a Named Selection with the exact name of that bone (from the model config). In fact, this is the case across the board for other LOD's as well (hitpoints, etc.) [*]IF-Specifics IF "fire geometry" LOD's are actually very close to A3 standards already, and should largely work with some minor modifications Solid blocks of geometry need to be added to the turret interior and hull interior; they should be assigned a weak material such as void.bisurf? "Hit-points" LOD Use "(bone-)Named Selection sets"!Mem-points must (only) be grouped into bone-Named Selection sets Note: this means the mem-points don't identify the hit location type they are associated with (e.g. HitHull)... [*]...So how are mem-points associated with a hit location type? It happens in the cfgVehicle config file! You specify the selection set name in the hitpoints section of the config file ("name" property) e.g., name="motor"; //where "motor" is the bone-Named Selection set in the P3D file [*]IF-Specifics IF "hit-points" LOD's are odd and need quite a bit of re-working Remember this means re-writing the hitpoints section of the vehicle config file also! Remove all "hit_xxx" hitpoints (there are a lot of them!), they are for armor pieces which do not use hitpoints in A3 HitHull should be only hull vertices (not the "Damage" vertices that currently cover the whole vehicle ) HitEngine, HitRTrack, HitLTrack may need some tweaking but they are generally OK The commander's "turret" (cupola) and gun should have it's own set of hitpoints (HitTurret) and gun hitpoints (HitGun, if there is a machine-gun attached to the cupola) The (main) gun hitpoints should be redone, there are too many of them--they should simply be spread evenly along the length of the gun The (main) turret hitpoints should be redone, they need to be spread throughout the turret (e.g. not just along the turret ring) [*]RAM-additions Add HitAmmo vertices, they should be bone-Named ...? Geometry LOD's (As usual, you must use bone-named-selection-sets to ensure that the right geometry pieces are attached to the right bones) Vehicle Config IF-Specifics (HitPoints class)Remove all "visual_xxx"--these are associated with the "hit_xxx" vertices in the P3D file's "hit-points" LOD and they are unnecessary "radius" properties are missing and should be added to each hitpoints sub-class "explosionShielding" properties are missing and should be added to each hitpoints sub-class All "minimalHit" values are much too high--they should be on the order of 0.1 (not 100). [*]RAM-Additions (HitPoints class) Add HitAmmo sub-class; it needs to be located before the HitHull sub-class Add following line to HitHull sub-classdepends = "10 * HitAmmo"; [*]You can (somehow) have multiple hit locations (e.g. HitAmmo), each assigned to a different "name" property e.g. HitAmmo in the turret and HitAmmo in the hull Naming conventions You either stick with the existing Czech names (e.g. for inheritance reasons), or completely and thoroughly update the naming standards. e.g. CUP naming standards IF-SpecificsIF naming bone convention is a strange mix of Czech and English and should be cleaned up to a consistent standard at some point - I recommend using CUP standards (i.e. consistent English). * Notes on Model Configs/Bones/Skeletons Bones are listed in the form "Child","Parent", A bone with no parent (i.e. parented to the model root) is listed "Parent","", * Notes on Config Files ​(paraphasing kju:) All configs get merged into one big config in memory when the game starts Where there are duplicates, which config's value takes precedence depends on load order - the last config loaded "wins" by overwriting any previous value(s) Load order is determined by modfolder order, PBO name, but most importantly by the "requiredAddons" section of the "cfgPatches" classFor test purposes, you can throw any old requiredAddon in there as long as you know it's a late-loaded one. However, Final config's should reference precise requiredAddons to prevent load order problems from cropping up. [*]IF-Specifics For compatibility reasons with A2, IF configs are a delicate mish-mash of standard and custom values To maintain compatibility, new A3 and test configs will be layered over IF like a mod(s) i.e. instead of going in and re-writing the base configs, for the time being we are overlaying a new set of configs and make sure--via cfgPatches--that our new values overwrite any old ones. Edited October 13, 2014 by Olds added Geometry LOD section and requiredAddons note Share this post Link to post Share on other sites
