[MOD 12.11+] Train Outposts

[Jonny]

[Marchombre]

Hi,

I can make a switch in the config. Resources should still be somewhat balanced, but I will not design the balancing for the non-endless mode.

Thank you

[Qon]

After playing with the mod for a lot of time I can say I do not like it. The real problems aren't really something that you would notice until it's too late though. I guess I'll have to try and see if RSO can fix (heard it has on-demand resource regeneration) the mess this has left because it's too late to restart.

Problems:
I have more resources then I can mine from my starting area. I did set resources to very big and rich, but these get extremely big very close to where I started. I didn't even mine the tiny patches that was at (0,0 because) I had big and ultra big patches within walking distance. I thought this mod was supposed to spread them out?

No resources at all at long distances. I get a few fairly big patches of stone and and oil at a distance >2k tiles. And natives. But that's it. No iron, coal or copper at all so far. But I've limited my search now because...

Load times. Discovering new terrain increases load times by a huge amount. Using STRS long range radar will increase load times by like 20 seconds for each full scan area. When the save file loading completes it stays at 100% for over a minute if you use three of them! Without train outposts mod the load is instant! I had to reset to an earlier save with less discovered area before I found out TO was at fault because it increases load times to ridiculus times if you explore.

Mod incompatability. If you have another mod that adds new types of ore patches then forget about using them. This mod removes ore spawning from all other mods.

With the huge ore patches I get and a minimum of 50%, I don't even notice that they give less over time. I still use the very first iron ore patch I hand mined when I began and I haven't placed miners on half of the available area of it. I'm at the end game. Just for comparison I use 0.4GW of power. The only train I use is a single single oil tanker wagon train that goes to small oil field at belt distance.

So the result is a mod that is doing it's very best to discourage you from exploring, using other mods, using trains and everything it says it encourages. I'm disappointed.

[SirRichie]

First of all, thank you for the feedback.
Some of the things you mention (load times, mod support, no resetting of resources at runtime) have been called out before and are on the list to be fixed for the next version.

What I do not understand, however, is that you complain about resource patches that are too big, when you have set them to very big.
Admittedly, I never balanced for these settings other than have a map generated and look at the sizes. Seeing that quite a number of others like the balancing on normal settings make me believe that balancing is generally in a good shape though.
Bottom line: if you do not want such big patches, do not set them to so big.

[Qon]

First of all, thank you for the feedback.
Some of the things you mention (load times, mod support, no resetting of resources at runtime) have been called out before and are on the list to be fixed for the next version.

What I do not understand, however, is that you complain about resource patches that are too big, when you have set them to very big.
Admittedly, I never balanced for these settings other than have a map generated and look at the sizes. Seeing that quite a number of others like the balancing on normal settings make me believe that balancing is generally in a good shape though.
Bottom line: if you do not want such big patches, do not set them to so big.

I want them to be big, but not so close to my spawn. I have massive coal, iron and copper within my base of a few hundred tiles in radius. I use belts and robots (modded but it could work with unmodded too) to transport ore from miners to the production area. And I set resources to low frequency also. That does make them bigger in vanilla, but it shouldn't make them so close at least.

I played vanilla before with big resources and medium frequency and they were smaller but far away enough that I used trains at least. They weren't extremely far away but for a medium frequency setting with no mod that should space them out it was far compared to what I have now.

The problem isn't that they are big, but that they are big within belt and walking distance of eachother and spawn. These huge ore patches are something like 600~ tiles from world origin and within 200 tiles from eachother.

[SirRichie]

In that case, you may want to go with the normal size. Patches will grow with distance and you will find lucrative (=big) ones that will make you use a train.

Also (and this is intentional and indicated), the resource settings do not work as in vanilla. I believe they work the way you would guess from their labels. In vanilla, resource frequency affects patch sizes. In my mod, this is not the case. It's just the frequency, period.

[Qon]

In that case, you may want to go with the normal size. Patches will grow with distance and you will find lucrative (=big) ones that will make you use a train.

Also (and this is intentional and indicated), the resource settings do not work as in vanilla. I believe they work the way you would guess from their labels. In vanilla, resource frequency affects patch sizes. In my mod, this is not the case. It's just the frequency, period.

Well for that I need a way to change settings and regenerate all ores.

Well vanilla uses perlin noise for world gen so if you are familiar with it and the mathematical use of frequency on wave functions then it's intuitive.

Well I still wonder why there is ore so frequently with TO.

[Alkel U3]

At first seemed great. However, it would be worth explicitly noting that it only works with vanilla resources in the first post. I got quite many hours into a game with this and Homeworld and only then found out there's no sand to mine from the deserts.

Also the rather longer map segment generation leads to funny stuff like driving a car far far away from the base, poof,huge copper patch spawns on me, poof, biter nest spawns in front of me and I crash into it . Seems like radar-based exploration is the only safe approach.

[SirRichie]

Yes... sorry about your wasted hours... I hope I'll try to find some time this weekend to implement support for other ores and resource regeneration.

And I am continuously improving the chunk generation overhead, so hopefully, there will not be so many funny things in the future. Although if also happens without the mod... if you go fast enough...

[joozek]

I'm having the same error as Jonny when I enable Test Mode. Without it it works fine.
Error for reference:

Code: Select all

---------------------------
Error
---------------------------
__TrainOutpost__/data-updates.lua:5: attempt to index field 'autoplace' (a nil value)
---------------------------
OK   
---------------------------

Oh BTW, Thanks SirRitchie! It's my favorite mod!

[SirRichie]

Thank you.
This is because testmod implements its own ores and that's what confuses TO so far.
That will change in the next release (I hope).

[SirRichie]

And... here is the latest release with support for bob's mod and also support for any other resource-adding mod (I hope). There will still probably be some bugs, so please report if you find any.
Also in this release: code rewrite for performance improvements, use native math.random

See first page for download and detailed info.

[pdiddy973]

when i try an load a game i get this error

[DerGraue]

Hi there,

first off, thanks for this awesome mod! I really like how the resources are distributed over the map, it's far better than in the vanilla game.

However, I'd really like the ore resources not to be infinite. You mentioned in a previous post in this thread that you could implement that option in your config file. I looked it over and found in "data-updates.lua" the line:
" data.raw.resource[resource_name].infinite = true ". If I set this to false, the resources are actually not infinite anymore, however I have no clue what I am doing xD

Is this the correct way to do this or did that break something in your mod that I am not aware of?

[Qon]

Der, I think the reason it's not in a config yet is because finite ores are not balanced yet. So if you just turn it off you get finite ore that are not balanced with regards to the distribution. So you might get ore patches that are way smaller and way poorer than what is reasonable because they are meant to be infinite. And on top of that that they are also spread out further by the mod. You do it at your own risk.

I didn't get them properly balaced in infinite mode either though...

[DerGraue]

The balance is not the issue for me, since I can alter the settings in the configs anyways.

I was rather asking about creating a bug with that change.
Actually, I just realised that with my change the oil patches became a finite resource as well, which was not really my intention

I managed to fix that problem by puttinge the true/false variable into the if statement:

Code: Select all

-- make resource infinite
	-- data.raw.resource[resource_name].infinite = false
	if resource.category and resource.category == "basic-fluid" then
		data.raw.resource[resource_name].infinite = true
		data.raw.resource[resource_name].minimum  = to.config.liquid_min
		data.raw.resource[resource_name].normal   = to.config.liquid_normal
	else
		data.raw.resource[resource_name].infinite = false
		data.raw.resource[resource_name].minimum  = to.config.resource_min
		data.raw.resource[resource_name].normal   = to.config.resource_normal
	end

I don't know if that is smart, but that worked

However, I can't load savegames, so I have to wait for a fix anyways

[SirRichie]

Sorry about the loading bug, I should have tested this, but I was so glad to be finally done with some major changes.
The fix is coming soon - I do not think it is a huge problem.

Regarding the non-endless mode. The changes you make are perfectly sane. You will not create any bugs.
You may want to increase the minimum patch size a bit and probably increase the size of the starting resources, unless you are looking for a good challenge.

[sparr]

A hacky fix for the loading problem:

Code: Select all

diff -ru TrainOutpost_1.0.1.broken/config.lua TrainOutpost_1.0.1/config.lua
--- TrainOutpost_1.0.1.broken/config.lua	2016-05-29 16:43:50.000000000 -0700
+++ TrainOutpost_1.0.1/config.lua	2016-05-30 20:00:15.000000000 -0700
@@ -92,7 +92,7 @@
 
 	if not to.config.resources then to.config.resources = {} end
 	base:update_ores(to.config.resources)
-	if game.entity_prototypes["tin-ore"] then bobores:update_ores(to.config.resources) end
+	if game and game.entity_prototypes["tin-ore"] then bobores:update_ores(to.config.resources) end
 end
 
 function to.config.init_enemies()
@@ -102,8 +102,8 @@
 	to.config.unit_spawner = base:update_spawner(to.config.unit_spawner)
 	to.config.turret = base:update_turret(to.config.turret)
 	
-	if game.entity_prototypes["bob-biter-spawner"] then bobenemies:update_spawner(to.config.unit_spawner) end
-	if game.entity_prototypes["bob-big-fire-worm-turret"] then bobenemies:update_turret(to.config.turret) end
+	if game and game.entity_prototypes["bob-biter-spawner"] then bobenemies:update_spawner(to.config.unit_spawner) end
+	if game and game.entity_prototypes["bob-big-fire-worm-turret"] then bobenemies:update_turret(to.config.turret) end
 end
 
 -- TODO
Only in TrainOutpost_1.0.1.broken: control.bak
diff -ru TrainOutpost_1.0.1.broken/control.lua TrainOutpost_1.0.1/control.lua
--- TrainOutpost_1.0.1.broken/control.lua	2016-05-29 16:43:10.000000000 -0700
+++ TrainOutpost_1.0.1/control.lua	2016-05-30 20:00:43.000000000 -0700
@@ -467,21 +467,23 @@
 	global.to_enemies.turret.size_max = to.config.turret.size_max
 	global.to_enemies.turret.size_distance_adjust = to.config.turret.size_distance_adjust
 	
-	for entity, entity_specs in pairs(game.entity_prototypes) do
-		if entity_specs.type == "unit-spawner" then
-			-- create empty table to which we can copy
-			global.to_enemies.unit_spawner.types[entity] = {}
-			copy_table(to.config.unit_spawner.default, global.to_enemies.unit_spawner.types[entity])
-			if to.config.unit_spawner.types[entity] then
-				copy_table(to.config.unit_spawner.types[entity], global.to_enemies.unit_spawner.types[entity])
-			end
-		elseif entity_specs.type == "turret" then
-			-- create empty table to which we can copy
-			global.to_enemies.turret.types[entity] = {}
-
-			copy_table(to.config.turret.default, global.to_enemies.turret.types[entity])
-			if to.config.turret.types[entity] then
-				copy_table(to.config.turret.types[entity], global.to_enemies.turret.types[entity])
+	if game then
+		for entity, entity_specs in pairs(game.entity_prototypes) do
+			if entity_specs.type == "unit-spawner" then
+				-- create empty table to which we can copy
+				global.to_enemies.unit_spawner.types[entity] = {}
+				copy_table(to.config.unit_spawner.default, global.to_enemies.unit_spawner.types[entity])
+				if to.config.unit_spawner.types[entity] then
+					copy_table(to.config.unit_spawner.types[entity], global.to_enemies.unit_spawner.types[entity])
+				end
+			elseif entity_specs.type == "turret" then
+				-- create empty table to which we can copy
+				global.to_enemies.turret.types[entity] = {}
+
+				copy_table(to.config.turret.default, global.to_enemies.turret.types[entity])
+				if to.config.turret.types[entity] then
+					copy_table(to.config.turret.types[entity], global.to_enemies.turret.types[entity])
+				end
 			end
 		end
 	end
@@ -584,7 +586,9 @@
 	-- initialize the random number generator again
 	init_rng()
 	-- initialize the weights again, as we rely on them
+	to.config.init_ore()
 	read_resource_settings()
+	to.config.init_enemies()
 	read_enemy_settings()
 	init_weights()
 end

[keyboardhack]

The error is thrown by these two lines in the on_load method.

Code: Select all

read_resource_settings()
read_enemy_settings()

Now the on_load method doesn't do this but before you can actually call the above two methods you have to call these two methods below to construct the settings.

Code: Select all

to.config.init_ore()
to.config.init_enemies()

Problem is just that those two methods rely on the fact that they have access to the game table which they don't because they are called in the on_load method.
Luckily the on_load is only nessesary if you add bobsenemies or bobsores to an existing game which means that for most cases there is no need for the on_load method.

So the simple fix is to remove every line in the on_load method so it looks like this.

Code: Select all

local function on_load()
end

[SirRichie]

You are correct in your analysis, this is what I found yesterday in the few minutes I had.
Not initializing the resource settings will not do the trick though, as further code relies on the index structures to exist.
Instead, I will store the initial structures in global and not re-initialize them in on_load. Simply removing on_load will cause errors in the long run.