Jolt Country

Posted: **Sat Nov 03, 2012 2:17 pm**

Roody_Yogurt wrote:In the end, I decided, why put off until 2013 what you can do in 2012, so yes, people can also submit ZIL games (if so, you'll want the ZIL manual and ZILF). You're welcome!

Thank You! I'm sure this is old news to some people, but I had no idea ZIL was available. I had the impression that it was still owned by Activision. I see now, thanks to Wikipedia, that they abandoned the Infocom trademark in 2002; Which just happens to be one of dates on the ZIL manual. Man am I behind the times!

Anyway, I took a break from Hugo last night and checked it out. So far I've made two rooms, a torch(providing light), a desk with a single drawer(although the drawer isn't in desk, it has the flag NDESCBIT, which causes it not to be mentioned in the room description), the verb "score"(which does nothing more than print a message) and a poisoned apple that kills the player if he eats it.

I've found that ZIL isn't terribly difficult to learn, but the manual is incomplete and sometimes misleading. For instance, it states that the flag CONTBIT is all that is needed to implement a container that can be opened and closed, but in reality you also need to give it the OPENABLE flag as well, which isn't even mentioned in the manual.

Other items of interest:

The file "parser.zil" should more accurately be called a library, since it contains not only the parser but globals, constants, object properties, attributes(which they call "FLAGS"), misc routines, verbs and verb syntax. The manual mentions other items of what it calls the "Substrate" which aren't present; like some common object definitions and code for in-game hints.

The code can be broken into parts and included just like Hugo. The syntax for that is "<INSERT-FILE "[file to be inserted]">. I haven't figured out yet whether it matters where the file is included. So far it doesn't.

The "again" verb causes my parser to freeze. I don't know if this is due to the v-again routine itself or an error in the shell. I wish we had access to the source from a full Infocom game so we could see exactly how they put it together.

I haven't figured out how to replace routines or objects from "parser.zil". I suspect that this wasn't an option and they just copied and modified the library files themselves. It would be nice to know for sure, since I prefer the way Hugo handles replacing routines and objects. It would also make fixing ZIL's "Cloak of Darkness" easier, since the current version doesn't do it justice(Ex: The darkwarning mentions the possibility of being eaten by a grue, which I'm pretty sure isn't present in any other CoD game).

I think you're right about having some lessons to learn from The Implementers. It's amazing how similar its functionality is to modern IF languages. I haven't read through the entire manual yet, but so far I'm impressed with ZIL. It's also a dream come true to see some of the original code from Zork I!

Since contributing a game in ZIL is an option, I think it might be a good idea to split the ZIL conversation off and provide coding support for anyone who actually tries to use it. I'm not suggesting that anyone neglect their own IF work; I just think it wouldn't take that much effort to learn a few of the more dangerous pitfalls associated with ZIL. I'm guessing Inform users could be especially helpful in this area, since I get the impression that Inform and ZIL are closely related.

-lc

Posted: **Sat Nov 03, 2012 2:59 pm**

loafingcoyote wrote:I've found that ZIL isn't terribly difficult to learn, but the manual is incomplete and sometimes misleading. For instance, it states that the flag CONTBIT is all that is needed to implement a container that can be opened and closed, but in reality you also need to give it the OPENABLE flag as well, which isn't even mentioned in the manual.

Not only is the manual incomplete (although hey, isn't it great that it was written?), but ZILF is basically the product of reverse-engineering so some things in the manual don't work as described. You're going to want to take a look at the ZIL_ZILF_differences.txt file in the library folder. As it implies, I think the OPENABLE bit was a modern addition to bring ZIL up to current understandings of containers.

loafingcoyote wrote:The file "parser.zil" should more accurately be called a library, since it contains not only the parser but globals, constants, object properties, attributes(which they call "FLAGS"), misc routines, verbs and verb syntax. The manual mentions other items of what it calls the "Substrate" which aren't present; like some common object definitions and code for in-game hints.

I think parser.zil is somewhat a construction of the ZILF maintainers. The original games didn't really share a library between them to save space, so again, the ZIL library is basically a construction of modern times.

The internet's deep dark secret is that there is Infocom game code out there (as witnessed by that waxy.org scandal the other year when that guy released part of the Hitchhiker's sequel), and the library as it stands, is the best we can put together so far until more of it is freely available to work off of.

I even wrote Laird Malamed about it (releasing game code freely) the other month, but I must have not explained my case very well because he gave the standard ZIL-is-lost-to-the-sands-of-time answer.

loafingcoyote wrote:The "again" verb causes my parser to freeze.

Hmm, that isn't listen among the not-yet-supported things, so I don't know what the deal with that is. Whatever the case, one can tell that ZIL support is not yet 100%. Including it in this competition is one way I'm trying to motivate wider adoption, but I also think that maybe we could do a kickstarter down the road for it to try to reward the people who have put time and effort into this.

loafingcoyote wrote:Since contributing a game in ZIL is an option, I think it might be a good idea to split the ZIL conversation off and provide coding support for anyone who actually tries to use it. I'm not suggesting that anyone neglect their own IF work; I just think it wouldn't take that much effort to learn a few of the more dangerous pitfalls associated with ZIL. I'm guessing Inform users could be especially helpful in this area, since I get the impression that Inform and ZIL are closely related.

Yeah, if there's interest, we definitely should start a ZIL thread (or possibly even create a base for them).

I think Inform doesn't have much from ZIL, syntax-wise or anything, although it probably got some design elements out of the reverse engineering of the z-machine format.

(This was one of those posts where half of the things I said are technically wrong in some way but I hope it was still informative in the right ways.)

Posted: **Sun Nov 04, 2012 2:17 am**

Roody_Yogurt wrote:Not only is the manual incomplete..., but ZILF is basically the product of reverse-engineering so some things in the manual don't work as described. You're going to want to take a look at the ZIL_ZILF_differences.txt file in the library folder.

Yeah, I dove right in and missed the "zilf_differences" file. Looking at it is sobering. There is far more work to do than I first realized. I suppose all that extra stuff was lost with the missing "Substrate" files, but who knows?

I worked on ZIL a bit more today and found something else not covered in the "ZIL_ZILF_differences" file. I was trying to define some verbs when I realized that the "A" and "T" TELL tokens were not working properly. I needed them to display object articles correctly, like this:

Code: Select all

<ROUTINE V-TOUCH &#40;&#41;
	<TELL "You touch" T ,PRSO ", but feel nothing unexpected." CR>>

In the above, if the player tries to touch an object, it should respond with something like this:

"You touch the rabid alpaca, but feel nothing unexpected."

Unfortunately, neither the article nor the object name were printed. I worked around the issue by doing this:

Code: Select all

<ROUTINE V-TOUCH &#40;&#41;
	<TELL "You touch">
	<THEARTICLE .PRSO>
	<TELL D PRSO ", but feel nothing unexpected." CR>>

<ROUTINE THEARTICLE &#40;OBJ&#41;
	<COND &#40;<FSET? .OBJ ,NARTICLEBIT> <TELL " ">&#41;
              &#40;ELSE <TELL " the ">&#41;>>

This code prints properly. The second routine is mine and is similar to The(obj) for Hugo.

Roody_Yogurt wrote:The internet's deep dark secret is that there is Infocom game code out there (as witnessed by that waxy.org scandal the other year when that guy released part of the Hitchhiker's sequel), and the library as it stands, is the best we can put together so far until more of it is freely available to work off of.

This is pure gold. The demos, though very sparse, are worth trying. I hadn't heard of Michael Bywater before this but his perspective is enlightening. Reading the comment section is like watching a train wreck, except that in this case the train somehow pulls itself together and makes it to the station. The one thing that's obvious to me is that the demise of Infocom must have been very painful for all those involved

Roody_Yogurt wrote:I even wrote Laird Malamed about it (releasing game code freely) the other month, but I must have not explained my case very well because he gave the standard ZIL-is-lost-to-the-sands-of-time answer.

Yeah, he was probably too busy playing "Guitar Hero" to pay any serious attention to your request.

Roody_Yogurt wrote:Including it in this competition is one way I'm trying to motivate wider adoption, but I also think that maybe we could do a kickstarter down the road for it to try to reward the people who have put time and effort into this.

This is an interesting idea. What would a ZIL kickstarter look like?

Roody_Yogurt wrote:(although hey, isn't it great that it was written?)

Oh, absolutely! Playing with ZIL the last couple of days has reminded me of all my old feelings for IF. Strangely enough, its the sounds that bring back the best memories. I remember the rattling sound my old Apple IIe would make when I turned it on and knew adventure and fun were just moments away. The best sound, by far, was when I would figure something out and the disk drive would start spinning, rewarding me with a screen full of new text.

Now...that...is old-school text adventuring.

Posted: **Sun Nov 04, 2012 1:46 pm**

loafingcoyote wrote:This is an interesting idea. What would a ZIL kickstarter look like?

Yeah, I dunno. Maybe we could detail the features we'd most like to see added. In some ways, it'd be a bit of reward for the work done so far, but yeah, it'd be good to determine what we'd most like to see fixed/added.

The money would go to Jesse McGrew and possibly Josh Lawrence, based on interest to continue development.

In the meantime, I think we just need wider adoption to pinpoint where it needs the most work.

Posted: **Sun Nov 04, 2012 6:17 pm**

I read through the manual and was excited about writing a ZIL game. Then I read this thread and found out that not everything works in the language and that made me the opposite of excited about writing a ZIL game. I have enough problems getting things to work in Inform, a language that works great with great documentation and an army of people willing to help. Sounds like for this round, Hugo it is.

Posted: **Wed Nov 07, 2012 2:25 pm**

Hey guys, I haven't worked on the ZILF libary in...wow, must be two years, now, and can't right now because of multiple *other* unfinished projects I'm trying to actually finish, but I encourage anyone messing with ZILF and finding bugs to please report them on SourceForge:

http://sourceforge.net/tracker/?group_i ... id=1329565

I don't know if Jesse (who did all the heavy lifting with the ZIL reverse-engineering to craft ZILF) has free time either, but seeing people poking around with ZILF and reporting more bugs would likely catch his eye. (roody, if you're still on ifMUD, maybe let him know?)

loafingcoyote, AGAIN was a bear to get working, as it involved the deep internals of ZIL parsing that are out of my league, but it I know it was working at some point. Jesse would probably have to tackle that. Did you try different interpreters and it failed on all of them?

Not sure why T and A aren't working, I'm 80% certain they were working previously, too.

And just a note, as well things that are missing, that differences.txt file also notes some things that are improved in ZILF vs. ZIL -- more flexibility with containers, more options with readable text, more logical use of SIZE, CAPACITY and WEIGHT, multiple PICK-ONE options, new WAIT-TURNS routine, differentiation between turning light sources on/off and turning machines on/off. And some of the unimplemented bits are undocumented in Infocom's ZIL manual or of questionable use, so the news in that differences file is not ALL bad. :)

That's not to say that making a ZILF game at this point would not be some rough going, especially with things like TAKE ALL and OOPS not implemented, and AGAIN apparently broken again.

It actually might be best used at this point for more experimental stuff, where the game is parser based but does some things outside the IF norm, because it is much simpler (once you grasp ZIL syntax) to re-wire how things are handled in the engine than in modern languages -- IE you could have a specific command that would whisk the player into some text mini-game (all its own routine) that would have its own internal set of play turns and then take the user back to normal IF parsing when it's done, or have that mini-game running parallel to each turn of normal IF play, etc. And likewise the library of default actions and responses is simple (too simple at this point, yes) enough that to totally customize it to your liking is doable, something that would be a nightmare in Inform or TADS or (I'm guessing) Hugo (although certainly all 3 languages have made strides to ease customization of handling of default actions). That was the kind of stuff I wanted to explore whenever I return to ZILF.

Posted: **Wed Nov 07, 2012 7:19 pm**

Thanks for the info, Josh! I was actually replicating the T/A thing myself this afternoon, so your post had great timing.

jjsonique wrote:... I encourage anyone messing with ZILF and finding bugs to please report them on SourceForge:

http://sourceforge.net/tracker/?group_i ... id=1329565

I already reported the AGAIN issue, but yeah, I'll do the T/A thing, too.

jjsonique wrote:I don't know if Jesse (who did all the heavy lifting with the ZIL reverse-engineering to craft ZILF) has free time either, but seeing people poking around with ZILF and reporting more bugs would likely catch his eye. (roody, if you're still on ifMUD, maybe let him know?

I haven't brought anything to his attention yet. He has a new job (he's also now in the Bay Area, if you hadn't heard), so I imagine he has less free time. Still, I'll run these issues past him next time I see him.

jjsonique wrote: It actually might be best used at this point for more experimental stuff, where the game is parser based but does some things outside the IF norm, because it is much simpler (once you grasp ZIL syntax) to re-wire how things are handled in the engine than in modern languages -- IE you could have a specific command that would whisk the player into some text mini-game (all its own routine) that would have its own internal set of play turns and then take the user back to normal IF parsing when it's done, or have that mini-game running parallel to each turn of normal IF play, etc. And likewise the library of default actions and responses is simple (too simple at this point, yes) enough that to totally customize it to your liking is doable, something that would be a nightmare in Inform or TADS or (I'm guessing) Hugo (although certainly all 3 languages have made strides to ease customization of handling of default actions). That was the kind of stuff I wanted to explore whenever I return to ZILF.

I haven't looked at ZIL long enough for the possibilities to take form yet, but I look forward to getting to that point of familiarization.

I think the main thing we should take away from this is, even if we don't have any ZIL submissions in this year's HugoComp (although I hope we still do), we do have a good handful of genuinely-interested parties, and maybe we could steamroll this interest into a more organized event in 2013.

Also, just having a JC thread with ZIL code in it is pretty awesome. Thanks for that, loafingcoyote!

Posted: **Sun Nov 11, 2012 6:21 pm**

Jesse has weighed in. He's thinking that AGAIN works in the latest version, just not 0.3, the latest built release... so maybe we'll see a new release sometime in the near future.

As far as the A/T token stuff goes, no, it has not been implemented yet, so it was moved to "feature requests." In the meantime, loafingcoyote's earlier code is a good example of how it's within our abilities to contribute on the library/code side of things, so that's cool.

Posted: **Sun Nov 11, 2012 10:34 pm**

Some more ZILF news. The new release 0.4 is now available here.

The AGAIN issue was tracked down to some specific code.

In older versions of Cloak of Darkness:

Code: Select all

    <REPEAT &#40;&#41;
        <COND &#40;<PARSER>
                <PERFORM>
                <APPLY <GETP> ,M-END>
                <OR <META> <CLOCKER>>&#41;>
        <SETG HERE <LOC>>>>

In the AGAIN-working version, it looks like this:

Code: Select all

    <REPEAT &#40;&#41;
        <COND &#40;<PARSER>
                <PERFORM>
                ;"WAIT loops through M-END and CLOCKER in a special way during PERFORM, so skip
                those routines if WAIT ran this turn"
                <OR <META> <AND> <APPLY <GETP> ,M-END>>
                <OR <META> <AND> <CLOCKER>>
                ;"backup inputbuffers"
                <COPY>
        		<COPY>
        		<SETG>&#41;>
		<SETG HERE <LOC>>>>

So hey, make sure your game has that code.

Posted: **Sun Nov 11, 2012 11:46 pm**

Hi jjsonique! Thanks for weighing in on this discussion. I understand if you don't have much time for this since, in reality, neither do I. However, any advice or information you have concerning ZIL would be invaluable to me or anyone else around here interested in learning ZIL.

To me it presents an intriguing puzzle and a genuine mystery. It's my understanding that ZIL is the first language made exclusively for writing IF, so I can't believe more people aren't involved with it. Of course, I can understand how daunting it is since, in its current form, it resembles a salvage operation more than anything. That's not to disparage all the hard work that's been put into it, by the way. Without it we wouldn't have anything to work with now!

jjsonique wrote:That's not to say that making a ZILF game at this point would not be some rough going, especially with things like TAKE ALL and OOPS not implemented, and AGAIN apparently broken again.

Yeah, whoever makes a game in ZIL is going to have to approach the project with limited expectations on what they can accomplish. That's why Hugo Comp is the perfect place for new ZIL games. No one is going to be torn appart by wolves for contributing a game that is less than perfect(in either ZIL or Hugo). We're just just glad for new Hugo games, no matter what they look like.

Roody_Yogurt wrote:As far as the A/T token stuff goes, no, it has not been implemented yet, so it was moved to "feature requests." In the meantime, loafingcoyote's earlier code is a good example of how it's within our abilities to contribute on the library/code side of things, so that's cool.

What ZIL needs, other than full time users, is more example code. So, yeah, we can contribute a lot by simply writting functioning code. I've focused on adding simple verb-stub type verbs so far. I also wrote a working version of the verbs "lock"/"unlock". I cheated a bit, since what I wanted to do was add a "KEYOBJECT" property to lockable items, just like Hugo. After an exasperating couple of hours I had to admit that it was beyond my current ability. I ended up having the PRSI(indirect object) handle the locking and unlocking part while the verb routines handle all the default messages. Here is the code:

Code: Select all

<SYNTAX UNLOCK OBJECT WITH OBJECT = V-UNLOCK>

<ROUTINE V-UNLOCK &#40;&#41;
	<COND &#40;<NOT <FSET?, PRSO, LOCKABLE>>
			<TELL "You can't unlock">
			<THEARTICLE .PRSO>
			<TELL D PRSO "." CR>&#41;
		&#40;<FSET?, PRSO, OPENBIT>
			<CTHEARTICLE .PRSO>
			<TELL D PRSO " is open." CR>&#41;
		&#40;<NOT <FSET?, PRSO, LOCKEDBIT>>
			<CTHEARTICLE .PRSO>
			<TELL D PRSO " isn't locked." CR>&#41;
		&#40;<NOT <FSET?, PRSI ,KEYBIT>>
			<CTHEARTICLE .PRSI>
			<TELL D PRSI " wont unlock anything." CR>&#41;
	&#40;ELSE <TELL "That isn't going to work." CR>&#41;>>

<SYNTAX LOCK OBJECT WITH OBJECT = V-LOCK>

<ROUTINE V-LOCK &#40;&#41;
	<COND &#40;<NOT <FSET?, PRSO, LOCKABLE>>
			<TELL "You can't lock">
			<THEARTICLE .PRSO>
			<TELL D PRSO "." CR>&#41;
		&#40;<FSET?, PRSO, OPENBIT>
			<CTHEARTICLE .PRSO>
			<TELL D PRSO " is open." CR>&#41;
		&#40;<FSET?, PRSO, LOCKEDBIT>
			<CTHEARTICLE .PRSO>
			<TELL D PRSO " is already locked." CR>&#41;
		&#40;<NOT <FSET?, PRSI ,KEYBIT>>
			<CTHEARTICLE .PRSI>
			<TELL D PRSI " wont unlock anything." CR>&#41;
	&#40;ELSE <TELL "That isn't going to work." CR>&#41;>>

I'm sure this isn't optimal but It works. What the above needs most is for the verb to to be able to match the subject in the messages (whether the PRSO is plural or singular). It's easy to do but I ran out of time.

Now, for any key object, you would need this code in its action routine.

Code: Select all

<ROUTINE SILVERKEY-F &#40;&#41;
	<COND &#40;<AND <VERB? UNLOCK>
		<EQUAL? ,PRSO ,WOODENBOX>
		<FSET?, PRSO, LOCKEDBIT>>
			<TELL "You unlock">
			<THEARTICLE .PRSO>
			<TELL D PRSO " with">
			<THEARTICLE .PRSI>
			<TELL D PRSI "." CR>
			<FCLEAR, PRSO, LOCKEDBIT>&#41;
		&#40;<AND <VERB? LOCK>
		<EQUAL? ,PRSO ,WOODENBOX>
		<NOT <FSET?, PRSO, OPENBIT>>
		<NOT <FSET?, PRSO, LOCKEDBIT>>>
			<TELL "You lock">
			<THEARTICLE .PRSO>
			<TELL D PRSO " with">
			<THEARTICLE .PRSI>
			<TELL D PRSI "." CR>
			<FSET, PRSO, LOCKEDBIT>&#41;>>

In this example the silver key unlocks the wooden box, which has the LOCKABLE flag. To use this action routine with other key objects all you would have to do is change the "WOODENBOX" object to the object that the given key unlocks(You would also, of course, have to change the name of the action routine).

That's not quite all. You need to drop one more piece of code into the V-OPEN routine found in parser.zil.

Code: Select all

	&#40;<FSET?, PRSO, LOCKEDBIT>
	    <PRINTR "You'll have to unlock that first.">&#41;

I put it in just before the ELSE statement.

You know, I'm starting to get a little self conscious about posting all this ZIL code in the Hugo Comp thread. I would like to keep this up, but I wonder where would be the best place to post new ZIL code? I can focus on it for about another week before I have to bear down on my Hugo Comp game. Then I expect it will dominate my life(for about four weeks anyway).

Roody_Yogurt wrote:Some more ZILF news. The new release 0.4 is now available here.

The AGAIN issue was tracked down to some specific code.

All right. It's nice to see progress already.

-lc

Posted: **Mon Nov 12, 2012 3:29 pm**

Hurrah! Glad to know AGAIN isn't broken now. And I must have been thinking about NARTICLE, which is implemented, instead of A and T. Thanks for reporting those, roody.

Great to see a start on some lock/unlock zil code, loafingcoyote.

So maybe we should start a separate ZIL thread with this sub-forum? Or maybe if there's enough interest it could become a new base, because I agree, it maybe doesn't make a lot of sense to have it mixed in with HUGO threads?

In any case, I did dig up my extended zil version of cloak which tests a lot of what's in the library currently. Just compiled it with 0.4 and it seems to be working:
https://dl.dropbox.com/u/3847822/IF/cloak_plus.zil

Things it demonstrates:

Event queues - edible apple that when examined, queues up a routine that will fire in 3 turns (and also kills you if you eat it, to test JIGS-UP), a table that when examined queues a routine that will repeat every turn until you take another action (examining the hook in the cloakroom) to deque it.

Pulling text from tables - Examining the painting or card should randomly display a different description each time, not repeating until all possible descriptions have been shown once (6 for the painting, 3 for the card). Reading the painting should pick from three different signature possibilities to display, in a 'totally' random fashion - ie, it doesn't guarantee all other possibilities have been shown before repeating a particular possibility.

A closet whose lit state can be changed by a lightswitch in a adjoining room, and a flashlight, and a transparent container (the SPHERE) containing a lightsource (FIREFLY) to test lighting routines.

A SIGN and a BOOK to test difference between TEXT (shows when object examined or read) and TEXT-HELD (only shown when object is held and read).

A bunch of containers (openable or otherwise) and surfaces in the Study to test container model, SIZE, CAPACITY, etc.

Grapes to test PLURALBIT, a cube that executes WAIT-TURNS, 'darkness' as a global, generic object you can THINK ABOUT, two animals to test PERSONBIT and the personal pronouns, and the proverbial more...

EDIT: Corrected description of card and painting's behavior.

Also, realized my original notes for this code are in the 'testing' folder of the ZILF source. The debug verbs have been removed (and the Zoom problem was resolved), but the rest of this text should be valid:

http://zilf.svn.sourceforge.net/viewvc/ ... iew=markup

Posted: **Mon Nov 12, 2012 10:39 pm**

jjsonick wrote:So maybe we should start a separate ZIL thread with this sub-forum? Or maybe if there's enough interest it could become a new base, because I agree, it maybe doesn't make a lot of sense to have it mixed in with HUGO threads?

Well, the ZIL discussion is pretty much on topic since ZIL is welcome to the Hugo Comp, so I wouldn't be too concerned. It's just that I have a fair bit more code to share and would rather not flood the Hugo Comp discussion with code that may be of interest to only a few people. I may just do like you did and use Dropbox.

jjsonick wrote:In any case, I did dig up my extended zil version of cloak which tests a lot of what's in the library currently. Just compiled it with 0.4 and it seems to working:
https://dl.dropbox.com/u/3847822/IF/cloak_plus.zil

This is exactly the sort of example code I was talking about. There is a lot here that I haven't even tried to implement and would have struggled to learn on my own.

In addition to what you mentioned, this example code helped me understand M-ENDs better. I now know that there are four of them(M-BEG, M-END, M-ENTER AND M-LOOK), they're defined as constants in parser.zil and they work with a room's room argument(RARG) to signal a local event.

Thank you for this!

Posted: **Mon Nov 12, 2012 11:23 pm**

Sure thing! I hope it helps you and any others exploring ZILF. Most everything demonstrated in that code should be mentioned either in the ZIL manual or in ZIL_ZILF_differences.txt. I've forgotten some things (both ZIL-wise and what we did in ZILF), but I'm warming up looking back over this stuff again.

Some of your earlier comments:

loafingcoyote wrote: I haven't figured out how to replace routines or objects from "parser.zil". I suspect that this wasn't an option and they just copied and modified the library files themselves. It would be nice to know for sure, since I prefer the way Hugo handles replacing routines and objects.

Yeah, you just edit parser.zil itself to replace anything.

loafingcoyote wrote: The file "parser.zil" should more accurately be called a library, since it contains not only the parser but globals, constants, object properties, attributes(which they call "FLAGS"), misc routines, verbs and verb syntax...

Yeah it would make sense to actually break the current parser.zil up into parser.zil (the actual parser), and library.zil (the library/world model stuff), or maybe even finer divisions, some point soon. I'll add that as a feature request. There may be some limit to the number of other zil files you can include in your main zil file (the one you compile), but I'm guessing it's high enough that you would never practically reach it. So you can split your zil game into whatever more logical division of zil files, and have a INSERT-FILE for each of them in the zil file you actually compile.

Posted: **Mon Nov 19, 2012 3:03 pm**

jjsonick wrote: I've forgotten some things (both ZIL-wise and what we did in ZILF), but I'm warming up looking back over this stuff again.

It's too bad you don't have time to submit a ZIL game to Hugo Comp. I think Roody has the right idea about having a ZIL specific event in 2013. Maybe call it the "Build ZIL Comp", where the theme is to add something functional to the language.

jjsonick wrote:Yeah it would make sense to actually break the current parser.zil up into parser.zil (the actual parser), and library.zil (the library/world model stuff), or maybe even finer divisions, some point soon. I'll add that as a feature request.

That's probably a good idea, since it would make it a little easier for new users to understand. I'm thinking specificaly about section 14.2 in the manual where it states, "And you can't touch the parser files. Ever." That's where I got the impresion they could be replaced some other way.

Here is an improved version of the verbs lock/unlock for ZIL. It's similar to the one above, except that you don't need a separate action routine for the PRSI. All the action is now handled by the verb routines.

https://dl.dropbox.com/u/11102009/lockv.zip

This has been fun but I'm afraid I wont be able to do much with ZIL till after Hugo Comp. My game might be a little too ambitious for the time allowed and comes with three new extensions for Hugo, so I'm officially swamped.

-lc

Posted: **Sun Dec 16, 2012 3:05 pm**

Is this still on? Is the deadline going to be the end of the day on the 21st?

If the world ends and I still haven't finish my game for HugoComp, I'll know I'm late. ;)

Posted: **Sun Dec 16, 2012 10:10 pm**

This is still on! Personally, I intend to submit at least one collaborative game that doesn't use any of the suggested Hugo Comp themes. Requiring more of a miracle is my other game idea, which I haven't even started on yet.

Games are due at the end of the day on the 21st, wherever you are. They can be uploaded to http://hugocomp.gerynarsabode.org/ or e-mailed to roody.yogurt@gmail.com (I have that e-mail address properly forwarding this year).

After games have been received, we'll take the rest of the year to betatest and go over the games ourselves. Then, we can release the games in 2013, the next year, just as we did last year.

That's the plan, anyway.

Posted: **Fri Dec 21, 2012 10:41 am**

Deadline tonight, right? Is anyone in danger of not making the deadline?

Posted: **Fri Dec 21, 2012 2:20 pm**

I just emailed mine. It's not what I was originally going to submit, but I'm happy enough with it.

EDIT: I emailed and uploaded my game, because I'm compulsive and paranoid. I hope that doesn't annoy anybody.

Posted: **Fri Dec 21, 2012 10:28 pm**

Alright, let's GET TO THOSE GAMES!

Posted: **Sat Dec 22, 2012 1:14 am**

Ok, it's midnight on the west coast, so it's time to release some games! I was reminded recently that we called it the Hugo Open House last year, and it's a pretty good description this year. For the most part, our offerings are a bit more humble this time around. That said, it helped me finish up the year with a little bit more out the door (I also will be releasing a short artistic game within the next couple days). I hope everyone else feels the same way.

The games!

Waiting- Paul Lee's offering, with source.

Clockwork Boy 2- A very short sequel to last year's game by Marius Müller, coded by me. We got into a disagreement about where it was going so the story pretty much is unfinished.

Patty Flinger- The only game submitted months ago, by Tdarcos!

Cyberganked- Robb's WIP. This is the proof of concept!

EDIT: loafingcoyote's game has joined the fray!

C.H.U.M.S.- Looks intriguing!

Jolt Country

HugoComp 2012

Re: HugoComp 2012 announced

Re: HugoComp 2012 announced

Re: HugoComp 2012 announced

Re: HugoComp 2012 announced

Re: HugoComp 2012 announced

Re: HugoComp 2012 announced