OpenXcom Forum
OpenXcom Forks => OpenXcom Extended (OXCE) => OXCE Suggestions DONE => Topic started by: Finnik on April 08, 2019, 01:07:25 pm
-
I think it could be very useful for modders to have an additional option in mission script to check if the player has specified item. The script will check if the player has listed items and if conditions are met, it will run mission. Probably, syntax could look like that:
missionScripts:
- type: treasureHunting
missionWeights:
0:
STR_TREASURE_HUNTING: 100
executionOdds: 100
itemDependency:
- item: STR_TREASURE_MAP
needed: true #default is true
- item: STR_TREASURE_CHEST
needed: false #that means if already has an item, mission will not spawn
-
I support this idea. It can be used in a variety of ways, for example having a commander in your base could provoke additional retaliations, as the aliens try to recover them. Or it would prevent missions from spawning if you already have the item they're meant to give you.
-
This carries the risk that important items are sold, lost or destroyed and might not be recoverable. It's already possible to tie missions to research triggers and unlock research topics via completed missions. While i can see this having a niche use, somebody who actually knows the ins and outs of mission design should have look at this.
-
Its not ment to be instead research triggers, it should add extra flexability to mission desighn when you are speaking of somethin rare and special, but ment to be repeatable, so cant be configured with research triggers
-
If you lose the item, them the mission starts spawning again.
-
or vice versa if so intended ;)
-
As long as we are discussing additional triggers for mission sapwns, can we also implement a way to tie base functions to missions? Like building scanner/radar base modules to enable certain missions? Or building a 'support/hangar' module to enable underwater missions?
-
As long as we are discussing additional triggers for mission sapwns, can we also implement a way to tie base functions to missions? Like building scanner/radar base modules to enable certain missions? Or building a 'support/hangar' module to enable underwater missions?
It can be done allready by specific research, allowed by facility special function.
-
It can be done allready by specific research, allowed by facility special function.
No, it can't be ->
It's already possible to tie missions to research triggers and unlock research topics via completed missions. While i can see this having a niche use, somebody who actually knows the ins and outs of mission design should have look at this.
Its not ment to be instead research triggers, it should add extra flexability to mission desighn when you are speaking of somethin rare and special, but ment to be repeatable, so cant be configured with research triggers
You can't enable/disable research triggers in the same way you'd be able to with items or base functions.
-
Done.
missionScripts:
- type: treasureHunting
...
itemTriggers:
STR_TREASURE_MAP: true
STR_TREASURE_CHEST: false
Items considered are ONLY items directly in base stores.
Not considered are:
1. weapons, ammo, vehicles and items in crafts
2. items in transfer
3. weapons, ammo, vehicles and items in crafts in transfer
4. items worn by soldiers (armor)
5. items being researched
6. potential manufacture refunds
7. potential facility dismantle refunds
8. anything else I forgot
And as a bonus, there is also a possibility to define minimum and maximum required score (from the previous month), similar to how the difficulty constraint works.
The score constraint is NOT checked at the beginning of the game (before first month).
missionScripts:
- type: xxx
...
minScore: -1000
maxScore: 200
Test build: https://lxnt.wtf/oxem/builds//Extended/Extended-5.6.4-4e8202a0f-2019-09-18-win32.7z
EDIT: there is also a possibility to define minimum and maximum required funds (from the current month, i.e. after monthly rating), similar to how the difficulty constraint works.
The funds constraint is NOT checked at the beginning of the game (before first month).
missionScripts:
- type: xxx
...
minFunds: -1000
maxFunds: 200
-
Added one more attribute (in OXCE v6.5).
Similar to research and item triggers, there are base facility triggers.
missionScripts:
- type: xxx
...
facilityTriggers:
STR_FACILITY1: true
STR_FACILITY2: false
Facilities from all bases are considered.
-
Added one more attribute (in OXCE v6.5).
Similar to research and item triggers, there are base facility triggers.
missionScripts:
- type: xxx
...
facilityTriggers:
STR_FACILITY1: true
STR_FACILITY2: false
Facilities from all bases are considered.
What is the conditional in the facility triggers? Is it AND or an OR? In other words, do STR_FACILITY1 and STR_FACILITY2 need to be both present somewhere among all bases? Or, perhaps, the interpretation is that either of STR_FACILITY1 and STR_FACILITY2 needs to be present somewhere among all bases?
-
What is the conditional in the facility triggers? Is it AND or an OR?
It's AND.
In other words, do STR_FACILITY1 and STR_FACILITY2 need to be both present somewhere among all bases? Or, perhaps, the interpretation is that either of STR_FACILITY1 and STR_FACILITY2 needs to be present somewhere among all bases?
None of your options is correct.
The example above means "STR_FACILITY1 is present somewhere among all bases AND STR_FACILITY2 is not present in any base".
-
It's AND.
None of your options is correct.
The example above means "STR_FACILITY1 is present somewhere among all bases AND STR_FACILITY2 is not present in any base".
Thank you for clarifying this.
I wonder, if it could be possible to check by the BaseFunc type? E.g. if I had two types of psi labs, how could I depend on e.g. an ADVPSILAB? I know that I could in principle for each event (scripted ones, through configuration only, without invoking a script engine) provide two entries, each checking for a specific building type. However, is there a better solution? Checking by BaseFunc would be much more streamlined and would avoid duplication of entries (which is not optimal in general, even with anchors, etc., especially in extension points).