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

[Solarius Scorch]

Well i also and one of its components is the PORT_ATTACK.

EDIT: ok i see you do not have it in the FMP as such.
Could you try a couple of unmodded runs to see if you still get the double terrormissions?

Yeah, and I didn't get the double terror. So it's the mod's fault.

(BTW had to delete all config files after disabling FMP, because the game would crash at start.)

EDIT: I'll attach the ruleset in question.

[SupSuper]

I should mention that's probably the last major change for TFTD, so if you were waiting until the waters calmed, now's the time to start updating your mods for 2.0.

We'd really appreciate it if modders could start reviewing all their content, old and new, to make sure they're fully-functional for the next version and self-contained, so new players can easily install them just by dropping them into the "mods" folder (either manually or through third-party programs ). Feel free to update other's mods as well if the original author has vanished.

I'll check with Jo5hua if we'll need some kind of version filtering on the site to avoid mixing up old and new stuff (obviously the old stuff will still work but the install is different, so it's important to distinguish).

Edit: Also remember now that mods have their own folder, you are free to organize files inside however you see fit. You don't need to put all your resources in one folder, all the rules in one file, etc. Use whatever conventions suit you (plus it's faster to parse multiple rulefiles than a single huge one).

[Hobbes]

I've just confirmed the bug with a 2nd terror mission being generated. I've edited the missionScripts.rul file and deleted the entry for the monthly terror site generation. Then I started a new game without any mods and a terror mission was still generated check pic (ignore the Mixed race).

[Solarius Scorch]

As I already (sort of) reported on the IRC, I had to delete my own missionScripts version to make the second Terror go away. I deleted out vanilla missions before introducing them again in the ruleset, but apparently it was not working.

[SupSuper]

I figure I should clarify why some stuff about TFTD mods is broken and how you can avoid it for now.

So let's talk about resource IDs. You know, sprites, sounds, etc. OpenXcom has many many checks to make sure these don't go awry

For example you have a new weapon:

Code: [Select]

id: STR_THE_COOLEST_GUN
floorSprite: 20
handSprite: 50
When loading your mod, OpenXcom will check if your sprite ID is vanilla or mod by cross-checking with the reserved vanilla IDs. If it's vanilla, it stays as-is, otherwise the ID is put into the reserved mod region to avoid conflicts with other mods.
The problem is all these checks were designed with UFO in mind. After all, surely vanilla will never change? But of course TFTD is completely different: more sprites, more sounds, different files, so we need to rewrite all that. And that comes second to getting TFTD stable.

So until then, here's what you need to know for TFTD mods:
- Using new IDs (extraSprites/extraSounds) should be fine, just make sure you're using big IDs to not accidentally overwrite TFTD stuff.
- Using vanilla IDs means walking into the ~~danger zone~~, and will only work if it happens to be within UFO limits.
Too confusing? Don't worry, if your mod crashes the game you'll know.

[Hobbes]

The problem is all these checks were designed with UFO in mind. After all, surely vanilla will never change? But of course TFTD is completely different: more sprites, more sounds, different files, so we need to rewrite all that. And that comes second to getting TFTD stable.

And hopefully designing mod implementation for TFTD without much of an impact on the existing UFO mods, all of which takes time.

Thanks for the explanation SupSuper

[SupSuper]

TFTD mods should work correctly on the latest nightly now. All the changes were purely code-based so everything that worked before should still work (let me know if this isn't the case ).

[Orz]

TFTD mods should work correctly on the latest nightly now. All the changes were purely code-based so everything that worked before should still work (let me know if this isn't the case ).

I can attest to this. What previously was crashing my game is no longer doing so. So far so awesome

[Orz]

I don't know if this has come up with already or I am an isolated case. But to to follow up on the above, the latest nightly (2015_09_13_2018) causes my UFO/EU game on Ironman mode to crash every time it automatically attempts to save (like immediately after landing on a crashed site). Aside from that, the game works as normal.

So I reverted back to openxcom_git_master_2015_09_13_1549 for the time being.

I'm sure all shall work perfectly again with the next fixes!

[Solarius Scorch]

So, I heard that recent nightly changes break mods.

Is this true? If so, how do I fix it?

EDIT: See Hellrazor's post for a neat explanation for this.

[Arthanor]

From a look at the changes, I suspect it breaks saves that came from older versions (since the old way to define soldiers was type: XCOM, but the new way is Type: STR_SOLDIER). So if you purchased soldiers in a previous version, you had a bunch of XCOM which the new game doesn't really know what to do with because now it is looking for STR_SOLDIER.

I'd expect that if you start a new modded game with the newest nightly, it should work fine, but that it's not really working for old saves being loaded in.

[Solarius Scorch]

From a quick test of the FMP, it seems to be working correctly. We'll see if there's trouble.

[SupSuper]

From a look at the changes, I suspect it breaks saves that came from older versions (since the old way to define soldiers was type: XCOM, but the new way is Type: STR_SOLDIER). So if you purchased soldiers in a previous version, you had a bunch of XCOM which the new game doesn't really know what to do with because now it is looking for STR_SOLDIER.

I'd expect that if you start a new modded game with the newest nightly, it should work fine, but that it's not really working for old saves being loaded in.

The types were never used before so it shouldn't cause troubles, but I added some safeguards just in case.

So, let's talk about soldier types! OpenXcom has always had "soldiers.rul" with a lot of potential but no actual execution... so I decided to fix that.
To clarify, "soldiers" in this context are just X-COM units that can be levelled and equipped (unlike HWPs which are fixed items), they can look like a robot or an alien or whatever you want. Soldier types let you mix up the body pool. For example:

You can use them like Apoc soldiers, where you have a bunch of types with different starting stats:

Code: [Select]

soldiers:
  - type: STR_SOLDIER
    costBuy: 40000
    costSalary: 20000
    minStats:
      tu: 50
      stamina: 40
      health: 25
      bravery: 10
      reactions: 30
      firing: 40
      throwing: 50
      strength: 20
      psiStrength: 0
      psiSkill: 0
      melee: 20
    maxStats:
      tu: 60
      stamina: 70
      health: 40
      bravery: 60
      reactions: 60
      firing: 70
      throwing: 80
      strength: 40
      psiStrength: 100
      psiSkill: 16
      melee: 40
  - type: STR_SUPER_SOLDIER
    costBuy: 400000
    costSalary: 200000
    minStats:
      tu: 500
      stamina: 400
      health: 250
      bravery: 100
      reactions: 300
      firing: 400
      throwing: 500
      strength: 200
      psiStrength: 0
      psiSkill: 0
      melee: 200
    maxStats:
      tu: 600
      stamina: 700
      health: 400
      bravery: 600
      reactions: 600
      firing: 700
      throwing: 800
      strength: 400
      psiStrength: 1000
      psiSkill: 160
      melee: 400

You can use them to emulate turning aliens to your side:

Code: [Select]

soldiers:
  - type: STR_MUTON_SOLDIER
    requires:
      - STR_MUTON
    armor: MUTON_ARMOR0
    costBuy: 100000
    costSalary: 50000
    minStats:
      tu: 56
      stamina: 90
      health: 125
      bravery: 80
      reactions: 60
      firing: 54
      throwing: 62
      strength: 70
      psiStrength: 25
      psiSkill: 0
      melee: 76
    maxStats:
      tu: 56
      stamina: 90
      health: 125
      bravery: 80
      reactions: 60
      firing: 54
      throwing: 62
      strength: 70
      psiStrength: 25
      psiSkill: 0
      melee: 76

The sky's the limit! One problem you might've noticed is, what happens if you give the same armor to different soldier types? They'll all look the same! Not to worry, you can restrict armors per unit to make sure each soldier type gets the appropriate appearance. Does this mean you have to make X new armors for every Y units? Well, yes and no. You need to make new armor types, but they can all use the same item, effectively working as armor variations (you can use the same trick for cosmetic armor changes):

Code: [Select]

  - type: STR_PERSONAL_ARMOR_HUMAN
    spriteSheet: XCOM_1A.PCK
    spriteInv: MAN_1A
    storeItem: STR_PERSONAL_ARMOR
    units:
      - STR_SOLDIER
  - type: STR_PERSONAL_ARMOR_ALIEN
    spriteSheet: XCOM_1B.PCK
    spriteInv: MAN_1B
    storeItem: STR_PERSONAL_ARMOR
    units:
      - STR_ALIEN
  - type: STR_PERSONAL_ARMOR_ANDROID
    spriteSheet: XCOM_1C.PCK
    spriteInv: MAN_1C
    storeItem: STR_PERSONAL_ARMOR
    units:
      - STR_ANDROID


[Dioxine]

Awesome! Nothing seems to be missing. Great feature.
....Ohhh yeah. How are the death sounds defined? One per armor, or is there some way to have 6 unique sounds per soldier type (3 male/3 female), like with default soldiers?
Oh and what about names?

[R1dO]

This is a cool addition.

Although i am wondering what will happen if a muton defected to the xcom side decides to use it's default armor only to discover it's masters build in a safeguard against defecting mutons, eg:

Code: [Select]

soldiers:
  - type: STR_DEFECTED_TO_XCOM_MUTON
    armor: STR_PERSONAL_ARMOR_MUTON


Code: [Select]

  - type: STR_PERSONAL_ARMOR_MUTON
    units:
      - STR_ALIEN_MUTONS