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,
Add requiresSell and requiresSellBaseFunc.
Require a facility to be built adjacent to another facility (not the same as requiresBaseFunc).
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.
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
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?
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.
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.
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).
"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.
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
9. no feedback, I didn't read the linked thread
You would do that. I wouldn't.
I think the example I gave makes perfect sense. It's only one example though.
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.
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 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 important questions are again the first two: what gameplay benefit does it have? how does it make player's experience better?
...
, 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?
...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.
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.
...
The important questions were the 2 before my opinion: what gameplay benefit does it have? how does it make player's experience better?
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.
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?
issue #2The point being, you have yet to put forth a compelling argument why it is so.
...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...
...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 #3Yes. 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?
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...
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 #4Why does everything have to be next to the PP? What happened to power cables?
For instance, you could require all existing facilities have access to a Power Plant.
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.
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.
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).
- 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).
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.
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.
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?
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.
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'.
OK, I don't want to keep going around in circles.
- 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?)
Can you name the benefit and/or experience improvement or not?
No benefit/improvement = feature is not going to be implemented.
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 wanted to implement this, but I see that hidePediaInfoButton already does what you want.
Do you have an example where/when it works differently?
I have a practically endless list of requests by now, many of which are never going to be implemented.
So, you can use the building adjacency feature (issue #3) to build two facilities next to each other.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.
Then you can use the service change feature (issue #4) to increase performance.
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.
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.
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.As already mentioned, using these two features as a half-assed way to add adjacency bonuses does nothing to justify the features themselves.
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.
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'd rather have devs focus on things that are actually useful.
I personally would take customisable hangars over all of your proposals.
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. :P
Thankfully, the final decision isn't up to either of you.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.
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.
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."
- 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).
- 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.
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
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.