Topics

1

OXCE Support / The interaction between damageModifier, ArmorEffectiveness, and shields.

« on: May 31, 2023, 01:31:07 am »

I would like to get a more precise understanding on how the damageModifier on armor and ArmorEffectiveness on a weapon interact.  The full picture would ideally include the understanding of how shields work in this setting.

I see that in XCF shields are implemented as scripts that modify the damage, and perhaps the issue of shields is not a part of the OXCE mechanics proper.  Currently it appears that shields are just scripts that run as hooks whenever an incoming damage arrives.  One of their outputs is the amount of damage to pass through to the armor.  Is that a precise perspective?

Is there a general consensus on how shields should operate?  The question of particular interest is whether their resistances (the reductions, like e.g. 0.5 HE for gold shield) should be applying to whatever damage they encounter after the shield itself is depleted?

Another question is whether the damageModifier set on an armor applies to a weapon damage with an ArmorEffectiveness not equal to 1.0?  Would the damageModifier be applied only while the armor itself is non-zero?  Would the damageModifier apply if the ArmoreEffectiveness is set to 0.0?

Let's consider a more specific example.  What would be the fraction of damage passing through the armor in the following situations:

ArmoreEffectivess = 0.0 , damageModifier = 1.0 (my guess: 100%; none of the damage would need to interact with armor)
ArmoreEffectivess = 1.0 , damageModifier = 1.0 (my guess: 0%; all of the damage would need to interact with armor)
ArmoreEffectivess = 0.0 , damageModifier = 0.0 (my guess: 0%, i.e. completely blocked)
ArmoreEffectivess = 1.0 , damageModifier = 0.0 (my guess: 0%, i.e. completely blocked)
ArmoreEffectivess = 0.5 , damageModifier = 0.5 (my guess: 25%, while the remaining 75% would need to interact with armor)

2

OXCE Support / Modding collections (lists, maps).

« on: March 26, 2023, 11:18:57 pm »

I would like to create two mods that add ammunition to a weapon in a vanilla game, along with some other items specific to each mod.

A question is, how could this be accomplished with current configuration interpretation semantics.

Currently, there exists a definition

  - type: STR_SMALL_LAUNCHER
    compatibleAmmo:
      - STR_STUN_BOMB
      - STR_ELERIUM_BOMB
      - STR_EMP_BOMB

which corresponds to configuration

{ { type : "STR_SMALL_LAUNCHER" ,
      compatibleAmmo: [ "STR_STUN_BOMB" , "STR_ELERIUM_BOMB" , "STR_EMP_BOMB" ]
   },
   # ...
}


I would like to provide additional definitions, along the lines of

  - type: STR_SMALL_LAUNCHER
    compatibleAmmo:
      - insert: STR_MEGA_BOMB
      - insert: STR_GIGA_BOMB

in one mod and also

  - type: STR_SMALL_LAUNCHER
    compatibleAmmo:
      - insert: STR_GIANT_BOMB
      - insert: STR_ULTRA_BOMB

in another mod in order to yield the following configuration:

{ { type : "STR_SMALL_LAUNCHER" ,
      compatibleAmmo: [ "STR_STUN_BOMB" , "STR_ELERIUM_BOMB" , "STR_EMP_BOMB",
      "STR_MEGA_BOMB", "STR_GIGA_BOMB", "STR_GIANT_BOMB", "STR_ULTRA_BOMB" ] },
   # ...
}


What is the best way to accomplish that?

3

OXCE Support / Modding master mods.

« on: March 26, 2023, 11:00:10 pm »

I would like to consider the issue of creating modifications to larger mods.

For example, I would like to add some additional ammunition types to existing weapons in the XCF, as well as to add a player class, and adjust some armors.  Conceptually, the problem is relatively simple: it requires that some data nodes be inserted into the existing configuration node tree, and in some cases collections in existing paths would need to be appended to.  While these particular modifications do not require deletions, it would in general be desirable to have these capabilities available.

Now, it is entirely not clear how to implement these changes.  The primary issue is as follows.  Let's consider an approach of copying the entire .rul files from the parent mod and editing them.  If the files in the parent mod change, then new instances in the child mods need to be generated.  This at the very least requires dependency on specific parent version, as well as introducing additional maintenance and release hurdle.  Even worse, the dependency on what set of modules is being loaded would be introduced.  That is, if other mods make changes to the same files, then the changes should be made against versions in these mods.  Not only this complicates the maintenance, but also makes modding much less flexible.  In particular, it would be quite challenging to have two mods with each adding an individual weapon.

The question is, how to solve this problem.

First, I would like to understand what is the exact semantics associated with adding new ruleset definitions in child mods?  Is this semantics dependent on the names of the files?  Is it only dependent on the total contents of all YAML definitions in all of the files (and thus the file name are actually irrelevant)?

I would like to consider several approaches, and to get clarifications.

First, is patching the files from the parent mode directly.  This requires ability to depend on exact version, and introduces issues with flexibility.

A partial solution to the previous issue would be to have a single mod contain several instances that would apply based on what parent mods versions are installed.

Another approach is to enable some form of patching of definition trees.  There are some extensions to YAML that allow that.  Approaches not based on these YAML extensions could be considered.  Specifically, a set of commands along the lines of

DELETE /armors/type:STR_GRAVMODULE_ARMOR_UC/
DELETE /armors/type:STR_ALIEN_BRAIN_ARMOR/
INSERT /items/type:STR_SMALL_LAUNCHER/compatibleAmmo/ /mymod/items/type:STR_SMALL_LAUNCHER/compatibleAmmo/

could be issued in mods.

I noticed that currently, it seems that there are provisions for issuing a delete directives.  I wonder, how could insertions be made in a sound fashion?  I think, a sound approach may be to utilize an existing YAML feature of tags, and to have the definitions in mods be tagged accordingly.  That is, if currenly a default action is to REPLACE, a special tag could indicate that the action should be to MERGE instead.

I wonder, if the latter approach is implemented already?  If so, I would appreciate some documentation reference.

In terms of engine semantics, I would like to consider an approach based on interpretation of configuration within the existing parsing semantics.

So, currently, there's an ability to add list nodes like

  - delete: STR_LASER_PISTOL
  - delete: STR_LASER_RIFLE
  - delete: STR_HEAVY_LASER
  - delete: SILACOID_WEAPON
  - delete: ZOMBIE_WEAPON
  - delete: REAPER_WEAPON
  - delete: CHRYSSALID_WEAPON


I would like to have the ability to define in addition to that something like

  - type: STR_SMALL_LAUNCHER
    compatibleAmmo:
      - insert: STR_MEGA_BOMB
      - insert: STR_GIGA_BOMB

in one mod and also

  - type: STR_SMALL_LAUNCHER
    compatibleAmmo:
      - insert: STR_GIANT_BOMB
      - insert: STR_ULTRA_BOMB

in another mod.  A final result should be the following configuration:

{ { type : "STR_SMALL_LAUNCHER" ,
      compatibleAmmo: [ "STR_STUN_BOMB" , "STR_ELERIUM_BOMB" , "STR_EMP_BOMB",
      "STR_MEGA_BOMB", "STR_GIGA_BOMB", "STR_GIANT_BOMB", "STR_ULTRA_BOMB" ] },
   # ...
}

4

OXCE Bugs / How to report a segfault? Which release to build?

« on: March 25, 2023, 11:38:03 pm »

I have attempted to build a release based on commit 1f93586a07c19d4629aba9bad95ffa12e7110fbe.  I used the following command to generate makefiles:

cmake -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_PACKAGE=OFF .

I got a segfault when attempting to play a battlescape from the main menu, for the purposes of testing.

[25-03-2023_14-22-52]   [FATAL] A fatal error has occurred: Segmentation fault.
[25-03-2023_14-22-52]   [FATAL] openxcom(OpenXcom::CrossPlatform::stackTrace(void*)+0x26) [0x55e22ddf4776]
[25-03-2023_14-22-52]   [FATAL] openxcom(OpenXcom::CrossPlatform::crashDump(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x3f8) [0x55e22ddf5138]
[25-03-2023_14-22-52]   [FATAL] openxcom(signalLogger(int)+0x31) [0x55e22dbd1a51]
[25-03-2023_14-22-52]   [FATAL] /lib/x86_64-linux-gnu/libc.so.6(+0x3bf90) [0x7f974429af90]
[25-03-2023_14-22-52]   [FATAL] openxcom(OpenXcom::Map::drawTerrain(OpenXcom::Surface*)+0xf63) [0x55e22dd949f3]
[25-03-2023_14-22-52]   [FATAL] openxcom(OpenXcom::BattlescapeState::init()+0xc8) [0x55e22dd44128]
[25-03-2023_14-22-52]   [FATAL] openxcom(OpenXcom::Game::run()+0xc0) [0x55e22de1bef0]
[25-03-2023_14-22-52]   [FATAL] openxcom(main+0x140) [0x55e22dba0990]
[25-03-2023_14-22-52]   [FATAL] /lib/x86_64-linux-gnu/libc.so.6(+0x2718a) [0x7f974428618a]
[25-03-2023_14-22-52]   [FATAL] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f9744286245]
[25-03-2023_14-22-52]   [FATAL] openxcom(_start+0x21) [0x55e22dba6ff1]
[25-03-2023_14-22-56]   [FATAL] OpenXcom has crashed: Segmentation fault.

As for the data, I copied over the "standard" and "common" directories into my ".local/share/openxcom" from the release under bin/ (logs indicate this directory is used, so ok).  I copied over TFTD and UFO data from a previously working openxcom release, under the same .local/share subdirs.  So, no issues are expected with data.

As you could see, the segfault message is not entirely helpful.  I do not feel like tracing a C++ code with gdb at this moment.  I could contribute some code in a safe language (rust, any functional stuff, etc.), but that is a much larger undertaking anyway, and this needs to be done collaboratively anyway.

A question is, what release should I in general be building?  Which ones should I expect to work?  The tag "v1.0" dates from 2014, which is a tad too old.

Should I use a master branch, perhaps?  Why?  Could you please suggest which recent branch or commit I could use and expect a reasonable outcome?

UPDATE The master branch at release 6b96200e1abfdea1d0215cd5cefeae7b51f2b99f seems to work.  I'll test further, and see if the full XCF runs fine with it or not.

5

The X-Com Files / Consideration for Zrbite use in crafts.

« on: August 23, 2022, 07:58:43 am »

Since Zrbite becomes a later game commodity available for purchase, and since it is both a fuel and a catalyst in the ion beam accelerators, it stands to reason that it could serve both as a component and fuel in advanced atmospheric, and also near space engines.  Note that the article about STARFIGHTER also mentions its advanced ion engines.

I think that the more advanced crafts should be able to use Zrbite as a fuel, and still have their excellent stats.  Those are essentially even better hypersonic variants of the hypersonic THUNDERSTORM vessel.  The latter should be understood as operating at the limit of accessible high energy chemistry, without the essential use of alien propulsion tech.  Therefore, a slight extension of this tech with ion beam accerators should yield a more advanced hypersonic craft.  The TORMENTOR fits the profile.

It stands to argue that the space-capable crafts that rely on modulation of gravity waves, of which AVENGER and LIGHTNING are presumably one such examples of, should still rely on Elerium for fuel.  However, anything atmospheric and oceanic, like Dropship and Tormentor, should rely in general on Zrbite.

6

The X-Com Files / Considerations for the THUNDERSTORM craft configuration options.

« on: July 29, 2022, 05:42:51 am »

Currently, the THUNDERSTORM craft is the only one that has these three properties:

• a speed sufficient to intercept most smaller UFOs (in could be argued that speeds over 4000 could not be attained without consumption of Elerium / Zrbite)
• enough armor to withstand — and to have an option to withdraw from battle in time without suffering annihilation — a confrontation with a heavy UFO (like a cruiser, terror ship, or a battleship)
• has no requirements for irreplaceable fuel items (like Zrbite or Elerium-115)

These qualities make it an excellent candidate for a general-purpose interceptor craft, with (3) being a critical factor for a craft to be a general-purpose one.

At this time, the only armament available for a THUNDERSTORM is a 2x heavy missile.  Such armament enables the use of a THUNDERSTORM in the heavy interceptor role, whence a pair of THUNDERSTORM crafts armed with 2x heavy STORMLANCE missiles, could in general shoot down a heavy UFO that flies in a patrol pattern at a lower speed.

At this time, there exists no option to utilize THUNDERSTORM with 2x cannon weaponry.  The takedowns of most smaller vessels — and even of terror ships — are feasible with 2x GAUSS CANNON weapons.  The use of STORMLANCE missiles, that require irreplaceable Elerium-115 resource, is wasteful for such targets.

The only other craft with the closest capabilities to THUNDERSTORM, that satisfies (3), and also has the capacity to field 2x cannon weaponry is the RAVEN.  The RAVEN lacks in both speed an armor, thus making itself as less-than-viable option for any missions that require support with larger vessel takedowns.

The only other craft that has nearly enough speed to consistently intercept the fastest alien vessels, including the most powerful ones, is the TORMENTOR.  This craft is capable of carrying 2x heavy missiles, and 1x cannon weaponry.  A pair of TORMENTOR crafts launched either from different bases, or even the same base, and armed with STORMLANCE missiles, could conceivably take down a single battleship, and at the same time be able to disengage from battle when necessary.  In special cases, the TORMENTOR may serve as rapid interceptor for smaller targets.  However, it is not fit for a general purpose interceptor duties, even when only armed with a single cannon, since it does not satisfy (3).

All of these observations suggest that a niche for a reasonbly fast general purpose interceptor, satisfying (1), (2), and (3) exists.  Currently, THUNDERSTORM fits this niche, but with the limitation that only weapons available to it are missiles.  Given the particular efficiency of the latter cannon weaponry (particularly GAUS CANNON), it would be a waste to ignore the opportunity to use those on a fast general purpose interceptor.  The TORMENTOR already has slots for a cannon, so it could be argued that such weapon system is suitable for a fast-moving aircraft.

As one option, I would like to request that a version of THUNDERSTORM be added that supports 2x cannon weaponry, in place of 2x heavy missiles.  It could be called THUNDERSTORM-K, for instance.

Please allow me to offer the following additional considerations.  The GAUSS CANNON is much more efficient than an equivalent STINGRAY, since it has a higher damage per shot, which plays role when penetrating shielded targets.  Thus, a craft armed with GAUSS CANNON, or a missile with higher damage output, would be much more efficient than the one armed with STINGRAY.

Please note that there exists a missile with a damage output equivalent to a GAUSS CANNON.  This missile is PIKE.  If it was available in a heavy missile bay, with increased, it would be a good replacement for the capabilities of a GAUSS CANNON on a general purpose interceptor.

It could be argued, that the presence of cannons is not suitable on a THUNDERSTORM, due to considerations of its engine technology and maneuverability constraints, etc.  In such case, a good replacement for the GAUSS CANNON is appropriate.  For the sake of balance, the replacement should have the same damage potential as the full STINGRAY bay.  For the PIKE missiles to have the equivalent damage potential to 12 STINGRAY missiles, a magazine of 8 would suffice.

Thus, as another option, I would like to request that a version of PIKE launcher would be added that fits into the heavy missile bay, with a magazine increased to only 8 or 9, istead of doubling it to 12, as was done with STINGRAY.  Perhaps, a slight decrease in reload time could be considered for this case, though optionally.  This could be considered as a GAUSS CANNON replacement for vessels less suitable for offensive close engagements.

Both of these options are interesting, and are consistent with the lore, and are well-balanced.  I am also interested in a discussion of these possibilities.

7

The X-Com Files / Sonic munitions disassembly for Zrbite.

« on: July 28, 2022, 04:53:11 am »

I would like to inquire, if it is possible to disassemble sonic ammunition for Zrbite?  My survey of the tech tree, both trough the middle click, and through the wiki (at the https://xcf.trigramreactor.net) had yielded no result.  It appears that at this point in the game, it is only possible to disassemble the plasma weaponry ammunitions for Zrbite, but not the sonic weaponry.

This situation is less than ideal, since there exists a craft that uses Zrbite, and some of the earlier sonic weapons are not being as useful as the game progresses.  Ideally, the munitions for the lighter weapons should be recyclable to both advanced craft fuel and to heavier munitions.