Are Prototypes and PrototypeMaps read only

[sboigelot]

@TomMalbran and I were discussing about modifying and adding Prototypes at runtime in #1369

What are your opinions about it?

Should we allow code to:

• Add prototype (we already do it in the Schedule event and I don't really like it)
• Modify prototype
• Add extra information to prototype

If yes to any of the above, should we save the prototypes in the save file?

As you can guess from my italic remarks, I'm not a fan of it. For me the prototypes should be created at load time, and reflect exactly what is in the xml definitions files. But I can see the ease of using them to store additional information.

[sboigelot]

from @TomMalbran

A prototype is only an instance of a class that you will want to copy so that it preserves the default values and then change the rest. I see no problem in changing it at run time, when we need to change a default for all the new instances created from a prototype or to add new prototypes that we will later copy, or even remove ones that we don't want anymore.

The issue here is that technically we don't need to clone the prototypes, since at the moment they don't hold data that will change at some point. But that will change when we expand the system.

[TomMalbran]

I was going to comment here. @sboigelot from that quote remove the last 2 paragraphs since those are specific to the HeadlineGenerator function.

We don't really need to save the changes, since would have been specific to playthrough. If required, they can be saved, but in the player dave file, and not modifying the original xml.

[dusho]

I also wouldn't change the prototype in runtime.. I think it's asking for troubles (desync between UI and logic). You change something in prototype (e.g. MaxStacksize or something) and then you will force some OnChanged on every instance of prototype? to have e.g. UI in sync with game logic.

[mikejbrown]

I don't like the idea of prototypes changing at runtime either (adding new prototypes excepted). What would be an actual gameplay use case for it?

[bjubes]

the only case i see is loading in a mod at runtime, which even then isn't a great case considering that could really mess up other components of the game, including saves.

[TomMalbran]

At some point everything in Streaming Assets will be a mod, and they will all be loaded and their prototypes set, and even overwritten, since a mod could overwrite another one. And when we have an UI to manage the mods, they will change the prototypes. But all of this is outside the actual game.

We could agree that modifying a prototype is not good, but I think that adding new ones can be beneficial. But once we have better mod support, we could just load the prototypes from different files which might even remove the need to add new prototypes at runtime.

[dusho]

for modding there should be also some name and order resolver, I guess. There may be some conflicts in names (e.g. someone else names Power Generator), then it will either break (name already exist in dictonary?) or one that is loaded as latest will be used Other solution would be to have every modder have their own folder (with custom mod files, e.g. StreamingAssets/mods/{author}/...), then if conflicts are detected, we would append {author} name to name of item (e.g. Power Generator ({author}) )

[koosemose]

In my opinion a prototype should not be modified during actual game play, if it needs to be modified during gameplay that suggests it isn't in fact a prototype. I'm also rather dubious of prototypes being added or removed during gameplay, and think that in at least most cases if it needs to be removed or added it is probably also not a prototype.