Nightly Builds Discussion for Modders/LPers/Players/etc.

[Ethereal]

I, too, will wait for developments. I see no sense in such changes. Especially by default to do this... Would put it as a separate option - that is another matter.

[Hobbes]

This is a heads-up for all mods that include changes to the appearance of alien races because of a recent nightly change.

Before the nightly change, races in alienMissions followed this monthly progression:

Code: [Select]

  - type: STR_ALIEN_RESEARCH
    raceWeights:
      0:
        STR_SECTOID: 70
        STR_SNAKEMAN: 10
        STR_FLOATER: 20
      1:
        STR_SECTOID: 60
        STR_SNAKEMAN: 10
        STR_FLOATER: 30
      3:
        STR_SECTOID: 30
        STR_SNAKEMAN: 10
        STR_MUTON: 30
        STR_FLOATER: 30
      5:
        STR_SECTOID: 20
        STR_SNAKEMAN: 10
        STR_MUTON: 40
        STR_FLOATER: 30
      7:
        STR_SECTOID: 30
        STR_SNAKEMAN: 10
        STR_MUTON: 30
        STR_FLOATER: 30
After openxcom_git_master_2018_07_19_1404, this is the new progression for all alienMission entries (not just Alien Research):

Code: [Select]

alienMissions:
  - type: STR_ALIEN_RESEARCH
    raceWeights:
      0:
        STR_SECTOID: 70
        STR_SNAKEMAN: 10
        STR_FLOATER: 20
      1:
        STR_SECTOID: 60
        STR_SNAKEMAN: 10
        STR_FLOATER: 30
      3:
        STR_SECTOID: 30
        STR_SNAKEMAN: 10
        STR_MUTON: 30
        STR_FLOATER: 30
      6:
        STR_SECTOID: 20
        STR_SNAKEMAN: 10
        STR_MUTON: 40
        STR_FLOATER: 30
      9:
        STR_SECTOID: 30
        STR_SNAKEMAN: 10
        STR_MUTON: 30
        STR_FLOATER: 30
Now, why were months 5 and 7 replaced with months 6 and 9 you may ask?

The answer is that the original info on UFOPaedia.org regarding alien missions, which was used when OXC was first implemented, has recently been discovered to be incorrect by magic9mushroom and this has been confirmed by Warboy through examination of the original code.

The original author wrongly induced from empirical data that the progression of months was 0, 1, 3, 5, 7, but further testing of the original game and a code dig revealed it to be 0, 1, 3, 6, 9 instead, and thus the nightly has been fixed.

The practical implication of this change is that the appearance of Mutons/Ethereals on Terror missions has been pushed forward to July (month 6) and the same for the appearance of Ethereals in Infiltration and Base missions. And other smaller changes.

The propose of this post is to warn modders because this change can lead to ruleset/balance issues if your mod doesn't take into account the new monthly progression.

[SupSuper]

Just a heads-up for modders, we've been improving mod loading in OpenXcom by optimizing extraSprites, since they were the biggest culprit in big mods. For example, now instead of loading everything right at the start, extraSprites are only loaded the first time the game needs them, which significantly improves initial load time and memory consumption. Let us know if this made things better or worse for you, and if you see any bugs from these changes such as graphical glitches.

Only downside for modders is that now "Image not found" errors will only occur in-game, instead of right at the start. If this is a concern, you you can go back to the old loading by setting "lazyLoadResources" to "false" in options.cfg.

[Yankes]

BREAKING CHANGE INCOMING

SupSuper merged my PR that change how OXC handle negative indexes and common surfaces for all mods.

This mainly affect `bigSprite`, where OXC use negative indexes for terror unit weapons. Right now they are now invalid, game will reject mods that use them. Only exception is `-1` but it now mean no-sprite not terror weapon sprite.
If your mod still need this surface there are still available but under different syntax:

Code: [Select]

bigSprite: { mod: master, index: 61 } # under this we have old "-1" sprite, 60 is "-2" etc. for UFO, XCOM2 have different offsets because it have more surfaces
This new syntax allow you to access resources of other mods (work for sound and other shared surface sets too).

Code: [Select]

bigSprite:
  mod: MyOtherMod #id of mod from `metadata.yml`
  index: 120

Old syntax still work

Code: [Select]

bigSprite: 120
and is equal to

Code: [Select]

bigSprite:
  mod: current #alias for current mod
  index: 120

Example of change I made to make Final mod pack to work with this new version:

https://github.com/Yankes/Final-Mod-Pack/commit/bdad8bb33713577259d0f36a779d50da295a9dd3


some additional changes:

added `ignoreInBaseDefense` from OXCE as some mods used negative index to limit usage of items.
if you exceeded `reservedSpace` for your mod, game will fail to load.

[hellrazor]

One stupid Question how did the indexing of bigSprites now changed?

And how do i have to change the indexes in my mod so that things loads normally?

[Meridian]

One stupid Question how did the indexing of bigSprites now changed?

Negative indexes are not allowed anymore.

And how do i have to change the indexes in my mod so that things loads normally?

1/ Easier method: Copy the terror weapon bigob sprites into your mod and give them positive indices.

2/ Easy method: Reference the existing terror weapon bigob sprites from xcom1 as described by Yankes above.

[The Martian]

Only downside for modders is that now "Image not found" errors will only occur in-game, instead of right at the start. If this is a concern, you you can go back to the old loading by setting "lazyLoadResources" to "false" in options.cfg.

That's handy.

Thank you for providing that toggle option.

[hellrazor]

Today was introduced "breaking" change to nightly build.
Up to this point every solder armor was always recolored (face & hair) by game, now its require rule change to enable this.
If you want maintain current behavior you should add this lines to any armor used by solders and showing skin:

Code: [Select]

  spriteFaceGroup: 6
  spriteFaceColor: [96, 96, 96, 96, 160, 160, 163, 163] #M0 F0 M1 F1 M2 F2 M3 F3
  spriteHairGroup: 9
  spriteHairColor: [144, 144, 164, 164, 245, 245, 166, 166] #M0 F0 M1 F1 M2 F2 M3 F3
Where group is index range of color form palette, e.g. 6 give range form 96 to 111, all pixel with that colors will be replace by new values.
Game extract shade part of that pixel and add value form color array based on race & gender, result value is displayed in place of original pixel.

One new feature is that code is enabled for aliens and civilians too, but position in table is choose at random when unit is created.
I hope it will be useful.

Could someone explain to me how i found out which bit value is which color and or range?

[Meridian]

Could someone explain to me how i found out which bit value is which color and or range?

Attached.

[hellrazor]

Attached.

Thanks. So it basically is a table 16x16. Count starts at zero.
The ruleset variable name is not initiutiv in this case.

Me and graphics...