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

Pages: [1] 2 3 ... 33
1
I wanted to write a long reply, but that would probably be counter-productive.
Long story short:
1. the suggestion as described cannot be done, the syntax is not a valid YAML
2. assuming (some other) valid YAML, `minPicks` is logically not doable, or at least not the way it's described
3. assuming (some other) valid YAML, `maxPicks` is doable, but it would complicate the code a LOT, probably not worth the effort

I tried to extract the gist of the request and came up with three requirements:
1. support more than one option per "item set" (in the request incorrectly called "tech level") -- Terminology on ufopaedia.org
2. add weights
3. (my own addition) support named "weapon sets" to cut down on copy-paste

Proposed new syntax is attached as picture.
Does that look useful?

Looks good! Should cover most use cases.

2
It would be nice if we could designate a set of loadouts/weapon sets that are randomly selected for a unit at each tech level, along with weighting values to make them more or less likely to be picked relative to other options at that tech level.

This would prevent us from having to messily kludge it by creating alternate versions/duplicates of the same unit simply for loadout variation.

Essentially adding the following parameters to builtInWeaponSets:

techLevel: Defaults to 1. The level of tech that this loadout is eligible for random selection in. If there are no loadouts eligible for a given tech level, it will default to selecting from eligible options for the tech level immediately prior (so if there are no techLevel 3 loadouts, it will default to techLevel 2 loadouts, and so on).

Weight: Defaults to 1. The relative chance of this loadout being picked if eligible for selection; final probability of a loadout being selected is equal to its weight divided by the total weight of all eligible loadouts. For example an eligible loadout with a weight of 50 while two other eligible loadouts have a weight of 30 and 10 would have a 62.5% chance of being selected: 50 / (50 + 30 + 10) = 0.625

maxPicks: Defaults to 0 (no limit). The maximum number of times this loadout can be picked. If a loadout hits its maximum, it can no longer be picked, and its weight is discounted for the purposes of determining pick probability.

minPicks: Defaults to 0 (no minimum). The minimum number of times this loadout can be picked. If the number of loadouts for a unit of this type remaining to be picked is equal to or less than the total amount of minPick loadouts for the appropriate tech level, it will automatically pick these options; they are prioritized according to weight. So if there are say 7 loadouts for a unit to be picked for a given tech level, and the total value of minPick loadouts is 5 (one loadout has a 3 minPick value, and another has a 2 minPick value), 5 of those loadouts will automatically be determined: 3 going to one minPick loadout, 2 going to the other minPick; the rest will be randomly determined by weights as normal. If there are only 4 loadouts to be picked and 5 minPick loadouts, they are randomly allocated from among the minpick options according to weight as normal; minPick loadout options that hit their quota from this pool are excluded from subsequent random allocations; in this example, if the loadout with a 2 minPick value is randomly selected twice, 'satisfying' it, the rest automatically go to the 3 minPick value loadout.

If there is only one loadout eligible for a tech level, it will be picked automatically regardless of the Weight value.

For example,

Code: [Select]
    builtInWeaponSets:
        techLevel: 1
        Weight: 30
        - STR_PISTOLS
        - STR_CHAOS_CLAWS
        - STR_PISTOL_CLIP_AP
        - STR_PISTOL_CLIP_AP
        - STR_ALIEN_GRENADE
        techLevel: 1
        Weight: 70
        - STR_PISTOLH
        - STR_CHAOS_CLAWS
        - STR_RIFLE_CLIP_AP
        - STR_RIFLE_CLIP_AP
        - STR_ALIEN_GRENADE
        - STR_KRAK_GRENADE
        techLevel: 1
        Weight: 30
        - STR_PISTOLS
        - STR_CHAOS_CLAWS
        - STR_PISTOL_CLIP_AP
        - STR_PISTOL_CLIP_AP
        - STR_ALIEN_GRENADE
        techLevel: 2
        Weight: 25
        minPicks: 2
        - STR_PLASMA_PISTOL
        - STR_CHAOS_CLAWS
        - STR_PLASMA_PISTOL_CLIP
        - STR_PLASMA_PISTOL_CLIP
        - STR_MGRENADE
        techLevel: 2
        Weight: 50
        - STR_PLASMA_RIFLE
        - STR_PLASMA_RIFLE_CLIP
        - STR_PLASMA_RIFLE_CLIP
        - STR_MGRENADE
        techLevel: 2
        Weight: 10
        maxPicks: 1
        - STR_MGRENADE
        - STR_MGRENADE
        - STR_MGRENADE
        - STR_MGRENADE
        - STR_MGRENADE

3
OXCE Suggestions OK / Re: [Suggestion] Dynamic Map Hazards
« on: February 04, 2023, 06:40:14 am »
https://openxcom.org/forum/index.php/topic,7671.0.html

This is not what I'm talking about; I'm talking about hazards, whether temporary or permanent that a weapon can dynamically create.

4
OXCE Suggestions OK / [Suggestion] Dynamic Map Hazards / Custom Smoke
« on: January 29, 2023, 10:26:05 pm »
Basically the ability to create custom hazard entities like toxic smoke clouds, areas of corruption, radiation, etc...

Some parameters it might have:

Duration: int or {int, int} (Duration in turns, fixed or variable within a range)
Sprite: int
Area of Effect: int (Radius of the effect)
Lighting: int (The level of lighting produced.)
Visibility Impact Fixed: int Increases/reduces visibility by this amount.
Visibility Impact Percentage: int  Increases/reduces visibility by this amount.
Triggers on Entry? int (whether its affects apply to entities whenever they enter an effected tile)
Triggers at Turn End? int (whether its affects apply to entities whenever they remain on an effected tile at the end of the turn)
Dissipates? int (Whether it dissipates gradually as smoke does over the Duration)
Power: int
damageType: int
damageAlter:
Tags:

5
Even more, you can decide WHAT will spawn

On this note, there doesn't currently appear to be a good way in a script to reference and utilize zombieUnitByArmorMale/zombieUnitByArmorFemale or otherwise create indices/switches for more dynamic zombification transforms that varies depending on the unit being zombified.

6
Good news, all this functionality is already available via scripting.

Was hoping for a convenient standardization of these parameters.

Unfortunately, while such a script can be produced, it is unlikely to be shared between projects, and I'm certain this functionality would be desired by many mods.

7
It would be nice to have additional parameters for zombification such as:

for weapons:

ZombificationOnDamage: int (zombification chance will only fire if the target takes at least X damage from the zombifying attack after armor/resistances, not on hit)
ZombificationOnKill: true/false (zombification chance will only fire if the target is normally killed by the zombifying attack)
ZombificationChanceRanged: int (zombification probability for the ranged element of this weapon)
ZombificationChanceMelee: int (zombification probability for the melee element of this weapon)

and for armors, so you have options other than straight up immunity:

ZombificationResistAbsolute: int (reduces the chance of zombification by this flat amount to a minimum of 0; modifies specialChance/ZombificationChanceRanged)
ZombificationResistPercent: int (reduces the chance of zombification by this percent to a minimum of 0; modifies specialChance/ZombificationChanceMelee)

8
OpenXcom Extended (OXCE) / Re: OXCE (OpenXcom Extended) main thread
« on: December 09, 2022, 10:11:13 pm »
Any plans to add them?

Also wondering if it's presently possible to determine the source of a fatal wound, or if they can be flagged/tagged in some way so they can be a prerequisite for certain interactions/scripts; for example in the 40k mod, if a unit is wounded with Nurgle weaponry, they could be made to transform into a zombie upon dying, should they have that Nurgle sourced/flagged wound on death.

9
OpenXcom Extended (OXCE) / Re: OXCE (OpenXcom Extended) main thread
« on: December 06, 2022, 07:36:36 am »
Are teleportation abilities currently possible with OXCE?

10
OXCE Support Y-scripts / [Solved] Add Healing Factor for Units
« on: December 05, 2022, 05:38:31 am »
Per title.

Basically each unit has a healing factor divisor that modifies their rate of wound recovery. A healing factor of 2 = half the standard wound recovery time for example. This value defaults to 1. This would be good for special units like 40k mod's Space Marines.

Alternately it could be made a multiplier that multiplies the rate of wound recovery; whichever would be best/easiest to implement.

11
40k / Re: [ADDON] ROSIGMA
« on: November 29, 2022, 12:10:41 am »
Eldar Seers can enter Devotion training despite never gaining Devotion from it.

12
40k / Re: [ADDON] ROSIGMA
« on: November 28, 2022, 11:29:31 pm »
Not sure if bug/unintended but I'm pretty sure that Khorne Valkyries shouldn't be using psionics as Khorne is clear on where he stands when it comes to sorcery; probably something that should be looked at for all Khorne affiliated units.

13
40k / Re: [ADDON] ROSIGMA
« on: November 28, 2022, 07:02:45 am »
Also it appears that unconscious units can dodge somehow.

14
40k / Re: [ADDON] ROSIGMA
« on: November 28, 2022, 04:13:08 am »
It seems that the Crozius Arcanum for the Grey Knight Chaplain is broken; even if you're Rank 3 or higher, you do not get access to it.

15
40k / Re: [ADDON] ROSIGMA
« on: November 27, 2022, 12:16:15 pm »
Oh, would definitely add the ability to see friendly shield values.

Apparently X-Chronicles mod displays shield values, and the script from this can be copied over.

Pages: [1] 2 3 ... 33