Hexdragon Posted February 6, 2023 Share Posted February 6, 2023 This is a follow up for that old but worthy thread : Posting info on GNPRTB.DAT and SDPRTB.DAT ============ GNPRTB.DAT ============ GNPRTB Header: ------------------------ DWword_H01 Unknown_H01 ( 0x01 ) DWword_H02 Entry Count ( 0xD5 ) DWword_H03 FileDescription Len ( 0x16 ) Bytes 12 to 33 FileDescription Text Entry data starts at position 34 / 0x22 Entry Size: 44 bytes (11 DWords ) GNPRTB Entry: -------------------- DWord_01 Primary Entry ID DWord_02 Unknown Always 0x01 DWord_03 Secondary Entry ID (???) / Second Byte sets Entry Group (???) DWord_04 Parameter: Alliance Multi player (???) DWord_05 Parameter: Alliance Single Player on Easy DWord_06 Parameter: Alliance Single Player on Medium DWord_07 Parameter: Alliance Single Player on Hard DWord_08 Parameter: Empire Single Player on Easy DWord_09 Parameter: Empire Single Player on Medium DWord_10 Parameter: Empire Single Player on Hard DWord_11 Parameter: Empire Multi player (???) =================== Known GNPRTB Entries =================== Entry Description Default Value -------- ---------------- -------------------- ---- 001st 0x01 Standard Space Travel Speed 0x6400 ---- 053rd 0x35 Seat of Power - Leadership bonus % 0x3200 ---- 060th 0x3C Han Solo Space Travel Speed 0x3200 ---- 083rd 0x53 Fleet 1 Placement Probability % (Yavin vs HQ) 0x3200 084th 0x54 CMUNYVTB.DAT - First parent item 0x0100 085th 0x55 CMUNYVTB.DAT - Max parent items 0x0100 086th 0x56 CMUNHQTB.DAT - First parent item 0x0100 087th 0x57 CMUNHQTB.DAT - Max parent items 0x0100 088th 0x58 CMUNCRTB.DAT - First parent item 0x0100 089th 0x59 CMUNCRTB.DAT - Max parent items 0x0100 090th 0x5A CMUNAFTB.DAT - First parent item 0x0100 091st 0x5B CMUNAFTB.DAT - Max parent items 0x0200 092nd 0x5C CMUNEFTB.DAT - First parent item 0x0100 093rd 0x5D CMUNEFTB.DAT - Max parent items 0x0100 094th 0x5E FACLHQTB.DAT - First parent item 0x0100 095th 0x5F FACLHQTB.DAT - Max parent items 0x0200 096th 0x60 FACLCRTB.DAT - First parent item 0x0100 097th 0x61 FACLCRTB.DAT - Max parent items 0x0100 ---- 101st 0x65 Luke Goes to Dagobah - Base 0x2C01 102nd 0x66 Luke Goes to Dagobah - Var 0x6400 103th 0x67 Bounty Hunter Frequency - Base 0x2C01 104th 0x68 Bounty Hunter Frequency - Var 0x2C01 ---- 151th 0x97 Required Shield Generators - Prevent Assault 0x0200 ---- 180th 0xB4 Raw Materials - Hard Limit 0x0F00 182nd 0xB6 System Energy - Hard Limit 0x0F00 ---- 185th 0xB9 Natural Disaster - Frequency - Base 0x0100 186th 0xBA Natural Disaster - Frequency - Var 0x8F01 187th 0xBB Resource Event - Frequency - Base 0x0100 188th 0xBC Resource Event - Frequency - Var 0xF301 189th 0xBD System Energy Base - Core sytems 0x0A00 190th 0xBE System Energy Var - Core sytems 0x0400 191st 0xBF Raw Materials Base - Core sytems 0x0500 192nd 0xC0 Raw Materials Var - Core sytems 0x0900 193rd 0xC1 System Energy Base - Rim sytems 0x0100 194th 0xC2 System Energy Var1 - Rim sytems 0x0400 195th 0xC3 System Energy Var2 - Rim sytems 0x0900 196th 0xC4 Raw Materials Base - Rim sytems 0x0100 197th 0xC5 Raw Materials Var - Rim sytems 0x0E00 198th 0xC6 % Populated systems - Core sytems 0x6400 199th 0xC7 % Populated systems - Rim sytems 0x1F00 ---- 207th 0xCF Garrison Requirement / Uprising - Threshold 0x3C00 ---- ======== Notes: ======== -Entries 84th to 97th enable the possibility to change the parent entry count in CMUNXYTB.DAT files and FACLXYTB.DAT files that otherwise only allow edits inside the default parent entries. -Entries 84th to 97th also enable the possibility to decide which parent entry may be ignored on specific side+difficulty level setups ======== Summary: ======== Entry Id Range Entry Group Decoded --------------------- ---------------- ---------------- 0x01 - 0x01 0x00 Space Travel 01 of 01 0x02 - 0x07 0x02 00 of 06 0x08 - 0x0E 0x06 00 of 07 0x0F - 0x14 0x08 00 of 06 0x15 - 0x30 0x0A 00 of 28 0x31 - 0x40 0x0C Char Specials (??) 02 of 16 0x41 - 0x46 0x0E 00 of 06 0x47 - 0x47 0x10 00 of 01 0x48 - 0x49 0x12 00 of 02 0x4A - 0x62 0x14 Assets 15 of 25 0x63 - 0x90 0x18 Events (??) 04 of 46 0x91 - 0x93 0x1C 00 of 03 0x94 - 0xD5 0x1E Systems 19 of 66 ---------------- 41 of 213 -------- 1 Link to comment Share on other sites More sharing options...
Hexdragon Posted February 6, 2023 Author Share Posted February 6, 2023 ============ SDPRTB.DAT ============ SDPRTB Header: ------------------------ DWword_H01 Unknown_H01 ( 0x01 ) DWword_H02 Entry Count ( 0x12 ) DWword_H03 FileDescription Len ( 0x13 ) Bytes 12 to 30 FileDescription Text Entry data starts at position 31 / 0x1F Entry Size: 76 bytes ( 19 Dwords ) SDPRTB Entry: -------------------- DWord_01 Primary Entry ID DWord_02 Unknown Always 0x01 DWord_03 Secondary Entry ID (???) / Second Byte sets Entry Group (???) DWord_04_05 Parameters: Alliance Multi player (???) DWord_06_07 Parameters: Alliance Single Player on Easy (#) DWord_08_09 Parameters: Alliance Single Player on Medium (#) DWord_10_11 Parameters: Alliance Single Player on Hard (#) DWord_12_13 Parameters: Empire Single Player on Easy (#) DWord_14_15 Parameters: Empire Single Player on Medium (#) DWord_16_17 Parameters: Empire Single Player on Hard (#) DWord_18_19 Parameters: Empire Multi player (???) (#) (#) On each DWord pair: -1st parameter applies to Alliance -2nd parameter applies to Empire =================== Known SDPRTB Entries =================== Entry Description Default Value -------- ---------------- -------------------- ---- 04th Entry (0x04): Number of (random) Characters at Day Zero - Small galaxy 0x01 (#) 05th Entry (0x05): Number of (random) Characters at Day Zero - Medium galaxy 0x02 (#) 06th Entry (0x06): Number of (random) Characters at Day Zero - Large galaxy 0x04 (#) ---- (#) The characters placed upon above parameters add to the 7 non-random characters: Thus, the (default) observed number of characters for each galaxy size are: 8, 9 and 11. (##) The 14 non-random characters (7 per side) can be edited in rebexe v1.02 around 0x15D42C For Alliance characters, their placement location (Yavin vs HQ) can also be edited there ---- ---- 30th Entry (0x1E): Side Lottery - Core Systems 1 - % Probability to be assigned to each side 31st Entry (0x1F): Side Lottery - Core Systems 2 - % Probability to be assigned to each side 32nd Entry (0x20): Side Lottery - Core Systems 1 - % Popular Support on systems selected upon 30th Entry - Base 33rd Entry (0x21): Side Lottery - Core Systems 1 - % Popular Support on systems selected upon 30th Entry - Var 34th Entry (0x22): Side Lottery - Core Systems 2 - % Popular Support on systems selected upon 31th Entry - Base 35th Entry (0x23): Side Lottery - Core Systems 2 - % Popular Support on systems selected upon 31th Entry - Var ---- ======== Summary: ======== Entry Id Range Entry Group Decoded --------------------- ---------------- ---------------- 0x01 - 0x03 0x0A ???? 00 of 03 0x04 - 0x1D 0x14 Characters 03 of 26 0x1E - 0x23 0x1E Systems 06 of 06 ---------------- 09 of 35 -------- 1 Link to comment Share on other sites More sharing options...
Hexdragon Posted February 6, 2023 Author Share Posted February 6, 2023 (edited) SWR - STAR SYSTEMS ------------------------------------ System Type ( Core / Rim) is defined in SYSTEMSD.DAT ( 5th DWord at each System Entry ) Sector Importance: is defined in SECTORSD.DAT ( 7th DWord at each Sector Entry ) System Type = 0x90 >>> Core System System Type = 0x92 >>> Rim System ================ I - SIDE LOTTERY ================ IF Sector Importance == 0x01 THEN System's starting side control (rebel imperial or neutral) is defined in a Side Lottery (either Core or Rim) ELSE System starts as neutral Side Lottery - Core Systems: SDPRTB.DAT Entry 30th (0x1E) sets % probability of Core systems to be assigned to each side, whose popular support is defined at entries 32nd (0x20), 33rd (0x21) SDPRTB.DAT Entry 31th (0x1F) sets % probability of Core systems to be assigned to each side, whose popular support is defined at entries 34nd (0x22), 35rd (0x23) SDPRTB.DAT Entries 32nd (0x20) and 34th (0x22) set base value SDPRTB.DAT Entries 33rd (0x21) and 35th (0x23) set random value (to be added to base one) Side Lottery - Rim Systems The sum of values set by SDPRTB.DAT at entries 30th (0x!E) and 31st (0x1F) defines % probability of Rim systems to be assigned to each side, SDPRTB.DAT entries 32nd (0x20), 33rd (0x21), 34th (0x22) and 35th (0x23) are ignored, as popular support for Rim Systems is pre defined to 100% when controled by alliance and unknown (slightly below 50%) when controlled by empire. Notes: (0) For the sake of easy reference: Core Systems assigned to side by means of entries 30th (0x1E), 32nd (0x20) and 33td (0x21) are labeled as "Rebel 1" and "Imperial 1" Core Systems assigned to side by means of entries 31st (0x1F), 34th (0x22) and 35th (0x23) are labeled as "Rebel 2" and "Imperial 2" Rim Systems assigned to side by means of entries 30th (0x1E), and 31th (0x1F) are labeled as "Rebel 3" and "Imperial 3" (1) At least one "Imperial 1" system is required, in order to be assigned to Coruscant. However popular support in coruscant starts at 100% Configuring a very low % probability for systems to start as controled by Empire in SDPRTB.DAT at entry 30th (0x1E) (i.e Probability for "Imperial 1" systems) may result in side-lottery giving no "Imperial 1" systems, As a consequence, the game resets popular support on "imperial 2" systems to "imperial 1" levels (while Coruscant gets 100% popular support as usual) (2) Yavin and Alliance Headquarter's system are assigned to alliance by means different than either side-lottery (3) Only "Rebel 2" and "Imperial 2" systems receive default garrisons at the start of the game. Default garrison's size fits system's garrison requirement which depends on popular support ( Threshold hanbdled by GNPRTB.DAT at Entry 207th / 0xCF ) (4) Coruscant, receive a custom garrison. Yavin, receive a custom garrison. Alliance. HQ's system receive a custom garrison. ================ II - CORE VS RIM ================ IF System Type = 0x90 (Core): THEN System starts as explored regardless of the side who controls it Player's side, Enemy side or Neutral Starting random assigment of assets for the system is defined in SYFCCRTB.DAT Number of energy slots for the system is defined in GNPRTB.DAT at entries 189th (0xBD) and 190th (0xBE) (*) Number of raw materials in the system is defined in GNPRTB.DAT at entries 191st (0xBF) and 192th (0xC0) (*) Probability of system starting as colonized is defined in GNPRTB.DAT at entry 198th (0xC6) IF System Type = 0x92 (Rim): THEN System starts as explored only if under Player's side control Starting random assigment of assets for the system is defined in SYFCRMTB.DAT Number of energy slots for the system is defined in GNPRTB.DAT at entries 193rd (0xC1), 194th (0xC2) and 195th (0xC3) Number of raw materials in the system is defined in GNPRTB.DAT at entries 196th (0xC4) and 197th (0xC5) (*) Probability of system starting as colonized is defined in GNPRTB.DAT at entry 199th (0xC7) (*) GNPRTB.DAT Entries 189th (0xBD), 191st (0xBF), 193rd (0xC1) and 196th (0xC4) set base value GNPRTB.DAT Entries 190th (0xBE), 192st (0xC0), 194rd (0xC2), 195th (0xC3) and 197th (0xC5) set random value (to be added to base one) (**) A hard limit for number raw materials in the system is defined in GNPRTB.DAT at entry 180h (0xB4) A hard limit for number of energy slots for the system is defined in GNPRTB.DAT at entry 182h (0xB6) Final number of energy slots for the system also puts a cap on raw materials -------- Edited February 6, 2023 by Hexdragon 1 Link to comment Share on other sites More sharing options...
Hexdragon Posted February 14, 2023 Author Share Posted February 14, 2023 An update on GNPRTB.DAT ===================Known GNPRTB Entries (new) =================== Entry Description Default Value -------- ---------------- -------------------- ----145th 0x91 Maintenance Shortfall Frequency 0x0A00 ----208th 0xD0 Garrison Requirement / Troop's order contribution 0xF6FFFFFF ( minus 10 ) ---- ========Summary: ( Updated ) ======== Entry Id Range Entry Group Decoded --------------------- ---------------- ---------------- 0x01 - 0x01 0x00 Space Travel 01 of 01 0x02 - 0x07 0x02 00 of 06 0x08 - 0x0E 0x06 00 of 07 0x0F - 0x14 0x08 00 of 06 0x15 - 0x30 0x0A 00 of 28 0x31 - 0x40 0x0C Char Specials (??) 02 of 16 0x41 - 0x46 0x0E 00 of 06 0x47 - 0x47 0x10 00 of 01 0x48 - 0x49 0x12 00 of 02 0x4A - 0x62 0x14 Assets 15 of 25 0x63 - 0x90 0x18 Events (??) 04 of 46 0x91 - 0x93 0x1C Maintenance (??) 01 of 03 0x94 - 0xD5 0x1E Systems 20 of 66 ---------------- 43 of 213 -------- Link to comment Share on other sites More sharing options...
Hexdragon Posted February 14, 2023 Author Share Posted February 14, 2023 (edited) Info on Garrisons at Day-Zero ========================I - GARRISON REQUIREMENT ======================== This is the conjecture, supported by test results: GR = Max [ 0, ( PS - UT ) / TC ] Where: GR = Garrison Requirement PS = Popular Support, for controlling side (%, as integer) UT = Uprising Threshold (%, as integer) TC = Troop's order contribution (negative integer) Result is rounded up to nearest integer UT Is handled by GNPRTB.DAT at Entry 207th TC Is handled by GNPRTB.DAT at Entry 208th Garrison Requirement gets doubled when uprising event is triggered on system ====================II - DEFAULT GARRISON ==================== Core Systems with a Garrison Requirement > 0 at day zero get a default garrison whose size fits the Garrison Requirement (#) (#) Only those Core systems assigned to controlling side by SDPRTB.DAT 31st Entry (" Imperial 2" / "Rebel 2" ) Default Garrison in Rebexe v102: -Troop Type for Empire can be edited at 0x1191A8 Default Value: 0x08000010 -Troop Type for Alliance can be edited at 0x1191CD Default Value: 0x02000010 - System Type (#) can be edited at: 0x119253 Default Value: 0x90000000 (#) - System Type (##) can be edited at: 0x11925B Default Value: 0x92000000 (##) ( # ) Lower End (inclusive) (??) Value greater than 0x900000 disables default garrison for both Core and Rim Systems(##) Upper End (exclusive) (??) Value greater than 0x920000 enables default garrison for Rim Systems (+/- 50% of "Imperial 3" systems get a garrison) ====================III - OTHER GARRISONS ==================== The following files deploy additional troops at day zero CMUNYVTB.DAT on Yavin CMUNCRTB.DAT on Coruscant CMUNHQTB.DAT on Alliance HQ's System CMUNALTB.DAT on Alliance Systems and Fleets ( Random deployment ) CMUNEMTB.DAT on Empire Systems and Fleets ( Random deployment ) CMUNAFTB.DAT on Alliance's Fleet 1 CMUNEFTB.DAT on Empire's Fleet 1 The following files may be edited to deploy additional troops at day zero FACLCRTB.DAT on Coruscant FACLHQTB.DAT on Alliance HQ's System SYFCCRTB.DAT on any Core system: Alliance, Empire, Neutral ( Random deployment ) (#) SYFCRMTB.DAT on any Rim system: Alliance, Empire, Neutral ( Random deployment ) (#) (#) A troop type set to be build-able by both sides is recommended in this case -------- Edited February 14, 2023 by Hexdragon Link to comment Share on other sites More sharing options...
Hexdragon Posted February 19, 2023 Author Share Posted February 19, 2023 ============================SWR - Day Zero Logistics Files ============================ This post relates to 11 .DAT files from GData folder related to asset deployment at Day-Zero ("logistics files") CMUNAFTB.DAT CMUNEFTB.DAT CMUNALTB.DAT CMUNEMTB.DAT CMUNCRTB.DAT CMUNHQTB.DAT CMUNYVTB.DAT FACLHQTB.DAT FACLCRTB.DAT SYFCCRTB.DAT SYFCRMTB.DAT For this post, I will take some licenses on the use of custom nomenclature, like "Carrier Entry", "Payload Entry", "Enclosed Deployment" and "Fake Deployment" -------- Below picture shows a summary of most relevant differences among those filesNotes And Remarks: --------------------------- - All CMUNXYTB Files and FACLXYTB files share the same structure and field definition - Only random CMUNXYTB files require available maintenance points in order to deploy assets at day zero - Non-random files require adjustment in GNPRTB entries in order to get working edits in parent entry count - Only FACLXYTB files auto adjust energy slots and material deposits on demand when deploying facilities - SYFCXYTB files do not feature "parent-child" entry structure nor "carrier/payload" entry logic Observed order of asset deployment events at Day Zero (does not include character deployment) I ENERGY SLOTS / MAT DEPOSITS ENERGY SLOTS / MAT DEPOSITS II DEF. MINE DEPLOYMENT DEF. MINE DEPLOYMENT III-A SYFCCRTB.DAT SYFCCRTB.DAT III-B SYFCRMTB.DAT SYFCRMTB.DAT IV FACLHQTB.DAT FACLCRTB.DAT V DEF GARRISON PLACEMENT DEF GARRISON PLACEMENT VI-A CMUNYVTB.DAT -- -- -- -- -- -- -- -- VI-B CMUNHQTB.DAT CMUNCRTB.DAT VII CMUNAFTB.DAT CMUNEFTB.DAT VIII CMUNALTB.DAT CMUNEMTB.DATRandom Seed Generation ------------------------------------ SYFCXYTB files Random Roll Count = Energy Slots - Mines added to System upon Default Mine Deployment CMUNXYTB files Random rolls and asset deployment continue as long as below statement remains true: CM <= A% x ( TM - XM ) Where:CM = Cap to MPs for assets deployed by CMUNALTB.DAT / CMUNEMTB.DATTM = MPs provided by Mine-Refinery pairs placed by SYFCXYTB.DAT and FACLXYTB.DAT or upon Default Mine DeploymentXM = MPs consumed by assets placed by SYFCXYTB.DAT and FACLXYTB.DATA% = 20 % (most of times) on Easy Difficulty setting ; 15% (most of the times ) on Hard Difficulty setting TM ignores MPs provided by other CMUNXYTB.DAT files XM ignores MPs consumed by other CMUNXYTB.DAT files -------- Link to comment Share on other sites More sharing options...
Hexdragon Posted February 19, 2023 Author Share Posted February 19, 2023 ========================================CMUNXYTB.DAT / FACLXYTB.DAT - Description ======================================== CMUNXYTB / FACLXYTB - Header: ---------------------------------------------------- Header Size: 32 bytes (08 DWords ) DWord_H01 0x01DWord_H02 Number of Parent EntriesDWord_H03 Description Len (0x14)DWord_H04-H08 Description Text CMUNXYTB / FACLXYTB - Entry: ---------------------------------------------------- Entry data starts at position 32 / 0x20 Parent Entry Size: 24 bytes ( 06 DWords ) Child Entry Size: 12 bytes ( 03 DWords ) Parent Entry: ------------------ DWord_P01 Parent Entry ID NumberDWord_P02 Unknown_P02 / Always 0x01DWord_P03 Probability Index ( Random seed generation ) (#)DWord_P04 Parent Entry Multiplier (##)DWord_P05 Unknown_P05 / Always 0x01DWord_P06 Child Entry Count (#) Random Seed Range: [ 0x01, .. ,0x64 ] ( 1 to 100 ) IF: Next Index > Random Result >= Current IndexOR: 0x65 > Random Result >= Current IndexTHEN: Current Parent Entry is selected for asset deployment Non random files fill this DWord_P03 with Parent Entry's ID value (##) Number of Instances deployed when parent entry is selected upon random seed generation Child Entry: ----------------DWord_C01 Unknown_C01 / Always 0x01DWord_C02 Unknown_C02 / Always 0x00DWord_C03 Asset ID & Asset Family (#) (##) (#) Fourth Byte in DWord_C03 indicates the Asset Type or "Family" Examples: 02000010 Alliance Army Regiment 07000010 Imperial Fleet Regiment 45000014 Corellian Corvette 49000014 Alliance Dreadnaught 85000014 Imperial Star Destroyer 0300001C X-wing 0500001C TIE Fighter 0700001C TIE Bomber 03000024 GenCore Level I 06000024 GenCore Level II 0300002A Construction Yard 0600002A Advanced Construction Yard 0200002D Refinery 0200003C Infiltrators 0500003C Imperial Probe Droid 0700003C Imperial Commandos (##) For every parent one, the first child entry has a special attribute, in the sense that SWR handles it as a "carrier" for the other child entries linked to the same parent For the sake of easy reference the first child entry will be labeled as the "Carrier Entry", while any other child entry will be labeled as the "Payload Entry" -On files whose target (for asset deployment) is a Fleet, the default Carrier Entry is: a Capital Ship, with the form: 01000000 00000000 XX000014 -On files whose target (for asset deployment) is a System, the default Carrier Entry is: a Null Entry, with the form: 01000000 00000000 00000000 -On files whose target are both Systems and Fleets, the default carrier entries are: a Capital Ship, with the form: 01000000 00000000 XX000014 a Troop,Regiment with the form: 01000000 00000000 XX000010 a Fighter Squadron, with the form: 01000000 00000000 XX00001C a Spec Force, with the form: 01000000 00000000 XX00003C In this case, a Carrier Entry different than Capital Ship should not go along with any Payload Entry Link to comment Share on other sites More sharing options...
Hexdragon Posted February 19, 2023 Author Share Posted February 19, 2023 ======================== SYFCXYTB.DAT - Description ======================== SYFCXYTB - Header: -------------------------------- Header Size: 32 bytes (08 DWords ) DWord_H01 0x01DWord_H02 Number of Parent EntriesDWord_H03 Description Len (0x0E)Bytes 12 to 25 FileDescription Text SYFCXYTB - Entry: ---------------------------- Entry data starts at position 26 / 0x1A Entry Size: 16 bytes ( 04 DWords ) DWord_E01 Parent Entry ID NumberDWord_E02 Unknown_E02 / Always 0x01DWord_E03 Probability Index ( Random seed generation ) (#)DWord_E04 Asset ID & Asset Family (##) (#) Random Seed Range: [ 0x00, .. ,0x64 ] ( 0 to 100 ) IF: Next Entry Index > Random Result >= Current IndexOR: 0x65 > Random Result >= Current IndexTHEN: Current Parent Entry is selected for asset deployment (##) Fourth Byte in DWord_E04 indicates the Asset Type or "Family" Examples: 42000014 Assault Frigate 43000014 Nebulon-B Frigate 81000014 Lancer Frigate 05000010 Mon Calamari Regiment 06000010 Stormtrooper Regiment 08000010 Imperial Army Regiment 0400001C Y-wing 0600001C TIE Interceptor 0400003C Bothan Spies 0600003C Imperial Espionage Droid 02000023 LNR Series I 05000023 LNR Series II 01000028 Shipyard 04000028 Advanced Shipyard Note: -------- By default, SYFCXYTB files feature a "null" entry as their first one, as shown below: 01000000 01000000 00000000 00000000 However normal (non null) entry is valid as first entry there (see below example): 01000000 01000000 00000000 01000028 The "Carrier" / "Payload" behavior described for CMUNXYTB files does not apply to SYFCXYTB files The conjecture is that an implicit null "carrier" is already considered when SYFCXYTB files are processed. -------- Link to comment Share on other sites More sharing options...
Hexdragon Posted February 19, 2023 Author Share Posted February 19, 2023 ======== SYFCCRTB.DAT and SYFCRMTB.DAT can be set to randomly place Troops, Spec Forces or even Fighter Squadrons in Core and Rim Systems respectively at day zero. As a result, Troops, Spec Forces and Fighter Squadrons may be present in neutral Systems Neutral troops can repeal assaults on System Neutral Squadrons do not fight against fleet in System's orbit After successful diplomacy mission on neutral System-Neutral Troops Will join player's side, but only if the unit type is set to be available for building to player's side (.DAT file) (*)-Neutral Spec Forces Will join player's side, but only if the unit type is set to be available for building to player's side (.DAT file) (*)-Neutral Fighter Squadrons Will NOT join player's side ( regardless of availability to side set in .DAT file) After successful assault on neutral system:-Neutral Troops Will NOT join player's side ( since every defending troop became casualty) -Neutral Spec Forces Will join player's side, but only if the unit type is set to be available for building to player's side (.DAT file)-Neutral Fighter Squadrons Will NOT join player's side ( regardless of availability to side set in .DAT file) Assault summary - After successful assault on neutral system:-Neutral Troops Will appear as neutral side casualties (**)-Neutral Spec Forces Will appear as neutral side survivors if the unit type is available to player's side (.DAT file) (*) (**)-Neutral Spec Forces Will appear as player's side casualties if the unit type is NOT available to player's side (.DAT file), only if previously revealed upon espionage. (**) -Neutral Fighter Squadrons Will appear as neutral side casualties (regardless of availability to side). (**) (*) Research is not required to be "done", for neutral unit to join player's side, even if such build-able unit type is still on research queue. (**) This also applies to neutral units from a system that turns to player's side because a successful assault in same sector In the case of Troops, for non build-able ones (build-able ones would join player's side). ======== Link to comment Share on other sites More sharing options...
Hexdragon Posted February 19, 2023 Author Share Posted February 19, 2023 ================================CMUNXYTB.DAT / FACLXYTB.DAT - Edit Notes ================================ I .- Normal Deployment - Enclosed Deployment - Fake Deployment ---------------------------------------------------------------------------------------- A proper Carrier / Payload setup for entries in the DAT files should result in normal deployment of their assets An improper Carrier / Payload setup for entries in the DAT files may result in : - "Enclosed" deployment" (i.e Embedded deployment) - "Fake" deployment (i.e. Pseudo-Deployment) And game crash, of course. Enclosed Deployment: ------------------------------ -Asset is not selectable nor visible on system -Asset consume maintenance points -Asset is featured in galaxy overview -If the asset is a "payload" enclosed in a "carrier" asset, it remains in game until the carrier asset is destroyed, retired or scraped -If the asset is a "carrier" asset enclosed in a System, it remains in game until the asset is destroyed by maintenance shortfall, or the host System is destroyed -If the asset is a "carrier" asset enclosed in a Fleet instance, it remains in game until the Fleet instance is removed - Enclosed refineries and mines provide maintenance points while in game - Game effects from other enclosed assets had not been observed Fake Deployment: -------------------------- -Asset is not selectable nor visible on system -Asset consume maintenance points at Day Zero -Asset is NOT featured in galaxy overview -Asset is removed from game and stops consuming (or providing) MPs at first logistics event in-game ( asset building, asset retirement or asset destruction ) Note: Fake deployment brings a minor annoyance when compared to enclosed deployment, as its effects seem to disappear pretty quickly Enclosed deployment, on the other hand, has interesting uses for modding, when mines and refineries are involved ( thinking about mobile resource pools embedded on capital ship and/or Alliance HQ ) II .- Normal Deployment Examples ------------------------------------------------ The following Carrier / Payload setups seem to provide a normal deploy A - FACLXYTB files and CMUNXYTB files whose target is a System: Default Setup Carrier Entry Null Entry 01000000 00000000 00000000 Payload Entry Troop,Regiment 01000000 00000000 XX000010 Payload Entry Fighter Squadron 01000000 00000000 XX00001C Payload Entry Spec Force 01000000 00000000 XX00003C Payload Entry Facility 01000000 00000000 XX0000ZZ ( Where ZZ = 22, 23, 24, 25, 28, 29, 2A, 2C, 2D ) Alternate Setups Carrier Entry Fleet Entry 01000000 00000000 04000008 Payload Entry Capital Ship 01000000 00000000 XX000014 Carrier Entry Troop,Regiment 01000000 00000000 XX000010 No Payload Carrier Entry Fighter Squadron 01000000 00000000 XX00001C No Payload Carrier Entry Spec Force 01000000 00000000 XX00003C No Payload Carrier Entry Facility 01000000 00000000 XX0000ZZ ( Where ZZ = 22, 23, 24, 25, 28, 29, 2A, 2C, 2D ) No Payload B - CMUNXYTB files whose target is a Fleet: Default Setup Carrier Entry Capital Ship 01000000 00000000 XX000014 Payload Entry Troop,Regiment 01000000 00000000 XX000010 Payload Entry Fighter Squadron 01000000 00000000 XX00001C Payload Entry Spec Force 01000000 00000000 XX00003C Alternate Setup Carrier Entry Null Entry 01000000 00000000 00000000 Payload Entry Capital Ship 01000000 00000000 XX000014 C - CMUNXYTB files whose target are both Systems and Fleets (Random Files): Default Setups Carrier Entry Capital Ship 01000000 00000000 XX000014 Payload Entry Troop,Regiment 01000000 00000000 XX000010 Payload Entry Fighter Squadron 01000000 00000000 XX00001C Payload Entry Spec Force 01000000 00000000 XX00003C Carrier Entry Troop,Regiment 01000000 00000000 XX000010 No Payload Carrier Entry Fighter Squadron 01000000 00000000 XX00001C No Payload Carrier Entry Spec Force 01000000 00000000 XX00003C No Payload Alternate Setups Carrier Entry Null Entry 01000000 00000000 00000000 Payload Entry Troop,Regiment 01000000 00000000 XX000010 Payload Entry Fighter Squadron 01000000 00000000 XX00001C Payload Entry Spec Force 01000000 00000000 XX00003C Payload Entry Facility 01000000 00000000 XX0000ZZ ( Where ZZ = 22, 23, 24, 25, 28, 29, 2A, 2C, 2D ) Carrier Entry Fleet Entry 01000000 00000000 04000008 <<< Side effects not ruled out yet Payload Entry Capital Ship 01000000 00000000 XX000014 Note: Facilities get normal deployment only if availability of free energy slots or material deposits (in the case for mines) allows their placement See details in section IV - B III .- Enclosed Deployment Examples ---------------------------------------------------- The following Carrier / Payload setups result in Enclosed Deployment A - FACLXYTB files and CMUNXYTB files whose target is a System: Carrier Entry Capital Ship Payload Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility In this case both the carrier and the payload get enclosed deployment Carrier Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility Payload Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility or Capital Ship In this case only the payload gets enclosed deployment Carrier Entry Null Payload Entry Capital Ship In this case only the payload gets enclosed deployment B - CMUNXYTB files whose target is a Fleet: Carrier Entry Capital Ship Payload Entry Facility In this case only the payload gets enclosed deployment Carrier Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility Payload Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility or Capital Ship In this case both the carrier and the payload get enclosed deployment (#) (#) The carrier asset is embedded in the fleet The payload asset is embedded in the carrier asset This result is observed if the fleet is actually created, which requires at least one Capital Ship properly deployed on it. Otherwise, the assets will get a fake deployment C - CMUNXYTB files whose target are both Systems and Fleets (Random Files): Carrier Entry Capital Ship Payload Entry Facility In this case only the payload gets enclosed deployment Carrier Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility Payload Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility or Capital Ship In this case only the payload gets enclosed deployment Carrier Entry Null Payload Entry Capital Ship In this case only the payload gets enclosed deployment D - SYFCXYTB files Capital ships included as regular entries in SYFCXYTB files also get enclosed deployment IV .- Fake Deployment Examples ------------------------------------------------ The following Carrier / Payload setups result in Fake Deployment A - CMUNXYTB files whose target is a Fleet: Carrier Entry Null Payload Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility In this case only the payload gets fake deployment (#) Carrier Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility Payload Entry Troop,Regiment or Fighter Squadron or Spec Force or Facility or Capital Ship In this case both the carrier and the payload get a fake deployment (#) (#) This result is observed if the fleet instance is not created, because no Capital Ship was properly deployed on it. Otherwise, the assets will get an enclosed deployment B - Logistics files that do not feature auto-adjust energy slots and auto-adjust material deposits attributes ( CMUNXYTB files ) Facilities get normal deployment only if availability of free energy slots or material deposits (in the case for mines) allows their placement If no available energy slots (or material deposits for mines) in the system, the facility may replace a previously a deployed one The replacement happens or not depending on the value of the "Family" ID of the facility If the previously deployed facility has a lower "Family ID" value, it gets replaced If facility does not get an energy slot (either free or by replacement) it gets a fake deployment Facility Replacement Hierarchy (when not enough energy slots available for deployment) - 0x2D Refinery - 0x2C Mine - 0x2A Construction Yard / Advanced Construction Yard - 0x29 Training Facility / Advanced Training Facilit - 0x28 Shipyard / Advanced Shipyard - 0x25 Death Star Shield - 0x24 GenCore Level I / GenCore Level II - 0x23 LNR Series I / LNR Series II - 0x22 KDY v150 C - SYFCXYTB files Mines deployed with SYFCXYTB files get an special case of fake deployment, if Energy Slots count > Material Deposit count in a given system. In such case, miles are placed on available Material Deposits, but all Energy Slots get filled. Further logistics events in game ( like asset building, or asset destruction ) do not remove the affected mines. Instead, any normally deployed mine being scraped on system also removes those with fake deployment in the same system, thus freeing their energy slots -------- Link to comment Share on other sites More sharing options...
bulkcruiser Posted March 23, 2023 Share Posted March 23, 2023 Fantastic work, was able to utilize the SDPRTB data to change the default galaxy setup in multiplayer. I can confirm the multiplayer values exist after the Imperial Hard Difficulty values. I was wondering if you had come across the data values that control the sector wide popular support swings when a regiment of troops or a ship is destroyed. I'm looking to reduce, or balance the swings that happen as a result of taking losses in a planetary assault or space battle. Link to comment Share on other sites More sharing options...
Hexdragon Posted March 24, 2023 Author Share Posted March 24, 2023 14 hours ago, bulkcruiser said: I can confirm the multiplayer values exist after the Imperial Hard Difficulty values. Glad to get this confirmed. Thanks ! 14 hours ago, bulkcruiser said: I was wondering if you had come across the data values that control the sector wide popular support swings when a regiment of troops or a ship is destroyed. I'm looking to reduce, or balance the swings that happen as a result of taking losses in a planetary assault or space battle. Did not find such values.GNPRTB seems the place to look at. There is a chance an entry in that file may handle them. On the other hand, worst case scenario is those values being set in rebexe itself For test and research, best approach is to edit SDPRTB In order to remove all randomness in popular support at day zero Regards, Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now