> 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.
>

Not really sure how relevant this is to the discussion, but I have a somewhat peculiar code setup for object actions in SOAT:

==============================================
1. My objectactions.sma looks like:

----------------------------------------------
~ item1
~ item2
...
~ itemXXX
----------------------------------------------

XXX different objects, and only 1 line of code for each - empty functions! This works in tandem with a few other files.

==============================================
2. In repeatpre.sma, I have:

----------------------------------------------
c S:3={"~}
____f zobjects.action (*)
----------------------------------------------

In other words, when the player examines an inventory item, run zobjects.action

==============================================
3. zobjects.sma has code that's basically (much renaming and simplification to not completely spoil what my code does):

----------------------------------------------
~ action
____c inventory_examination_requires_confirmation
________f zconfirm.confirm_examination
____C
________f action2
~ action2
____c prefix_condition
________f print_a_prefix_or_maybe_do_something_else
____f zobjectactions.{'S:4}
____c suffix_condition
________f print_a_suffix_or_maybe_do_something_else

----------------------------------------------


==============================================
4. And then finally, the *real* object descriptions are stored in zobjectactions.sma:
----------------------------------------------
~ item1
____P description of item1
~ item2
____P description of item2
...
~ itemXXX
____P description of itemXXX
----------------------------------------------


So my objectactions.sma is just the minimal function stubs required by the engine. The code in repeatpre.sma intercepts an inventory option chosen and calls zobjects.sma (I only separated this into a separate file because repeatpre.sma runs every turn so should be kept short). Then zobjects.sma *normally* calls zobjectactions.sma, which acts as a proxy for a normal objectactions.sma (and looks nearly identical) (**), but zobjects.sma *sometimes* can have other effects depending on S:4 (tag for the object examined) or some other global variables.

And those effects can be pretty general - e.g., I could have HTML style tags added in the form of prefixes/suffixes around the actual object description. And that would then work for all objects, instead of having to put in code like this for every object's description.

> >
> > (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.

Yep, that's exactly what I do in SOAT. An "actual" location file will have something like:

v location = 312

at the top. So anywhere else in the code base, I could refer to the "location" variable to know the actual location. And my "jump back to the game" code is just as RyaCAM has it. Even with several hundred conditionals in a row, the processing time turns out to be negligible both locally and on the website.

(*) I name all framework-related files to start with a "z" so they all show up together at the bottom of the list when, for example, navigating the folder.

(**) My zobjectactions.sma differs from a standard objectactions.sma in that the print commands are all of the "append" variety ("P", "A") rather than "p". Because of course, there may be a description prefix of some sort already generated in zobjects.action2, and I don't want that overwritten.