I think I've got answers for all of those, if I understand you correctly.


> I'm thinking of having the interface buttons print the description of an object and also add actions to the action column. Is it a good idea?

That could work well. One way you might do that is for each function in objectactions.sma to set the global variable "item" to a different value. Then each location file ends with a function, which runs when "item" has a value. This function can add additional action options - actions for every item in every location, actions for every item in particular locations, actions for particular items in every location or actions for particular items in particular locations.

>
> (I reread the preview and realized I wasn't being clear - it's "examine in a specific location to get a list of extra action options for that specific location", not a global examine.)

If it only happens once, I imagine something like:

~ potato
___p It's a potato.
___c loc = 1
______t - showOptions = 1


And the location code would be something like:


* jump Jump up and down.
___p Okay

c ...showOptions
___* potato Jump up and down on the potato.
______p You win!
______w



>
> 2. Going forward with #1 for now, I'm still unsure how to time those actions.
> a. Examination is free, action costs a move (at least).
> Problem: free examination won't spoil any puzzle that is currently planned, but only because I haven't currently worked out the fine details - as an abstract idea, it sure looks able to bring about the end of the world.


I'm not sure why that would cause problems. I've been working on a game where clicking an item examines it and turns back all timers but performing actions with the item costs a move.


> Can be potentially solved with a dedicated "examine" action where necessary.
>

My game has a dedicated "examine" action and also auto-examines the item when you click it. The dedicated option costs a move, but the auto-examine doesn't. (Now that I think about it, that's strange.)


>
> 3. Assuming the above is workable, how to better implement it in SMASH? Is it better to keep the code for those extra options in location files? function files? (e)objects.sma?


If an option appears in only one location, put it in that one location.

>
> 4. Character profiles / situation summaries. Looks like it's quite doable with virtual locations*, but I can't save the current in-game location. The following does not work:
> v loc1 = S:loc
> g loc2
> ....
> g {'loc1}
> (I tried several combinations of {}s, ''s, c: and S: operators. No luck.)


You could manage this by setting a variable ("loc") each time the player changes location, other than when entering virtual locations. Then, when the player must return to the previous location:

c loc = 1
___g dining
C loc = 2
___g kitchen
C loc = 3
___g bath


This could get ridiculous if there are many locations, but it works. My game has around 40 locations, and you say yours too has fewer than average.