Quest 4.0.5 is now available.

If you’re a Quest Pro user, you can download your update from the “My Downloads” area at http://www.axeuk.com/mydownloads

Otherwise you can download Quest 4.0.5 from http://www.axeuk.com/quest/download.htm

This is a bug-fix release, which addresses the following bugs:

Quest
- fixed various crashes when running using JAWS.
- when connecting to a QuestNet game with a blank title, Quest wouldn't successfully connect to the game.
- when double-clicking a QSG file in Explorer, if the ASL/CAS file was not found and you chose not to find it, quest.exe would remain running in the background.
- The word "and" was hard-coded (for room descriptions "You can see ..., ... and ..."). This has now been added to the LDF file so it can be translated.
- Variable names containing capital letters could cause a run-time error.
- If a game contained parameters with no end-of-parameter ">" character, no error would be reported.

QuestNet Server
- "disconnect" admin command didn't work.

QDK
- No changes.

Other changes
- QuestNet Server is no longer being actively developed - I am currently working on the next major version of Quest, version 4.1, and this will not include QuestNet Server. Unless any bugs are found, this will be the last version of QuestNet Server. The "Pro" version is now included with Quest Pro, and is no longer available for sale separately.
- There is a slight change to the version numbering convention - this version is called 4.0.5 instead of 4.05.

Bah! I mean, come on, you've got an IF/Text game making codebase developed and you think it's more intelligent to discontinue the multiplayer aspect? What sense does that make? Seriously, your codebase and learning curve are much kinder than any of your "competition" could hope for, but instead of supporting the product, increasing usability and increasing your market by advancing into graphics based games as well, or using any forward momentum you have to score, you just sort of put down the ball and walk away.

I realize Quest and ASL have been part of your life as a software developer for a long time, but it's really ridiculous that you've always sort of paid it the minimal due it has coming. Every time I think of purchasing a PRO license I remember that "it's for an unsupported product".

It's so long been obvious that with the strong engine behind it, doing something simple such as moving away from VB, adding OpenGL support and working on 2d graphic support, would have made Quest a huge "Make-Your-Own" game product, but instead it's a couple bug fixes for an old system and an option to polish the turd interface. I love the language and the potential it holds, don't even dislike the 12 person userbase, but man, at this point open source it and watch it fly rather than tie a stone to it.

P.S. For a bug for Questnet Server, how about clicking on any object made dynamically, from the object debugger, crashing the server.
And how about for a Quest bug, #variable:property# has NEVER worked consistently. I realize that $objectproperty(object;property)$ has been considered outdated for quite some time, but it's the only reliable way to reference an objects properties, stored in a variable or not. Whatever happened to moving things towards Object.property?

Bah! I mean, come on, you've got an IF/Text game making codebase developed and you think it's more intelligent to discontinue the multiplayer aspect? What sense does that make?

I only have a finite amount of time to spend developing and supporting Quest - it's not my full-time job. Quest and QDK need a lot of work to bring them into the .net world and to make their internal workings a bit more logical and consistent. It simply doesn't make sense for me to support the additional complication that multi-player brings, especially since absolutely no-one is using it. It makes much more sense for me to focus on Quest's core strengths, and it will enable me to develop new versions much more quickly.

I'm not saying that QuestNet Server will never come back - it may do at some point in the future, but it's much more efficient for me to put it aside for the time being.

Every time I think of purchasing a PRO license I remember that "it's for an unsupported product".

Are you referring to Quest Pro or QuestNet Server Pro here? Quest Pro is fully supported, and I'll continue to support QuestNet Pro and fix any bugs that arise in v4.0.x.

It's so long been obvious that with the strong engine behind it, doing something simple such as moving away from VB, adding OpenGL support and working on 2d graphic support, would have made Quest a huge "Make-Your-Own" game product, but instead it's a couple bug fixes for an old system and an option to polish the turd interface.

Wow, if moving away from VB and adding in 3D and 2D graphics support is a simple move, I'd love to know what counts as complex

Seriously though, it would be hard to do any of things with the Quest code in its current state. I'll be refactoring it over the following v4.x releases, to get it into a better state for migration to .net. Being better componentised it will also be easier to extend the framework, opening up the possibility of plugging in different user interfaces in the future. This isn't going to happen without a lot of work though so don't hold your breath...

I love the language and the potential it holds, don't even dislike the 12 person userbase, but man, at this point open source it and watch it fly rather than tie a stone to it.

It's a bit of a misconception about open-source projects that they automatically grow faster than closed-source. If I open-sourced Quest:

- few people would be interested in developing it, apart from me
- the code would still be horrible VB6 code
- I would have the additional overhead of supporting and documenting the source code rather than just the product
- I would have the additional overhead of managing additional developers

Realistically I don't see open-source working for Quest in its current state. If I ever decided not to actively develop it any more myself I would consider it, but right now open source isn't going to magically make things better.

P.S. For a bug for Questnet Server, how about clicking on any object made dynamically, from the object debugger, crashing the server.
And how about for a Quest bug, #variable:property# has NEVER worked consistently. I realize that $objectproperty(object;property)$ has been considered outdated for quite some time, but it's the only reliable way to reference an objects properties, stored in a variable or not. Whatever happened to moving things towards Object.property?

I've not previously been made aware of either of these bugs, as far as I know.

I will take a look at the QuestNet Server bug.

Do you have a repro case for the Quest bug? Is there an ASL file you can send me that demonstrates the problem?