How to figure out "age" of the surface

[orzelek]

I've run into a bit of a problem in RSO when trying to handle spawning of starting areas.
Currently when RSO finds out about surface there is no way to figure out if that surface needs it's starting location created (since it has been just spawned) or it has existed for some time and shouldn't be modified.

Until now it worked because I have it implemented only for Nauvis and here I can assume that after few ticks it's treated as "already exists".

Using the surface_created_event doesn't really help in this case - due to lack of reliability of the creation event I might not get it even for a surface that has been created in exactly same game tick (this could happen when multiple mods are added to the save a the same time).

[eradicator]

Hm. Let's see...

If you get on_surface_created it's obviously been created that tick.
If you find the surface in on_config_changed or on_init shouldn't it be sufficient to assume it's been created on that game.tick? Is loading RSO into an existing map even supported at all?

For rough estimates:
Surface.index should always be in linear order, even if some surfaces were destroyed, old indixes are never assigned to new surfaces. (at least i've never seen any of the ".index" properties of any other prototype behave differently). So if surfaceA.index < surfaceB.index then B has definetly been created after A. So if you happen to know when A was created you know that B wasn't created *before* that.
Meh.

[orzelek]

Hm. Let's see...

If you get on_surface_created it's obviously been created that tick.
If you find the surface in on_config_changed or on_init shouldn't it be sufficient to assume it's been created on that game.tick? Is loading RSO into an existing map even supported at all?

...

Thats why I did actually. Assuming that Nauvis needs to be filled if it's early in game and any new surface is new only if I actually get surface creation event.
You can add RSO to existing map.. it might not look nice if added to map that has been explored a lot already but it will still work. Removal has been an issue.. for some reason game would not revert back to spawning ores normally.

[eduran]

I don't think there is a good way to handle this automatically. How do you know that a mod created surface should be touched by RSO? Just because it is new? What about mods like Factorissimo, i.e. surfaces that represent indoors areas? Or a mod creating a surface with properties specifically set by that mod? No matter how you do it, you are going to end up in situations where RSO gets it wrong and changes a surface that is not supposed to be changed or vice versa.

Wouldn't it be better to provide a remote interface that other mods can call to hand over a newly created surface to RSO, if that is what they want to do?

[orzelek]

I don't think there is a good way to handle this automatically. How do you know that a mod created surface should be touched by RSO? Just because it is new? What about mods like Factorissimo, i.e. surfaces that represent indoors areas? Or a mod creating a surface with properties specifically set by that mod? No matter how you do it, you are going to end up in situations where RSO gets it wrong and changes a surface that is not supposed to be changed or vice versa.

Wouldn't it be better to provide a remote interface that other mods can call to hand over a newly created surface to RSO, if that is what they want to do?

There is a reverse interface to allow other mods to tell RSO that it should not touch given surface. I Don't think I've added it to startup handling so I might need to fix that one up a bit.
You can also call interface that makes RSO ignore starting location and not spawn it.

I'd rather have explicit exception support in this case then require explicit call to register surface especially that game provides creation call and map settings contain starting position/s.

[eradicator]

There is a reverse interface to allow other mods to tell RSO that it should not touch given surface.

Eh, does that mean RSO will automatically fuck up *every* surface it's not told to stay away from?
Every surface-related mod will automatically break until someone sends a bug report to the author?
Looking at your download count i'm having a hard time not to be *very* upset about that right now.
I don't like when i have to actively code *against* other mods breaking my stuff.

...as i'm guessing you don't intend to change this to opt-in...
What are the magic words i have to chant to not be shot at by you?
And can you please document this behavior on the mod portal?

[orzelek]

There is a reverse interface to allow other mods to tell RSO that it should not touch given surface.

Eh, does that mean RSO will automatically fuck up *every* surface it's not told to stay away from?
Every surface-related mod will automatically break until someone sends a bug report to the author?
Looking at your download count i'm having a hard time not to be *very* upset about that right now.
I don't like when i have to actively code *against* other mods breaking my stuff.

...as i'm guessing you don't intend to change this to opt-in...
What are the magic words i have to chant to not be shot at by you?
And can you please document this behavior on the mod portal?

Why so much negativity?
RSO will act only on starting positions entered in map settings during surface creation. So you need to be explicit about it.

I'll update the documentation on forums. And if this behavior proves to be really problematic I will reverse the interface to have it opt-in only.

[eradicator]

Why so much negativity?

I try to keep my mods *correct* so that they behave normally regardless of what mods they're packaged with. I.e. that my mods at least don't crash or cause completely unexpected behavior. And from that perspective the assumption that you described RSO makes that *every* surface by default wants to be changed is simply wrong. From what i've seen on the mod portal most mods that do something with surfaces look like they would break if RSO touched their surfaces. Stuff like factorissimo, underground belt layers, etc.

I firmly believe that *any* default behavior should always reflect what *most* people do. From that perspective for example i also think that the vanilla default for enabling recipes if not explicitly enabled=false'ed is wrong, because most of the time recipes are *not* available from the start, but locked behind research. And from *that* perspective an opt-out to having "my" surfaces managed by RSO is simply wrong. Imagine i made a mod that automatically deletes all mod gui buttons unless they opt-out of being deleted. That is how i felt when i read you describe that. And then to top it off i couldn't find any documentation about it either.

And now that you say "only starting positions" i'm even more confused and properly want that documented so i can keep my mods working i expected them too. As due to your "download count power" i can't just ignore this information now, because chances are too high that it'll impact my users.

[Bilka]

Why so much negativity?

And now that you say "only starting positions" i'm even more confused and properly want that documented so i can keep my mods working i expected them too. As due to your "download count power" i can't just ignore this information now, because chances are too high that it'll impact my users.

+1. Whatever you (orzelek) changed completely broke the starting area stuff for my mod. So now it's broken with RSO again, after I just fixed it because you removed a remote function. I found it rather rude that you removed the previous remote function without even putting it in the changelog, so I'd really appreciate if you could make an easily findable announcement for whatever changes you did in your latest version/are planning to do. Mostly because I expect literally every mod dealing with surfaces and your generation to be broken by it.

[orzelek]

Why so much negativity?

And now that you say "only starting positions" i'm even more confused and properly want that documented so i can keep my mods working i expected them too. As due to your "download count power" i can't just ignore this information now, because chances are too high that it'll impact my users.

+1. Whatever you (orzelek) changed completely broke the starting area stuff for my mod. So now it's broken with RSO again, after I just fixed it because you removed a remote function. I found it rather rude that you removed the previous remote function without even putting it in the changelog, so I'd really appreciate if you could make an easily findable announcement for whatever changes you did in your latest version/are planning to do. Mostly because I expect literally every mod dealing with surfaces and your generation to be broken by it.

I'm sorry guys but I have no idea what's going on anymore. Changes I did were after your post Bilka that asked for RSO using starting positions from map settings of a surface instead of requiring explicit calls.
And removal of that interface happened because I changed it into commands. I missed the fact it wouldn't be callable any more from other mods due to that.
It seems that I caused much more problems then anticipated when adding surface support to RSO and with the unexpected interface change. Sorry for that.

Location of starting points I used is from starting_points property in https://lua-api.factorio.com/latest/Con ... enSettings
It was a fix for players that would modify starting location in server settings in multiplayer and then get dropped in wrong place in RSO.

I will recreate the interface that was removed, without the true/false switch to reset the seed for now.
And then remove automatic usage of starting_points and go back to requiring explicit calls of AddStartingLocation to generate starting areas other then the initial one.

Would that be ok to make it work properly again and adress the concerns with RSO messing up other surfaces?

Edit:
I'm releasing above as described in 5.0.9. Let me know if any other changes are needed.

[Bilka]

I don't think I was very clear in what the problem was. I don't need the "regenerate" interface, it just annoyed me that you nuked it without saying so.

All I care about is a way to make RSO work for my new surface. Preferably without you breaking support for mods that used your old interface. I had this until 5.0.8 where you somehow broke the starting area generation again.

So, again the question for documentation: How do I make RSO generate normal ores on my surface?

[eradicator]

What i care about is "how do i make RSO *not* touch my surfaces", which i think should be the default because i don't understand how you can assume that it's ok to require every (newbie) modder to know your mod exists. While i think it's quite ok to ask modders who want their mod integrated with RSO to do an extra call.

Basically my metric is that "defaults" should be chosen in a way that requires the *least amount of work* for the cummunity as a whole. And i think there exist more mods that will need to opt-out than there are mods that need to opt-in. And i'd really like to convince you to swap that default ;).

For that matter i am also interested in your reasoning to chose opt-out over opt-in.

_______
Your forum thread says

Code: Select all

remote.call("RSO", "ignoreSurface","surface name")

I assume i need to call that *before* even creating the surface?
And i'd prefer if that was also linked from your FAQ page on the mod portal as that is where i would look first. (And that kind of thing is infact why i asked wube to implement the FAQ page in the first place ;).

Code: Select all

Q: How do i integrate my mod with RSO?
A: Please look at the forum thread [link]

Q: How do i stop RSO from generating ores on my modded surface?
A: Please look at the forum thread [link]

[orzelek]

In 5.0.9 default is off now - RSO will not create any starting location without being instructed to by remote interface.
It will spawn ores on a surface normally assuming center of surface being on 0,0. It will use map settings from the surface to define how it should generate ores for that surface.

If it doesn't work as above let me know.

If you want to spawn starting location for player then you will need to use the addStartLocation interface to give location to RSO. It will then generate starting location in the same way as the initial one on Nauvis.

For ore generation it generates ores by default because it tries to behave as base game. If you set in map settings that you don't want the ore (size = 0) then it will not spawn that ore.
Starting location spawning looked like good idea on paper since game already has starting_positions in map generation settings. So if game treats this area as starting location I assumed that RSO could do that automatically too. It seems it wasn't that good of an idea.

Tbh I didn't look into the FAQ page - I might need to do that.