Page 1 of 1

Additional dynamic technology effects

Posted: Mon May 22, 2017 10:10 pm
by deer_buster
TL;DR
Add additional technology effects that allow dynamic control of raw data

What ?
Currently, the technology effects are limited to what is "possible" in the modifier for the TechnologyPrototype (e.g. Possible values are "inserter-stack-size-bonus", "laboratory-speed", "character-logistic-slots", "character-logistic-trash-slots", "num-quick-bars", "maximum-following-robots-count", "logistic-robot-speed", "logistic-robot-storage", "ghost-time-to-live", "turret-attack", "ammo-damage", "give-item", "gun-speed", "unlock-recipe".). I would like a type of modifier that allows us to directly modify a value.

For Example:
effects = {
{
type="direct-modifier",
modifiers = {
data.raw.transport-belt["transport-belt"].speed = 0.04,
data.raw.transport-belt["transport-belt"].max_health = 175
}
}
}
Why ?
It would allow for more interesting technology mods, allowing the creativity of the community to shine.

Re: Additional dynamic technology effects

Posted: Tue Aug 15, 2017 1:39 am
by BrokenScience
I would love to make a mod that adds some technologies that reduce robot energy consumption, but this is not one of the modifiers.

I would very much like to see the modifiers removed in place of something that just allows the changing of values in data. As for what I understand, all the modifiers change values in data (e.g. "recipe-unlock" does the equivalent of changing the 'enabled' value in data to true for a recipe, etc), so I would like to think that there is a way to change nearly everything.

Re: Additional dynamic technology effects

Posted: Fri Sep 29, 2017 6:07 pm
by deer_buster
this is still needed IMHO. The only alternative we have is to replace existing entities with new updated entities, which is inefficient.

Re: Additional dynamic technology effects

Posted: Fri Sep 29, 2017 6:23 pm
by Rseding91
That's literally not possible to do: prototype values are immutable after startup - they cannot be changed for the lifetime of the game instance and everything depends on that.

Every modifier type is a link to backing C++ logic that stores them (per force) and handles changing the values + notifying what needs to know they changed when they change.

Every property that's possible to change runtime is copied from the prototype and saved per-entity. That means if you can change it runtime it's always saved in the map. As it is now because you can't change any prototype property none of them have to be included in the save file. That means the save file isn't massive and runtime memory usage is as small as it can be.

To make such a system work would reduce runtime performance by *far* more than simply replacing entities runtime with different versions.

Re: Additional dynamic technology effects

Posted: Fri Sep 29, 2017 7:30 pm
by deer_buster
Rseding91 wrote:That's literally not possible to do: prototype values are immutable after startup - they cannot be changed for the lifetime of the game instance and everything depends on that.

Every modifier type is a link to backing C++ logic that stores them (per force) and handles changing the values + notifying what needs to know they changed when they change.

Every property that's possible to change runtime is copied from the prototype and saved per-entity. That means if you can change it runtime it's always saved in the map. As it is now because you can't change any prototype property none of them have to be included in the save file. That means the save file isn't massive and runtime memory usage is as small as it can be.

To make such a system work would reduce runtime performance by *far* more than simply replacing entities runtime with different versions.
Could entities not have override properties stored on a per force basis? That way only the changed properties need to be stored. If they are strongly addressed it shouldn't be that difficult to apply them or store them.

Re: Additional dynamic technology effects

Posted: Fri Sep 29, 2017 7:46 pm
by Rseding91
deer_buster wrote:Could entities not have override properties stored on a per force basis? That way only the changed properties need to be stored. If they are strongly addressed it shouldn't be that difficult to apply them or store them.
That's how the current technology modifiers work (they're stored on the force instance) but you can't "only save what's changed" because at load time you would have no idea what should and shouldn't be loaded.

Re: Additional dynamic technology effects

Posted: Fri Sep 29, 2017 7:57 pm
by deer_buster
Rseding91 wrote:That's how the current technology modifiers work but you can't "only save what's changed" because at load time you would have no idea what should and shouldn't be loaded.
So you can't add a new property & value to a force at run-time and have it saved???? Should only save and load what has been overridden.

I know it is the bane of my existence when a non-developer tries to tell me how easy it should be to change some functionality when they don't understand the code, or even programming for that matter, but that seems like it should be easy enough to do.

Re: Additional dynamic technology effects

Posted: Fri Sep 29, 2017 8:07 pm
by Rseding91
deer_buster wrote:So you can't add a new property & value to a force at run-time and have it saved????
No, the backing C++ logic must support anything you can do runtime.