[0.12.x] RSO Discussion thread

[StoneLegion]

Any chance for multiplayer support for multiple starting areas?
https://forums.factorio.com/forum/vie ... 33&t=14409

[orzelek]

Any chance for multiplayer support for multiple starting areas?
https://forums.factorio.com/forum/vie ... 33&t=14409

I posted reply in that topic. Lets keep this discussion there for now.

[Grimshad]

If I could make a request:

Please add the ability to create multiple starting resource spawns depending on the amount of players. I am currently creating custom scenarios for this purpose, but it would be better to have it randomized. I play with friends where we are on separate forces, but not enemies and we race to see who can advance faster.

So this is how it should look if you create starting resources for multiple forces. Each [] is a starting spot that generates starting resources.

1 player:

[]

2 players:

[] []

3 players:
[]
[] []

4 players
[] []
[] []

Thanks for considering


EDIT: Just realized someone else already asked for this exact same thing.

[orzelek]

Yes - and see my reply on that thread.
It's a bit complicated so not sure when I will have time to play around with it.

[StoneLegion]

Not sure where I got this again was from reddit post long time ago prob here as well. It let my friend and I start 8k blocks away but I can't get the code working.

So this code is what we used to hand set our spawning locations. This means the host starts at like 8k something and my mate would start at normal spawnish. I would then hand do the spawn in the editor.

Edit Fixed Versions here for 0.12: https://forums.factorio.com/forum/vie ... 25&t=14447

Code: Select all

require "defines"

function init()
  if not glob.deadPlayers then
    glob.deadPlayers = {}
  end
end
game.oninit(init)
game.onload(init)

game.onevent(defines.events.onentitydied, function(event)
  if event.entity.type == "player" then
    for index, player in ipairs(game.players) do
      if not player.character and not glob.deadPlayers[index] then
        glob.deadPlayers[index] = true
        break
      end
    end
  end
end)

game.onevent(defines.events.ontick, function(event)
	for playerIndex, value in pairs(glob.deadPlayers) do
	local player = game.players[playerIndex]
   		if player.character then
			if playerIndex % 2 == 0 then
   				local position = game.findnoncollidingposition("player", {-63,67}, 50, 1)
	   			if position ~= nil then player.teleport(position) end
	   		else
   				local position = game.findnoncollidingposition("player", {-159,-8105}, 50, 1)
	   			if position ~= nil then player.teleport(position) end
			end
   			glob.deadPlayers[playerIndex] = nil
   		end
	end
end)

game.onevent(defines.events.onplayercreated, function(event)
	local player = game.players[event.playerindex]
   		if player.character then
			if event.playerindex % 2 == 0 then
   				local position = game.findnoncollidingposition("player", {-63,67}, 50, 1)
	   			if position ~= nil then player.teleport(position) end
	   		else
   				local position = game.findnoncollidingposition("player", {-159,-8105}, 50, 1)
	   			if position ~= nil then player.teleport(position) end
			end
   		end
end)

[Grimshad]

Yes - and see my reply on that thread.
It's a bit complicated so not sure when I will have time to play around with it.

So I'm not asking for the complexity you're thinking. I'm pretty sure you want to give each player a random start point and spawn resources at that location while protecting that location.

I still want 1 single spawn point for all players, right at 0,0 and still 1 starting area. However, the starting area size can be determined by the # of players and resources as well.

For example: If there are 2 players, double the start area protection/size. Then spawn the starting resources, but x2 with an offset. So if start is 0,0. then iron will spawn twice, once at -5 and once at +5.

The only thing that needs to be changed then are the # of players. Each # will have a starting area size, a # of starting resource groups to spawn, and the offsets for each group.

As far as i'm concerned none of this needs to be automatic either. I'll gladly open the config and change the player count (or start resource group count) as well as offset the groups from start manually.

[StoneLegion]

I had done the spawning of resources before by hand on the map editor and the above script actually sets the players locations.

But remember Biters are worse the deeper out you venture. So I assume that is where things would be tricky.

[AnarCon]

this version started freezing my game about 8 hours into a game.
in addition i had
explosive termites 1.1.6
landfill 2.1.5
dytech power 1.1.0
supremewarfare 1.0.4
treefarm-lite 0.2.0
dytech core 1.2.0
treefarm ac 0.2.1
dytech machine 1.1.0

every time i tried walking southwest towards my big power poles it kept freezing on me

[Gandalf]

I recently started a new world, my first with RSO. I have only vanilla ores and I left everything on normal except for biter bases (high). I was quite surprised by how rare both ores and aliens are with these settings, but that's actually fine. However I've been exploring quite a large area now and I haven't found any larger ore patches.

It was my understanding that with RSO the more distant ore patches would be bigger/richer. Is this correct? I.e., if I travel in one direction for a very long distance, will I eventually find an ore patch that doesn't run out in under half an hour?

To put it differently: I like it that I have to find ways to efficiently transport ores over a long distance, but I don't want to have to build new outposts every five minutes. Is that what RSO does (with default settings) or am I using the wrong mod?

[yeganer]

RSO should create big patches at far distances but i noticed that the resource in each spawn seems to be really low. I am currently using map gen settings big and very rich and i'm getting 200-500 ore per tile which is really bad compared to ~2k before the update. so it seems some balancing needs to be done there. I think i might be able to look into that tomorrow.

@AnarCon:
Could you enable debug view (F5) and then walk into that area? if RSO is causing the problem the mod-rso part in the scripting part of the game update would have high values. For me mod-rso has a value of ~0.02 while generating chunks, 0 otherwise.

[orzelek]

There was a lot of feedback that resource patches are to rich. So they aren't now

I might increase base amount (2-4x) and then make the richness setting in map settings to have more significant impact - it will allow people to modify it to their liking in an easy way.
And/or will play more with distance richness factor mainly to make richer deposits when you go far. Since it currently works on regional distance it might not be that visible (region is about 210 tiles by default). Might make it chunk based or simply increase it a bit.

I admit that I'm using 2x global richness multiplier by default but I'm playing with science costs tweaker so need lots more resources for research.
I also noticed that remote patches are not that big even with 2x modifier applied altho I wasn't traveling very far.

It's quite hard to balance this - and previously patches were reaching few mil ore per patch which made you only need one patch for whole game. Quite often it was only the starting patch and you were set. A lot also depends on playing style I think and thats quite difficult to balance

[roisto]

Hi,

I finished my first play trough in 0.12 with RSO. I left every setting normal. Game-play was quite laid back. Not much enemy bases nearby, even in desert I was almost left alone at start. Especially after I cleared couple bases. Starting area contained plenty of resources didn't have any hurry to expand.

When I started to build outposts I notice same thing as Gandalf and yegamer that even in relative faraway patches depletes rather quickly.

I took a look the default setting generated map in sandbox mode. It seems like to be 2 kinds of patches, one that have huge area but very low richness other one small but very dense. Is there perhaps a bug, those looked like from two different generators.

What I like to have on my next game is bit more intense game. Little more bitters, less but bigger patches. How does map setting actually effect the map generation? I kind a dropped by the wayside with this transition from pure config file to this dual configuration.

--edit--

Oh and I only need one oil outpost for whole game. I had to tap maybe half of it. It is wast on direct neighborhood but still it was the closest one. It richness of the oilfields where 966,960, 822, 614, 556, 465, 311,226 and 177.

[orzelek]

this version started freezing my game about 8 hours into a game.
in addition i had
explosive termites 1.1.6
landfill 2.1.5
dytech power 1.1.0
supremewarfare 1.0.4
treefarm-lite 0.2.0
dytech core 1.2.0
treefarm ac 0.2.1
dytech machine 1.1.0

every time i tried walking southwest towards my big power poles it kept freezing on me

I can't reproduce the issue here. By freezing you mean game is stuttering or it completely dies?

Please provide me your copy of RSO config file - it seems I really need to cap some modifiers.
This map has resources with one node exceeding 8 mil of ore per node. I think you went seriously overboard with some of parameters so resource patch generation is taking significant amounts of cpu time - and there is water northwards which means that it will try to generate a lot of resources on it and fail.

I need to definitely cap patch size modifiers - patches bigger then 32 tiles should be rare or none. Making them to big makes it very slow on resource generation and can also lead to strange issues with generated patches.

[orzelek]

Hi,

I finished my first play trough in 0.12 with RSO. I left every setting normal. Game-play was quite laid back. Not much enemy bases nearby, even in desert I was almost left alone at start. Especially after I cleared couple bases. Starting area contained plenty of resources didn't have any hurry to expand.

When I started to build outposts I notice same thing as Gandalf and yegamer that even in relative faraway patches depletes rather quickly.

I took a look the default setting generated map in sandbox mode. It seems like to be 2 kinds of patches, one that have huge area but very low richness other one small but very dense. Is there perhaps a bug, those looked like from two different generators.

What I like to have on my next game is bit more intense game. Little more bitters, less but bigger patches. How does map setting actually effect the map generation? I kind a dropped by the wayside with this transition from pure config file to this dual configuration.

Game settings should work as expected - they apply a modifier to values set in config files.
If you are curious about actual modifiers they can be found in control.lua at the beginning as set of tables.
It treats enemies in same way as resources currently - I might need to change that. There is also nothing currently that can increase amount of bases per region only their size. I can tie this to richness and size settings on enemy bases.

The 2 kinds of patches you are seeing is actually working as intended. There is a simple algorithm that will detect if there is a lot of space around and then generate this bigger deposit. It does produce very low values currently - might need to look at it and buff richness more when this generation is activated.

Are those patches really that easy to deplete ?

I'm usually using one of big mods and often playing on infinite resources so I don't have a lot of experience with that.

[yeganer]

The Problem with the current Ore gen is that you calculate a total resource value for the deposit, devide that by the number of patches and then calculate each patch size the following way:

Code: Select all

amount = min + force * (avg - min)

This results in the following:
If the patch is too big (total amount < #patches * min ) then patches start to have less than min amount of resource.
The 2nd problem is that the total amount is only connected to the size by some simple multiplication.

The way i think it should work would be that the total amount is calculated and if that isn't enough the multiplier is increased.
But since your force gives values between 0 and ~2 (i think it's capped kind of) the multiplier should be static, like 1000. This multiplier could then be modified by the distance and the map_gen_settings and optionally, if the deposit is too small increase it so the deposit total is big enough.

Code: Select all

amount = min + force * ( 1000 + map_gen_mod + patch_size_mod )

Of course the numbers should be tested further. but i'd say 1000 should be a good start

[orzelek]

Hmm can you tell me how did you come up with the first equation?
Actual one should be different and works in slightly different way.

The fact that some patches (big variant) have values lower then minimum comes from actual minimum amount reduction applied for patches in question.

Force calculation should never exceed 1. If it does let me know - it's a bug

Calculation you are proposing is the previous variant of ore generation. It doesn't give you any control over total resource amount and makes it dependent on patch size in very difficult to predict way.
I'd rather not go back to it.

Alternative is to use it and abandon all ideas about balancing of ore amount per patch. There is simply no way to predict total deposit ore amount with this new variant - there is no way to estimate total force value of whole deposit due to way that p/n-balls interact with each other.

[yeganer]

The first equation is in the source code control.lua line 531 and 536.
Since the approxDepositSize is always > 0 and the amount doesn't drop below the min amount. sorry i was wrong there. but the problem that big patches have only around 300 resources per tile persists.

The problem started when minSize and maxSize were made independent of the resource size because every patch now has the same resource, big patches just generate more tiles with less ore per tile.

The "old" approch garantees that the tiles have a reasonable amount of ore (~1-2k should be the minimum for tiles in the center). You are right, it's impossible to estimate the size of the spawn but without changing the current implementation it's not fun to set patches to big or very big. they are mined in ~30 min.

In my opinion there should be a bit of "luck" involved when generating ore patches. Either you get a big one with tons of resouces or you get a small one with only a fraction. But i think it's bad that every patch has the same resources, regardless of it's size.

One could add some small balancing. A factor that is tied to forceTotal. If forceTotal is too big, the factor is negative and reduces the size, if it's too small it's positive and increases the size.
something like

Code: Select all

force_factor = 1/(1+exp( (forceTotal - a) / b ) ) - 0.5
amount = floor(location.force * richness + min_amount + scale * force_factor)

a careful choice of a, b and scale should balance the thing. the force_factor is distributed according to the Fermi Dirac statistic. but one could choose any other method to calculate a forcefactor

[Vin]

In my opinion there should be a bit of "luck" involved when generating ore patches. Either you get a big one with tons of resouces or you get a small one with only a fraction. But i think it's bad that every patch has the same resources, regardless of it's size.

I strongly agree with this sentiment. RSO for me is about encouraging exploration and stretching out into the world. Having an actual system of discovery that makes for small excitement on finding new resources is key, and the chance of finding (and actually finding) a resource patch that has both large size and high richness can supply that. Of course, in order to have overpowered patches, there also need to be underpowered patches for balance and fun. If every patch is exactly the same, finding new patches becomes very repetitive.

Also, having patches that are worth building more than an ad hoc train stop to strip mine the place in very little time is very nice.

[orzelek]

@yeganer
I was aiming to make it simple. As simple as possible actually. Previous formula included relation to patch area and it was to rich for big patches due to large increase of amount of ore.

I'm actually pretty close to resign from any attempts at balancing total amount of ore per patch.
Simplest function of richness*factor*constant will also work and can generate quite varied ore patches. Starting area should cope somehow by using minimum spawn amount as now and other patches will be much more varied.

[jorgenRe]

Hey would it be possible to manually add new ores in(adding a new mod to the game after creating the game) without having to regenerate the whole map resources?
Since game.regenerate_entity does not work
For the moment i will just regen some of the ore deposits i dont need into y-res1 and 2 !