Messages

91

Released Mods / Re: [FACILITY] Improved Living Quarters - Now With Pictures

« on: May 30, 2023, 12:31:22 am »

yes please big stores and posablt 2x1 labs and workshops ?

Lab complex could be 2x2.  The caveat is that the labs are usually built incrementally.
The complex could even be 3x3, and accommodate 200 scientists.  Along with adequate defense and containment facilities, the base would 3 extra cells.

Should HQ be a part of the 3x3 lab complex?  Advanced Intelligence Lab?

92

Released Mods / Re: [FACILITY] Improved Living Quarters - Now With Pictures

« on: May 30, 2023, 12:23:22 am »

I agree with the Mars Attack craft... should contain creature comforts, bridge et al, but be not very good to use on Earth.

Meanwhile, I've made sort of template for drawing new 2x2 facilities, with spaces for all 8 potential doors left. Little gray pixels mark cutoff points.

If the craft in question is a military attack craft (which Avenger really is), then it needs not large accommodations.  In terms of lore, it might as well have very comfortable grav-seats if the flight takes more than a day (which it does not necessarily need to, given its use of alien propulsion tech).  In general, the military attack crafts are well packed.  A modern military transport airplane or with paratroopers or a helicopter with a squad of troops is an example.

93

OXCE Suggestions DONE / Re: [DONE][Suggestion] Access to object counters within Arc/Mission/Event scripts

« on: April 23, 2023, 06:50:02 pm »

I don't fully grasp counters. Are there examples of them implemented?
I'm thinking of using them to simulate alien infiltration level of human factions, but I need to understand better how they work.

They're global variables, operated by triggers at designated points, specified by constructs like increaseCounter and decreaseCounter in the config.

94

OXCE Suggestions DONE / Re: [DONE] Sharing tag defintions between multiple ruleset files

« on: April 23, 2023, 06:44:10 pm »

In OXCE 7.8.9 I added option to share tags definition between files:

Code: [Select]

extended:
  tagsFile: Ruleset/OtherFile.rul

this effective copy `tags` from other file and insert them in current file.

Thank you for including this functionality.  Could you please provide more details on how this works?  Currently, there's nothing in the Nightly Ruleset Reference.

I also would like to inquire, how did you overcome a limitation of YAML, that requires every data item to be present explicitly somewhere in the graph corresponding to the parsed file.  Did you define a special naming convention?

95

OXCE Suggestions DONE / Re: [DONE][Suggestion] Additional item trigger for mission scripts

« on: April 23, 2023, 06:41:04 pm »

It's AND.

None of your options is correct.

The example above means "STR_FACILITY1 is present somewhere among all bases AND STR_FACILITY2 is not present in any base".

Thank you for clarifying this.

I wonder, if it could be possible to check by the BaseFunc type?  E.g. if I had two types of psi labs, how could I depend on e.g. an ADVPSILAB?  I know that I could in principle for each event (scripted ones, through configuration only, without invoking a script engine) provide two entries, each checking for a specific building type.  However, is there a better solution?  Checking by BaseFunc would be much more streamlined and would avoid duplication of entries (which is not optimal in general, even with anchors, etc., especially in extension points).

96

OXCE Suggestions DONE / Re: [DONE][Suggestion] Additional item trigger for mission scripts

« on: April 23, 2023, 10:19:38 am »

Added one more attribute (in OXCE v6.5).
Similar to research and item triggers, there are base facility triggers.

Code: [Select]

missionScripts:
  - type: xxx
...
    facilityTriggers:
       STR_FACILITY1: true
       STR_FACILITY2: false

Facilities from all bases are considered.

What is the conditional in the facility triggers?  Is it AND or an OR?  In other words, do STR_FACILITY1 and STR_FACILITY2 need to be both present somewhere among all bases?  Or, perhaps, the interpretation is that either of STR_FACILITY1 and STR_FACILITY2 needs to be present somewhere among all bases?

97

OXCE Support / Re: [Solved] Manufactured soldier names issue

« on: April 20, 2023, 05:17:09 pm »

No

Ok.  Thank you for sharing this.

If I wanted to spawn multiple characters, do I need to launch several events?  Could I spawn them in separate events, all happening in the same day, and ideally simultaneously?

98

OXCE Support / Re: [BUG] Manufactured soldier names

« on: April 20, 2023, 03:31:10 am »

Define the name under:

Code: [Select]

spawnedPersonName:

instead of

Code: [Select]

spawnedSoldier:


For example:

Code: [Select]

manufacture:
  - name: STR_THEBAN_ASSAULT_CLONE
    spawnedPersonName: Клон-штурмовик
    spawnedSoldier:
        nationality: 20
        rank: 1
        armor: STR_PEASANT_ARMOR_BIOAQUA_EVA_UC
        initialStats:
          tu: 70
          stamina: 100
          health: 45
          bravery: 90
...


Is it possible to spawn more than one soldier this way, all within a single event, and to supply each with an individual name?

99

Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]

« on: April 11, 2023, 06:43:41 pm »

Stunned celatid clone unit cannot be recovered alive, because the corresponding geoscape item is missing.

You can fix the mod by adding an item like this:

Code: [Select]

  - type: STR_CELATID_CLONE
    size: 0.0
    recover: true
    liveAlien: true
    costSell: 40000


Is there a way for me as a modder to know which specific frames in a given pck are missing?  Currently, the debug message states only that some frames are missing, but does not say which.

100

OXCE Suggestions DONE / Re: Starting conditions (was: Enviros)

« on: April 10, 2023, 10:40:51 am »

INFO: There will be a breaking change in the next version.

Default armor will be a weighted list, instead of just a single entry:

Old syntax:

Code: [Select]

    defaultArmor:
      STR_SOLDIER: STR_SPACE_SUIT_UC

New syntax:

Code: [Select]

    defaultArmor:
      STR_SOLDIER:
        STR_SPACE_SUIT_UC: 50 # 50% space suit
        STR_ANNIHILATOR_ARMOR_UC: 25 # 25% annihilator suit
        noChange: 25 # 25% to keep whatever you have on


Is there a way to have an agent removed if a desired armor type is not available for him in the inventory?  A possible case is to require diving suits to be in inventory before they could be used in an underwater mission.

101

OXCE Support / Re: Best mods for OXCE 2023?

« on: April 01, 2023, 01:26:38 am »

The quoted list are just my personal top 3, it's nothing official.
XcomFiles is not there, because I don't like it.
Many other people like it, and it could even be on place 1 for some people.

XCF loosely contains FMP, but it's a completely different experience than playing just FMP.

Than you for sharing this.  I am looking for a good mod to play-through and to have even better experience than with XCF.

Could you please suggest which mods have all of the following?

• Highly devious, smart, and sneaky, extremely evil AI.
• Advanced intermediate crafts like Thunderstorm fro XCF.
• Advanced armors like Shock Armor and Juggernaut Armor from XCF.
• Ideally both land and oceanic bases.
• Sophisticated, well developed story in which both cyborg and psi lines are included.
• Tactically, have shields available that work on top of armor (like e.g. Ethereal's Grand Master in XCF).
• Large tactical maps.

102

OXCE Support / Re: Modding collections (lists, maps).

« on: April 01, 2023, 01:17:10 am »

Do we discuss OXCE or some theoretical data processing? I here to answer question for former not latter.
If you want simplified model how OXCE work I can provide it:
We start with yaml file:

Code: [Select]

fooA: "X"
fooB: "Z"
fooC: 123
And you have struct in code:

Code: [Select]

strict Data
{
   std::string fooA;
   std::string fooB;
   int fooC;
};
Then loading is function that is called for each loaded yaml file:

Code: [Select]

void load(Data& d, const YamlFile& f)
{
    if (f["fooA"]) d.fooA = f["fooA"].as<std::string>();
    if (f["fooB"]) d.fooB = f["fooB"].as<std::string>();
    if (f["fooC"]) d.fooC = f["fooC"].as<int>();
}

And there is nearly noting aside from that. With this you can understand most of OXC or OXCE loading of rulesets.
Again, if you want have copy of some item from master mod you need manually copy it yourself. I do not plan add any functionality that would allow copy existing rule objects under different name.

So, the algorithm is as follows:

1. Read config at current point.
2. Apply config data directly to a global object.
3. Advance cursor in (1).  If cursor points to the end, terminate.


Is that what is happening in the OXCE?

103

OXCE Support / Re: [QUESTION] maxDistance, aimDistance etc. for ammo

« on: March 31, 2023, 06:12:38 pm »

I assume you mean maxRange and aimRange, not maxDistance and aimDistance.

If yes, those attributes can only be used on a weapon, not on ammo.

PS: StatsForNerds always show all attributes for all kinds of items, they don't say if such combination makes sense or not.

I wonder if those attributes are configurable per shot type.  E.g. confAim, confAuto, confSnap?

104

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 mod.io, and playing through the whole XCF oncee.

105

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.