Has anyone ever published from the desktop editor, but the .quest file it produces is a buggy piece of trash? So frustrating.
I'm doing my best to debug based on runtime errors and the console log, but I don't understand why the export would be so different.
That's really weird. I can't see any reason it would be different; I assume you're using the same version of Quest to play the published version?
Can you change the extension of the quest file to .zip and break down what went wrong? Is everything in the folder that's supposed to be there (graphics, sounds, libraries etc)?
That's really weird!
Thanks Mateaus. I had no idea you could do that!
As it turns out, the reason it was breaking was because several of my rooms lacked an
<isroom /> attribute, even though they were checked-off as rooms in the GUI. This wasn't a problem when playing directly from the editor, but once it was all compiled into a .QUEST file, everything depending on that boolean broke. I guess the web player is a stricter interpreter.
Anyway, I'm in final beta testing now, and then I'll be excited to share my project with you!
Quest 5.8 has a known bug wherein the
.isroom attribute is inherited from the
editor_object type (which works fine in the editor, but goes away in a published game). If you uncheck and recheck the "Object is a room" checkbox for each room, then the
.isroom attribute will be inherited from the room itself instead of from
editor_object, thus making the attribute persist into a published game.
I did wonder about that. I've not seen it mentioned before, but when I saw that attribute I was wondering whether something like that could happen.
I guess in most games it doesn't make much difference because
isroom isn't used a lot. I'm still in the habit of treating objects and rooms interchangeably (if the player's inside it, it's a room).
Yes, I first noticed this bug when I couldn't get the
AllRooms() function (which checks for the
isroom attribute) to work in a published game.