Grimrock

I created a rope in LOG1. I got the model from The Tomb of Tiggy Tamal mod and used my own code. I placed the code in the dungeon and used the onUseItem() hook to call it. I found that I had to right-click the rope when in the champion's container (or backpack as I like to call it). It would not work from the champion's hand. I then defined the rope as a wand and created a spell to call the code when cast. This worked fine but only from the hand. I found that also calling the code with the onUseItem() hook, would allow the rope to be used from the champion's hand or backpack like the rope in LOG2. Success!

Now, the rope in LOG2 is great, but I am trying to add a climb-up feature to it. I added a 'secondaryAction' command to the definition so when right-click-hold is used on the rope it will run the code to climb up. I tried to add a 'UsableItem' component and used the 'onUseItem' hook to call my code. Well, to my suprise, when I tried it out, the champion ATE THE ROPE! So, I switched to the 'onAttack' hook of the 'ItemAction' component and it worked. But it only works from the champion's hand. I noticed the Grim 2 rope works from both places. Would love to know how you guys did it. Can't figure that one out.
Now, to use the climb-up feature, I have to check for an open pit on the level above and the 'map:entitiesAt()' function does not use a level parameter. I could not use something like 'party.map:entitiesAt()' because, of course, the party is on the level below which will not show the pit above. To resolve this problem I placed a blocker somewhere on each level and named them, lmL1 (level-marker-Level-1), lmL2, lmL3, etc. I was then able to refer to the correct marker entity with...

local lmID = "lmL" .. party.level -1 --set up correct ID
lma = findEntity(lmID) --lma = nil if level marker not found

Thus, something like...

function chkAbove(lm,x,y) --lma, party.x and party.y are passed
for e in lm.map:entitiesAt(x,y) do
if e.name ~= string.gsub(e.name,"pit","") then --if pit found
if e.pit:isOpen() then return true end --and it is open return 'true'
end
end
end

now works to find an open pit above the party. (To clarify, I also check for blockages above where the party will be landing.)

It seems like a lot of extra work to be able to use the new 'eneitiesAt()' function and more inportant, if I move levels up or down in the editor, it will screw up all my blocker markers. So any level order changes will result in my having to go in and change the blocker id's.

Am I going about all this the hard way? Is there a better way of checking for entities on other levels?

I know this is a lengthy post and I apologize for that but I didn't know how else to explain the problem.

If you return false from an onUseItem hook, the item will not be destroyed.
The rope and shovel in the base game are implemented in RopeToolComponent and DiggingToolComponent, not with the user scripting interface.
Why not just use Map:getAdjacentLevel() to get the level above the party?

I wasn't sure what getAdjacentLevel() got. If the was the level above, below, up, down, left, or right.
Will definitely try it!

Thank you again.

RayB wrote:I wasn't sure what getAdjacentLevel() got. If the was the level above, below, up, down, left, or right.
Will definitely try it!

It can get any map, at any distance. The three number arguments are the dx, dy, dz. So you could get the map above with getAdjacentLevel(0,0,-1), the map to the east with getAdjacentLevel(1,0,0), or the map two maps to the east, three maps south, and one map below with getAdjacentLevel(2,3,1).

If you get it to work correctly. Will you be sharing this item (code) with us?

I will, but so far no luck. When I try using Map:getAdjacentLevel(x, y, l) in my script I keep getting the error: 'attempt to index global 'Map' (a nill value). If you have any luck please post your solution.

As far as the climb up rope goes, I will certainly share the code with anyone who wants it.

...Map is a class name. Not an identifier. getAdjacentLevel is a method of the Map class. You would use Also, why are you checking the name of the object to detect if it is a pit? That will result in both false positives and false negatives. Why are you not checking if the object has a PitComponent instead?

I am sure you know your stuff so I will use your suggestion but you must realize that I am somewhat a novice at all this. What exactly do you mean by false positives or false negatives? I have come across the terms in the forums but don't really understand them.

By the way your example and mention of ‘Map’ being a class name in the last post has helped tremendously to clear up some of the scripting difficulties I’ve been having. Am I to assume that the long list of components can be considered classes? Is this why there is no ‘class’ dot operator for entities as in Grim 1?

https://en.wikipedia.org/wiki/False_pos ... _negatives
False positive: your test said "yes" when it should have said "no"
False negative: your test said "no" when it should have said "yes"

Yes, components should be considered classes. You can access a component's class name with the Component:getClass() method added in 2.2.4. At this point, I wonder if you have seen the scripting references.
http://www.grimrock.net/modding/scripting-reference/
https://github.com/JKos/log2doc/wiki/Components (more complete)

You could easily check if there is an open pit on a square with:

Thanks to your help (as mentioned in my last post) I was able to get a little better grasp on this scripting stuff and get my ‘rope-up’ routine up and running. At least it seams to work OK. I am still checking it for bugs.

To satisfy your curiosity, yes, I have seen the scripting reference and have even printed it out. However, there is a lot of new stuff in there and I am sure I missed a few important details. I have not seen the second link which you say is more detailed but I will certainly take a look. When you are new to this stuff, not so much the coding but the terminology (methods, classes, iterators, identifiers etc.) it can sometimes be a little overwhelming to understand all the relationships. Remember you are conversing with an old boy from the DOS days who has only programmed in Basic; no C or C+ or anything like that. But I am retired now and am enjoying all this stuff; especially during the Winter months. So thanks again for your help.

I am wondering though, your ‘check for level above’ routine is a bit more complex than mine. Maybe my understanding is not as thorough as I think. If I post my function would you consider taking a quick look and let me know if there are any serious flaws? As I said I have been testing it and it seems to be alright.