Loading tables issues

[drs9999]

I finally found some time to continue my blueprints-mod, but I direclty ran into some problems.

My control.lua file follows the following schematic:

Code: Select all

require "util"
require "story"
require "defines"

-- Table Declarations -- 
	glob.blueprints = {}											-- mod-Namespace
	glob.blueprints.XXX
       ...
---------------------------------

game.onit(function()
	game.player.character.insert{name="iron-plate", count=8}	
        ...
end)

game.onevent(defines.events.onbuiltentity, function(event)
...
end)

...									

The problem is that it seems like that the glob.-tables are not initialized every time.

So for example I start a new game, place 2 chest + 2 markers to copy them. Normally I should receive a Msg that tells me that 2 entities are copied.
But in approx 50% of my tests I received a Msg that tells me 0 entities are copied.

BUT if I exit the game completely or only the current freeplay, not factorio at all and start a new game I have a 50% chance again that it the mod will work correctly then..

Also this behaviour would explain why my treemod sometimes work and sometimes not...
I tried to place the table-declarations in the onInit as well, but same behaviour.

EDIT: I also tested it with "game.player.print(glob.blueprints)
When everything works fine I got an error " string expected, got table". That is what I expected, but when I do the same where the mod ar not working correctly I receive "string expected, got nil", that is why I think that the tables are not initialized correctly every time.

[slpwnd]

This is strange. The global scope is run everytime. I don't know what you are storing in the glob variable but remember that this is the "serialised" variable. That means even if you store something into the glob in the global scope it might get overwritten from the glob stored in the script.dat file. The pattern to use glob is to initialize it in onit and that should be it. Any changes you make there will be serialised and loaded on script load.

[drs9999]

I am using it like that: glob.blueprints.XXX, where "XXX" are a bunch of variables, tables etc. so I dont think that any other sprict will change that.

Atm I use these variables and tables while running the script. For example glob.blueprints.pos stores the position of an entity.
If I understand it correctly I have to/should use a blueprints-table in the script and only store the needed data in the onsave-event to the glob.blueprinbts table?

[drs9999]

Another question, could it be that "getdroppostion()" only work for mining-drills?
The wiki says it will work for mining-drills and inserters, but if I try this:

Code: Select all

local entities = game.findentities{ topleft = minpos , bottomright = maxpos}
			local k = 1
			for _, entity in ipairs(entities) do
				if (entity.name ~= "item-on-ground") and (entity.type ~= "resource") and (entity.type ~= "tree") then
					if (entity.name ~= "player") and (entity.name ~= "ccmarker") and (entity.type ~="unit") and (entity.type ~="unit-spawner") then
						glob.blueprints.relpos[k] = entity.position
						glob.blueprints.relpos[k].name = entity.name
						glob.blueprints.relpos[k].type = entity.type
						if (glob.blueprints.relpos[k].type == "mining-drill") or (glob.blueprints.relpos[k].type == "inserter") then
							local posit = entity.getdropposition()
							game.player.print(posit.x)
							game.player.print(posit.y)
						end
						k = k + 1
					end
					while (k-1) < #glob.blueprints.relpos do						-- needed to remove old entries
						table.remove(glob.blueprints.relpos)						-- from a previous blueprint
					end
				end
			end --_, entity in ipairs(entities)

It works fine for mining-drills. Position is displayed correctly, but for inserters only one line which says "1.79e+308" (max value of a double?!) is printed.

[drs9999]

Sorry for doublepost, but I made another test.

I "seperated" the glob-table from the running script. That means I initialized "glob.blueprints" and "blueprints" in the onInit

All calculations are done in the blueprints-table.

Only in the onSave-function I saved the "blueprints"-table into "glob.blueprints" and accordingly "blueprints=glob.blueprints" in the onLoad.

But the problem is still the same. Sometimes it is working correctly - sometimes not...

[ficolas]

Code: Select all

 glob.blueprints = {}

that sets it to blank each time it runs.
use

Code: Select all

if glob.blueprints~=nil then
    glob.blueprint={}
end

[drs9999]

that sets it to blank each time it runs.

Thats the point - this part just runs ones...

Anyway, that wont explain why it works every now and then.

[FreeER]

In the code you had initially posted ficolas would have been correct, however the onit should (from my understanding) only run when the world is first created. And other than that I don't see anything wrong with the code, I'd love to have the full code so I can play around and see if I can get it working lol. Though I am a little busy with my 0.3.x guide and I don't know if I'd be able to spot any thing you can't, I just love to play around with code It's part of why I'm helping ficolas out where I can lol

[drs9999]

So quick update:
I sent a copy of my the code so far to FreeER and he tested it. Here is a copy of what he found out:

Code: Select all

Ok, I've been playing around a bit and I have to say I don't think it's your code...
I've narrowed it down to line 93 where you use findentities. Your tables are loaded, BUT findentities is not finding any entities (at all). How do I know that, well I used print statements to show that your tables exist, when I realized that your tables DO exist the next step was to see if findentities was working...so I threw

Code: Select all
    game.player.print(tostring(entities[1])..tostring(entities[2])..tostring(entities[3])..tostring(entities[4])..tostring(entities[5])..tostring(entities[6]))

right after the local entities = findentities command. When the mod is working the table addresses are printed to the screen and when it doesn't all that's printed is nil. This seems more like the devs did something to the findentities function in the update, or how it's loaded or something lol. Tested on 0.3.2 not sure about 3.0/1 though I'd expect them to be the same.

The related code is this:

Code: Select all

local entities = game.findentities{ topleft = minpos , bottomright = maxpos}

			local k = 1
			for _, entity in ipairs(entities) do
				if (entity.name ~= "item-on-ground") and (entity.type ~= "resource") and (entity.type ~= "tree") then
					if (entity.name ~= "player") and (entity.name ~= "ccmarker") and (entity.type ~="unit") and (entity.type ~="unit-spawner") then
						blueprints.relpos[k] = entity.position
						blueprints.relpos[k].name = entity.name
						blueprints.relpos[k].type = entity.type
						
						k = k + 1

						while (k-1) < #blueprints.relpos do						-- needed to remove old entries
							table.remove(blueprints.relpos)						-- from a previous blueprint
						end
					end
				end
			end --_, entity in ipairs(entities)

I tried to reproduce what he explained and came to the same conclusion.

Also there is still no way to receive the orientation of transport belts and inserters ( and steam-engines), right?

[rk84]

I just tested game.findentities in console and noticed topleft and bottomright are wrongway compared to debug view coords.

Try

Code: Select all

local entities = game.findentities{ topleft = maxpos , bottomright = minpos}

Also there is still no way to receive the orientation of transport belts and inserters ( and steam-engines), right?

Right, at least I haven't seen any sign of it in update release notes, wiki or in game.

[FreeER]

I just tested game.findentities in console and noticed topleft and bottomright are wrongway compared to debug view coords.

Try

Code: Select all

local entities = game.findentities{ topleft = maxpos , bottomright = minpos}

Really? I don't recall it being off ( I used printstatements for minpos.x, etc.) I'd check again myself to see how far off but I'm about to head to class. I wouldn't think it work work at all if those were off that much though (and 50% of the time it works perfect). Oh well, I'll check back here when I get to class (and I'll go look at it again myself lol). Not that I don't trust you but I like learning new things and I hadn't seen this method used before

[drs9999]

Try

Code: Select all
local entities = game.findentities{ topleft = maxpos , bottomright = minpos}

Nope, behaviour is still the same...

[kovarex]

Oups.

We changed the behaviour, that you don't need to input position in format {x = 1, y = 3}, but you can input directly {1, 3}, and same with bounding box.
instead of {topleft = {0, 3}, rightbottom = {1, 4}}, you can write {{0, 3}, {1, 4}.

It is backwords comaptibile with the old position input, but I didn't make the backwards compatibility with the bounding box.

This means, that if you use topleft, bottomright, the order will be random (as lua hasmap ordering is random).
The solution is
a) Use the new format
b) Wait for the backwards compatibility fix

[rk84]

Still I think that parameter keys are wrong way.

This is what I tested (while having entities near 0,0)

Code: Select all

game.player.print( #game.findentities({ topleft = {-5,-5} , bottomright = {5,5}}) )-- always 0

game.player.print( #game.findentities({ topleft = {5,5} , bottomright = {-5,-5}}) )-- this works

and I checked coordinates in debug view. Moving topleft direction lowers coordinate values and vice versa

[kovarex]

Still I think that parameter keys are wrong way.

This is what I tested (while having entities near 0,0)

Code: Select all

game.player.print( #game.findentities({ topleft = {-5,-5} , bottomright = {5,5}}) )-- always 0

game.player.print( #game.findentities({ topleft = {5,5} , bottomright = {-5,-5}}) )-- this works

and I checked coordinates in debug view. Moving topleft direction lowers coordinate values and vice versa

When you use keys, it is kind of random, so anything can work, try it without using keys.

[drs9999]

awesome!
7 of 7 times this was successfully:

Code: Select all

local entities = game.findentities{ minpos , maxpos}

Thanks! I guess that is/was the issue in the treemod as well.

[FreeER]

very probably. Glad this has been solved, I'll make sure to add this to my guide

[rk84]

hehe i missed that boundingbox change. Good thing we got bottom of this