Adv3Lite New Feature Beta-Testing?

As many of you will know, I frequently upload intermediate, work-in-progress versions of adv3Lite to GitHub. It may be a while until the next official release of adv3Lite (although that will largely depend on how much user feedback I get and the speed at which issues come to light), but it occurs to me that in the meantime there’s an opportunity here for anyone who’s interested to test out some of the new features before they become part of an official release, and that this is more likely to happen if I let people know what’s happening.

I’ve just written another couple of extensions for what will eventually be version 1.5 of adv3Lite. One of these is to allow game authors to track weight in much the same way as the main adv3Lite library tracks bulk (this is standard in the adv3 library but not many games need it, so it seems best to provide it as an extension).

The other (called symconn, for “Symmetrical Connectors”) is aimed at reducing the work needed to specify connections between rooms. With symconn you only need to specify the connection in one direction, and the extension will automatically add the connection back in the opposite direction. The extension also provides SymConnector, SymPassage and SymDoor classes which are forms of two-way travel connector. For example, using a SymDoor you can create a door using one object instead of two, and you need only specify it in one location.

Anyway, anyone who’d like to try these new extensions out is welcome to do so by downloading the WIP version of adv3Lite from GitHub. Note that you will need the complete library, not just the extension files, since various changes have been made to other parts of the library to accommodate the new extensions. Note also that intermediate builds on GitHub do not include the Library Reference Manual, so you will need to make sure you keep the existing 1.4 version of the LRM if you decide to try out this WIP version of adv3Lite.

Finally, if anyone wants to discuss adv3Lite features or offer suggestions, there’s also a forum available at http://ericeve.livejournal.com/. At the moment I seem to be talking to myself there, but it may offer an alternative to cluttering up this forum with too much chatter about adv3Lite development (as opposed to requests for help and so forth).

Hey Eric,
that sounds like an awesome idea. However I can’t find the forum on github. Maybe you haven’t opened it for public. Or where do I have to click?

I put the link a couple of times in my original message, where it says GitHub. That seems to have worked for other people in the past.

But if you’re looking for the forum rather than the source code, that’s on livejournal at http://ericeve.livejournal.com/.

Yeah, I found the code without problems. But you said in the first post

Maybe the wrong link, that’s why I asked. And on your blog I couldn’t find the least bit of discussion going on…

Ugh! It looks like I somehow managed to paste the wrong link. I’ve corrected it now, in case anyone else is misled!

Which is precisely why I said:

But that doesn’t mean than no discussion could take place there in the future, which is why I thought it might be worth drawing attention to it.

I don’t have time to try it out right now – a non-IF project is on the front burner. But I’m curious what happens if the author wants th symconn functionality for some room connections but not others. If I decide at some point down the line that I need a twisty map, will I have to go back and specify a bunch of exits that were handled automatically before? Or conversely, if I start using symconn with a project that’s already in progress, what will happen to two-way connections that I’ve already specified manually?

If you want a very twisty map then you probably don’t want to use symconn at all, but most connections in most IF these days probably are symmetrical. If you just want a few twisty connections, then you’d have to define something else on the direction properties you didn’t want the symconn extension to assign automatically; symconn won’t overwrite any non-nil direction properties that are already defined in game code, and if you want a one-way connection you’d define noExit on what would otherwise be the connection back.

Nothing; they’d be totally unaffected. Symconn only adds connections to direction properties that game code has left at nil, so if you’d already defined hall.east = lounge and lounge.west = hall symconn would leave it alone.

Good. That makes sense. I was sure you’d think of this stuff … I was just curious how it would work.

Hey Eric, thanks for your continued work.

I will likely test out these features soon and try to get some useful feedback.

I just wanted to ask generally if you consider feature requests and how you deal with contributions to adv3lite directly.

I’m just curious.

Regards,
Dustin

I certainly consider feature requests, and am open to considering contributions.

I’m not anxious to increase the complexity of the adv3Lite library, since that would rather negate the point of adv3Lite, so for any given request/contribution I’d want to consider (a) whether it should be included at all (is it in accordance with the general design philosophy of adv3Lite and/or is it something that several people are likely to want, as opposed to being purely idiosyncratic) and (b) if so, is it better incorporated into the main library or into a separate extension.

To give concrete examples, the SceneTopic extension was my adaptation of a contribution, while the signals extensions was a response to a suggestion on this forum. Also, I quite often make changes or add features in response not so much to explicit requests as to noting what people are having trouble with or criticizing or otherwise discussing.

I should add that adv3Lite has probably reached the stage at which its further development will largely be driven by such user feedback, since apart from odd rough edges which I happen to come across and smooth out in the course of my own use of it, I don’t envision myself just adding more and more features for the sake of it, and I think it’s probably reached the point where it’s only worth making further changes in response to user feedback (hopefully with some user discussion of any proposals).

Basically I’m having a lot of trouble designing a capable window that worked as well as it does in adv3.

My IF motivations are essentially on standstill because I cannot come to a marriage between my absolute love of adv3lite’s attribute-based focus and your (active) tender loving of the library and my desire for capable windowing/sense passing.

I am trying to make a game that takes place purely in an underground metro system and windows are going to be very important to me and I just cannot seem to implement one that works as well as in adv3. Further, things like putting light sources into backpacks and having the lights go out just gives a very authentic feel to the world.

I’m just so philosophically divided I’m hoping I can emphasize the position that perhaps that adv3lite has become a standard FSVO ‘standard’ and that perhaps it deserves a slightly more sophisticated support for sense passing if only as extensions.

All that said, if you can help me figure out how to get a window that works as robustly as they do in adv3 then I could probably be satisfied enough to just commit 100%

I think I showed you my utility before for taking flowcharts and generating TADS3 code that builds up the topography of the world. I wrote that for adv3 first and then realized I like adv3lite much more and then found I couldn’t reimplement my window class and basically all my productivity stopped.

Sorry, I understand that was a bit of a ramble.

Thanks for replying,
Dustin

Could you say a bit more about what it is you’re trying to do and having trouble with? What is it that you need your window class to be capable of? Is it the kind of thing the adv3lite Viewport extension is meant to handle, or something quite different?

To expand on my previous reply, I’m not sure what features of a window you’re trying to implement. If you want a window you can look through to see what’s on the other side, that’s what the Viewport extension does. For some features of the adv3lite sense passing system in general with an example of a window that passes sound and smell only if its open you can look at the Sense and Sensibility example code which can be found in the Exercises & Samples chapter of the adv3Lite Library Manual.

If you simply want your window to pass light so that a light source in one room illuminates a neighbouring room if there’s a window between them, then you might do something like this:

[code]
class Window: Door
canTravelerPass(traveler) { return nil; }
explainTravelBarrier(traveler)
{
"^<> too small to climb through. ";
}

isLit = (destination && destination.isIlluminated)
;

[/code]You’d then define a physical window using two Window objects in the same way as a door, with each side of the window in one of the rooms it connects and each side pointing to the other via its otherSide property.

This should certainly work in adv3Lite (unless there’s a bug I need to fix). Of course you need to make sure that the room itself isn’t lit (define isLit = nil on the room) otherwise putting the light source in a container won’t affect the lighting, and you need to close the backpack before the light is extinguished.

A possible issue that popped into my head (without having tried the viewport extension) is whether the other side of the window is fixed or can change. If the PC is on a train and it’s moving from station to station, then the other side of the window can change while the PC remains in the same room. And conversely – if you’re at a station, different trains with different windows may come and go. I don’t know if this is what mokau has in mind, but it’s an interesting wrinkle, because one usually thinks of windows as being fixed…

Regrettably, I was actually ignorant of the viewport module and I have never actually read through the ‘extensions’ chapter in the manual. Sorry to embarrass myself. I’ll try to utilize the viewport and if I have any further troubles I’ll report back.

Thanks for the replies.

It can change, simply by changing the value of the Viewport’s visibleRooms property, but if you do that it would be a good idea to reset the value of the enclosing room’s roomsViewed property to [] at the same time (by the enclosing room, I mean the room containing the Viewport).