So, I'm working in a text editor, creating libraries for Quest 5. (Right?)

...and I hate, I hate, I hate when I code something which should be nested in <[CDATA[ ]]>, but I forget to nest it in CDATA. (This is infrequent, but I'd like to eradicate the thought from the back of my mind -- when it does decide to make an appearance.)

As far as I know, there are three characters which need to be nested in CDATA: <, > and &.

I never use &, and I made a text processor thingy to use "{br}" instead of "<br/>", so I don't have to worry about that.

I also created greater than and less than functions which return booleans.

Am I missing anything? (I feel like I am.)

I think it is only < and &. This means you need to always use > in comparisons.

Or use CDATA for everything.

I think it is only < and &. This means you need to always use > in comparisons.

I thought that, too. In fact, I only had those two listed in the post. Then, I decided to check > before I clicked post, and if you put > in a script using the editor, Quest will put that script in CDATA.

I didn't test it in a library to see if it throws an error. Hold on . . .

Nope. No error. So it is just < and &. Cool.

use CDATA for everything.

That's what I used to do. (Or at least that's what I used to mean to do. Hehehe.)

It makes the text look funny in the VS Code editor. It's not a big deal at all, really. Just distracting.

Maybe I should just switch pack to Notepad++ . . .

NOTE

We can put a > in a library's code without nesting the script in <![CDATA[ ]]>, but Quest will automatically copy that object (or function, or whatever -- the whole block of code which owns the offending character (>)) into the game's main code, nested in <![CDATA[ ]]>.

That's why my code kept ending up in the main game's code while we were making Pixie's Quest a long time ago!

I'd code something, then change it a little, then the changes wouldn't take effect. I'd eventually find the damned code copied into the main game's code, and I always blamed it on XanMag (not really)! I even threatened to thump my ashes into his beer, which (if you don't know) causes a beer to foam over. Bwahahahaha! (NOTE: I didn't really threaten to do that. My ashes are too good to thump into XM's Milwaukee's Best Ice! Ha ha ha ha ha!)

Anyway, I learned something today. I forget what it was now, but this stuff about the > causing the code to get copied into the game's code and probably confusing the game author is pretty interesting, too.

I have certainly used > in libraries without a problem. Could this just be with objects?

Hrmm...

I tried to make it do it again to double-check, and I changed something else that made Quest copy the object into the game's code.

Now my theory concerns editing the library file while the game is loaded in the Quest editor and an object in said library with a parent attribute which targets a room in the game's main code.

I tested it out.

You are right about >. My > just happened to be in a script on an object in a library, and the object had a parent attribute targeting a room in the game's main code.

So:

• the Quest editor is open and the game is loaded in it
• open the library file in Notepad++
• make any simple change to the library file and save your change
• Quest is still open and says the library has been modified outside Quest

At this point, if I save in Quest before clicking "Reload", it copies the object(s) with parent targeting objects in the game's main code.

To be more precise, this only happens if an object in the library has parent targeting an object in the game's main code and this was the case before opening the game in Quest. At this point, any change at all to anything in the library will be the first step towards the magic. Then, save Quest before clicking "Reload" when prompted. If all these stars align, any objects in the library which have a parent in the main game's code will be copied into the main game's code.

Note that changing an object in the library to make it have a parent in the game while the editor is open will not trigger this. The library object must be tied to the in-game object before opening Quest to trigger this.

So . . .

To negate this worry, I shall no longer use a parent attribute in libraries. I'll just write a script to handle moving things around while the game is loading.

My ashes are too good to thump into XM's Milwaukee's Best Ice!

1. Re: ashes - my beer is too good for your ashes to be thumped into.

2. Re: aforementioned beer - That is incredibly insulting and was not advertised that way in “Pixie’s Quest”. If anyone is wondering what my favorite beer is... maybe you should go play the game!

http://textadventures.co.uk/games/view/-t63d7lfaus4vr6uo4bnka/pixies-quest-link

K.V.
This makes sense when you stop and think about it.
If you have a game open along with some referenced libraries and you are editing said game.
If you then make changes outside of Quest to one of these referenced components and quest sees this, then Quest will/should try to preserve the code as it was in order to keep the status quo.
Saving before or without a reload (to obtain the updated library code) means Quest has to preserve what it has - just in case.

I hope that makes some sense.

Exactly.

I should either edit a library or edit the game's main code, not both at once.

Plus, if I didn't have something in a library with a parent attribute targeting something in the main code while editing both at the same time, this wouldn't happen.

I guess when you click SAVE in Quest, if it finds that you have code in the main code which differs from anything in any included libraries, it saves the code in the game to the code in the game.

I was trying not to be confusing, but I'm doing crazy stuff and this is just what happens when people do crazy stuff. (They write run-on sentences.)

It is a while since I did this, but I have a feeling the editor monitors all the files in the game file, and will notice if any are changed by another program. I suspect this is so image files get updated in the editor if the author changes them.

Also, when I have had objects in a library, I think I made sure they were separate from the rest of the game. No objects in the main file have any reference to them, eg via exits.

You are right on both counts, sir.