I have a question directed mainly at Alex, but here because it is probably of general interest.

Currently Quest allows the inclusion of libraries of pre-written code (like the extension libs I've done over the years since it became possible!) but these have always had to be distributed in source code (asl) form.

I'm wondering, would be advantageous if QCompile was able to compile the asl library separately from a game and this make it possible to distribute libraries in 'CAS' format?

Obviously Quest would need to be able to handle included CAS format and QCompile would need to be able to compile mixed ASL source & pre-compiled 'CAS'. I appreciate that this may well be a distinctly non-trivial change!

The advantage I see in this is that the library author's code is protected against accidental or deliberate changes being made to it and so should be less likely to cause problems due to well intentioned but incorrectly made alterations.

Personally I have always put an emphasised warning in the documentation for my libraries (and in the libraries themselves) that they should not be altered in any way.

This is just a thought that came to me as I started to write the demo for the latest 'typelib.qlb' (this beta 3 version adds some very cool new features in my opinion) and once again found myself typing the 'don't mess with my library code' disclaimer! :-)

I'd be interested to hear what Alex and y'all think of this.

BUT as you are the author of the library which MANY people do/will use I think you *should* be able to protect the code from being *altered*. You may also wish to add a source code file, so if anyone does happen to peruse the file and see anything which (in their opinion) could be altered then they could e-mail you with the precise details...... Then again not very many people would like looking through a file VERY big (and last time I looked the library was mighty big - too big for my tastes).

Just my tuppence...

quote:

---

...I don't really care if *my* code it seen or changed - be it on their heads - so I say!

---

LOL - I understand the sentiment, but if you put a lot of work into coding a few neat puzzles for your player to fathom out, it is undesirable that he/she can just open your *.asl file and read the solutions - that's one of tthe real 'points' of Qcompile.

The other main point is that a game can be broken into numerous manageable pieces for coding, several ASL files and maybe a library (or two) actually making one game.
Obviously this makes distributing the finished game rather messy.

You might start with (say) seven seperate source files that make up your game. Run the game through Qcompile and you get one compressed file containing all your source ASL files and libraries - MUCH nicer to diistribute.

A side issue here is that if you use libraries, distributing a game can cause problems where you used a different release of the library to the one the eventual player has - give them a copy of 'your' version and there is the risk you'll overwrite a different version on the players machine and 'break' other games. Obviously if you distribute 'compiled' versions - this problem is completely avoided.

A note to Alex - it would be really nice if QCompile also allowed authors to build a "resource" file conntaining the graphics and sounds (if any) that a game uses - say it output 'mygame.cas' (for the game) and 'mygame.res' for a comiled resource file.
This would only require the Quest runtime to look for a 'res' file that matches the name of the current game and look in that rather than in the game folder for sound and music files.

Currently I 'fake' this external resource capability by means of a self written 'exe' file containing sounds and graphics that is shelled from Quest and uses command line switches to pass info as to which image/sound to use (and a password to prevent running it externally and cheating!

It would be better if Quest could call resource files directly and making it possible to build those with QCompile would also 'add value' to the registered version of Quest-Pro of course!

quote:

---

... You may also wish to add a source code file, so if anyone does happen to peruse the file and see anything which (in their opinion) could be altered then they could e-mail you with the precise details...... Then again not very many people would like looking through a file VERY big (and last time I looked the library was mighty big - too big for my tastes).

---

Yeah, I understand that as it is 1500 lines plus now which IS big (though tiny compared to the libs that come with TADS or Inform!).
I tried breaking it into smaller individual libraries, but there is so much interdependence (not least for providing the QDK interface) that in order for each indiviual piece to work you need to include so many of the others that it becomes impractical to leave anything out.

Essentially the lib has two main 'functions' provision of "containers" and "clothing" - as you have to in some way keep track of the clothing you need to put it in containers. Containers need virtually every inbuilt Quest command to be overridden to work properly - you have to allow people to look at (even look inside/examine) things, take them, give them, put them into things.. none of which is allowed in Quest by default unless the object is in the inventory or current room. The size and complexity of the library is thus pretty unavoidable.

Thanks for the feedback CW!

quote:

---

I'm wondering, would be advantageous if QCompile was able to compile the asl library separately from a game and this make it possible to distribute libraries in 'CAS' format?

Obviously Quest would need to be able to handle included CAS format and QCompile would need to be able to compile mixed ASL source & pre-compiled 'CAS'. I appreciate that this may well be a distinctly non-trivial change!

---

It would require a bit of work, but it's certainly possible - a nice idea, I'll add it to the "to do" list...

quote:

---

A note to Alex - it would be really nice if QCompile also allowed authors to build a "resource" file conntaining the graphics and sounds (if any) that a game uses - say it output 'mygame.cas' (for the game) and 'mygame.res' for a comiled resource file.
This would only require the Quest runtime to look for a 'res' file that matches the name of the current game and look in that rather than in the game folder for sound and music files.

---

Actually I like that fact. I'm actually going to include a cheating ability in my games, so if they want to they can cheat - it just means they don't get the extras (this isn't a Quest game BTW).

"You might start with (say) seven seperate source files that make up your game. Run the game through Qcompile and you get one compressed file containing all your source ASL files and libraries - MUCH nicer to diistribute.

A side issue here is that if you use libraries, distributing a game can cause problems where you used a different release of the library to the one the eventual player has"

Well I agree that it's much easier to distribute one file.
On your second note; that is why you standardise(SP?) the library (as you know). You use mostly the same syntax or parameters, and only ADD to them (where you can). I understand how in some cases you may need to update it - but in those cases wouldn't you add a NEW command or call with different parameters, keeping the older one for backward compatibility and then if you remove it, just add a bit to convert the old call to the newer call (erm, this is geting out of hand right here... I only meant to comment).

"Currently I 'fake' this external resource capability by means of a self written 'exe' file containing sounds and graphics that is shelled from Quest and uses command line switches to pass info as to which image/sound to use (and a password to prevent running it externally and cheating!"

LOL...
Again - I don't really mind about that - infact I promot it since *I* myself like looking for stuff like this... Infact I have spend hours scanning my PSX discs for pictures, sounds and movies : )

"I tried breaking it into smaller individual libraries, but there is so much interdependence (not least for providing the QDK interface) that in order for each indiviual piece to work you need to include so many of the others that it becomes impractical to leave anything out."

Totally understandable Al. I do like putting things in sections, but when it comes to overlapping code and writing out the SAME code more than twice I get annoyed (I had such a fun time checking tables of results for my various courseworks! And let's not forget some coding in true BASIC which needs you to alter one thing in several identical lines of code), as do ALL coders by nature.

Thanks for the discussion Al.