Messages

1

Work In Progress / Re: [WIP][MOD][OXCE] From the Apocalypse 0.30.4

« on: January 28, 2025, 01:00:20 am »

If you are want you can either take the zip above or apply this patch file to get 8.0 compatibility. Or I can also create a pull request assuming there is a public repo. Up to you.

Code: [Select]

# make a commit to return to and then run this in (git) bash
git apply FtApoc_diff_8.0.patch
# the patch file also includes a few validations/bug fixes


2

Work In Progress / Re: [WIP][MOD][OXCE] From the Apocalypse 0.30.4

« on: January 27, 2025, 09:03:44 pm »

Had a bit of time so I figured I fix a few things to make FtApoc 8.0 compatible. Fixed a few other things with the Ruleset Validator too.

Code: [Select]

    few issues in extraSprites remain
    duplicate for BIGOBS.PCK index 105
    duplicate for BASEBITS.PCK index 166

Edit: correct attachment

3

40k / Re: [ADDON] ROSIGMA

« on: January 08, 2025, 09:21:59 pm »

I cannot follow where the _1/2 files are coming from. They are not referenced and the files without the _1/2 work as intended. We don't have _1/_2 as part of our naming convention.

For example VH_SINGLETURN is used for the "VALKYRIE DROP TRANSPORT" and "TAUROS" (names for new battle). What I can see is that they are used at different positions.

Code: [Select]

  - type: STR_VALKYRIE_GRAV_DROP  # VALKYRIE DROP TRANSPORT
    battlescapeTerrainData:
      name: GUARD_GRAV_DROP_HWP
      mapDataSets:
        - BLANKS
        - GUARD_GRAV_DROP
        - VH_SINGLETURN            # index 1 (assuming BLANKs doesn't count)
...

  - type: STR_TAUROS  # TAUROS
    battlescapeTerrainData:
      name: TAUROS_DROP_PLUS_FOUR
      mapDataSets:
        - BLANKS
        - TAUROS_036
        - GUARD_GRAV_DROP
        - VH_SINGLETURN            # index 2 (assuming BLANKs doesn't count)


But that explanation can't be it. ARVUS_DOORS are used for three crafts at the same index and the TAUROS_036 is only used once in the entire mod. They are also not part of the 40k mod.

---

This is what I get when I search the files in the current release on mod.io (rosigma28a-aizk.zip)

Code: [Select]

rosigma/TERRAIN$ find | grep -E "ARVUS_DOORS|GUARD_GRAV_DROP|REPULSOR|TAUROS_036|VH_SINGLETURN" | sort  # left out the CHIMERA intentionally
./ARVUS_DOORS.MCD
./ARVUS_DOORS.PCK
./ARVUS_DOORS.TAB
./GUARD_GRAV_DROP.MCD
./REPULSOR.MCD
./REPULSOR.PCK
./REPULSOR.TAB
./TAUROS_036.mcd
./TAUROS_036.pck
./TAUROS_036.tab
./VH_SINGLETURN.MCD
./VH_SINGLETURN.PCK
./VH_SINGLETURN.TAB


GUARD_GRAV_DROP missing a PCK/TAB is fine, because it draws it from the 40k mod.

In short all files seem to be here and everything is in perfect order.
Can you explain where this information is coming from? (edit: just saw the message in Matrix)

[Spoiler]

4

OXCE Support / Re: Mutual Surprise Rule - Sidestepping (OXCE 8.0 Regression Defect?)

« on: January 02, 2025, 03:11:30 pm »

Previous Answer; nevermind that.

Spoiler:

However, if Lucas sidesteps to the entrance of the barn they won't get shot at even tho their reaction score should be almost non-existant

I get reaction shots here. No idea why I get different behaviour. I tested with fresh installs (extract OXC/OXCE, put in UFO+TFTD, enable Alternative Movement Method, enable debug in options.cfg), tried with and without debug used.

I ran multiple versions now and that's my truth table for sidestepping drawing reaction fire with Lucas in the above mentioned savegame.

Code: [Select]

OXC 1.0.587102a15-dirty (Linux)                       - no reaction
OXCE 8.0.0 (v2024-12-27) (Linux)                      - reaction
OXCE 8.0.0 (v2024-12-30) (Windows 7)                  - reaction
OXCE 7.15.0 (v2024-11-01) (Linux)                     - reaction
OXCE 7.13 (v2024-07-26) (Linux)                       - reaction

What I found interesting is that I get a different sequence of animations in OXC (torso stays towards west/the enemy while walking) compared to OXCE (turn north/towards walking direction, walk, turn west/towards enemy)

@CrazedHarpooner, what is your sequences of walking/turning animations?

Any ideas what I could try?

Conclusion:
I am pressing CTRL+SHIFT+Left click and that breaks the mutual surprise rule. If I only press CTRL+Left click it works 
OXC doesn't care about the SHIFT button and it works either way.

5

OXCE Support / [Solved] Mutual Surprise Rule - Sidestepping

« on: January 01, 2025, 11:30:50 pm »

Since Alternative Movement methods is part of the OXC tab, I think this belongs here.

Does sidestepping work with the Mutual Surprise Rule? I got the situation in screenshot 1 (after CTRL+D)

When I move the unit directly forward (TU cost 8, red arrow), the soldier has a higher reaction score and no shots are fired. When I move the yellow arrow, I always get the mutual surprise rule (TU don't matter). But if I take one step along the red arrow (4 TUs), turn towards the alien (2 TUs) and then sidestep with CTRL+click (5 TUs, or 11 TUs in total), I get fired at due to a lower reaction score.

Is side stepping supposed to trigger the mutual surprise rule?

Mod is Multimod running with OXCE 8.0. You can also have a look at the attached video.


---

Edit: Sidestepping works as expected when using the latest stable (Extended-7.15.0-0f8616d83-2024-11-01-bionic-x86_64.7z)

Added a vanilla savegame (mutual surprise vanilla.sav). How to test: Waste some TUs. Step forward two tiles. Next time do that with sidestepping.

6

Released Mods / Re: [OXCE] XCOM Multimod

« on: December 29, 2024, 10:00:14 pm »

Cevaralien isn't around currently, so I made an update for OXCE 8.0 compatibility + a few bug fixes
# 1.10
- Fixed a few crashes
- Made Small Launcher consistent with Cevaralien's design
- New Battle works correctly now (soldier stats)

# 1.10a
- Added stats for nerds info for laser weapon batteries (rechargeable)
- Interceptors initially start with correct amount of fuel
- Made Stunrod consistent with Cevaralien's design
- Soldiers are correctly recruitable again (bug introduced in 1.10)

7

OXCE Bugs FIXED / Re: [BUG][OS-dependent] Yaml Multiline with (double) quotes crashes the game on Win

« on: December 29, 2024, 02:56:29 pm »

PS:
(and lastly, I will also update native Linux builds from Kubuntu 18.04 to 24.04 if possible... or is there a more popular distro nowadays? I read/heard somewhere something about Kubuntu being 'evil'... as all distros eventually will become in the eyes of the Linux community)

Short Answer:
I think Kubuntu is a good choice to continue with.

Long Answer:
I am not that deep in what the "Linux community" thinks to be "evil". In general I can say that Canonical (Ubuntu) needs to make some money at some point to cover their costs, so they try to commercialize it a bit more. Be it the Ubuntu Software Center (a store), selling professional support (kinda like Red Hat) or becoming relevant for the IoT market (Ubuntu Core). Debian is also seemingly becoming more commercial with the extended LTS (10 years) but it's a service provided by a different project (Freexian). KDE (Kubuntu) got a bit bad reputation for eating a lot of resources and not managing to get a stable environment while communicating badly a few years ago. No clue what's it like now.

I personally like Xfce as a desktop environment and use Xubuntu for ease of use. I personally don't like Unity (desktop environment, not the game engine), that's why I don't use Ubuntu. There is also Linux Mint which is ok. It's very popular for people starting out with Linux. For one of my old Thinkpads I am using Zorin OS but that's becoming slow too. Fedora and OpenSUSE I tried ages ago.

Ubuntu is also used a lot for docker containers (f. ex. in github workflows). For a server VM I would probably use anything that has apt like Debian or some kind of Ubuntu LTS with your favorite desktop environment and its applications. I would definitely NOT use anything that is a rolling release (Arch, Manjaro). Manjaro managed to corrupt my boot partition a few times. You can probably use Kubuntu as it's always beneficial that you are familiar with it and the KDE devs seem to have managed to make it stable.

8

OXCE Suggestions Y-script / Re: [Suggestion] Ability to BLIT objects by script.

« on: December 29, 2024, 01:20:05 pm »

Hi, I played around with the idea of blitting inventory sprites a bit as some ROSIGMA spriters kinda wanted to add visible taint on inventory sprites once specific research topics are researched (join Chaos).

The attachments show what came out of it working on a red eyes/doom face prototype. The proof of concept is using this branch. You may have to add a line to src/Battlescape/InventoryItemSprite.h:

Code: [Select]

#include <climits>


9

Work In Progress / Re: [TOTAL CONVERSION] [GLOBE] DUNE - Desert world 0.28

« on: December 28, 2024, 11:51:05 am »

Good points.
Increased version from 0.28 -> 0.29 and no .git folder

10

OXCE Bugs FIXED / [SOLVED] Yaml Multiline with (double) quotes crashes the game on Win

« on: December 28, 2024, 11:36:10 am »

Only affects Windows, doesn't happen on Linux (Xubuntu)

Running Extended-8.0.0-2e70fa97b-2024-12-27-win64 a multiline set up with (double) quotes will crash the game.
Our member Mercury reported it worked fine previously on Windows builds for the release candidate for rapidyaml builds (self-built). They were using a rapidyaml branch for testing 8.0.

Code: [Select]

  STR_GENERAL_STORES_UFOPEDIA: "All equipment,
    weapons systems, munitions, recovered material and Heavy Weapons Platforms are placed in stores, including equipment assigned to craft in hangars."

It works fine with a block scalar (both literal | and folded >)

Code: [Select]

  STR_GENERAL_STORES_UFOPEDIA: >  # or alternatively |
    All equipment,
    weapons systems, munitions, recovered material and Heavy Weapons Platforms are placed in stores, including equipment assigned to craft in hangars.

We (ROSIGMA) have changed from double quotes to block scalar for now as a stop gap measure.

11

Work In Progress / Re: [TOTAL CONVERSION] [GLOBE] DUNE - Desert world 0.28

« on: December 28, 2024, 11:06:19 am »

Fixed up version for OXCE 8.0

(Edit: Attachment removed)

12

Tools / Re: Ruleset Validator for VSCode v0.9.36

« on: December 26, 2024, 02:16:46 pm »

Thanks for fixing them  . I ran ROSIGMA through it and deleted all invalid rul syntax already.

As for the above I will try to take another poke at it later and ask Supsuper if I am not getting anywhere. For the curious I found that Spectral assumes a bit too much how yaml has to look (it takes JSON as a reference), so Parsing Options (incompatibleValues) need to be added to the bundled/dereferenced ruleset file to avoid some false positives.

13

Tools / Re: Ruleset Validator for VSCode v0.9.11

« on: December 25, 2024, 08:34:56 pm »

Different topic:

While linting ROSIGMA with yamllint I got to have a deeper look in the validation results produced by OpenXcom Ruleset Tools v0.9.35

There are results for four kinds of validations that seem to produce false positives
First three:

Code: [Select]

vaporColorSurface: {mod: 40k, index: 3}
vaporColor: {mod: 40k, index: 1}
moveSound: {mod: 40k, index: 828}
VS Code Result: Incorrect type. Expected "integer".
The reference says that this should be possible and the game works as expected.

Fourth:

Code: [Select]

customArmorPreviewIndex: {mod: 40k, index: 52}
VS Code Result: Incorrect type. Expected one of array, integer.

This can be an integer or an array for normal values. This works in the game as expected.

Would be great if those false positives could be looked at. Thanks.

14

Tools / Re: Ruleset Validator for VSCode v0.9.11

« on: December 21, 2024, 10:51:34 pm »

Hi,
I have been trying to create a github workflow for linting rul files and I don't get how some particular details work for the OpenXcom Ruleset Tools (vscode ruleset yaml validator).

For the purpose of creating said workflow I am using Spectral which gave the best results so far. Except that it can't deal with the recursive bits in the json files (vscode-ruleset/schemas). As a consequence it will create false positives as described below.

So far I understood that I need to merge the oxc bits into oxce-merge. That works well enough with the JSON merger.

Code: [Select]

// merger.js
// put it in vscode-ruleset/schemas/oxce-merge
// run with: node merger.js

const jsonMerger = require("json-merger");
const fs = require("fs");

var result = jsonMerger.mergeFiles(["AlienRace.json", "../oxc/AlienRace.json"]);
fs.writeFileSync("AlienRace.json", JSON.stringify(result, null, 2));

Inside the AlienRace.json there is a setting retaliationMissionWeights

Code: [Select]

//AlienRace.json > properties > retaliationMissionWeights
    "retaliationMissionWeights": {
      "$ref": "WeightedOptions.json#/definitions/Map"

and for WeightedOptions.json

Code: [Select]

{
  "$id": "https://openxcom.org/schemas/oxc/WeightedOptions.json",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "additionalProperties": {
    "type": "integer"
  },
  "definitions": {
    "Map": {
      "patternProperties": {
        "^\\d+$": {
          "$ref": "#" // <-------------- is this a circular reference to WeightedOptions.json ?????
        }
      },
      "additionalProperties": false,
      "type": "object"
    }
  }
}

When I use bundle or dereference of the node package @apidevtools/json-schema-ref-parser, the circular reference is either adapted with bundle in such a way that it persists and therefore Spectral ignores it or the dereference deletes the entry for retaliationMissionWeights altogether meaning that Spectral will try to use a standard value (string) to lint retaliationMissionWeights creating a false positive.

Is there something I am missing or do you have different ideas what I could try?

15

OpenXcom Extended (OXCE) / Re: Converting OXCE to rapidyaml

« on: November 30, 2024, 08:23:51 am »

You probably are testing with the ROSIGMA version on mod.io. Meridian was already kind enough to create a pull request to fix the major part of it. The Repo is here

Also I can confirm that the stack smashing error is gone.