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