Grim 2 rope item

[minmay]

The routine you posted parses the names of all the objects on the square. This doesn't work, because an object having "pit" in its name does not guarantee that it is actually a pit. For example, if there were a piece of pitroot bread on the level above, your function would cause an error, because the pitroot_bread object has "pit" in the name, but it doesn't have a component (or other field) named "pit", let alone a PitComponent named "pit".

My routine iterates through all the components of all the objects on the square, and returns true if there any of them are PitComponents that are open.

[RayB]

The routine I posted is not the one I was referring to. I took your advice and got rid the string check and used what I though would be a component check. It's just that the routine I came up with (before I saw yours) is a little different. This is what I did.
l is the level entity I pass to the routine along with the x and y coordinates.

Code: Select all

-- This function checks for a pit directly above the party
function chkAbove(l,x,y)
	for e in l:entitiesAt(x,y) do
		if e.pit then return e end
	end
end

This seems to work alright but it doesn't have the nested iteration. I was just wondering if this was OK? It seems to return the pit entity if there is one and nil if there isn't one.

[minmay]

The routine I posted is not the one I was referring to. I took your advice and got rid the string check and used what I though would be a component check. It's just that the routine I came up with (before I saw yours) is a little different. This is what I did.
l is the level entity I pass to the routine along with the x and y coordinates.

Code: Select all

-- This function checks for a pit directly above the party
function chkAbove(l,x,y)
	for e in l:entitiesAt(x,y) do
		if e.pit then return e end
	end
end

This seems to work alright but it doesn't have the nested iteration. I was just wondering if this was OK? It seems to return the pit entity if there is one and nil if there isn't one.

It'll work if all your PitComponents are named "pit" and none of your other components are named "pit". If (and only if) that is true in your dungeon, then this approach will work.

[RayB]

Well, I am not quite sure what to do here...

kelly1111 posted: If you get it to work correctly. Will you be sharing this item (code) with us? - (about my rope routine)

I replied that I certainly would once I checked it thoroughly but here's the problem:

to minmay:
I wasn't quite sure what you meant about your componentIterator script but after looking at the Grim 2 asset pack and their pit definitions, it finally sunk in. I thought I was referring to the component by using 'e.pit' but I was only referring to the component name. I noticed there is no Pit component name in the Grim 2 definition so I assume that the default name (the component name 'Pit' in lower case) is automatically used. However, as you say, if someone were to define a new pit object with a pit component and specify a name other than 'pit' for that component then my code using 'e.pit' would not work. (I know. I tried defining such a pit.) So wanting to be correct and check for a component and not just a component name, I decided to use you code. The problem is, I couldn't get it to work. I kept getting the following error:

attempt to call method 'getClass' (a nil value).

I don't know what I could have done wrong. I pasted it directly from the forum.

So what do you think? I can post my routine with my code but I wouldn't want to post anything that will cause a problem for people. Although I could note this potential problem in my post; an explanation of the 'e.pit' issue.

By the way, where did you get the 'componentIterator' method from? I looked through the Grim 2 modding pages and the scripting reference but I couldn't find it anywhere.

[minmay]

Your problem is that you are using an old version of Grimrock 2. The Component:getClass() method was added in 2.2.4, as I said in my earlier post. Update your game with the patches here.

By the way, where did you get the 'componentIterator' method from? I looked through the Grim 2 modding pages and the scripting reference but I couldn't find it anywhere.

It's used in the asset pack.

[RayB]

OK what happened!
I went to the link you gave in your last post and upgraded my Grim 2 program. Now the code won't even run!

Because -setting up to climb down or up and fading the screen to black- and -actually moving the party and fading the screen back in- are in two different functions, I had to use some global variables for the 'party:setPosition' to work. These are the first few lines of code:

-- Global variables: x2, y2, direction, tile-above-elev., level
x2, y2, dir, tae, lvl = 0,0,0,0,0
mkr = 0 --marker entity (or level above party if not using markers)
mgcRope = true --set to false if rope will become a magic rope in game

Since the upgrade every time I try to run the code I get the following error on the very first line (the rem line ???):

cannot serialize table 'mkr' with metable x

How can I get an error on a rem line? I deleted the first line, the rem line, and tried to run the code again and got the same error at the first line again (this time not a rem line)

I don't want to appear ungrateful but it seems to be stumbling block after stumbling block after stumbling block and now I probably cant even get back to my older version! What the hell is going on?

[minmay]

What's going on is that you didn't read all the instructions:
http://www.grimrock.net/modding/save-ga ... variables/
You're trying to store an object reference in a permanent variable (mkr), which is unserializable. The only serializable types in user scripts are number, boolean, string, function (with no upvalues), and table (with no metatable, and obviously all keys and values need to be serializable types).
If you need to keep track of a GameObject, don't try to store it in a permanent variable, store its id instead and use findEntity() to retrieve it.

Also, those are not global variables, those are actually going to be fields of the ScriptComponent - if you accessed them from somewhere else you'd need to use "script_entity_1.script.mkr" not "mkr". The global namespace is read-only to user scripts.

[RayB]

what exactly does serializable mean.

It was when I tried to use mkr = level:findEntity('entity.id') that it messed up. I take it that anything such as entitiesAt() or getAdjacentLevel() would cause the same error unless I use a local variable? I tried using a local variable for the 'findEntity' call and then setting 'mkr' to it but the same error occurred; which brings me to another question. Why didn't I have this problem before I upgraded?

Also (on a slightly different note) I noticed an item called 'boulder' in the item list and placed one in my test dungeon to see what it looked like. It looked like a oval shaped silver globe. I looked in the assed pack (I have version 2) and found a model and definition for it but could not find a material definition or any textures. Is this a glitch? I should be able to create my own material definition and use the textures for a rock, right?

And thank you once again.

[minmay]

Serializable means that it can be saved in a save game. The error you are getting would still appear in previous Grimrock 2 versions when you tried to save the game. In the latest versions, the editor tests for serializability too as you are editing, so that you can catch bugs like this one earlier.

It was when I tried to use mkr = level:findEntity('entity.id') that it messed up.

Yeah, that's exactly what I told you...findEntity returns a GameObject. That is the entire point of findEntity, you give it an id and get the GameObject back. What you need to do is store the GameObject's id in mkr, NOT the GameObject itself. Then when you want to use the GameObject, use findEntity(mkr) to retrieve it. If you are going to store a reference to a GameObject, only do it in local variables (and I mean TRUE local variables, not upvalues) that are inside blocks, so that the reference disappears when the block exits, and therefore won't be saved.

The boulder is just an unfinished item. It doesn't have a texture.

[RayB]

The boulder is just an unfinished item. It doesn't have a texture.

It does now and I must admit it looks pretty good.

And thank you for your last post. Once again you have cleared a few things up for me. As far as the serialization goes and the newer version checking for it, I think it's a good thing. It no doubt saved me a lot of headaches down the road.

Thanks again.