For the error, did you create the ladder object (see line 2 of my code)? If not, that would make the compiler give you this complaint. Otherwise it’s working for me so not sure what could be causing the issue.
Glad the support here has been helpful, and apologies for giving you advice you’ve already tried to follow! The main reason I made the suggestion is that it seems like you might be a bit fuzzy about how to tell Inform to do stuff, which isn’t just a syntax thing, it’s a conceptual thing that might make lots of stuff harder. If you already get all this, sorry for belaboring the point, but here’s a quick summary in case it’s helpful (this is a bit oversimplified but hopefully communicates the concept):
Broadly, you can divide the code in your game into two parts – things that tell the compiler about the initial state of the world, and things that tell the compiler how those initial conditions will change over time. So when you’re creating rooms or objects, or using Understand commands to tell the parser how to translate player input into actions, or writing descriptions, that’s all bucket one. Bucket two is telling the game to display text at a particular time using the “say” command, or writing how new actions work, or creating custom responses or condition changes for existing actions, or things outside the player’s direct control like timed events, NPC activity, etc.
The key thing to understand is that everything in bucket two needs to be included in a rule of some kind, so that Inform knows when and how to trigger the change. So that’s why rules always include a first line stating when they run – “every turn when the player is in the kitchen”, “before taking the branch,” “instead of asking someone about when the noun is the Oracle of Delphi”, etc. After this initial bit, they have a colon, and then the code for what happens when the condition is met needs to be indented below, with semicolons after each statement.
Of course rules can get really elaborate, with more nested ifs, elses, and otherwises – or they can be simple one-command things, in which case the syntax is likewise simplified so you don’t need the colon or nested newlines (you can just write “Instead of taking the ladder, say ‘That’s too heavy to lug around.’”) But anytime you’re writing code that changes the state of the world, you should be doing it inside a rule. Beyond the small syntax issues, that was the problem with your example code in the first post – you had state changes (unlocking the panel, displaying text with a say command) that wasn’t part of a rule, but instead nested under an Understand statement.
Hope that makes sense – most of Inform 7 is I think learnable through deduction and analogy from looking at examples, but the thing about rules is a little trickier to suss out just from looking at how folks are solving specific issues so that’s why I thought it might be worth writing up in more detail!