OpenXcom Forum
OpenXcom Forks => OpenXcom Extended (OXCE) => OXCE Suggestions DONE => Topic started by: Solarius Scorch on March 03, 2021, 10:41:20 pm
-
I would like to ask about a possibility to do this:
alienRaces:
- id: STR_SECTOID
retaliationMission: [STR_ALIEN_FLYBY, STR_ALIEN_FLYBY, STR_ALIEN_RETALIATION, STR_ALIEN_TERROR]
So if a retaliation mission happens after shooting down a UFO, you get 50% chance for STR_ALIEN_FLYBY and 25% for each of the remaining two missions.
-
I would say a WeightedOptions would be better, and maybe we could have even a std::vector<std::pair<size_t, WeightedOptions*> > to define time progression?
-
I would say a WeightedOptions would be better, and maybe we could have even a std::vector<std::pair<size_t, WeightedOptions*> > to define time progression?
I thought so too, but didn't want to make things overly complicated.
What would the ruleset format even be?
-
Probably the way it's done for other alien mission weights by month:
alienRaces:
- id: STR_SECTOID
retaliationMission:
0:
STR_ALIEN_FLYBY: 50
STR_ALIEN_RETALIATION: 25
STR_ALIEN_TERROR: 25
1:
# and so on
-
I've never thought of months, but yes, it sounds pretty useful.
Thanks Otto, a brilliant idea like always! 8)
-
That's just Finnik's idea but written in what the ruleset looks like.
-
yeah, sorry for speaking about its code, not ruleset
alienRaces:
- id: STR_SECTOID
retaliationMission: [STR_ALIEN_FLYBY, STR_ALIEN_FLYBY, STR_ALIEN_RETALIATION, STR_ALIEN_TERROR]
So if a retaliation mission happens after shooting down a UFO, you get 50% chance for STR_ALIEN_FLYBY and 25% for each of the remaining two missions.
I dislike cases when we specify weights with copypasting entity, i can see a lot of such examples already.
I thought so too, but didn't want to make things overly complicated.
It is not that complicated, just a few extra lines very same to what we already have to get weighted entity, not a big deal at all if you ask me.
-
How should the game prevent excess missions?
Currently, if there is an ongoing retaliation mission in a region, it won't spawn another.
If we allow other mission types to spawn, this check will not apply and the player could generate hundreds or thousands of missions per month.
On a higher difficulty, after generating a few missions, you'll have so many UFOs to shoot that your mission generation capability will increase exponentially.
-
I might be thinking too simplistic here.
But if the current behavior is not to spawn when there is ongoing retaliation, would it not make sense to chose one of the following routes:
1) If any of the missions defined under retaliationMission already takes place for that region do not even try to spawn one.
- This should be inline with current behavior (albeit possibly with a different mission type).
- This could well lead to fewer missions (due to existing non-retal mission types, if modder reuses existing mission types from the normal generator).
2) Let RNG decide which of the missions should spawn, if that mission already exist do not spawn.
- This would create extra missions compared to current behavior (up to the amount of uniquely defined mission types)
-
I would vote for option 1), as players tend to be overwhelmed with retaliations anyway.
But option 2) would work too, since I can simply decrease retaliation chances...
-
OK, option 1 done.
Syntax:
alienRaces:
- id: STR_SECTOID
retaliationMissionWeights:
0:
STR_ALIEN_HARVEST: 10
STR_ALIEN_ABDUCTION: 50
4:
STR_ALIEN_BASE: 20
STR_ALIEN_INFILTRATION: 40
members:
- STR_SECTOID_COMMANDER
- STR_SECTOID_LEADER
- STR_SECTOID_ENGINEER
- STR_SECTOID_MEDIC
- STR_SECTOID_NAVIGATOR
- STR_SECTOID_SOLDIER
- STR_CYBERDISC_TERRORIST
- STR_CYBERDISC_TERRORIST
-
Thank you! Very much appreciated.
-
I did not immediately appreciate this idea. Great idea, thanks for the implementation. One question - is it necessary to start a new game by introducing all this?
-
is it necessary to start a new game by introducing all this?
no
-
Understood thanks. A very useful option.