Guild of Writers

Feature requests will all wind up on github. Putting them straight there is easiest. But if you don't have a github account, post them here and I'll copy them over.

(Unless I miss something, which can happen.)

Thanks for looking at the wiki ad structure! I also normally run noflash/noscript, but Seltani development involves having a lot of browsers open and pages can wind up displayed anywhere.

Pavitra wrote:I think that just giving the name of a Text property should do it. text("some string") should work too.

text('foo') prints {'type': 'text', 'text': 'foo'} in the event pane. The name of a Text property works, but I was hoping for an inline syntax (without defining another property), like the suggested reinterpretation of print().

Gorobay wrote:

Pavitra wrote:I think that just giving the name of a Text property should do it. text("some string") should work too.

text('foo') prints {'type': 'text', 'text': 'foo'} in the event pane. The name of a Text property works, but I was hoping for an inline syntax (without defining another property), like the suggested reinterpretation of print().

Oh, right. I forgot it defaults to Event.

Right now a bare symbol naming a code property runs the code. It's effectively a function call. So if I change this to setting focus, it may break some existing worlds. In fact I know it will break Laufensea -- it uses function calls in this way.

The change I'm considering is that "foo" (on a text or code property) sets focus, and "foo()" is a function call. That's slightly more intuitive for Python users, I think.

(What does "foo()" mean if foo is a text property? I guess it will default to the Event behavior. The semantics of this thing were so simple when I first sketched this out, back in the spring...)

EDIT-ADD: No, this plan breaks all action links. Drat. Back to the pacing board.

What if a bare symbol used the same behavior as a [singlebracket]-link? That is, it would focus-display Text properties, evaluate Code properties, move on Move properties, and so forth.

That's what it does now. Or that's what I think it does.

Now that I look, the Shoutwiki terms of service specify that you may not remove the ads from the wiki template. (Not a surprise, really.)

You should undo that change. We can survive on ad-blockers, unless we want to switch hosts.

(I paid for an ad-free hosting plan. It wasn't very much, so I figured why not.)

As for the in-line textfocus thing, what if any line that returns a value has the same effect as a bare symbol that has that value? That is, should do the same thing as assuming foo is a Text property with value 'bar'.

(Honestly, I just don't see a situation where it would be useful to be able to call the same symbol as either Text or Event.)

Oh! Didn't realize that's what you'd done. Thank you! (again)

Allowing a text('...') statement as a focus makes sense, but it's not possible the way the system is currently set up. The focus field of the player's record must be a property name (or a few other special cases).

I've finally finished the portal-editing interface in the build system.

I'll more more detailed docs later, but the short form is: a "portlist" is a bookshelf. You need to create a portlist from the world screen, populate it with links, and *also* create a PortList property in a location. The key of the list and the property must match.

To create a single book (not part of a shelf), create a portlist with exactly one link. Then set the "focus" field of the PortList property to "true". Yes, this is awkward.

The last line ("label") of the PortList property is for describing the bookshelf (or the standalone book). This tells the player what the shelf is like, where the book is, what the cover looks like, what stamps are on it -- that sort of thing. Do *not* put the linking panel description here.