Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - zee_ra

Pages: 1 ... 5 6 [7] 8 9 ... 14
OXCE Support / Re: Best mods for OXCE 2023?
« on: March 31, 2023, 06:11:18 pm »
1. TWoTS
2. Piratez
3. FMP

I'm surprised why the X-Com Files is not mentioned in this list.  What is your rationale for not including it?  I'm asking from the standpoint of a user and modder who appreciates the richness of playthrough and story that was enabled by XCF and which the vanilla is missing.

Also, I wonder if FMP is actually a part of XCF?  That's been my impression after reading descriptions at the, and playing through the whole XCF oncee.

OXCE Support / Re: Modding collections (lists, maps).
« on: March 31, 2023, 06:05:14 pm »
because two separate things, yaml file and rules in engine, data can only flow from yaml file to engine not in opposite way.
OXCE only support "coping" in yaml file as some nodes are duplicated in multiple places.
This duplication do not alow in any way to duplicate any thing that is in engine as this is different layer.

Well, let's for the sake of discussion assume that a solution at the YAML level is not being considered.  In YAML, it's possible to parse multiple data buffers and to merge them.  The tooling for that is not a part of a YAML specifications.

If we treat the config as just data, then we in the end have a set of definitions that are processed in the second step.  The merging occurs in that step, whence definitions from sub-mods are applied.  At this step, all config data is already parsed, and we have available to us a set of unmerged configuration definitions.  The definitions then need to be applied in descending order to the main configuration.  The definitions thus may refer to whatever was previously defined.  The way this reference is achieved is not through the YAML constructs, but through the reference (e.g. a field, without any special meaning in YAML, called "inheritFrom", which contains an id of the parent definition).


Please allow me to note that the specific problem that I'm trying to solve is a very practical one, and it is about extending master mods, and actually any other mods, in a way that eliminates the bulk of the maintenance burden.  I'm working out a solution within the current implementation constraints.

Anywhere a copy-pasting at the level of writing mod files is involved, we get a source of bugs and maintenance burdens.

OXCE Support / Re: Modding collections (lists, maps).
« on: March 31, 2023, 01:52:37 pm »
Currently, there is no solution.

OXCE does not support inheritance.
Most we can do is various forms of smart copypaste, within the scope of one single rul file.

You can change the definition from a parent mod.
You cannot reuse a definition from a parent mod to define something new.

Could I create a copy of the item already available in a mod?

Why is my original technique invalid?  What happens when those definitions are applied?

OXCE Support / Re: Modding collections (lists, maps).
« on: March 31, 2023, 01:49:56 pm »
Currently, there is no solution.

OXCE does not support inheritance.
Most we can do is various forms of smart copypaste, within the scope of one single rul file.

You can change the definition from a parent mod.
You cannot reuse a definition from a parent mod to define something new.

I basically need to copy data from the parent mod.  The binding time is at the instantiation of the data.  Clearly, the copying semantics is satisfactory.

I hope the use of terminology that is homonymous with that adopted by c++ does not convey the wrong idea.

You mentioned smart copying.  How could this be achieved?

OXCE Support / Re: Modding collections (lists, maps).
« on: March 31, 2023, 01:10:53 pm »

it's invalid

since the example is invalid, this question is also invalid

but purely technically, it makes a technical difference, we don't have any reason to add 2 keywords doing exactly the same thing :)

Could you please suggest a solution to my original task of reusing definition from the parent mod?  Would the stub code above be sufficient for illustration?

OXCE Support / Re: Modding collections (lists, maps).
« on: March 31, 2023, 12:44:19 pm »
It's not inheritance, it's an automated copy-paste.

I will update the ruleset reference this weekend to be more precise.

It seems that I still need to import an anchor into my mode's namespace in order to enable the propagation of values.

Could you please have a look at the technique suggested below and ascertain its validity.

Code: [Select]
# In order to reference the large rocket definition in my mod,
# I actually need to create an anchor that refers to a parent
# definition
    override: STR_LARGE_ROCKET
# nothing is done to this definition
# the override there is merely as a means of importing the definition
# [...]
# Now I could take advantage of the definition through refNode.
    type: STR_GAS_ROCKET
    refNode: *STR_LARGE_ROCKET
# I could define whatever fields need to be defined.
# All the values that were populated in the parent mod large rocket definition
# would be pre-populated in this definition already.
# [...]

I also wonder, whether it makes a difference whether I use update: or override in the example above.

There is no fixed place for the head (or any other part of the paperdoll), it is fully up to the modder to decide.

No, it's the complete paperdoll, not just the torso.

What values determine the appearance on battlescape?  Is battlespace appearance computed automatically from the "paperdoll" model?

Feature implemented in OXCE 5.1

You can now define any number of layers you want to use in your mod.
It's the same number of layers for each paperdoll, so give it a little thought at the beginning, or you'll have to rework your ruleset if you decide to add a new layer somewhere in the middle later.

Furthermore, each layer can not only use its own sprites, but also sprites from other paperdolls.
(only one sprite "set" per layer)

I admit the description is not very simple/easy to understand... maybe some ruleset examples will help:

Code: [Select]
  - type: STR_NONE_UC
    layersDefaultPrefix: HUMAN
      8: JUMPSUIT
      M0: ["", "", "M0_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M0_FACE", "", "", "", "", ""]
      M1: ["", "", "M1_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M1_FACE", "", "", "", "", ""]
      M2: ["", "", "M2_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M2_FACE", "", "", "", "", ""]
      M3: ["", "", "M3_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M3_FACE", "", "", "", "", ""]
      F0: ["", "", "F0_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F0_FACE", "", "", "", "", ""]
      F1: ["", "", "F1_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F1_FACE", "", "", "", "", ""]
      F2: ["", "", "F2_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F2_FACE", "", "", "", "", ""]
      F3: ["", "", "F3_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F3_FACE", "", "", "", "", ""]
    layersDefaultPrefix: HUMAN
      M0: ["", "", "M0_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M0_FACE"]  #trailing ""s are not needed
      M1: ["", "", "M1_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M1_FACE"]
      M2: ["", "", "M2_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M2_FACE"]
      M3: ["", "", "M3_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M3_FACE"]
      F0: ["", "", "F0_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F0_FACE"]
      F1: ["", "", "F1_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F1_FACE"]
      F2: ["", "", "F2_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F2_FACE"]
      F3: ["", "", "F3_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F3_FACE"]

Based on this, sprites with composite name will need to be defined.
First part is the "prefix" (e.g. HUMAN), then layer number (e.g. 8) and last sprite name (e.g. M0_FACE); they are separated by two underscores.

Code: [Select]
  - typeSingle: JUMPSUIT__8__M_JUMPSUIT
    fileSingle: Resources/LayeredJumpsuit/08-outer_clothes_armor_and_boots/male.png
  - typeSingle: JUMPSUIT__8__F_JUMPSUIT
    fileSingle: Resources/LayeredJumpsuit/08-outer_clothes_armor_and_boots/female.png
    fileSingle: Resources/LayeredPersonalArmor/08-outer_clothes_armor_and_boots/male.png
    fileSingle: Resources/LayeredPersonalArmor/08-outer_clothes_armor_and_boots/female.png
  - typeSingle: HUMAN__2__M0_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M0_male_blond.png
  - typeSingle: HUMAN__2__M1_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M1_male_brown.png
  - typeSingle: HUMAN__2__M2_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M2_male_asian.png
  - typeSingle: HUMAN__2__M3_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M3_male_african.png
  - typeSingle: HUMAN__2__F0_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F0_female_blond.png
  - typeSingle: HUMAN__2__F1_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F1_female_brown.png
  - typeSingle: HUMAN__2__F2_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F2_female_asian.png
  - typeSingle: HUMAN__2__F3_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F3_female_african.png
  - typeSingle: HUMAN__10__M0_FACE
    fileSingle: Resources/LayeredHuman/10-face/M0_male_blond.png
  - typeSingle: HUMAN__10__M1_FACE
    fileSingle: Resources/LayeredHuman/10-face/M1_male_brown.png
  - typeSingle: HUMAN__10__M2_FACE
    fileSingle: Resources/LayeredHuman/10-face/M2_male_asian.png
  - typeSingle: HUMAN__10__M3_FACE
    fileSingle: Resources/LayeredHuman/10-face/M3_male_african.png
  - typeSingle: HUMAN__10__F0_FACE
    fileSingle: Resources/LayeredHuman/10-face/F0_female_blond.png
  - typeSingle: HUMAN__10__F1_FACE
    fileSingle: Resources/LayeredHuman/10-face/F1_female_brown.png
  - typeSingle: HUMAN__10__F2_FACE
    fileSingle: Resources/LayeredHuman/10-face/F2_female_asian.png
  - typeSingle: HUMAN__10__F3_FACE
    fileSingle: Resources/LayeredHuman/10-face/F3_female_african.png

As you can see, we have added also a shorter way of defining single sprites.

The following definitions are equivalent:

Code: [Select]
  - typeSingle: HUMAN__10__F3_FACE
    fileSingle: Resources/LayeredHuman/10-face/F3_female_african.png

Code: [Select]
  - type: HUMAN__10__F3_FACE
    singleImage: true
    width: 320
    height: 200
    subX: 0
    subY: 0
      0: Resources/LayeredHuman/10-face/F3_female_african.png

I am also attaching a working sample, which you can try with xcom1... it replaces paperdolls for jump suits and personal armor.

PS: for big mods, this could cut down the number of paperdolls by 90% or more... and improve both loading time and memory usage... and most importantly time to create new paperdolls

Could you please suggest, where in the armor encoding the head is encoded?  Are these parts of definition (under the key layersDefinition, layersDefaultPrefix and layersSpecificPrefix) intended for torso only?

The X-Com Files / Re: The X-Com Files on Matrix
« on: March 30, 2023, 05:24:00 am »
If you play X-Com Files and want to chat about it, or just want to chat about it, here is a Matrix space:!

See you there!

It's great to see the Matrix presence.  Thank you for making it available.

I wonder, if there's also a chatroom available?  Any plans, if not?

The X-Com Files / Re: Starting problems: STR_HUMAN_SONIC_SHOTGUN
« on: March 30, 2023, 05:22:56 am »
The 'master' branch contains the latest OXC.

The naming is fine in my opinion, OXC is a "master mod" for OXCE :) And I can't rename it anyway (I think?).

The name of the repository is OXCE, and the general convention to have master branch refer to the project's current development state.  In case of OXCE, it should have been OXCE's current development state, not OXC's.

I also cannot add any files to the master branch, because then it wouldn't be a 100% copy of OXC and the merge history would start to look absolutely awful from the moment I add a first non-OXC commit. Already tried that some years ago, we really don't want that.

You may create a branch for OXC.  The issue is not the presence of a branch dedicated to OXC, but rather its name.

The merge history would not really look any different if branches are named differently.

Released Mods / Re: [WEAPON] New Heavy Weapons
« on: March 30, 2023, 05:16:12 am »
I've added new fields for custom short names in the ufopedia.


Code: [Select]
  - type: STR_RIFLE
      shots: 4
      name: STR_BIG_BOOM
      shortName: STR_BIG_BOOM_SHORT
      name: STR_SMALL_BOOM
      shortName: STR_SMALL_BOOM_SHORT
      shots: 2
      name: STR_SMALL_BOOM_X2
      shortName: STR_SMALL_BOOM_X2_SHORT

Code: [Select]
  - type: en-US
      STR_BIG_BOOM: "Big boom"
      STR_BIG_BOOM_SHORT: "Big (x{0})"
      STR_SMALL_BOOM: "Small boom"
      STR_SMALL_BOOM_X2: "Double boom"
      STR_SMALL_BOOM_X2_SHORT: "Small (x{0})"

Feature will be available in OXCE 7.4.1

I wonder if it is possible to provide kneeling and custom aiming bonuses to the specific shot configurations?

That is, is something like this possible:
Code: [Select]
  kneelBonus: 300
  arcing: true
    firing: 0.5
    psiStrength: 0.5

Suggestions / Re: Let custom .rul files live with options.cfg?
« on: March 30, 2023, 02:43:13 am »
You can add a "data" subfolder to your saves folder, and it will be treated same as the OpenXcom\data folder, so you can put your custom mods/etc without messing vanilla installation.

How would those definitions be added to the game?  I know, I need to specify mods to load in the menu, which reflects in the global config file.

OXCE Support / Re: Modding master mods.
« on: March 29, 2023, 10:23:57 am »
Stateless calculation of some values. Can you make that some Lua script will have absolute not effects aside from return value?
And it will be not some gentleman agreement but enforced requirement.
Why this is needed? because if I remove call to some script hook or add it in another place nobody can detect it and relay on it.
How would you refactor big code base if any change of order of some function would break every mod?

State could be eliminated by removing the primitives that enable sharing of state.

I mentioned a Clausewitz II design trap in my previous post, which is essentially a reflection on the mis-use of state in fully scriptable engines.  I am aware of that problem.

It seems that the current approach of well thought out static configuration semantics plus lightweight scripting works out decently well.  It seems to be enough for me to make meaningful submods.  Now, if I wanted to approach making a master mod, I would actually consider remaking the engine.  Actually, the desired system could be concocted with the aid of Lua, but the engine that would result from it all would be a totally different one -- not a small interpreter compatible with original X-Com semantics.  It's a topic for a very much different project.  Quite a bit beyond the domain of pleasant sub-modding.

OXCE Support / Re: Modding master mods.
« on: March 29, 2023, 10:22:20 am »
After Yankes implemented loops in y-scripts, I don't see any practical reasons to change it to Lua from modding perspective. It would be a huge time investment and I don't see the goal for that but to change scripting syntax. Would be much better to invest that time to expand y-script API with more gesocape hooks.
Also, I don't see a point - if "there could be only one", then what about backwards capability? Lots of mods are using y-scripts.
About syntax - yes, it can be intimidating, but you can use to it. Also, there is an extension made by Pedro to highlight y-scripts code, witch is very helpfull.

Concerning the language itself.  It does matter.  The current language is not satisfactory in a number of ways.  The one important conclusion that I would argue forth is that the current scripting is not suitable for sophisticated scripted logic.  Note that all the larger mods are not attempting to implement anything sophisticated with scripting.  And, as Yankees pointed out, this has not been the goal nor an intended application of the scripting engine.

However, that is largely irrelevant at this point in the grander scheme of things.  The reason for this is as follows.  All the larger mods have already made the use of scripting to produce a logic that is reasonably configurable through the config stanzas.  That is largely more than enough for modding.

Currently, the end result is adequate, and is well maintained.  It is also moddable.  This is what matters from the standpoint of enjoying the game.

I think, any significant improvement -- that includes (a significant improvement to ...) scripting -- would require ultimately nothing short of a rewrite.  I think that adding Lua, while possible, is not worth time, given that sub-modding could adequately be done without it.

I suggested Lua as a known and suitable option.  Ultimately, a future game engine should not be using such scripting engine, if only not to fall into the Clausewitz II (which is another game engine) design trap.

OXCE Support / Re: Modding collections (lists, maps).
« on: March 29, 2023, 09:45:03 am »
I think that your current mental model of ruleset OXC is so different to how OXC work that become unmatchable for me to anything in OXC.
What could even mean "no-op"? Especially in case of `costBuy`, this is simple numerical value, noting more, nothing less. If value is zero then item will not be available to buy. If you add some `requiresBuy` then it only can add to "not available", this mean both condition need be meet to have given item available to buy.

I see.  This matches my understanding.  It's a classical config file approach, and it seems that most values always exist, with well-defined defaults in case they're absent in the configuration.

The "no-op" means essentially a zero value, where zero is whatever makes sense in the context.  The "no-op" means that a value does not convey any properties to the object upon which it is applied.  If I moved by zero meters, then I did not move at all.  I assume, the analogy is rather obvious.

Pages: 1 ... 5 6 [7] 8 9 ... 14