MOD AUTHORS - Important Format/Data Changes! [7/8 UPDATE]

Homeworld Remastered Collection Homeworld Remastered News
#1

This isn’t in the ‘Mods’ area because it is EXTREMELY important that everyone be aware of it… FYI.

Howdy guys - over the next few patches (and the past few) you are going to see some BIG changes to certain script and data files. Generally these are done to help Mods. We get little if any direct benefit ourselves. However, these changes are often not backwards compatible for many reasons (oh the joys of being data-driven!).

I’d like to cover a few quick ones right now, as I know that with this last patch a few major changes will cause crashes and issues until Mods are updated. If your Mod didn’t touch any of these systems, it is likely just fine. But often Mods include files they don’t need, or they make minor edits. So, be warned. The next round of changes will likely be MUCH more of a delta to many things, so this is a sort of warm-up!

Strike-groups/Formations

The old engine would load strike-groups based on the contents of Strikegroups.lua - now it loads any .lua file (except the one just mentioned) and adds it to a list. The files now also contain lots of info (name, title, artwork, icon, sorting order, ai preference, etc) - I won’t document that just yet (subject to change) - but now you know to go digging. If you add or remove one of these now, the UI (and right click menu!) will auto-update to reflect the delta.

As well as changes to Strikegroups - Formations are also now loaded simply by searching - a new formation can be added to the game with very little work, and as with SGs there is a fair bit of new meta-data inside their scripts.

A word about AIs & SGs - Before this patch the AI would select a Strike-group based on a random # between 1 and 3 - that’s it. Frigate Line, Fighter Screen, Capitol Phalanx - that’s it. Totally random. Now, using the AI weight property, you can allow AI to select any SG (and weight the results) - including SGs that you don’t allow to be seen on the UI, etc.

User Campaigns/Missions

With the addition of Raider Retreat we’ve added systems to allow anyone to add Campaigns. Now you can add content and the menus will auto-show it! Again, we’ll document it properly soon - but many of you know how to look for this stuff, and will quickly notice the difference. In addition, I plan to shortly add the ability to save and load ‘campaign’ key/value data into a user profile - and allow levels to be hidden or shown with a filter - meaning levels that fork or change, based on more than just persist files. We’ll go into details once the systems are in place, but understand they are coming, and will bring a whole new level of detail to SP games.

Forthcoming Systems Edits (added 7/8)

In a forthcoming patch a LARGE number of very major systems edits is going to make future Mod authors squeal with glee, and current Mod authors maybe a bit grumpy…

I won’t go into extreme detail because we haven’t released it - and things can and will change. BUT - I wanted to give a heads-up because some of what’s being done can be planned for, etc. This has been a HUGE effort and is looking quite solid - but as with all large deltas (something like 350 files at this point), it takes time and careful testing before anyone sees it…

The main thing is that ‘rubrics’ are GONE. The game has 3 major modes: Single Player, Skirmish, and MP. But those aren’t used or exposed to scripts/assets any longer. Instead, all modes must have a GameRule (GR). If you know much about the engine, you know this was already the case (sorta) - but the new system is making this the #1 rule.

GR can ‘filter’ game content in a number of ways:

  • Limit Races available
  • Limit Levels available

GR also have a number of new properties that can be seen and used by assets (.ship files) and in-game (the Rules lua, AI, etc)

  • Tags - essentially ‘yes no’ flags, any you can imagine.
  • Numbers - any you can imagine
  • Strings - seeing a pattern yet?

The properties of a GR aren’t stored in a single file (though an initial single file is used to create a GR)… instead there are a series of folders that are searched for script/properties to add to the GR. This means modding a GR for almost anything is an ‘add a new file’ process - almost NEVER a ‘change this existing file’ or ‘nuke this file’ process.

When a GR is selected the tag filters it has for Races/Levels are applied to what the game has detected, so if a level doesn’t match the GR tags for levels, it won’t show up in any lists - ditto for Races.

Races, like GR, now have properties - Tags/Numbers/Strings - and like GR they are loaded by searching sub-folders. In addition, when a GR filters (and keeps) a Race, an extra set of folders defined by the GR is searched under the Race - allowing GR to actually mutate Races. Maybe you have a ‘Free for all’ GR for DM - and the Races are all balanced - but then a ‘Topple the Empire’ GR for DM where one Race is MUCH more powerful and players are supposed to gang up, etc. This is all VERY easy now. This also means that balance tweaks and Mods become less about hacking, and more about careful planning and properties building.

AI used to be a ‘per level’ or ‘per game rule’ thing. The AI files were very heavily hard-coded for races as well. Yeah, that’s gone.

AI can still be per-level. But AI is now defined per-race (and yes, GR can override this per-race). AI scripts use the Race properties and GR properties… so instead of ‘if race is Vaygr do X’ you see ‘math value = SelfRace_GetNumber(“important_property”, 1.0)’ - no more hard coding, period.

AI also used to live in a bubble where they couldn’t see much about the world - and while this is still true (though I think we have a bit more to do there) - the new systems to query Race and GR values, on top of AI being able to vary (completely distinct code per Race if you wish!) is going to mean much smarter AI with way less hacking or hard-coding. I am excited not just for what we can do, but for what all of you will do.

If a file used to exist in some random folder (I’m looking at you BuildAndResearch!!!) - it’s now most likely found under a specific Race’s path. Almost every script or config asset has been moved and rebuilt to work properly. In theory adding a new Race will be CRAZY easy.

Oh, and that old ‘Random’ Race select in Game setup? ‘Random’ is now a type of Race - and it can choose to filter the other races. So while ‘Random’ can be a Race which selects any playable (and allowed by the GR) race, it can also apply stronger limits…

  • Random
  • Random HW1 Race
  • Random HW2 Race
  • Random Evil Race
  • Races With Extra Arms

You get the picture. And as Mod authors, you can go nuts - without hacking.

I’ll outline more as it seems solid/safe to do so… As always, if I wrote something here you want clarity on (when I can) - or ideas you think I might be able to use now to get you something you want, let me know…

  • Please use this space to ask questions, get clarifications, etc…
16 Likes
[HWRM MOD][9CCN] v1.35 (Full) - Crossroads
I think the entire community would like an answer to a question I pose
Bulletmod needs help
#2

You are an absolute saint @Bitvenom!!!

With the ability to more easily add custom campaigns, do campaign only mods (ie those with stock assets) need to use a different Workshop tag than “MOD”, “Locale”, “Badges”, or “Cursors” ?

I’m downloading the update now, so if I have anything useful to report from BrickSpace I’ll be sure to let ya know.

Edit 1840 hrs: Well shoot. Launching BrickSpace I get an Access Violation, not even a General Failure that I can troubleshoot. I’ll do some investigating and see what I can find.

Edit 1952 hrs: After removing my modified “styles” folder, finalbuild.lua, and newmainmenu.lua, the mod launches without issue again. Yay!

#3

Will custom campaigns be limited to using the Hiigaran race (or whatever race is #1 in race.lua) like it was with HW2C? If we can just say that a certain player is a certain race and then have it all go through as expected that would be fantastic :smile:

#4

Well, no - I mean the RR mission is Kushan, right? I don’t think you have that limitation. BUT - if you do, or have similar issues, please outline them to me, so that I can design whatever is required to get it all working clean…

4 Likes
#5

Exciting stuff coming up ! Thanks for the heads up and info !

#6

Same issue here :

The race used for my campaign or any other mission for SP game is the first race located in race.lua .
Why you don’t just let the script of the mission give the priority to the race.lua linked (dofilepath) in that lua script?

#7

It’s not really my area of expertise - so I have to look into it. We’ll evolve this whole thing quite a bit before it’s final, no worries… It’ll just take a while, because it’s a ton of work and very sensitive stuff to screw with :wink:

#8

What are you trying? I can use any race I want.

#9

We can use any ship of any race but if that race is not in the first position in the race.lua then the build list is empty in SP Game (Scenario and Campaign) …

I maybe got a solution:
Deleting the race.lua located in the .big of the mod then making multiple race.lua and renaming them for each race, like that: CampaignTauri.big / CampaignGoauld.big etc … and modify the shortcuts : -mod Main.big, CampaignXXX.big
To be clear, I want to create one race.lua for each scenario.

What do you think?

#10

Okay I think I know what you’re doing wrong. In your .level file, the players array can contain a value called raceID. This represents the race of the player. For example mine looks like this:

player = {};
player[0] =
{
 id = 0,
 name = "Player",
 resources = 0,
 raceID = 5,
 startPos = 0,
}
player[1] =
{
 id = 1,
 name = "Enemy",
 resources = 0,
 raceID = 6,
 startPos = 0,
}

This allows me to build the appropriate ships for my race.

Additionally the individual race.lua for each scenario would allow the player to build ships, but unless it was the same race the AI wouldn’t be able to do the same.

#11

Oh !

So the raceID = X is the race X in the Race.lua right ?

#12

It looks that way. I figured these out through trial and error but it seems to line up.

#13

Yep.

Now we can’t launch mod with the last patch of Gearbox :

The log =>

Wed Jun 10 17:33:46 2015
 Version 1.28, Build Number 10, Changelist Number 1057918 
 Loaded Archive: 'Homeworld2.big' 
 Loaded Archive: 'UpdateHomeworld2.big' 
 Loaded Archive: 'HW1Ships.big' 
 Loaded Archive: 'UpdateHW1Ships.big' 
 Loaded Archive: 'HW2Ships.big' 
 Loaded Archive: 'UpdateHW2Ships.big' 
 Loaded Archive: 'HWBackgrounds.big' 
 Loaded Archive: 'UpdateHWBackgrounds.big' 
 Loaded Archive: 'French.big' 
 Loaded Archive: 'UpdateFrench.big' 
 Loaded Archive: 'DataMP.big' 
 Loaded Archive: 'Compatibility.big' 
 LOCALIZER -- Duplicate string line 356 in LOCALE:sgmod.dat 
 Uing ..profiles\ for profiles folder 
 LUA -- luaconfig -- FATAL EXIT -- luaconfig/1161:! --stack trace--

What happened at the last line?
Any solution ?

#14

Well, you’ve got a problem with the localizer, line 356 in LOCALE:sgmod.dat is a duplicate string, possibly colliding with one of the new strings added for the lobby or extra mission support. I wouldn’t expect that to crash, but it’d be the first thing I’d try fixing.

Next I’d try deleting your existing profiles directories(possibly with a backup of course) and seeing if old data in a profile is causing the trouble. That’s happened in mods in the past.

From the filename and your avatar picture, I take it this is for the stargate mod? I think I remember talking about singleplayer mission attempts in past threads, if that’s true and removing the profiles doesn’t solve the issue, you might try removing your campaign files from the mod to see if that resolves the crash. If it does, that’d at least tell us where to focus efforts from there. The other hotspot that I find breaks frequently with patches is any menu or GUI moding.

#15

Campaign files : i removed them and now the mod launch.

Yes, i’m in the Phoenix team. :wink:

#16

In that case, my next troubleshooting step would be to extract fresh copies of the stock campaign files and see if there are any changes to them you need to copy.

#17

Yep. Or use the new button add by Gearbox … ^^

#18

Struggling with this one… I was previously using my own campaign called “Asencion” (a hang over from HW2 days when a new campaign had to be called “Ascension”, with the following command line:

“C:\Program Files (x86)\Steam\steamapps\common\Homeworld\HomeworldRM\Bin\Release\HomeworldRM.exe” -overrideBigFile -dlccampaign HW2Campaign.big -campaign Ascension -moviepath DataHW2Campaign -mod compatibility.big

However this no longer works. It now loads a “Homeworld 2” menu screen with the “extra missions” option but no campaign!

Any ideas what I am doing wrong?

I also had a look in the new “HW1Campaign.big” expecting to find some new formatting for the extra missions, but it all seems the same - one campaign, one list of missions. No clue as to what makes Raider Retreat show up as an extra…

#19

My campaign just worked. I would try renaming the campaign to something else, as campaigns named Ascension were always treated differently.

#20

You need to rename your .campaign, and add this to .campaign :
Something like this >

   -- localized display name for the UI
displayName = "Campaign XXX"

-- 2 = Extra
contentType = 2
contentName = "Campaign_XXX"
contentOrdered = 0
contentChooseText = "Campaign XXX"
contentThumbName = "Name of ARC" -- If you have more one mission in the Campaign files
contentThumbDesc = "Description of ARC" -- IF you have more one mission in the Campaign files
contentSort = 0.4	-- Default is 1.0, so 0.4 will appear _before_ others.

Mission = { }   -- create a mission structure

-- Mission 1 
Mission[1] = {
    postload        = function () end,

    directory       = "MyMission",
    level           = "MyMission.level",
    postlevel       = function () postLevelComplete() end,
		
    displayName     = "",
}

You acces your mission in the new button created by Gearbox.

1 Like