aliens

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.


Topics - zee_ra

Pages: [1]
1
The X-Com Files / How to handle laser rifle clips?
« on: December 06, 2023, 12:31:30 pm »
I have noticed that currently laser rifle clips are set to be disassembled for E-115 like their plasma counterparts.  I wonder, if that is an oversight, or a deliberate design decision.  Ideally, I would like to be able to convert clips (e.g. if I really love portable laser cannon / PLC, and would like to transform all of those Alien Laser Rifle clips into PLC clips).  I think that such conversion should be possible.  Question is, whether it needs to involve going through E-115 and then back, or perhaps the laser clips should be broken down into something like "laser clip components / pieces".  What are your thoughts?

2
The X-Com Files / Firearms vs. heavy armor
« on: November 19, 2023, 10:58:16 pm »
I wonder, how could we deal with the fact that BlackOps auto-sniper rifle, when used by a soldier with really high accuracy, using default bullets could demolish in 2-3 auto bursts an enemy wearing Power Suit or Shock Armor?  Should there be a cap on the maximum damage for a given weapon, regardless of how high a damageBonus may be?

I see the following ways to fix this situation:
  • Increase armorEffectiveness to for all human rifle shots.
  • Increase kinetic resistance on all armors starting with Power Suit (thus, to enumerate all: Power Suit, Shock Armor, Jugernaut Armor).
  • Adjust OXCE to provide a special configuration option that would limit maximum total damage.
    E.g. maxPower defined either at the level of a weapon or a clip.
  • Make the shot power vary on a curve.  Probably, a pretty flat inverted parabola would work best.
    However, it would complicate the damage definition formula visible in Ufopaedia a bit, making it slightly counter-intuitive.
  • Perhaps, (1) and (2) should be used together.  Thus, increase armorEffectiveness and armor resistance against kinetic.  (If this creates a slight disbalance with weaker armor types, then either (a) adjust resistance of the weaker armors against kinetic to a lower value, or (b) increase slightly damage multiplier for a munition.  However, for a genuine AP bullet, there's no need to increase the multiplier, and the increase in power should come from switching to a more armor-piercing TT variant anyway.)
  • Increase the power armor resistance against kinetic by lowering the damage modifier to 0.6-0.7, and also increase the armor penetration of gauss and mass driver weapons by lowering the armor effectiveness modifier.  Keep the rest intact.

I think, option (6) would be a best approach.

Also, the tile damage for the lower caliber sniper guns seems to be excessive.  For instance, having the auto-sniper rifle remove a section of a brick barn wall is a bit excessive.  It's much more appropriate to have a larger-caliber M82 accomplish that.  So, for lower-caliber sniper guns we should probably have something like damageAlter.ToTile: 0.1.

3
OXCE Support / Blast radius calculations in OXCE
« on: November 18, 2023, 01:34:45 am »
I would like to start using dynamic radius more widely in a mod that I am working on.  I would like to inquire, how is the dynamic blast radius calculated as a function of damage power?  Would it be possible to post a table of this somewhere on the wiki?  The table is going to be much more useful than a direct formula.

The forum search reveals little w.r.t. this issue.

4
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)


5
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?


6
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" ] },
   # ...
}









7
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.

8
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.

9
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.


10
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.

Pages: [1]