intfiction.org

The Interactive Fiction Community Forum
It is currently Thu Oct 19, 2017 4:05 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Wed Oct 04, 2017 5:24 pm 
Offline
User avatar

Joined: Sat Jun 25, 2016 12:13 pm
Posts: 149
Hi Marnix,

Thanks for your replies and explanation. Here, I'm going to pick up on your reply to my original XVAN problems, later I'll write about the JSON ideas;

Firstly, thanks for explaining how it works. Following your ideas (working with the COD example), i factored t_drop and t_take_off into common triggers as suggested, thus:

Code:
  t_take_off
    if testflag(%this.f_worn) then
       printcr("You take off [the] [%this]")
       clearflag(%this.f_worn)
    else
       printcr("You're not wearing [the] [%this]")
       disagree()
    endif

  t_drop
    if testflag(%this.f_worn) then
#       trigger(t_take_off)
       printcr("  [[Taking off [the] [%this]]")
       clearflag(%this.f_worn)
    endif
    if (owns(o_player, %this)) then
      clearflag(%this.f_bypass)
      move(%this, owner(o_player))
      printcr("[%this]: dropped.")
    else
      printcr("One must hold something before it can be dropped.")
      disagree()
    endif


Now, as you mentioned, i can just call these from the objects;

Code:
$OBJECT o_cloak
   ...
   d_drop       "This isn't the best place to leave a smart cloak lying around."

 TRIGGERS
   "take off [o_cloak]"                 -> t_take_off
   "drop the [o_cloak]"                 -> t_drop_cloak
   ...

   t_drop_cloak
     if equal(l_location, l_cloakroom) then
       if trigger(t_drop) then
         setflag(l_bar.f_lit)
       endif
     else
       printcr(d_drop)
     endif



This works neatly, where the bulk of the logic is factored out of the verb into the common triggers, yet i can still affect the `bar.f_lit` as required.

Quick question; looking at my definition of `t_drop` above, why can't i call `trigger(t_take_off)` here (commented out), would be nice to do this and factor more code.

I understand your explanation of how you might implement global triggers. When moving logic (such as drop above) into common triggers, the global trigger would be nice and would avoid having to have "drop the X" -> t_drop on **every** object that can be dropped. same for "get" if that were factored.

## handler ordering

Thanks for this. I see how it goes; object->common->verb. I can also see how i might call `trigger(t_something)` and make use of the result. But what would be nice is, if a handler could call the next in the chain (the one that it goes to for `nomatch`) but it be a *call* and not a `nomatch` because `nomatch` does not come back!

What's happening is; without being able to manually call (and return from) the super chain, logic must be factored into common handlers like i have done above for "drop". Since pretty much everything will sooner or later need to be called from an object handler, *all* verb logic will eventually be in common handlers and *none* in verbs - which would be a rather perverse state of affairs.

If the version in the verb could be invoked from the object (or common), then it would not have to be factored out.

That's just my view of it. Of course, it still works by factoring to common triggers.

Will address the JSON ideas next....


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Oct 04, 2017 5:43 pm 
Offline
User avatar

Joined: Sat Jun 25, 2016 12:13 pm
Posts: 149
Just a quick question concerning XVAN object IDs and JSON;

Because XVAN compiles, the runtime does not have access to object names in a convenient way, only identifiers. understood.

But, could the compiler have an option to emit some kind of "symbol table". Something that connects XVAN IDs with identifiers; object identifiers, location identifiers, word identifiers, trigger identifiers.

Perhaps this "symbol table" could also be a JSON object and Brahman could load this in, so that it can work with JSON messages to and from XVAN using IDs.

We could design this symbol table to be an optional offering from a (arbitrary) back-end, whenever string identifiers were not to be used (in the absence of such a table, the corresponding JSON messages would have identifier strings instead of, say, ID numbers).


Top
 Profile Send private message  
Reply with quote  
PostPosted: Thu Oct 05, 2017 8:19 am 
Offline

Joined: Wed Aug 26, 2015 11:18 am
Posts: 83
Location: The Netherlands
Good to see you got it to work.

Quick question
The trigger() function is what I call a testfunction. It is always used in an IF clause. So if you change your t_drop trigger a bit, calling t_take_off will work.

Code:
t_drop
  if testflag(%this.f_worn) then
    if not(trigger(t_take_off)) then
      # something happened in t_take_off and we must stop
      disagree()
    endif
  endif
  if (owns(o_player, %this)) then
    clearflag(%this.f_bypass)
    move(%this, owner(o_player))
    printcr("[%this]: dropped.")
  else
    printcr("One must hold something before it can be dropped.")
    disagree()
  endif

Come to think of it, maybe move the 'worn' test inside the 'owns' test.

Code:
t_drop
  if (owns(o_player, %this)) then
    if testflag(%this.f_worn) then
      if not(trigger(t_take_off)) then
        # something happened in t_take_off and we must stop
        disagree()
      endif
    endif
    clearflag(%this.f_bypass)
    move(%this, owner(o_player))
    printcr("[%this]: dropped.")
  else
    printcr("One must hold something before it can be dropped.")
    disagree()
  endif

To keep in mind: with common triggers the definition also is the declaration. If you call one common trigger from another, the called trigger must be defined before the calling trigger. If you move t_drop to above t_take_off in the file, the compiler will assume t_take_off is a local trigger and it will throw a 'missing local trigger owner' error. I can fix this by making a separate declaration section for common triggers before defining them, I'll do that when I implement your global trigger suggestion.

Manually calling and returning from the super chain
I have to check the XVAN source (don't have access right now) but I think I can make runverb() and runcommon() functions that can be called from a trigger. Runverb() would call the verb default code and runcommon() would call a local trigger's common counterpart.
There would be some restrictions, though. Runverb() may not be called from the verb code itself and runcommon() may only be called from a local trigger to prevent looping.
Your earlier example would look like this:

Code:
TRIGGERS
"drop the [o_cloak]" -> t_drop
 ...

t_drop
  # run the verb code
  if runverb() then
    setflag(l_bar.f_lit)
  endif


I'll get back on the JSON thing later.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Mon Oct 09, 2017 10:00 am 
Offline

Joined: Wed Aug 26, 2015 11:18 am
Posts: 83
Location: The Netherlands
Regarding the JSON interface, there's no need for the compiler to spit out a symbol table, the interpreter can do it as well. Internally, the interpreter works with ids, but it also has all the info to print an object's real world name.

The data sources the interpreter uses to convert location and object ids to text strings are:
    - location directory
    - object directory
    - word table

Here's how it works. Suppose we have an object identifier. The interpreter would use the identifier to access the object directory and find the struct for this specific object. In the struct, among other things, is the object's extended system description, which in it's most extended way looks like:
Code:
[article id] [adjective ids] [noun id] [preposition id] [adjective ids] [noun id]

e.g. "the old grumpy man with the shiny sword"

Next, the interpreter would look up the word ids in the word table and print the associated text string (or send it to a Glk output handler).

So, by JSONifying (?) the location and object directories and the word table, Brahman should be able to convert an id to the text string.

But would this not be too much interpreter knowledge in the GUI? By only communication through text strings, Brahman could interface with any interpreter without knowing about how it's structured internally.

W.r.t. running verb and common trigger code, I completed the runverb() function. You can now call the verb code and after execution it will return to the caller. The code for the runcommon() function is almost completed.

Are you on windows or linux?


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group