Autofill for items in non-campaign gamemodes #13335
Conversation
We moved from the probability-based spawns to the pre-configured start item sets because configuring them using spawn probabilities was really inconvenient: it's hard to estimate how many of a given item based on probability values, and even harder to control the starting items precisely when it's probability-based. I feel like a better way to go about addressing the scarcity of items in non-campaign modes would be to configure a new start item set for those game modes. |
|
I see, I suppose in a way I understand the argument here, with one small problem. There's no predictability required since every round is allowed to be somewhat different from each other in terms of the items available, kind of the same way as sometimes you could lack certain resources in a campaign after having used it all up and not being able to find any. It creates a dynamic that requires the crew to work with what they've got. Furthermore I also disagree with creating a new start item set to address the lack of items. This might work for a few simple things like fuel and ammunition, but spawning in a dozen of crates to have a somewhat evenly distributed amount of raw materials is not ideal in my opinion. The reason we want materials and not the items directly is to allow the crew to be able to craft their own things they might need for the specific situation. If it's having to find and pickup an artifact, why not craft an artifact holder with the resources. If it's sandbox, maybe there's a roleplay situation going on where someone wants to set up a gardening area for the crew. Raw Materials give players a chance to play the game in a way they seem fit, whereby using an item set is just limiting every round to be the same few items at all times since, like I explained, putting the materials and ores into crates at the start is not a very enjoyable solution. TL;DRProbability-based item spawning creates a more dynamic and fresh gameplay loop for the other gamemodes while item sets create a static way to play the game by just enabling the crew to do the mission with the tools they're given and being unable to play in other ways than Point A -> Mission Objective -> Point B -> Round over |
|
To be clear, by "start item sets" I'm talking about the content type
I somewhat agree with this, although I feel there needs to be some predictability: we need to be able to ensure e.g. that there's some minimum amount of basic supplies available.
I'm not sure I follow this reasoning. I'm not talking about spawning crates, nor am I saying that the starting supplies should consist of pre-made items rather than raw materials. The starting supplies don't spawn in crates if there's space in cabinets, and the supplies should include raw materials too. The set of items you spawn with could be identical to the ones you've configured here, and there could be some randomness involved, but imo the appropriate place to configure them would be start item set (rather than it being sprinkled across all the item xml files). |
|
Oh I see, guess I was just always using ships that didn't have the appropriate space for the items and thus always spawned in crates which I then just assumed was always the case. |
|
I copied over the values and added them to the normal itemset, unfortunately there's some things that don't work as it did using the other approach. I edited the original post and also listed the issues with the change. |
|
This is still active by the way, just took a break from things. Currently working on editing the source code to make the updated .xml file work |
class StartItem receives more public properties and class AutoItemPlacer filters and adjusts the spawn according to those values
Why the change?
I added back the values from pre 0.18 in the preferred containers so other gamemodes than the campaign can actually be played without using any mods for that again. The current situation being just that the players don't have any materials and are basically screwed when the tiny amount of supplies runs out for the necessities to keep a sub running. (eg. fuel, ammo & meds) This makes the gamemodes actually enjoyable and dynamic and not a slugfest that drags on without a real chance of success in sight.
To this day I'm not really sure why this change happened, and it also can't be for balance because the entire concept of the gamemode is unbalanced to begin with.
How is it changed?
Essentially all I did was using the already existing preferred containers that were matching with the files leftover from back when the autofill was still there and added the same amount and probability to the things that don't spawn in enough at allIt still essentiall works the same using the same (almost, will come to that in a bit) values to spawn in the items, now using an Itemset that also only spawns in the items if it's not a campaign while allowing there to be a more consistent minimum amount of resources for missions etc.
Example
This line would make it so the item always spawns in the container and there's either 0 of the item, 1 of the item or 2 in the container. This would only happen in a gamemode other than campaign and would be ignored if it was a campaign and then it only assigns the primary container to the item.As before, this line gives a 10% chance for there to be either 1 or 2 titanite on the sub on the initial spawn, but that only when the current gamemode is not a campaign.
What else to consider?
Currently there also spawns a crate with some starter items to help out during the trip/campaign. From what I know this change happened at the same time as the aforementioned change with the item spawn and is a good thing for campaign, but not for other gamemodes that require more items due to the sub resetting each round.Seems like it was more of an issue on my side (skill issue, ik). Using this now to give a more consistent and organised result for readability and it being generally more reliable.There's also some items where it could be (re)implemented to also spawn randomly in the given containers (eg. captains outfit, commoner outfit etc.) I unfortunately don't have the pre 0.18 files anymore and don't know if they had been changed or not, but since it's not campaign related it wouldn't make sense to bring the argument of balance into this and it'd have to be decided on a per item basis if it should be added to the random pool or not.
Using the new approach however, doesn't behave the same way. The biggest difference really being that while it used to be on a per container basis, it is now on a per submarine basis, meaning if its minamount ="2" maxamount="4", there's always only gonna be 2-4 items of it on a ship, while with the per container method it used to be 2-4 items per container, meaning a ship with 3 suitable containers could have anywhere from 6 to 12 of said item. This is not a very big concern however and could be dealt with by just adjusting the values a bit.Current Issues with the new approach
Currently an itemset cannot handle a range like
minamount="2" maxamount="4", this would always spawn in 1 single itemAn itemset cannot handle a spawn chance like
spawnprobability="0.25", this would be ignored and always spawn inAn itemset cannot distinguish between items that should and shouldn't spawn using
notcampaign="true"Changed Files:
OLD APPROACH
NEW APPROACH