What is this pesky ___ SPACE___ that gets magically inserted when I try to copy-paste code. It only happens occasionally and sometimes I can get it to go away and other times it ALWAYS returns!?!?

This time I am trying to copy-paste

<source src=\"" + GetFileURL("Creepy Good Night.ogg") + "\" type=\"audio/ogg\" >

or this

<source src=\"" + GetFileURL("filename.mp3") + "\" type=\"audio/mp3\" >

It always reverts to this: <source___SPACE___src...

I've tried typing it without a copy-paste, copy-pasting from different formats, etc...

Thanks in advance.

(filler for getting my edited post, updated/posted)

I think from whatever the medium/software that you're copying it from, has its own 'space/whitespace' character/symbol code for its formating, which is unable to be recognized by the copying of it into quest, and so it instead replaces it with the '___space___', which is either: quest's own 'space/whitespace' character/symbol code, or it's that medium-software's (that you copied it from) own 'space/whitespace' character/symbol code for its formating

the '__space__' represents a space/white-space character:

Hegemon Khan === Hegemon__space__Khan

HTML:

Hegemon Khan === Hegemon Khan

etc etc etc languages...

ht.tp://www.asciitable.com (see/find the: chr 'space' or dec '32' for space/whitespace coding)

all programs/software/programming-languages have their own formatting codes and codes for their characters/sumbols... which may not be universally recognized by other programs/software

This is what works for me:

msg ("Playing audio file 2...<audio autoplay><source src=\"" + GetFileURL("file name.ogg") + "\" type=\"audio/ogg\" ><source src=\"" + GetFileURL("file name.mp3") + "\" type=\"audio/mp3\" >Your browser does not support the audio tag.</audio>")

I tested with a space in the name, and it still works.

Do you have that nested between <audio autoplay> and </audio>?

Here's the entire cup (from Two Sounds and a Cup):

    <object name="cup">
      <inherit name="editor_object" />
      <look><![CDATA[Just an average cup.<br/>]]></look>
      <take />
      <listen type="script">
        play sound ("03da cloud remix ext inst.mp3", false, true)
      </listen>
      <shake type="script"><![CDATA[
        msg ("Playing audio file 2...<audio autoplay><source src=\"" + GetFileURL("snd effect.ogg") + "\" type=\"audio/ogg\" ><source src=\"" + GetFileURL("snd effect.mp3") + "\" type=\"audio/mp3\" >Your browser does not support the audio tag.</audio>")
      ]]></shake>
    </object>

http://textadventures.co.uk/games/view/ro3fkuza30ee6ya-clhega/two-sounds-and-a-cup

EDIT:

I've tried everything I can think of to recreate your error, but I can't. (I've seen your error before, mind you. I just can't get it show its ugly face this time.)

It's what happens when you try to do something like "player.play game" instead of "player.playgame," for example.

Generally computer languages do not like spaces in object or variable names, and I guess Quest gets around that by internally converting a space to ___ SPACE___, on the assumption no one will have that in a variable name so it will not conflict. I have never seen that when copy-and-pasting, but I have seen it in error messages.

Are you doing it in code view or with the GUI view? I always do it in code view, which might be safer as it is just text at that time.

Looks to me like you have an opening quote missing.

I am doing it in... code view. Sort of.

Here is what I have so far in a little test game.

    <object name="music stick">
      <inherit name="editor_object" />
      <look type="script">
        msg ("Looks like a music stick.  Listen to it.")
      </look>
      <listen type="script">
        play sound ("Creepy Good Night.mp3", false, true)
      </listen>
      <shake type="script"><![CDATA[
        msg ("Playing audio file 2...<audio autoplay><source src=\"" + GetFileURL("latin demon.ogg") + "\" type=\"audio/ogg\" ><source src=\"" + GetFileURL("latin demon.mp3") + "\" type=\"audio/mp3\" >Your browser does not support the audio tag.</audio>")
      ]]></shake>
      <take />
    </object>
  </object>

The "playing audio file 2..." message shows but the file never plays. The original file will play and continue to play (Creepy Good Night), but the other file will not.

What am I missing?

EDIT: FYI, the space error has been fixed, I think.

Also, @KV, in your demo, 'listen to cup' doesn't appear to play any sound. 'Shake cup' gives me the melodic 'sound effect' =)

Try this

msg ("Playing audio file 2...<audio autoplay><source src=\"" + GetFileURL("latin demon.ogg") + "\" type=\"audio/ogg\" /><source src=\"" + GetFileURL("latin demon.mp3") + "\" type=\"audio/mp3\"/>Your browser does not support the audio tag.</audio>")

<audio autoplay>
  <source src=\"" + GetFileURL("latin demon.ogg") + "\" type=\"audio/ogg\" /> 
  <source src=\"" + GetFileURL("latin demon.mp3") + "\" type=\"audio/mp3\"/>
  Your browser does not support the audio tag.
</audio>

The source element tag needs to end in /> to close it, not >, which leaves it open.

(It's just like <include ref="Core.aslx" />. It you have <include ref="Core.aslx" >, it leaves that element tag open, which, of course, throws an error. The /> closes it. <br> and <hr> are the only two I know of which are closed by default. (<br/> and <hr/> is what is actually 'interpreted' by the browser.))

(sorry, going off at a tangent here)

I don't think <br> and <hr> are the only exceptions. In HTML3, which was based on SGML rather than XML, the browser was supposed to assume a tag was closed unless it found a matching close tag somewhere (because <tag /> notation didn't exist). There were a ton of rules about where it was supposed to assume the presence of the missing closing tag. An unclosed <br> or <img> used to be correct, so a lot of systems that shouldn't have to deal with the complexity end up with a ton of special cases in their code to handle markup like that.

A lot of browsers have kept some of those rules, but not in a consistent way. I think <img> is normally converted to <img /> as well; as there are very few circumstances where it would make sense to put something inside an image. I also remember something about <script> being converted to <script /> if the following code is not a CDATA block and doesn't look like a recognised scripting language. I'm sure there are others that I can't think of off the top of my head. Some tags (such as <p> and <li>) will be assumed to have a corresponding closing tag immediately before the next tag of the same type if they aren't properly paired; while others (such as <b>) may have the implicit closing tag added before the end of the containing element. Unfortunately, there are some edge cases that vary between different browsers. Last time I checked, <b>this<i>is</b>invalid</i> might be magically converted to any of <b>this<i>is</i></b><i>invalid</i>, <b>this<i>is</i>invalid</b>, or <b>this<i>is</i></b>invalid depending on your browser.

mrangel,

Your tangents are awesome! (I always learn something that makes all sorts of other puzzle pieces fall right into place.)