Tiny Wisdom's wishlist

[Tiny Wisdom]

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.

[krautbernd]

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.

That's not what your "issues" actually describe. Building them next to each other wouldn't be optional but mandatory. And in that case the "bonus" would be entirely pointless. How would that even work with identical facilities providing boni to each other? The first one would have to be placed next to an existing one which hasn't been build yet.

Right now you're just trying to fit your "issues" into the example you were given, something that's not going to work. I honestly don't see how the adjacency requirement would be useful or positively impact gameplay, and you seem to be hard pressed to come up with useful examples. The same goes for the forced transformation of facilities due to adjacency. The existing upgrade mechanic leaves it up to the player if they want to transform facilities. I don't see how this would positively impact gameplay either.

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

Spoiler:

Like vehicle specific hangars *winkwink*

[Juku121]

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

If you meant it, you wouldn't be arguing with us. You'd at most provide said examples Meridian asked for, and otherwise leave the features to speak for themselves.

You misunderstood what was said.

This is your typical rationale. It is 'obviously' arguable your way, you just won't do it, or will argue generic platitudes.

Which is why even if there are interesting use cases that would make others reconsider, they won't come out in this discussion.

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

This is not about mods, it is specifically about the details of your proposal #3. Adjacency bonuses are an established and fun mechanic, implemented in a multitude of games. If you'd asked for those, it'd be quite hard to argue they're not an improvement, they don't have a positive impact, etc. Not so with your proposal #3.

Issue #4 has nothing to do with requiring adjacency.

In which case, why is requiresBaseFunc 'Power Plant' not good enough? You can get a slight bit more granularity out of an additional soft requirement, but I'd say it's too minor to warrant a new feature. YMMV, obviously.

You can get essentially the same effect by having a bunch of diffetent General Stores facilities with different power requirements via requiresBaseFunc.

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.

This is an argument Meridian explicitly rejected.

...and I'm not alone in not caring...

Proof?

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.

As already mentioned, using these two features as a half-assed way to add adjacency bonuses does nothing to justify the features themselves.

The example I gave is also not how I intend to use the feature...

So will you please say what your intended use case is so it'd be clear whether it's something others might consider valuable or not?

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.

No, the issue is not that people don't want your ideas. People want their ideas, many of which have already been discussed and todolisted, with clear benefits. Robbing dev time from those for features even the person who proposed them can't make a good use case for is what's getting you dogpiled.

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

[Tiny Wisdom]

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.

[Juku121]

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

Only if you PM them, and not when you make a public post. Proposals are made in public with the unwritten assumption that others might support them and provide additional pressure on the developers.

As I said, the only feature out of your set I'd really like is making mission site loot go into the transfer queue (and not anything more complex). And, honestly, that one doesn't really have much gameplay benefit going for it, either.

[krautbernd]

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.

That's not going to solve any of the issues with your proposals regarding forced adjecancy/transformation. It might have passed you by, but "the developers" have asked you basically the same thing - how is this supposed to benefit players? So far you've haven't been able to come up with an explanation, and the "example" you're given isn't related to what you're proposing - and if it was it wouldn't work the way you're describing it.

Note that so far I have only addressed your suggestions regarding #2, #3 and #4.

I am not dismissing the entire lot based on those, only the ones I've asked you to clarify and provide explanations for - something you've so far failed to do, and which you've basically admitted you're either unable or unwilling to do.

[Meridian]

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

Yup, I see it now.
It's a bug, will be fixed.
(info button feature for craft weapons was added later than the switch for disabling info buttons and simply got forgotten)

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

Fixed.
Now works also for Craft Weapons articles.

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

Implemented.
Works for landed/crashed UFOs, mission sites, alien bases and the final mission.
Checked at destination selection and on landing... shows error message.
For Cydonia, no error message, just hides the Cydonia button.

Code: [Select]

startingConditions:
  - type: STR_COMMANDER_REQUIRED
    requireCommanderOnboard: true

alienDeployments:
  - type: STR_MEDIUM_SCOUT
    startingCondition: STR_COMMANDER_REQUIRED
  - type: STR_TERROR_MISSION
    startingCondition: STR_COMMANDER_REQUIRED
  - type: STR_ALIEN_BASE_ASSAULT
    startingCondition: STR_COMMANDER_REQUIRED
  - type: STR_MARS_CYDONIA_LANDING
    startingCondition: STR_COMMANDER_REQUIRED

Test build: https://lxnt.wtf/oxem/builds//Extended/Extended-7.6.1-c24190974-2022-07-20-win64.7z

[psavola]

This will likely lead to problems if your commander gets wounded and you want or must do missions in the meanwhile. In most cases I suppose it could be argued that highest ranking officer on duty should go on the most important missions. There are however many scenarios where you won't want even that (for example, if your higher ranked soldiers have poor PSI strength so you want to leave them out). But I suppose this is an issue a mod author needs to consider; personally I rather see this making the gaming experience worse than better.

[Solarius Scorch]

This will likely lead to problems if your commander gets wounded and you want or must do missions in the meanwhile. In most cases I suppose it could be argued that highest ranking officer on duty should go on the most important missions. There are however many scenarios where you won't want even that (for example, if your higher ranked soldiers have poor PSI strength so you want to leave them out). But I suppose this is an issue a mod author needs to consider; personally I rather see this making the gaming experience worse than better.

If the player cannot ensure presence of Commander for the final mission... Well, I guess the final mission has to wait.

But what if a player simply does not have enough soldiers to get a commander? That's not a common problem in vanilla, but may happen with some... extreme players.