Exceeding 1,000 HandObs in 1 Mod?

[The Martian]

For mods using the same sprite index numbers in BIGOBS, FLOOROBS, anything that used indexed sprites, etc., there are a certain number of indexes that are reserved for the original game's resources - for example, 0-127 for HANDOBS.  These are persistent between mods, so if you change any of those 'vanilla' HANDOBS, all mods that reference those for an item will use the modified graphics.  Indexes greater than the reserved values are unique between mods - each mod gets 1000 of each index for its own use, so HANDOB 128 will be index 128 for the first mod loaded, 1128 for the second mod loaded, 2128 in the third, and so on.  You don't need to worry about these numbers, as the only time you'll see this +1000 for each mod is if you look at the output of openxcom.log with verbose logging turned on.  In practice, that means each mod has its own separate HANDOB 128 and does not know about any of the other mods' HANDOB 128.  Thus you can 'reuse' those indexes for each separate mod without worrying about which image resource will be loaded for each mod, as long as you don't go over that 1000 or so limit.

(Question): I've run out of reserved HandOb values and need to exceed 1,000. What is the best way to do this?

Should I create a second Mod file that loads after my primary one to gain an extra 1,000 HandOb images or is there a simpler way that allows the images to continue to be indexed from the first Mod that already has the 1,000 images attached to it?

[Solarius Scorch]

If using vanilla, probably yeah. It's not an elegant solutions, but oh well.
If using OXCE+, it can deal with indexes over 1000.

[bulletdesigner]

haha i always think of this image when i read similar thread

[The Martian]

Thank you, I'm currently using vanilla OpenXcom so I'll split the Mod.

OXCE+ sounds better every time I hear about it.

haha i always think of this image when i read similar thread

[ivandogovich]

OXCE+ sounds better every time I hear about it.

Yeah, OXCE+ was really built for modders.  Helps overcome all sorts of things like this (custom palettes, more weapons on craft, etc).  Meridian brought a ton of Player improvements too it as well.

[Warboy1982]

i've upped the limit to 100,000. honestly i'm a little surprised how quickly people seem to be hitting the limit.

[Meridian]

i've upped the limit to 100,000. honestly i'm a little surprised how quickly people seem to be hitting the limit.

That was not necessary (and might slow down the application on a few specific places).

I can PR a change where modders can decide if they need 1000, 2000, 3000 or more...  if you'd be interested.

[Warboy1982]

sounds good, go for it (dynamic is better honestly)

[Solarius Scorch]

honestly i'm a little surprised how quickly people seem to be hitting the limit.

But seriously Warboy, I'm really happy this improvement is on the way. Many thanks!

[Meridian]

https://github.com/SupSuper/OpenXcom/pull/1175

PS: I couldn't test if it compiles without c++11, because my environment has c++11 dependencies already... and Travis checks on Github don't work either, because... you guessed it, it uses yaml-cpp version that requires c++11 too... I did change all c++11 code back to pre-c++11 code when back-porting from OXCE+ to OXC, but 100% certainty can only be achieved if someone actually compiles it on a non-c++11 environment

As for usage:
Just add a new line to your metadata.yml and specify how much space do you want to reserve for your mod... default is 1 (i.e. indices up to 999)

Code: [Select]

name: "My Big Mod"
version: "2.4"
description: "This mod is really big"
author: "Meridian"
id: my-big-mod
reservedSpace: 2                           # you can now use indices up to 1999 (3 => 2999, 4 => 3999, etc.)
isMaster: false
master: xcom1


[zee_ra]

https://github.com/SupSuper/OpenXcom/pull/1175

PS: I couldn't test if it compiles without c++11, because my environment has c++11 dependencies already... and Travis checks on Github don't work either, because... you guessed it, it uses yaml-cpp version that requires c++11 too... I did change all c++11 code back to pre-c++11 code when back-porting from OXCE+ to OXC, but 100% certainty can only be achieved if someone actually compiles it on a non-c++11 environment

As for usage:
Just add a new line to your metadata.yml and specify how much space do you want to reserve for your mod... default is 1 (i.e. indices up to 999)

Code: [Select]

name: "My Big Mod"
version: "2.4"
description: "This mod is really big"
author: "Meridian"
id: my-big-mod
reservedSpace: 2                           # you can now use indices up to 1999 (3 => 2999, 4 => 3999, etc.)
isMaster: false
master: xcom1


When is the reservedSpace attribute referenced?  I attempted to add the following

Code: [Select]

isMaster: false
master: x-com-files
reservedSpace: 10
into a mod that depends on X-Com Files, and has some definitions like this

Code: [Select]

  - type: STR_AUTO_MORTAR
    categories: [STR_XCOM_TECH, STR_LAUNCHERS, STR_HEAVY_WEAPONS, STR_EXPLOSIVES, STR_LAND]
    size: 0.6
    costSell: 95500
    weight: 22
    bigSprite: { mod: master, index: 1041 }
    floorSprite: { mod: master, index: 906 }
    handSprite: { mod: master, index: 1896 }
    bulletSprite: { mod: master, index: 4 }
    fireSound: 2
    compatibleAmmo:
      - STR_MORTAR_SHELL_HE
      - STR_MORTAR_SHELL_I
      - STR_MORTAR_SHELL_SMOKE
      - STR_MORTAR_SHELL_STUN
    noLOSAccuracyPenalty: 75
    accuracyAimed: 70
    accuracyCloseQuarters: 66
    tuAimed: 70
    accuracyMultiplier:
      firing: 0.5
      psiStrength: 1.0
    costThrow:
      energy: 20
      time: 30
    flatThrow:
      time: true
    battleType: 1
    twoHanded: true
    blockBothHands: true
    invWidth: 2
    invHeight: 3
    armor: 45
    arcingShot: true
    minRange: 10
    dropoff: 25
    kneelBonus: 300
    experienceTrainingMode: 4
    attraction: 23
    listOrder: 34203
inside of it.  When attempting to load, I'm still getting the error

Code: [Select]

Error for 'STR_AUTO_MORTAR': offset '1041' exceeds mod size limit 1000 in set 'BIGOBS.PCK' at line 75

It appears that the attribute reservedSpace had been entirely ignored in the child mod.  However, it does work in the parent mod.  The X-Com Files has the following in its medata file:

Code: [Select]

name: "X-Com Files"
version: "2.4.1"
enforcedExtendedVersion: "7.4.3"
requiredExtendedVersion: "7.4.3"
author: "Solarius Scorch"
description: "From a humble UN agency to the military power we know, in the vein of the 90's sci-fi paranoia TV series and 80's horror movies."
id: x-com-files
isMaster: true
master: xcom1
reservedSpace: 3


[Meridian]

reservedSpace is only for your mod, it doesn't do anything when referencing other mods (they have their own setting)

Use ` bigSprite: { mod: x-com-files, index: 1041 }` instead of ` bigSprite: { mod: master, index: 1041 }`

master is the top-most master, i.e. `xcom1` in this case

sample mod attached

[zee_ra]

reservedSpace is only for your mod, it doesn't do anything when referencing other mods (they have their own setting)

Use ` bigSprite: { mod: x-com-files, index: 1041 }` instead of ` bigSprite: { mod: master, index: 1041 }`

master is the top-most master, i.e. `xcom1` in this case

sample mod attached

Thank you.  This fixed the issue.

I wonder, if mods have their own namespace for referencing the graphics indexes?  If not, should I be defining enumeration that is globally unique?

[Meridian]

Yes, mods have their own "namespaces", or better said number ranges.

E.g. bigob index 654 in XCF will internally in the engine be for example 1654, same index 654 in your XCF submod will be for example 7654... depending on the position of the mod in the mod list and on the mod's reservedSpace.

You cannot manually define globally unique indices, even if you wanted to, so don't try.

The only exception are the vanilla (UFO1994 / TFTD1995) resources that are shared across mods, e.g. bigob index 15 will always just be 15 internally, never 1015 or 5015 or 19015.
Applies to the following image and sound sets: BASEBITS.PCK, BIGOBS.PCK, FLOOROB.PCK, HANDOB.PCK, HIT.PCK, INTICON.PCK, SMOKE.PCK, X1.PCK, Projectiles, UnderwaterProjectiles, GlobeMarkers, BATTLE.CAT and GEO.CAT

[zee_ra]

The only exception are the vanilla (UFO1994 / TFTD1995) resources that are shared across mods, e.g. bigob index 15 will always just be 15 internally, never 1015 or 5015 or 19015.
Applies to the following image and sound sets: BASEBITS.PCK, BIGOBS.PCK, FLOOROB.PCK, HANDOB.PCK, HIT.PCK, INTICON.PCK, SMOKE.PCK, X1.PCK, Projectiles, UnderwaterProjectiles, GlobeMarkers, BATTLE.CAT and GEO.CAT

What is the effect of clobbering the original game index in the mod?  I assume the mod's definition would simply take precedence over the original.  Is that correct?