[Solved] Save game blowing up with my custom dungeon

[MrChoke]

This issue may have been answered before but I can't seem to find the thread. Now that export is fixed, I am testing my custom dungeon in the actual game. Every time I close the game or try to save, it blows up with this:

[string "Script.lua"]:0: attempt to concatenate field 'id' (a nil value)
stack traceback:
[string "Script.lua"]: in function 'saveValue'
[string "Script.lua"]: in function 'saveState'
[string "GameObject.lua"]: in function 'saveState'
[string "Map.lua"]: in function 'saveState'
[string "GameMode.lua"]: in function 'saveGame'
[string "SaveGameMenu.lua"]: in function 'update'
[string "GameMode.lua"]: in function 'update'
[string "Grimrock.lua"]: in function 'display'
[string "Grimrock.lua"]: in main chunk

Too bad the stack trace isn't in any of my LUA. I seem to recall this may be coming from using locals where I should be using globals or something... Anybody seen this before?

[NutJob]

This issue may have been answered before but I can't seem to find the thread. Now that export is fixed, I am testing my custom dungeon in the actual game. Every time I close the game or try to save, it blows up with this:

[string "Script.lua"]:0: attempt to concatenate field 'id' (a nil value)
stack traceback:
[string "Script.lua"]: in function 'saveValue'
[string "Script.lua"]: in function 'saveState'
[string "GameObject.lua"]: in function 'saveState'
[string "Map.lua"]: in function 'saveState'
[string "GameMode.lua"]: in function 'saveGame'
[string "SaveGameMenu.lua"]: in function 'update'
[string "GameMode.lua"]: in function 'update'
[string "Grimrock.lua"]: in function 'display'
[string "Grimrock.lua"]: in main chunk

Too bad the stack trace isn't in any of my LUA. I seem to recall this may be coming from using locals where I should be using globals or something... Anybody seen this before?

The error message should of followed up with what file to send and what email to send it to.

Anyways, I have *almost* this exact error, myself, now that this thread exists.

Edit: So far I can reproduce this crash *as long as I keep saving* over and over. So while the crash is is 100% reproducible it's not easy to tell which save will do it. The last test I saved nearly ten times (all different places and states of variables) before it happened and the first few tests it would do it on second or third save. Never happened on the first save yet.

[MrChoke]

Not sure if I want to email them this though. If everybody's custom dungeons are blowing up with errors like this then yeah it needs an email. But if it is blowing up because I am doing something wrong in script, hopefully just a reply here in the forum would be good.

[NutJob]

Not sure if I want to email them this though. If everybody's custom dungeons are blowing up with errors like this then yeah it needs an email. But if it is blowing up because I am doing something wrong in script, hopefully just a reply here in the forum would be good.

Understandable, though I wasn't, really, condemning this bug report [here] only condoning sending it email to them.

I'm also getting other crashes dealing w/ranged attacks that will happen occasional using the blowgun. ~shrugs~ Probably some of my code on that one being I have half my code tight and clean and all my "test code" haphazard trashed across all levels with functions named zugzugDoItNow() and omfgWork() lol

[JohnWordsworth]

I'm pretty sure I know what your problem is, as I get the same error if I make a "repro case" here...

So, one of the biggest things you need to be really careful about in your scripts is making sure that you do not have any references to entities stored in variables that are not local. So, for instance the following script entity will cause a crash (when you try to save from an exported dungeon)...

SpoilerShow

Code: Select all

function a()
	something = self.go;
end

function b()
	print(something)
end

a()
b()

If you run the above code, you will notice that the script actually prints "table: XXXXXX" to the debug log. This is because the variable "something" is stored in the script scope, not the function scope (like you would expect if you program in most other languages) and so is also available to function b() later.

So, the problem here, is that the line "something = self.go" is actually making a variable in the script's global scope pointing to the game object of this script entity. This variable hangs around and is stored in the script entity. When the game comes to save this script entity, it is trying to save the variable "something" into the save file. However, the variable is a reference to a game object, which the save file doesn't know how to save. This causes the crash.

You can fix this in two ways.

1. In this case, you might want "something" to just be a temporary variable that is used in a(). For this, you should just type... "local something = self.go" instead. By putting the word "local" at the start of the line, you are saying "keep this variable in this function only, and then delete it when this function is done". This is the tidiest solution, as long as you don't need to keep the variable around for method b(), and means you won't have any problems trying to save the variable (it gets deleted at the end of the method call).

2. If you do need to use that variable across multiple methods, then my advice is to first define it at the top of the script (mainly for you to keep track for). However, you still run into the problem that you can't save a game entity. Instead, you will have to just keep the ID of the entity in a variable and use findEntity to retrieve it later. So, in this case, I would change the above to the following...

SpoilerShow

Code: Select all

someEntity = nil;

function a()
	someEntity = self.go.id;
end

function b()
	if (someEntity ~= nil) then
		local e = findEntity(someEntity);

		if e ~= nil then
			print(e)
		end
	end
end

a()
b()

Hope this makes sense.

Unfortunately, going through your existing code and finding these errors can be a bit tiresome. Hope you track them down okay.

[NutJob]

So, one of the biggest thing you need to be really careful about in your scripts is making sure that you do not have any references to entities stored in variables that are not local. So, for instance the following script entity will cause a crash...

If that is the case I think I'll just start over. ~laughs~ oops

Oh, Doridion, if you read this reply please remove every single example code I have in the depository super thread (or depositary as you call it). They're all broken because I store tons of entities in global tables. Ouch, my entire project has just been crushed by the hammer of doom. ~laughs~

Edit: Thank you John for this insight.

[JohnWordsworth]

Haha. Yeah, I remember finding this out for the first time in LOG1 quite late on too...

Sorry, just to clarify (have tweaked the above post), the crash only occurs on game save from the exported dungeon. So test out mods frequently in the main game after exporting!

[NutJob]

Haha. Yeah, I remember finding this out for the first time in LOG1 quite late on too...

Sorry, just to clarify (have tweaked the above post), the crash only occurs on game save from the exported dungeon. So test out mods frequently in the main game after exporting!

I desperately wanted too. =)

Anyway, this'll give me time to refocus on structure and conforming to this API.

[MrChoke]

@JohnWordsWorth,
Yes, that was it! Works now.

Lesson learned here is even though LUA will let you scope a variable anyway you want, you need to watch yourself when the game runs the code. You can't be lazy on what you are doing.

SUGGESTION to all big-time scripters like Nutjob, John, Prozail and others,
Are you guys using any IDE for writing your LUA? By IDE, I mean like Eclipse or at least advanced editors like Notepad++? I am not using Notepad++ but I have the LUA plugin for Eclipse. It is very cool in that it color codes the scope of the variables (local or global) as well as looks for compile errors real-time. That is how I fixed this issue so fast. Anyway, its a good IDE for this.

[NutJob]

@JohnWordsWorth,
Yes, that was it! Works now.

Lesson learned here is even though LUA will let you scope a variable anyway you want, you need to watch yourself when the game runs the code. You can't be lazy on what you are doing.

SUGGESTION to all big-time scripters like Nutjob, John, Prozail and others,
Are you guys using any IDE for writing your LUA? By IDE, I mean like Eclipse or at least advanced editors like Notepad++? I am not using Notepad++ but I have the LUA plugin for Eclipse. It is very cool in that it color codes the scope of the variables (local or global) as well as looks for compile errors real-time. That is how I fixed this issue so fast. Anyway, its a good IDE for this.

Yes, I use "Sublime Text 3 [Beta]" and nearing completion on full syntax highlighting for the LoG2 API methods ( along with the LUA, too, of course).

Edit: Oh and thanks for clumping me in the Elite Scripters Group.... I'm many many levels below their expertise. (as I yell across the forums to remove all my scripts because they're totally broken) =]