OpenXcom Forum
Modding => OpenXcom Extended => OXCE Suggestions DONE => Topic started by: Meridian on August 02, 2017, 01:07:22 pm
-
There is already a research bounty (usually a research gateway unlocking other research or missions or other stuff),
see here: https://openxcom.org/forum/index.php/topic,5227.msg79244.html#msg79244
After discussion on Discord (Solarius, Warboy), I added an item bounty as well... in case you can't put such item into a terrain or into a ship/UFO (as it is normally done).
I decided to add only a single item, for the following reasons:
1. It is easier for player to spot 1 item called "Mission Bounty" in the debriefing "recovered items" GUI than it is to spot several random items. I also suggest giving bounty item a low listOrder, so that it appears on the top of the list
2. You can use this item in manufacturing and turn it into not only any number of items... but also into engineers, scientists, soldiers or crafts. This is more flexible and also allows you to wait until you can actually use the bounty... e.g. until you have a free hangar for a craft or free space for a new staff member.
3. I'm lazy
The bounty item is added into base stores automagically, after any "successful" mission.
OpenXcom counts as success:
- normal mission: killed or stunned all aliens
- destroy objective(s) mission: at least 1 survivor, objective(s) already destroyed and no next stage... even if you abort the mission afterwards with at least 1 soldier in exit area (e.g. TFTD alien colony)
OpenXcom counts as failure:
- normal mission: all soldiers lost
- normal mission: aborted
- destroy objective(s) mission: no survivors or aborted while not all objective(s) destroyed yet or not last stage yet
Vanilla ChronoTriggers FORCE_WIN and FORCE_LOSE will override the above, ChronoTrigger FORCE_ABORT will behave the same way as if you aborted a mission.
alienDeployments:
- type: STR_LOC_GDX_PRISON
unlockedResearch: STR_LOC_GDX_PRISON_DONE
missionBountyItem: STR_LOC_GDX_PRISON_BOUNTY_ITEM # item added after successful mission
Suggestions, improvements, critique, etc. are welcome...
-
Hello Meridian:
Some things have occurred to me, that I do not know if they will be able to be implemented:
- An object only appears once throughout the game, for example, unique artifacts, valuable components.
- That a concrete weapon, that is, only affects a certain objective. For example, a poison that attacks only the sectoids, or the mutons.
-
Hello Meridian:
Some things have occurred to me, that I do not know if they will be able to be implemented:
- An object only appears once throughout the game, for example, unique artifacts, valuable components.
Possible.
Make a mission that only appears once and make this item the bounty from this mission.
- That a concrete weapon, that is, only affects a certain objective. For example, a poison that attacks only the sectoids, or the mutons.
Possible.
There are 10 more armor resistance types, use one of them and make everybody except your selected foes immune to this type of damage.
-
Great news!
Now we can have the "mysterious chest" feature... Except it will be examined by brainers, not runts. But that's just as good, and perhaps even better.
-
I decided to add only a single item...
You can now spawn more than one item (of the same type).
Example:
alienDeployments:
- type: STR_TEST
missionBountyItem: STR_SOME_ITEM
missionBountyCount: 42
-
What about making it in the form of a more complex data type, like a map of items to their count?
-
It is technically possible.
-
Sure. :) More interesting - is it required? I usually spawn items on the map directly, so it naturally goes to the loot.
-
I don't know if it is required.
Nobody asked for it yet.
My guess is that it is not required, there are other options to achieve the same result.
-
There are some designs that would be much easier if you could be able to award multiple items from the alienDeployments.rul.
alienDeployments:
- type: STR_TEST
missionBountyItem: [STR_SOME_ITEM, STR_SOME_OTHER_ITEM, STR_ANOTHER_ITEM, STR_ONE_ITEM, STR_LAST_ITEM]
missionBountyCount: [42, 112, 14, 1, 5]
I've had to compromise what I've been building a few times because only one type of item could be awarded for mission victory via bounty.
If multiple bounty items per alienDeployment: were added I would make use of this feature.
-
There are some designs that would be much easier if you could be able to award multiple items from the alienDeployments.rul.
alienDeployments:
- type: STR_TEST
missionBountyItem: [STR_SOME_ITEM, STR_SOME_OTHER_ITEM, STR_ANOTHER_ITEM, STR_ONE_ITEM, STR_LAST_ITEM]
missionBountyCount: [42, 112, 14, 1, 5]
I've had to compromise what I've been building a few times because only one type of item could be awarded for mission victory via bounty.
If multiple bounty items per alienDeployment: were added I would make use of this feature.
Why this is two separate lists? This will only make harder to load it and harder for modders to edit it.
If we need multiple item with different count then it should look like:
missionBountyItemX: #this could be same node or node with different name
STR_SOME_ITEM: 12
STR_ANOTHER_ITEM: 5
-
Why this is two separate lists? This will only make harder to load it and harder for modders to edit it.
If we need multiple item with different count then it should look like:
missionBountyItemX: #this could be same node or node with different name
STR_SOME_ITEM: 12
STR_ANOTHER_ITEM: 5
I was basing it off how i'd seen zombieUnitByArmorMale: & zombieUnitByArmorFemale: written in the past.
zombieUnitByArmorMale: { STR_NONE_UC: STR_DOT_TENTACULAT_ZOMBIE_DIVING_SUIT_UNIT, STR_PLASTIC_AQUA_ARMOR_UC: STR_DOT_TENTACULAT_ZOMBIE_PLASTIC_AQUA_UNIT, STR_ION_ARMOR_UC: STR_DOT_TENTACULAT_ZOMBIE_ION_ARMOR_UNIT, STR_MAGNETIC_ION_ARMOR_UC: STR_DOT_TENTACULAT_ZOMBIE_MAGNETIC_ION_ARMOR_UNIT }
zombieUnitByArmorFemale: { STR_NONE_UC: STR_DOT_TENTACULAT_ZOMBIE_DIVING_SUIT_UNIT, STR_PLASTIC_AQUA_ARMOR_UC: STR_DOT_TENTACULAT_ZOMBIE_PLASTIC_AQUA_UNIT, STR_ION_ARMOR_UC: STR_DOT_TENTACULAT_ZOMBIE_ION_ARMOR_UNIT, STR_MAGNETIC_ION_ARMOR_UC: STR_DOT_TENTACULAT_ZOMBIE_MAGNETIC_ION_ARMOR_UNIT }
The way you're displaying it is much better, a single easy to read list like that would be much more preferable.
As you can see from the above code the other kind of list can get difficult to read pretty fast.
-
I was basing it off how i'd seen zombieUnitByArmorMale: & zombieUnitByArmorFemale: written in the past.
They have completely different syntax, I don't see how you could base one off the other.
The way you're displaying it is much better, a single easy to read list like that would be much more preferable.
As you can see from the above code the other kind of list can get difficult to read pretty fast.
Yankes' syntax and the zombie example are both doing the same thing and are interchangeable.
You can use the same syntax for zombie stuff to make it more readable.
More info here: https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html