Tiny Wisdom's wishlist

[Tiny Wisdom]

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

[Meridian]

Just a very quick, raw and unpolished feedback:

1. really? this is the number one issue?

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

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?

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?

5. ok, why not

6. just no (I'll skip the 10 page explanation, sorry)

7. has been discussed several times, and at the end we haven't found any big enough gameplay benefit that would justify adding such a feature

And I must react to this too: "Rationale: The alien capacity to 100% destroy X-COM craft is a bit suspect."

...in the entire history of humanity, nobody ever survived an uncontrolled plane crash (while staying onboard).
And the only thing/item that "survives" an uncontrolled plane crash is the black box.
Nobody to save, nothing (valuable) to recover.

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

9. no feedback, I didn't read the linked thread

[Yankes]

How to detect when BattleActions are used by BattleTypes and then edit BattleUnit (regardless of outcome)?

As I said on other thread some thing like this is on my TODO list, only problem is lack of constructive time to implement this,
I suggest multiple modders to nagging me, then at some point I will implement this.

Add requiresSell and requiresSellBaseFunc.

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.

Require a facility to be built adjacent to another facility (not the same as requiresBaseFunc).

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.

Allow a facility to change the services provided by another facility.

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

Require a Commander for the final mission.

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

Require physically transferring loot from mission sites.

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

Add alien rescue missions/ambushes.

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

[krautbernd]

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

[Tiny Wisdom]

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

[Finnik]

9. no feedback, I didn't read the linked thread

I can't say really like how vanilla base defense works. There is literally no gameplay around it, even interception has a small mini-game. I like the way current mechanic coded, as it is relatively friendly to adjustments. Actually, the fact you added a mechanic to reduce attackers numbers based on UFO damage that easy (with just a few lines) really inspired me to learn coding...
I don't like the solution we have in referenced tread, but there could be a mini-game design.

Like, for instance, we have a distance for UFO, it is approaching to land. Once it is landed, you can't fire, it's a battlescape time. All defense facilities have stats similar to craft weapons - power, range, accuracy, projectile type, clip size. Worth adding accuracy/power drop with distance.
Then the player would have to decide, he or she wants to start fire from long range, risking wasting all ammo with no decent hit ratio. Or is it better to let it come closer, but then there would be a risk that fire rate would not let you provide all power because UFO would land. Grav shield would matter a lot in that strategy.

I'm aware how hard that would be to code. And considering how rare base defense events appear, compared to the similar (in terms of required effort) mechanic of Dogfight, I would not put it very high in the priority list. And it is definitely beyond vanilla experience, but I just felt to share my thought on the topic 

[davide]

In the past I tried to mergeed the redv's branch
https://github.com/OpenXcom/OpenXcom/compare/master...redv:active_base_defense
on the oxce one but by now the code was very different and knowing it little I didn't succeed.

At that time we discussed about to diversify in some way the basic defense missions by blocking the aliens on the surface and then fighting in different terrains.
 Even with two-level base structures thanks to an improvement by ohartenstein23 if I remember correctly

[Meridian]

You would do that. I wouldn't.

Yeah, I shouldn't have written that opinion, it doesn't matter at all what I would do.

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

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

Again, yes, the example makes perfect sense, an alien containment definitely needs an alien life support (and I'm sure the vanilla alien containment also contains alien life support).

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

[Juku121]

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

Complicates your logistics and delays income from loot. It's about the same in principle as having to maintain the armoury yourself via periodic buying/selling/manufacturing, especially of ammo.

I'm not particularly for or against this request, but it has roughly the same amount of merit as stuff already in-game, stuff that's been streamlined away in other similar games (both NuCom and Xenonauts do away with ammo management, in one way or another).


I am interested in the loot transfers. Every other base than the one the strike team came from already gets treated like that. It's not a particularly strong feature gameplay-wise, but it does help with immersion.

How is the current system implemented, anyway? Transfers from a mission site go from the strike base to other bases via regular transfer? Or does it take into account where the mission site was?

[krautbernd]

Again, yes, the example makes perfect sense, an alien containment definitely needs an alien life support (and I'm sure the vanilla alien containment also contains alien life support).

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.

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?

[R1dO]

...
, 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.
...
Can you give any actual useful examples that demonstrate why this is needed?

Even though i'm not sure how one could implement this (e.g. suggestion 3) during build-up-the-base phase that clearly communicates to the player the available spots are limited or even that an existing facility must first be removed to make place.
One potential use case i could come up with is simulation of irregular buildings (e.g. 1x2, 2x1, L-shaped) without restrictions on orientation (1x2 vs 2x1).
And that is under the following assumptions:
* The implementation requires some form of adjacency: be it 4 or 8 connected, perhaps even a specific side.
* It is much harder to implement actual irregular buildings (possibly with rotation support?) than it is to implement this idea.


As for point 2 of the suggestions (requireSell):
I'll side with the persons that see no benefits to that.
If only because it would eventually result into a player trap (no space left for buying and not being able to sell anything).
Off course one could come up with solutions to "dump" when necessary, but that is just selling with a cost of 0. At that point you've introduced variable pricing for a specific group of items, might as well roll with yankes idea of research base pricing which has a broader reach.

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

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.

[Tiny Wisdom]

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.

[Juku121]

issue #2

...it is arguably of equal game play benefit and provides the same quality to the player's experience as things already in the game.

...sell ... at a loss by making costSell a negative value.

...explain why...

The point being, you have yet to put forth a compelling argument why it is so.

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.

Perhaps there is a better argument in favour of this feature. It has not been raised so far.

...interact with the item before seeing the UFOpedia entry.

That same criticism can be raised against many (and I mean really many) other game mechanics that are opaque until the player reads a Ufopedia article, and possibly remain so even after that.

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

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?

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

Base defense is never trivial even in the most fortified base, unless you've got a line of extreme security buildings somewhere. Mined to all hell, full of friendly turret spawns and maze-like corridors, etc. And a fortified base always suffers from being worse at actually being a... base.

issue #4

For instance, you could require all existing facilities have access to a Power Plant.

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

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.

The only really compelling example I was able to come up with was a moat or wall, and that has no place in a secret underground bunker.

Edit: The Radar/HWD example would work just fine without adjacency, except for some minor base Tetris. 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'.

Another thing would be some sort of complex constructed from multiple parts (a space launch facility or such), but that could be reasonably well simulated by just making a big facility.
/edit

I'm also not sure why I need to defend why something should be moddable.

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.

[Meridian]

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.

OK, I don't want to keep going around in circles.
Can you name the benefit and/or experience improvement or not?
No benefit/improvement = feature is not going to be implemented.


Example:
- 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

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

I fully admit that I have been wrong many times in the past, and likely will be wrong many more times in the future.
But I give the option to show/tell me where I am wrong.

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

You don't need to defend yourself, you're not being judged here.
Your opinion is fully accepted.

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)

I have a practically endless list of requests by now, many of which are never going to be implemented.
If yours should make it, I need to see at least some benefit or improvement described in clear words (btw. "same benefit as other features" are not clear words).
Implementing new features takes time, effort, maintenance, etc.
And I get literally nothing back for it other than a good feeling... a good feeling from improving player's experience or creating some kind of benefit for the player.

[Meridian]

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

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?