Spawnclass Renaming Technique - Known or Not?

• Spawnclass Renaming Technique - Known or Not?
  Posted by doudley on 30 Mar, 2017 02:36
• Hi guys! (My first topic )
  
  While working on my Potion of Insight mod and discussing merchant option with @Aherin, I found out that there's an easy way to add merchant's stock without modifying original game content. Its a breakthrough news for me but I don't know about you guys...
  
  Initially (for a long time now), my perception in data overriding/mod load order is like this
  
  

  Quote

  Mod A changes the "Catacombs_EchoPass" Spawn Class to only spawn Skeletons.
  Mod B changes the "Catacombs_EchoPass" Spawn Class to only spawn Zombies and also alters the lighting to be pink in the "DefiledCrypt" Level Rule Set.
  
  If Mod A is higher than Mod B in the Selected Mod Order list in the Mod Launcher then Skeletons will appear in the Defiled Crypt and the lighting will be pink. If Mod B is higher then Zombies will appear and the lighting will be pink. At no point will both Skeletons and Zombies appear as the edited Spawn Class files from each mod are not combined, but regardless of mod order the pink lighting in Defiled Crypt from Mod B will be used as there was no conflict with it.

  
  Now I found out its not simply so and there's a non-conflict way, it was already pointed out by my long time idol in modding, lyravega.
  
  Here's his explanation about this.
  
  

  Spoiler (hover to show)

  Quote from: lyravega

  Ignore the previous stuff. Apparently, AG already found a sweeter and easier way.
  
  Lets say, we are trying to add stuff to MERCHANT_GENERAL_INVENTORY spawn class. Create a new spawn class, and call it whatever you want (but not anything that is being used in the game or any mod, simplest example is calling it after your mod for example). In this spawn class, one thing has to be same with MERCHANT_GENERAL_INVENTORY, and it is the name.
  
  So, your file should look like this:
  

  Code: [Select]

  [SPAWNCLASS]
     <STRING>NAME:MERCHANT_GENERAL_INVENTORY
     (stuff that your mod adds are below)
     ...
[/SPAWNCLASS]
  So, yeah. Only the name string has to match, and file name(s) should be unique. Anyone used the project stuff before, if you delete the MOD_GENERAL_INVENTORY.DAT from your mods, and change the name string in your spawn classes to "MERCHANT_GENERAL_INVENTORY", you'll effectively add your stuff to that spawn class. I'm moving the entire post to 2nd post, and marking all as spoiler.

  
  That's it guys!
• 
  
• #1 Reply
  Posted by Phanjam on 30 Mar, 2017 03:17
• Thanks for this doudley!  Good to know this if ever I need to work with SPAWNCLASSES stuff
  
  I use a similar technique to add new sounds (make a new SOUNDS_UNIQUE_NAME.DAT file and add new sound definitions with...
  
  

  Code: [Select]

  [SOUNDDATA]
[SOUND]
[/SOUND]
[/SOUNDDATA]

  So far it doesn;t give me any trouble
• 
  
• #2 Reply
  Posted by Anarch16sync on 30 Mar, 2017 03:53
• Hello @doudley, like you pointed this method for merging spawnclasses without conflict has been know from that time, obviosly people that get into modding now or haven't worked on spawnclasses may not know it, so the reminder is always good.
  
  Let me add that this also work with the WardrobeSets.Dat file, to make not conflicting addition to the wardrobe list, this is how I handled the wardrobe additions for the TL1CP. 
  There may be other files that can work this way, like the SoundData PhanJam pointed,but I haven't tried. Well, I tried on unit files and it didn't work, so there is that.
• 
  
• #3 Reply
  Posted by doudley on 30 Mar, 2017 06:38
• Thank you guys for the response!
  
  But I like to think that WardrobeSets and SoundData files are like Affixes and TriggerableActions. All of these are non-GUID files, which we can create even without using GUTS. A Spawnclass on the other hand, has a specified "name" just like an Affix or a TriggerableAction, they are all registered in the game by their specific code "names" unlike some files that are dependent by their GUID.
  
  *code name is <STRING>NAME:BASE inside the data and file name is BASE.DAT
  
  A unit data cloned with different code "name" but uses only one GUID, will be read by the game as one (actually conflicts like this are discarded by the game). These make sense to me and I know for the fact the changing file names won't matter as long as the code name and GUID were remained intact.
  
  That's why the spawnclass file renaming technique is a big shock to me...apparently changing the file name of a spawnclass while assigning it to an already been used code name, will make this renamed spawnclass an appendage of an existing spawnclass!!
  
  .
  
  .
  
  .
  
  Sorry, I'm still shocked by it...
•