Messages

1

OXCE Wishlists / Re: [Suggestion][Rulesets] Issues that stopped me from adding features to SALT.

« on: July 19, 2022, 08:44:19 pm »

I'd rather have devs focus on things that are actually useful.

I personally would take customisable hangars over all of your proposals.

Thankfully, the final decision isn't up to either of you.

If I have a hard time articulating myself sometimes, that's between me and the developers.

I will no longer be responding to either you because you don't care what I said no matter how I say it.

2

OXCE Wishlists / Re: [Suggestion][Rulesets] Issues that stopped me from adding features to SALT.

« on: July 19, 2022, 07:19:37 pm »

Because dev time doesn't grow on trees. You want to make your own fork of OXCE with researchable Chryssalid sales, Power Plant tiling, blackjack and hookers, go ahead. Finnik did exactly that when he felt the confines of OXCE becoming too limiting for himself.

Please read the P.P.S. of my first post.

Your only one so far is that it'd explain why it costs money to 'sell' items. This issue will not go away with 'requiresSell'. You will still need to explain why it costs money to 'sell' and why it requires research to sell.

You misunderstood what was said.

Yes. And the point being raised is why are these not sufficient? What does adjacency as a requirement, not a bonus, do for gameplay? Except make it more convoluted for little benefit?

Are mods to be a bonus or are mods to be a change?

If mods are to be a bonus then everyone would objectively agree that every mod is useful to everyone.

Why does everything have to be next to the PP? What happened to power cables?

Issue #4 has nothing to do with requiring adjacency.

If you required me to tile all my bases with regularly placed Power Plants, I would immediately go and disable that silliness. I don't think I'm alone in this.

If your ideal of base building is making them out of relatively fixed blocks of adjacency-required buildings, I think your idea of fun is quite distant from most others'.

As already stated, this is a customizable value, it's up to the modders to implement and users to enjoy. As with all other customizable values, some will and some won't.

You are not alone in not enjoying the example I mentioned and I'm not alone in not caring if I had to deal with the example I mentioned. Thankfully, subjective opinions shouldn't have a place in whether or not a customizable value should objectively be added.

OK, I don't want to keep going around in circles.

I don't either but I can't explain things better than I already have.

Actually, I'll try again. The basic features I requested have a lot of flexibility, especially if you use some together. Look at the example you gave:

- in the XCOM2012, when you build two facilities of the same type next to each other, you get better overall performance:
  * Gameplay benefit: player gets a new option of increasing performance (for the cost of some early planning)
  * Experience improvement: happiness when rewarded for learning and doing something more efficient

So, you can use the building adjacency feature (issue #3) to build two facilities next to each other.

Then you can use the service change feature (issue #4) to increase performance.

This is not how I intend to use the features I mentioned but they are generic and bland enough that modders can come up with interesting combinations.

- in your general stores example:
  * Gameplay benefit: ?? (the player doesn't get any new option, as far as I can say)
  * Experience improvement: ?? (sadness, disappointment and frustration that they have lost storage capacity and additionally now have a completely useless facility?)

So here you can reduce storage and increase something else. The way I worded the issue doesn't prevent this.

The example I gave is also not how I intend to use the feature, it's just a possible implementation.

Can you name the benefit and/or experience improvement or not?
No benefit/improvement = feature is not going to be implemented.

Except for issue #1, I worded every issue to allow for more possibilities, the examples I gave are bland and uninteresting but that doesn't mean the modder's implementations have to be.

Obviously, for my case, I want to mix things up even if others see it at convoluted (obviously, they should seek another implementation aside from mine since the basic feature itself does not lean towards being convoluted or not, it, like any other customizable value simply allows for being convoluted or not).

But if you want something to be implemented, you do need to provide arguments why it should be implemented.
(I'm sorry, but "I want it this way" is not a reason for me to do anything)

The thing is that the impression I'm getting for some issues is that the response is "but I don't want it this way" and that's one reason why we are going in circles.

However, what I did was thought about the issues I had then broke them into pieces that other modders can use separately or together.

That's the benefit/improvement, it is for modders.

How they choose to use the pieces can be very interesting or very uninteresting.

I wanted to implement this, but I see that hidePediaInfoButton already does what you want.
Do you have an example where/when it works differently?

With both options on, the INFO button still shows up for Stingyrays, Avalanches and Cannons in UFOpedia.

Clicking said button leads to another window that says, "This feature is disabled."

I have a practically endless list of requests by now, many of which are never going to be implemented.

I forgot to mention, I understand this, I really really do.

So, if you see something I wrote and your first reaction is this, then have at it.

If not, no big deal, really.

3

OXCE Wishlists / Re: [Suggestion][Rulesets] Issues that stopped me from adding features to SALT.

« on: July 19, 2022, 04:53:06 pm »

The important questions were the 2 before my opinion: what gameplay benefit does it have? how does it make player's experience better?

If I followed correctly, this is about issue #2.

The point I was trying to make is that it is arguably of equal game play benefit and provides the same quality to the player's experience as things already in the game.

You can already be forced to sell Snakemen, Chryssalids and Celatids at a loss by making costSell a negative value.

Without requiresSell or something like an immediate itemTriggers, there's nothing to explain why the initial sell cost is negative.

For this specific example: you are better off writing an ufopaedia article on why some stuff cost money to sell instead of hoping a (new) game mechanic does that job in a satisfactory way.

That would naturally be done since I believe every change I have made is reflected in UFOpedia. Most importantly, except for "items-known-about-before-alien-contact", you have a chance to read about the change before interacting with said items.

The only instance, afaik, where this is not the case would be if I set a negative sell price and you interact with the item before seeing the UFOpedia entry. It would not be amiss for someone unfamiliar with what's happen to incorrectly assume it's a bug.

Hence one reason for the original issue.

The important questions are again the first two: what gameplay benefit does it have? how does it make player's experience better?

The important question for me (concerning the example) would be what either facilities do by themselves. If the only purpose of the life support system is to enable you to use alien containment than the facilities serves no actual purpose, because all it accomplishes is to clutter up the base. If that's the idea just make a 4x4 alien containment center which accomplishes the same thing.

If I followed correctly, this is about issue #3.

Again, the point I was trying to make is that it is arguably of equal game play benefit and provides the same quality to the player's experience as things already in the game.

You can already force a facility to require another facility through the use of provideBaseFunc and requiresBaseFunc (this can already result in facilities that serve no purpose except to clutter up the base).

Any reason as to why something like that would be done is probably also a reason as to why those facilities might logically be adjacent to each other.

As mentioned in a follow up explanation, requiring building adjacency also complicates base design to reduces the likelihood of trivializing base defense missions.

Note, this is a customizable value, it's up to the modders to implement and users to enjoy. As with all other customizable values, some will and some won't.

The same holds true for the storage/warehouse example. Why should I build both if the outcome is downright detrimental and just serves to clutter up the base?

Can you give any actual useful examples that demonstrate why this is needed?

For the record, this is about issue #4.

If whether or not a customizable value could result in something detrimental is the basis on whether or not said customizable value is useful or needed then quite a few of them need to be removed.

I'm also not sure why I need to defend why something should be moddable. A big reason why mods exist is because the modder probably has a different implementation in mind and that's one of the only things that should matter (besides any developers exposing the functionality).

That said, it probably wasn't the best example (despite being a valid example). However, if you are biased, you probably won't accept any example I give.

For instance, you could require all existing facilities have access to a Power Plant. If a General Store doesn't have access then it provides 0 storage. Likewise, Alien Containment would contain 0 aliens. And, so on. Implementing it this way allows facilities to run at "full", "half", "low" or no "power".

Could you soft-lock this way? Probably not as live aliens already die without containment. If you lack storage space you are already forced to sell/transfer the items. If you also lack living/work space then similar screens could pop up. Not really where I was trying to go though.

If your first thought is, "but, why do I need a Power Plant to begin with?" then I have nothing further to say on this issue.

4

OXCE Wishlists / Re: [Suggestion][Rulesets] Issues that stopped me from adding features to SALT.

« on: July 19, 2022, 12:29:03 am »

1. really? this is the number one issue?

Just for the record, these issues weren't listed in order of priority...

2. what benefit does it have? how does it make player's experience better? if you forced me to do that as a player, I'd just keep the items indefinitely, or ask for a feature to dump the stuff into the ocean for free

You would do that. I wouldn't.

Therefore, I don't think there's an objective way to answer this question since we are both already biased. For example, the community is probably divisive on clearing Terror Sites at night. Some roll with it but others avoid them even if they have to cheat, it's still part of the base game though. It's logical that there's a day and night cycle, so it makes sense that Terror Sites might need to be cleared at night.

In the same line of thinking, Snakemen carry eggs, Chryssalids create zombies and Celatids clone themselves, so it makes sense that not properly disposing of them should have consequences. Like before, some will roll with it but others avoid it even if they have to cheat.

I can already make it cost to dispose of them but without requiresSell I'm missing a step in explaining why that's the case. Like you said, players can choose to hoard the items instead but I can just increase the size...

How you clean up space when all of it is dead Chryssalids? You can lockup yourself and before you could remove them.
For me better would be if you can change sell price based on research, this could be used for XPZ too.

Wouldn't 2) pose potential soft-lock issues with enforced containment/storage limits?

It's true you could soft-lock so changing the sell price based on research works too but there's still that missing step explaining the initial sell prices.

I'd use itemTriggers but doesn't that executes on a monthly basis and not immediately when you first acquire the item?

3. what benefit does it have? how does it make player's experience better? I'm commanding a planetary defense system... I think I'll be forgiven to abstract and assume my alien containment facility already contains alien life support... otherwise it's not really an alien containment system, is it?

Implementable but probably bit more costly than current version (as now you check 1 value, now you need track 6x6 values).
Bigger problem is how it will behave when you do not have lot of free space in base. Some way you will have base Tetris.

I think the example I gave makes perfect sense. It's only one example though.

Another one would be for Hyper-wave Decoders to be built adjacent to both a Small Radar System and Large Radar System. This prevents old systems from being obsoleted, purposely takes up space and makes it so you probably won't be able to design your base to trivialize base defenses.

So you can instead look at this as a way to restrict the freedom in constructing new bases thereby increasing the difficulty.

Tetris is a good description.

4. the description sounds relatively interesting, but I don't understand the example at all... why would general stores lose the ability to store items when something else is built next to them?

This is only asking for corner cases bugs, probably to much for what its is worth.

Because the purpose of the General Stores changed, it would be purely a storefront leaving excess storage to the Warehouse.

This isn't quite the use case I have for it but it's close.

Probably is more trouble than it's worth though.

5. ok, why not

It could be possible now, craft could require pilot that can only be commander. You would need check if all tools are available (pilot with special type, transformation to this special type, transformations require specific rank).

If at all possible, I would like this to work without activating the pilot mechanic.

"living" crash site that you need loot is probably no-go, only solution I could see that could work is all loot go to transfer queue.

Actually, using the transfer queue would be perfect.

8. there's already Reinforcements mechanics for that... not exactly the same, but same general idea

Time do not flow outside battlescape, one work around that could be easy to implement is that alien deployment can change based on time, like bases have now.
Depending who implemented it could simulate whole rescue sequence:
0h - 4h: only craft crew
4h - 8h: craft crew + some rescue recon
8h - 16h: multiple rescue units
16h - 30h: only empty crash site

A quick look at the  reinforcements script shows that it could do the job (although without landing another craft).

5

OXCE Wishlists / Tiny Wisdom's wishlist

« on: July 18, 2022, 10:08:30 pm »

On my recent post introducing Snug Assortment of Little Things (SALT) to the the Work In Progress sub-forum I mentioned that some rulesets and script hooks were missing in order for it to be considered 100% feature-complete.

The scripts have already been addressed here:

• [y-script] How to detect when BattleActions are used by BattleTypes and then edit BattleUnit (regardless of outcome)?
  
  Reference: [y-script] Script hooks
  Reference: changing item use cost

The rulesets are as follows:

• Remove the INFO button completely (not the same as hidePediaInfoButton & oxceDisableStatsForNerds).
  
  Rationale: The INFO button still shows up even if hidePediaInfoButton and oxceDisableStatsForNerds are used (it'll just say it's disabled).
  
  
• Add requiresSell and requiresSellBaseFunc.
  
  Rationale: We already have requiresBuy and requiresBuyBaseFunc. It makes logical sense to have the opposite action.
  
  Example: Prevent the selling of Snakemen and Chryssalids without research. Said research would allow them to be sold (while possibly triggering related missions) or properly disposed of (at cost).
  
  
• Require a facility to be built adjacent to another facility (not the same as requiresBaseFunc).
  
  Rationale: For facilities that directly require another facility to operate.
  
  Example: Alien Containment facilities must be built adjacent to Alien Life Support Systems facilities.
  
  
• Allow a facility to change the services provided by another facility.
  
  Rationale: For facilities with multiple operating modes.
  
  Example: General Stores built by itself provide 50 storage but Warehouses (which also provide storage) can set the storage provided by adjacent General Stores to zero (0).
  
  
• [DONE] Require a Commander for the final mission.
  
  Rationale: The ultimate craft is required, why not the ultimate soldier?
  
  Example: If the difficulty of acquiring a Commander is increased (soldiersPerCommander), not requiring said Commander for the final mission makes the increase in difficulty pointless.
  
  
• Require physically transferring loot from mission sites.
  
  Rationale: Loot magically teleports back to the base, let's introduce logistics giving another reason to have X-COM crash sites (e.g. aliens can shoot down crafts carrying loot).
  
  Example: When a crash site/alien base is cleared, whatever loot can fit is transported back with the craft and automatically deposited into the base stores upon arrival. Whatever loot can't fit is left behind to be picked up later by a craft with carry capacity (changing the crash site/alien base icon to a collection site icon).
  
  
• [REJECTED] Add X-COM crash sites.
  
  Rationale: The alien capacity to 100% destroy X-COM craft is a bit suspect.
  
  Example: In a world based on scarcity where aliens actively hunt X-COM craft (which may or may not be carrying loot), being able to recover some of your losses might be a matter of balance.
  
  Reference: [WIP] [Suggestion] Solar's wishlist
  
  
• Add alien rescue missions/ambushes.
  
  Rationale: Aliens crash but don't signal for help?
  
  Example: When an alien crash site is created, one alien ships within a certain radius of the crash site is randomly selected to land and provide support. This could be used as a way to penalize taking too many turns.
  
  
• [REJECTED] Allow manual control of base defenses.
  
  Rationale: Pew-pew.
  
  Reference: Base Defense Mechanics

P.S. Note, I have marked the items that were previously rejected in the past. I am only mentioning them again to "add my vote".

P.P.S. Also, this isn't quite a request to add to add these features as there's probably a reason why some things aren't possible, but, just in case...

6

OXCE Support Y-scripts / Re: [y-script] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 18, 2022, 07:52:33 pm »

It's not impossible, it's just very inconvenient within the current architecture and flow.

I wasn't sure about the particulars since I'm not that familiar with the codebase.

So thank you both for taking the time to explain.

P.S. Thus ends my journey with y-script. I'll be making a separate post about some possible rulesets (sorry ;).

7

OXCE Support Y-scripts / Re: [y-script] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 18, 2022, 04:37:27 pm »

For what this 3 items will be used? You ask for even more, to script replace one item by another that is another can of worms (you can't replace ammo with corpse and some item are forbidden in some slots).

Proper solution is dedicated calculation of number of waypoins, that can be done safety when game require it. Same how some bonues are calculated.

It's not that I want these 3 particular items.

What I actually want is the dedicated calculation of the number of waypoints but you said that would be impossible so I was seeing if I could think outside the box a bit. Did I misunderstand what you meant?

Of course, someone could try replacing ammo with a forbidden item but my intent was to filter out what was replaceable by using the refNode attribute (i.e. only copies of items with minor changes can replace the original).

What I'm asking for is in line with the first two examples (i.e. restricting item performance by using various unit stats as parameters), it's just that waypoints are an additional factor for Blaster Launchers.

All in all though, I'm asking because I believe you would have a solution that could benefit more modders rather than me duct taping in something at the code level.

[Spoiler]

8

Work In Progress / [UNRELEASED][OXCE][UFO] Snug Assortment of Little Things

« on: July 18, 2022, 04:48:59 am »

What is Snug Assortment of Little Things?

Also known as OpenXcom Extended with SALT.

Snug Assortment of Little Things is a lightweight yet comprehensive canon-friendly overhaul of the original experience.

In addition to at least 1 global option and 33 fixed user options, it consists of:

Spoiler:

5 first-party mods by OpenXcom
32 second-party mods by Snug Assortment of Little Things
14 third-party mods by Various Authors

Why is it unreleased?

While it's 99% done and playable, the addition of a few rulesets and script hooks are needed for the remaining 1%.

That said, I am not quite sure it's releasable. More specifically, I need clarification on licensing:

• OpenXcom and derivatives are under GPL v3.
  
  If I package Snug Assortment of Little Things like X-Piratez, adding a user folder for the master mod, is the entire package now considered a derivative and under GPL v3?
  
  Note, I would not be compiling OpenXcom at all, just adding a user folder.
  
• (Once again) OpenXcom and derivatives are under GPL v3.
  
  Are included mods like Aliens_Pick_Up_Weapons and Limit_Craft_Item_Capacities under GPL v3?
• Snug Assortment of Little Things is a master mod.
  
  To make sure everything meshes, required first-party and third-party mods are bundled with appropriately adjusted metadata.yml files. There is a clear distinction between these mods in the file hierarchy:
  
  
  Spoiler:

  %HOMEPATH%\Documents\OpenXcom\mods\
  ├───[OpenXcom]_Aliens_Pick_Up_Weapons
  ├───[OpenXcom]_Limit_Craft_Item_Capacities
  ├───[OpenXcom]_TFTD_Damage
  ├───[OpenXcom]_UFOextender_Gun_Melee
  ├───[OpenXcom]_UFOextender_Psionic_Line_Of_Fire
  ├───[SALT]_Snug_Assortment_of_Little_Things
  │   ├───LastRuleset
  │   │   ├───Purchasing_and_Building_are_More_Complex
  │   │   └───Research_and_Manufacturing_are_More_Complex
  │   └───Ruleset
  │       ├───Aliens_Base_Invaders_Understand_Futility
  │       ├───Alien_Containment_Requires_Research
  │       ├───Alien_Items_Do_Not_Get_Phased_Out
  │       ├───Alien_Pacts_Are_Not_Forever
  │       ├───Armor_Conforms_to_Ufopedia
  │       ├───Base_Defense_Systems
  │       ├───Base_Defense_System_Response_Make_a_Difference
  │       ├───Country_Funding_Equalized
  │       ├───Coveralls_Described_in_Ufopedia
  │       ├───Craft_Speeds
  │       ├───Craft_Weapons_Balanced_on_a_Linear_Distribution
  │       ├───Difficulty_Level_Affects_Sell_Prices
  │       ├───Difficulty_Level_Starts_on_Veteran
  │       ├───Geoscape_Expanded
  │       ├───Handheld_Elerium-Based_Weapons_are_Heavier
  │       ├───Handling_Two-Handed_Weapons_With_One_Hand_is_Heavily_Penalized
  │       ├───Laser_Weapons_Balanced_Againist_Plasma
  │       ├───Plasma_Beams_Consume_Elerium
  │       ├───Promotions_Cost_Money
  │       ├───Promotions_Take_Time
  │       ├───Psionic_Skill_Affects_Devices_and_Weapons
  │       ├───Rank_Affects_the_Power_of_Handheld_Weapons
  │       ├───Region_Costs_Increased
  │       ├───Sectopods_Use_Lasers
  │       ├───Solider_Stats_Balanced_on_a_Linear_Distribution
  │       ├───Standard_Rockets_Shots_and_Weights_Adjusted
  │       ├───Standard_Weapons_Shots_Adjusted
  │       ├───Start_a_Few_Months_Earlier
  │       ├───Stunning_Affects_Morale
  │       └───UFO_Detection_Systems
  ├───[Various]_Accuracy_Penalty_When_Flying_by_Kzer-Za
  ├───[Various]_Armed_Civilians_by_Hobbes
  ├───[Various]_Celebrate_Diversity_by_Solarius_Scorch
  ├───[Various]_Chryssalid_Zombification_Doesn't_Always_Succeed_by_Dioxine
  ├───[Various]_Expanded_Terror_Reworked_by_hellrazor
  ├───[Various]_Expanded_Ubase_Reworked_by_hellrazor
  ├───[Various]_Extra_Explosions_by_Starving_Poet_&_Arathanor
  ├───[Various]_Improved_Hand_Objects_by_IvanDogovich
  ├───[Various]_Moar_Zer0_by_Solarius_Scorch
  ├───[Various]_Outworldy_Physics_by_Hobbes
  ├───[Various]_Self_Medkit_Use_by_N7Kopper
  ├───[Various]_UFOpaedia-friendly_Celatid_by_Kzer-Za
  ├───[Various]_UFO_Vanilla_Variants_by_hellrazor
  └───[Various]_Woundable_Reaper_by_Kzer-Za
  The mods folder is a meta-project/meta-repository (not a real project/repository as you cannot really license empty files) as such, the original license of each individual mod is respected:
  
  
  • OpenXcom mods under GPL v3 (??)
  • SALT project under ?? (I haven't decided yet....)
  • Various mods under ?? (Not all of them have licenses and would require some followups...)
  
  right?

Spoiler alert: I know anyone who replies regarding this section is probably not a copyright lawyer and that I should seek an actual lawyer for legal advice. I am just asking to gauge the waters and if it's too much of a hassle... oh well.

Forget the legalities for a bit, give us some details about the mod!

First-party mods are self-explanatory and are what I believe should objectively be in the base game.

Third-party mods are self-explanatory and are what I believe should subjectively be in the base game.

Second-party mods are more biased in intentions and could benefit from explanations. The emphasis is 99% on each mod being "a lightweight yet comprehensive canon-friendly overhaul". A summary of what was done is included at the top of each mod's metadata.yml file. For instance...

Craft_Speeds:

Spoiler:

Code: [Select]

#
# In the base game (xcom1) the Lightning is slower than the Firestorm,
# giving yet another reason not to use it.
#
# We flip the speeds and adjust the acceleration values shown in UFOpaedia
# (the latter which also affects the disengagement speed in piloted crafts).

Craft_Weapons_Balanced_on_a_Linear_Distribution:

Spoiler:

Code: [Select]

#
# In the base game (xcom1) some craft weapons either do too little damage
# or too much.
#
# We balance damage and accuracy on a linear distribution
# with increased minimums and decreased maximums,
# however, we peg range to UFO size.
#
# We reduce reload times where continuous fire is expected.
#
# We split craft weapons into types to delay planned obsolescence.
#
# We give every craft a built-in cannon as a measure of last resort.

I can also do likewise for the other second-party mods (as I'd like general feedback on the balance decisions I made) but does anyone even read these walls of texts?

References:

• [RULES] Modest Rebalance
• [UFO MEGAMOD] Reaver's Faithful Megamod
• [UFO] Ramikin Rebalance
• exponential difficulty
• General XCom balance
• Reaver's Rebalance
• Vanilla Rebalanced - nothing is added, but everything is different!
• Weapons and Craft rebalance

9

OXCE Support Y-scripts / Re: [y-script] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 18, 2022, 02:43:33 am »

This will be impossible, waypoints number should be set long before item is used, script I want to add is call right after unit was used, this mean too late to change that.

Is that the case even if we skip the computation:

Code: [Select]

items:
  - &STR_BLASTER_LAUNCHER
    type: STR_BLASTER_LAUNCHER
    waypoints: 9
  - type: STR_BLASTER_LAUNCHER_6
    refNode: *STR_BLASTER_LAUNCHER
    waypoints: 6
  - type: STR_BLASTER_LAUNCHER_3
    refNode: *STR_BLASTER_LAUNCHER
    waypoints: 3
and use a (not yet available) script hook to do the rest?

10

OXCE Support Y-scripts / Re: [y-script] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 17, 2022, 06:36:38 pm »

No, cost is static for other parts of AI plan ahead moves. This is why I do not add scripts for cost calculation as it will easy interfere with it and even with reserved move cost.

That makes sense.

I have in plans add script hook like this, probably biggest problem for me doing it is figure how best do it as I have bit decision paralysis as there multiple way to do it and each have different draw backs and benefits.

I forgot to mention it earlier, but, hopefully the script hook implementation you come up with can also handle:

Example #3: If Launch Missile is used by Blaster Launcher, change waypoints allowed from nine (9) to a number computed using various unit stats as parameters.

11

OXCE Support / Re: OXCE installer Bug

« on: July 17, 2022, 06:29:49 pm »

it seems this both patches offered on installer are failing to download and all enemies sprites are not showing even the zip version is presenting the same issue can i use these patches https://openxcom.org/downloads-extras/ to fix it?

As for the installer, it works for me.

FWIW, enemy sprites aside, the download issue can happen if you are behind a restrictive firewall.

I ran into this issue myself before adding an inbound rule for the OXCE installer.

Of course, you can also download the Data Patches directly from the link you provided.

12

OXCE Support Y-scripts / Re: [y-script] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 14, 2022, 07:39:38 pm »

Btw most `cost*` should have option to switch from flat cost to % cost, you should can have 50% hp cost (I could some miss remember bit it should work)

It does, however, both flat cost and % cost are fixed values which aren't further modified by using various unit stats as parameters.

So I can't dynamically get 50% if Psi Skill is 0-33 and 25% if Psi Skill is >=34.

13

OXCE Support Y-scripts / Re: [y-script] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 14, 2022, 04:34:05 pm »

About examles: it is easy to do with costUse, costSnap etc.

The reason why I'd prefer a script is so the % penalty in the examples can change based on one or more of the attacker's stats.

For instance, in the Psi-Amp example, it could change based on Psi Skill.

This wouldn't be a problem if costUse (and friends) could use various unit stats as parameters like with damageBonus but it doesn't, iirc.

I have in plans add script hook like this, probably biggest problem for me doing it is figure how best do it as I have bit decision paralysis as there multiple way to do it and each have different draw backs and benefits.

Well that's good to hear.

Beside, use of `ptr` is critical and deliberate, changing it will allow crippling game state that could even result in crashes.

I did read you saying that somewhere.

So either I compromise and use costUse (and friends) until you add the script hook or I change things at the code level and temporarily roll my own binaries?

And just to be clear, there isn't an awful misuse of an existing script hook that can pull off what I want is there?

14

OXCE Support Y-scripts / [Answered] How to detect when BattleActions are used by BattleTypes and [...]?

« on: July 14, 2022, 03:13:56 am »

Subject: [y-script] How to detect when BattleActions are used by BattleTypes and then edit BattleUnit (regardless of outcome)?

Examples:

Example #1: If Aimed Shot is used by Heavy Laser, decrease attacker Stamina/Energy by 50% even if the shot misses or does 0 damage.

Example #2: If Panic Unit is used by Psi-Amp, decrease attacker Health by 50% even if the attempt fails.

Problems:

There isn't a script hook that directly does this.

hitUnit: Requires a unit to actually be hit. Even if I compromised here and required hits, Psi-Amps (for instance) don't trigger this event. Unless there's a way to simulate a hit?

awardExperience: Doesn't actually trigger until the end of the mission. Even if I compromised here and required successful outcomes, the event triggers too late.

newTurnItem: Can't detect when an item is used or change item use costs.

skillUseUnit: Items aren't skills. Unless I can hide the default item actions and replace them with skills that do the exact same thing (but then the skill menu would have to be used and that'd be misleading since they aren't actually psi skills)?

tryPsiAttackUnit: This gets Example #2 the furthest, however, you cannot edit the BattleUnit because attacker and victim are both ptr and not ptre (this is a trivial change at the code level afaik and I would like this change to be made, but it doesn't solve Example #1).

Solutions:

Other than changing things at the code level, I'm out of ideas.

I don't want to roll my own binaries so hopefully I missed an outside-the-box solution?

15

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

« on: September 08, 2019, 10:34:07 pm »

About making Celatid clones into spotters I'm apprehensive because, as far as I know, you can't limit spotters to relaying their information to only a certain type of units. I mean, it would be okay if they spotted only for primary Celatids (kind of psi-link between them), but if someone uses a mod in which, e.g. Muton navigators are snipers, then they (navigators) would also get information from the clones. That would, in my opinion, be unreasonable both from the "realism" point of view since Celatids are not sentient, and from the gameplay one since it would essentially give non-Celatid snipers psi-vision too (since Celatids would detect someone with psi-vision and relay that information to snipers).

I knew about this concern but I never experienced it myself so I left my theoretical changes in place until I encountered a Celatid.

And boy, oh boy... it was a slaughter. The clone Celatids took point and the Mutons rained reaction fire. I lost over half my troops (barely taking out 4 aliens in the process) before I noped out of there.

Definitely felt "cheaty".

To make primary Celatids more or less stay in hiding it's not necessary to decrease their psi-vision radius. We can just decrease their aggression to 1 or 0. I think, 1 would be okay, and I made this change, but I won't be able to test it for a week or so.

So yeah, unless the spotter/sniper values can be further restricted that idea is out the window.

I'm going to try reducing the aggression instead as you mentioned.