In the settings below the AllowHV and AllowBlueprintHV contradict each other. One of them needs to be toggled - depending what the intention is. Ref: ...\Playfields\Omicron\playfield_static.yaml # ============================================================== # Special parameters: # ============================================================== AllowHV: False # Dis-allow HVs to enter/spawn in this playfield, default is True AllowSV: False # Dis-allow SVs to enter/spawn in this playfield, default is True AllowCV: False # Dis-allow CVs to enter/spawn in this playfield, default is True AllowBA: False # Dis-allow BAs to enter/spawn in this playfield, default is True AllowMaxCPUTierBA: 1 # Set the max CPU Tier allowed; Only applies to spawning blueprints AllowMaxCPUTierSV: 1 # Set the max CPU Tier allowed; Only applies to spawning blueprints AllowMaxCPUTierHV: 1 # Set the max CPU Tier allowed; Only applies to spawning blueprints AllowMaxCPUTierCV: 1 # Set the max CPU Tier allowed; Only applies to spawning blueprints # RestrictToOrigin: Human # Only players of the defined origin are allowed to enter the playfield AllowBlueprintSV: False # Dis-allow to spawn SV Blueprint in this playfield, default is True AllowBlueprintCV: False # Dis-allow to spawn CV Blueprint in this playfield, default is True AllowBlueprintBA: False # Dis-allow to spawn BA Blueprint in this playfield, default is True AllowBlueprintHV: True # Dis-allow to spawn HV Blueprint in this playfield, default is True AllowBPFactory: False #Will deny adding a BP to the factory or opening the factory; does not prevent opening the BP Libary # ==============================================================
I actually do not see a contradiction here. While I cannot be sure exactly what ties to which flg, they are all designed to be a little different. My guess is: AllowHV : controls is a craft can enter or be spawned AllowBlueprintHV : Controls if a Blueprint can be spawned My guess here is that "spawned" either refers to 2 different methods of spawning OR, more likely, these two flags overlap, insofar as AllowHV is just a group of flags that includes AllowBlueprintHV, and they simply set everything to false, despite AllowBlueprintHV being redundant to the more inclusive AllowHV flag. In either case, the intention here is clear: They do not want you bringing, or spawning a ship into/on Omicron. It is clear they want you to take the crappy ships on the ground, and build one up from the ground up.
Yeah, it could be that you can SAVE a HV blueprint but not spawn it, otherwise you can use one if you find it. That must be it, except that I still don't know if you can build one on Omicron. Because the player can use the new hoverbike, using a HV would not change very much in terms of mobility, but with a HV you could equip heavy weaons on it and attack a POI for loot and seen that most POIs are story-driven and the dev want to 'protect' them (keeping the storyline stable) the entire blueprint ban wouldn't make much sense otherwise.
Allowblueprinthv is redundant if allowhv is set to false because allowhv also prevents you from spawning a hv. It was probably just an oversight.
Redundant? Maybe... I am not 100% sure it's an oversight. Without knowing exactly how config files are read, it is impossible to determine. If all of those configs are required, or worse, default to true if not defined, then that could cause issues, depending on how, or what order, those configs are read/applied. Regardless, even if that flag truly is redundant currently, and could have been left out, it is generally good software engineering practice to set them all to false, should the code that handles them change in the future to, perhaps, allow a default true value for Allowblueprinthv to override allowhv in the future, regardless of what it does today. Pretty sure setting it all to false was intentional, and honestly, exactly what I would have done as well.
The default setting is true, otherwise all playfields would disallow spawning of any type. Using redundant parameters usually does not cause an issue, but it can and isn't good form. It can also lead to situations where if you want to change it later you might forget to change all parameters, leading to your intended changes not actually working (source: personal experience).
I'll start off by saying this first: I do not know your profession, training, or experience, but I respect your opinion, and your argument certainly has merit, particularly given your outstanding contributions to this community. You likely have more experience with these settings than virtually anyone, and your callout on missing redundant paramters is valid, and worth some attention (If I worked at Eleon, I personally would solve it with an editor that auto sets redundant parameters). That said, I do disagree on the "bad form" part. In Software Engineering, the redundant parameter setting is actually best practice, as the intention is to absolutely stop all spawning, and is thus a safeguard against future code changes that may alter how paramteres (including default ones) "stack" or "conflict." (source: being a software engineer in games for over 15 years).
This isn't software however, it's just config changes. Probably why I write them the way I do with the experience I have working with playfield and config files in this game. Things can break very easily and since we do not have access to the code, we have to make do with the config files available to us. Generally speaking redundant parameters like this usually do not make any difference, but there have been times when older parameters are changed or removed, or the way the game handles different parameters changes. The more you add to your playfield files, the more can break with them. Since playfields are actually a set of 3 files not just one (if a planet or moon), some settings are shared between them and in that case having redundant settings in one will actually lead to unintended results. For example there are several fog settings that can be set as a fixed value in playfield_static, but set as a random value in playhfield_dynamic. If you set your fog using both files, one will overwrite the other, making one setting useless. It's better to use one or the other, and generally you will want to simply use the random value in playfield_dynamic since it can be set to a fixed value anyway. This way you have a consistent workflow across all your playfields and won't forget to change the fog value in both file types. With the example in this thread that is not a problem, but I am a big proponent of forming habits and sticking with them as it makes it much easier that way. For me, that means not using redundant settings because it makes the config files more confusing and time consuming and more prone to errors. When you have several hundred playfield files to keep track of, cutting out unnecessary settings saves a lot of time and headache in the end.
Well... this IS software... I am speaking holistically as software design, not just "code." These config files are examples of what we refer to as "data" generally, and go hand in hand with software design. One of the biggest parts of software design, particularly in games, is how to handle the massive amount of data needed to run a complex environment like this. Our job as software engineers is to give designers [you, in this case] the tools they need to be able to create the worlds they want, and reduce the possibility of errors as much as possible. Now it is clear you have a deep understanding of how these configs interact with each other. You have pointed out various issues, some benign, others not so much, that all lead back to the overall design. That said, I will say this is to be expected from a game that is still in alpha (beta?). But ultimately, good software design is formed specifically to prevent the issues you are talking about. As I have done in the past, the ideal design is to create a tool that anticipates issues like this, and spits out the configs based on what you actually want, rather than modifying said files directly, with flags that may or may not be clear. But again, with a game like this, that is rapidly changing, such a finished and polished tool is unrealistic at this stage. Regardless, I happen to agree with your paradigm, generally. I just also understand why the devs did what they did in this thread's specific example.
