Hexdragon

Glad to get this confirmed. Thanks ! 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,

Good Job !

Yep, subscribed there. Mostly inactive though.

My above statement is actually wrong. Custom values like 0x05, 0x07 and 0x0A in MIssion's DWORD_09 behavior like binary flags, just as Metasharp remarked Hence: -A custom mission profile ( MIssion's DWORD_09 ) with a value like 0x05 ( 1 + 4 ) will match SpecForces DWORD_29 with values 0x01 and 0x04 -A custom mission profile ( MIssion's DWORD_09 ) with a value like 0x07 ( 1 + 2+ 4 ) will match SpecForces DWORD_29 with values 0x01 , 0x02 and 0x04 -A custom mission profile ( MIssion's DWORD_09 ) with a value like 0x0A ( 2 + 8 ) will match SpecForces DWORD_29 with values 0x02 and 0x08 On the other hand, custom value like 0x05 in SpecForces DWORD_29 will not match MIssion's DWORD_09 with values 0x01 and 0x04 That's, my former test result. ---- Further, a second ( and cleaner) solution for OP request is available: In order to give assassination mission to Imperial Commandos, just modify that mission's entry in the second byte of MIssion's DWORD_09 From 00 08 00 00 to 00 0C 00 00 That will match both : SpecForces DWORD_29 = 00 08 00 00 ( Noghri Death Commandos ) And SpecForces DWORD_29 = 00 04 00 00 ( Imperial Commandos ) ---- Regards p,s The extra units mini-mod, referred in previous post, has been uploaded here: https://swrebellion.net/files/category/9-star-wars-mods/

================================ 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 --------

======== 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). ========

======================== SYFCXYTB.DAT - Description ======================== SYFCXYTB - Header: -------------------------------- Header Size: 32 bytes (08 DWords ) DWord_H01 0x01 DWord_H02 Number of Parent Entries DWord_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 Number DWord_E02 Unknown_E02 / Always 0x01 DWord_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 Index OR: 0x65 > Random Result >= Current Index THEN: 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. --------

======================================== CMUNXYTB.DAT / FACLXYTB.DAT - Description ======================================== CMUNXYTB / FACLXYTB - Header: ---------------------------------------------------- Header Size: 32 bytes (08 DWords ) DWord_H01 0x01 DWord_H02 Number of Parent Entries DWord_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 Number DWord_P02 Unknown_P02 / Always 0x01 DWord_P03 Probability Index ( Random seed generation ) (#) DWord_P04 Parent Entry Multiplier (##) DWord_P05 Unknown_P05 / Always 0x01 DWord_P06 Child Entry Count (#) Random Seed Range: [ 0x01, .. ,0x64 ] ( 1 to 100 ) IF: Next Index > Random Result >= Current Index OR: 0x65 > Random Result >= Current Index THEN: 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 0x01 DWord_C02 Unknown_C02 / Always 0x00 DWord_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

============================ 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 files Notes 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.DAT Random 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.DAT TM = MPs provided by Mine-Refinery pairs placed by SYFCXYTB.DAT and FACLXYTB.DAT or upon Default Mine Deployment XM = MPs consumed by assets placed by SYFCXYTB.DAT and FACLXYTB.DAT A% = 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 --------

Kurukaze was the first guy who got to add a new type of unit, if I am not mistaken Back in 2007 he got to add two new characters to game Be reading carefully about his method got to add new Troops and Spec Forces Also, found the tactical pointer tables he was looking for (#) (#) Sadly those were found inside Rebexe, which was the worst case scenario Because of the above, limitations that remain are: -Tactical Pictures Those 32x32 pics in TACTICAL.DLL used to display Troops, Spec forces and Characters (as Ship "passengers") during tactical battle The pointers between units IDs in the Strategic part of the game and their tactical images is located in Rebexe There are two unused pics ( from Imperial Probe Droid and recon LongProbe Y-Wing recon team ) that can be re-assigned for new units Any new unit beyond the first two will lack its passenger picture ( if not taken from an existing unit by editing the pointer table in Rebexe) Not a serious limitation though (IMHO). The lack of a tactical "passenger" pic does NOT crash the game -Troop Finder / Spec Forces Finder Both are hardcoded in Rebexe Troop finder is limited to 5 units per side Spec forces finder is limited to 4 units per side However, it is possible to edit finders in Rebexe in order to make choice about which units ( originals or new ones ) shall be handled by the finders -Capital Ships 3D Models The pointers between Capital Ship IDs in the Strategic part of the game and the 3D assets is located in Rebexe On the other hand even without new 3D-Model new capital ships can be added. In tactical battles new Cap Ships will feature the Mon Calamari Model, which is used by the game as sort of default model I will expand about the HowToDo in a different post Also will upload a couple of "extra unit" test bed mini-mods I made in late "pre-pandemic" times For now, I will left the ultra short version: The whole process reduces to: 1- Adding the new Entry for the unit in the proper DAT File ( like SPECFCSD.DAT ) (#) 2- Determine the correct ID numbers for the new unit's resources in DLL files ( BMPs and Text entries ) (##) 3- Add those resources to DLLs using resource Hacker, as well as the "Encyclopedia" picture in EData folder (###) (#) Dont forget to edit the unit count there (##) With the exception of TACTICAL.DLL resource ID numbers of units in DLLs have a mathematical relation with their Unit ID AND/OR the first byte of the unit's DLL reference number ( Unit Entry's 1st DWORD and 6th DWORD respectively, inside the DAT file ) (###) Special care should be taken in BMPs having the correct format and header (otherwise expect game crash) Regards

Typo correction. it shall be: DWord_M25: Mission aborts upon system's blockade (1=Y / 0=N) ???

Initially, I considered too that mission profiles may be handled on a bit-wise basis But test results suggest is not the case Custom profiles with values like 0x05, 0x07, 0x0A were evaluated byte-wise ---- Below, Info gathered on MISSNSD.DAT, upon Hex dump review and test MISSNSD.DAT - Description ======================= MISSNSD Header: -------------------- -Header Size: 16 bytes (4 Double words) DWord_H01: Unknown_H01 DWord_H02: Item Count 0x19 (25 items) DWord_H03: Asset type ("family") lower limit DWord_H04: Asset type ("family") upper limit MISSNSD Entry: -------------------- -Mission Entry Size: 112 bytes (28 Double words) per item. DWord_M01: Mission ID Number DWord_M02: Unknown_M02 / Always 0x01 DWord_M03: Unknown_M03 / Always 0x00 DWord_M04: Unknown_M04 / Always 0x00 DWord_M05: Item's "Family ID" DWord_M06: DLL Reference: First Word references mission name string's Number ID in TEXTSTRA.DLL DWord_M07: Available for rebels (1=Y / 0=N) DWord_M08: Available for empire (1=Y / 0=N) DWord_M09: Mission profiles ( meant to be referenced in SPECFCSD.DAT ) DWord_M10: Unknown_M10 / Recon mission gets 0x00000000. Others get 0x00000100. DWord_M11: Unknown_M11 DWord_M12: Unknown_M12 DWord_M13: Continue mission assignment after last mission's outcome (1=Y / 0=N) DWord_M14: Unknown_M14 / Player-initiated missions get 0x00. Others get 0x01 DWord_M15: Unknown_M15 / Bounty Hunter's mission get 0x00. Others get 0x01 DWord_M16: Unknown_M16 / Player-initiated missions get 0x01. Others get 0x00 DWord_M17: Unknown_M17 / Player-initiated missions get 0x01. Others get 0x00 or 0x02 DWord_M18: Unknown_M18 / Either 0x00 or 0x01. DWord_M19: Unknown_M19 / Either 0x00 or 0x01. DWord_M20: Unknown_M20 / Either 0x00 or 0x01. DWord_M21: Unknown_M21 / Either 0x00 or 0x01. DWord_M22: Mission can be carried on friendly planet (1=Y / 0=N) DWord_M23: Mission can be carried on neutral planet (1=Y / 0=N) DWord_M24: Mission can be carried on hostile planet (1=Y / 0=N) DWord_M25: Unknown_M25 / Either 0x00 or 0x01. DWord_M26: Unknown_M26 / Either 0x00 or 0x01. DWord_M27: Unknown_M27 / Either 0x00 or 0x01. DWord_M28: Unknown_M28 / Either 0x00 or 0x01. Open Conjectures: -------------------------- DWord_M11: Points gathered upon success (Base) ??? DWord_M12: Points gathered upon success (Var) ??? DWord_M17: Agent's Destination after mission abort ??? DWord_M28: Objective can result killed (1=Y / 0=N) ??? Conjectures provided by ThruthRealm ---------------------------------------------------- DWord_M10: Enable / Disable mission for characters >>> ( Verified by Truthrealm ) DWord_M18: Agent's Destination after mission completion ??? DWord_M19: Requires target to be explored (1=Y / 0=N) ??? DWord_M26: Mission aborts upon system's blockade (1=Y / 0=N) ??? DWord_M26: Mission aborts upon uprising (1=Y / 0=N) ??? DWord_M27: Objective can result in "Escaped" (1=Y / 0=N) ??? Mission ID Numbers ---------------------------- 0x01 Move 0x02 Return 0x03 Autorouting 0x04 Adrift 0x10 Diplomacy 0x11 Rescue 0x12 Sabotage 0x13 Espionage 0x15 Reconnaissance 0x16 Recruitment 0x17 Abduction 0x20 Ship Design Research 0x21 Facility Design Research 0x22 Troop Training Research 0x40 Incite Uprising 0x41 Death Star Sabotage 0x42 Jedi Training 0x43 Dagobah 0x44 Palace 0x45 Vacation 0x46 Sabbatical 0x80 Subdue Uprising 0x81 Assassination 0x82 Pickup 0x83 Bounty ----

Glad to know it was useful !

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 --------

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 --------

Older post on this forum ( like the one below) help a lot Then: hex-editor, free time to expend, and very (very) heavy hand on testing Also that tool "resource hacker" to check for resource IDs to look for. Yet that is not involved on this particular one.

HexEditor WinHex https://www.x-ways.net/winhex/ Attached images

You may edit the link between Imperial Commandos and Assassination Mission But no perfect solution if you also want to keep other spec force's mission profiles intact -SPECFCSD.DAT (SpecForces) Data: 116 bytes (29 Double words) per item. -MISSNSD.DAT (Mission) Data: 112 bytes (28 Double words) per item. The link among them is located at DWORD_29 for SpecForces item and DWORD_09 for Mission Item in MIssion's DWORD_09 a pair of mission profiles is set for given mission instance ( 1st byte = 1st Profile ID / 2nd byte = 2nd Profile ID ) In SpecForces DWORD_29 the Spec Force unit must pick only one of those profiles (1st OR 2nd ) For Assassination Mission ( ID 81 ) DWORD_09 = hex 00 08 00 00 This mean only one profile is set ( 2nd byte = 08 is the profile used by Noghri Death Commandos ) You may edit the Assassination Mission DWORD_09 to hex 02 04 00 00 Then, change Noghri Death Commandos DWORD_29 (their mission profile) from 00 08 00 00 to 02 00 00 00 -The above change in Assassination Mission DWORD_09 enables it to the profiles used by Imperial Commandos And Infiltrators -Further change in Noghri Death Commandos DWORD_29 gives them the profile used by infiltrators ( now with Assassination ! ) ---- Hope it helps

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 --------

============ 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 --------

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 --------