Internal commands

[FIQ]

Really? That's the internal version of squeak(sad)? Seems a bit strange. I thought it would be converted to a playef command or something.

It is possible to do with playef(), Terry did squeak() as an alias to not have to bother with numbers in playef() I suppose, as it's a bit more readable. Just like you can create a crewman with createentity() but making it with an own command simplifies stuff.

Also, "sad" is just an alias to cry I guess (didn't know it existed), just like vitellary is to yellow.

[Dav999]

Really? That's the internal version of squeak(sad)? Seems a bit strange. I thought it would be converted to a playef command or something.

It's only strange if squeak(cry) doesn't work as a simplified command. I can't check atm.

[avengah]

Well, it works as a simplified command, I never knew you could put squeak(cry)! I bet numerical arguments for say, happy, sad and squeak etc. are converted internally to colours too, even though technically the numerical arguments are the briefest since they use fewer characters.

Now, I wonder if happy(all) and sad(all) is converted differently depending on how many crew members are on screen / in the level and which colours they are... does anyone know how they are converted? Thanks, this is quite interesting.

EDIT: I tried it, and it seems the parser takes the happy(all) command and does something different with it, so you can't use this method to test it. Everyone became happy and I just got a text box containing the usual rubbish no matter what value I used for N. Unless I'm doing something wrong?

[FIQ]

Well, it works as a simplified command, I never knew you could put squeak(cry)! I bet numerical arguments for say, happy, sad and squeak etc. are converted internally to colours too, even though technically the numerical arguments are the briefest since they use fewer characters.

Now, I wonder if happy(all) and sad(all) is converted differently depending on how many crew members are on screen / in the level and which colours they are... does anyone know how they are converted? Thanks, this is quite interesting.

EDIT: I tried it, and it seems the parser takes the happy(all) command and does something different with it, so you can't use this method to test it. Everyone became happy and I just got a text box containing the usual rubbish no matter what value I used for N. Unless I'm doing something wrong?

happy(all)/sad(all) seems to be too long to be able to expose.

happy(viridian) converts to this according to the exposing method I told earlier, in bold:

customposition(center)
speak_active
endtext
changecustommood(customcyan,1)
squeak(player)
squeak(terminal)
text(gray,0,114,1)

I guess happy(all) does something similar as line 1 but for all the other crewmates. I'm not sure on this though as I cannot expose it.

[FIQ]

I just realized something.

You might not be aware of it, but it's an incredibly annoying glitch related to chain loading scripts that might make the script after the first one refuse to load.

Well.. I might have found out why. It's related to the internal scripting w/o cutscenes method.

For example, this (usually) fail:

a:
iftrinkets(0,b)

b:
flash
iftrinkets(0,c)

c:
say(1)
Test

The solution is to make a third line in b, with whatever content you like (I usually use ifflag(work,around)).

Now, try to replace iftrinkets(0,c) with alarmon. This triggers the ship alarm!

So it seems that (something)Say is completely unneeded - but it's generally a quirk in script loading! It seems like it's loading the last line as an internal scripting command for some weird reason.

Now, the first thing I thought when doing this is that then the script should be possible to load using the internal command for iftrinkets() -- customiftrinkets(). Well, I tried, but it didn't do anything. Possibly the same thing that stops move() to work properly for this method?

[Dav999]

I just realized something.

You might not be aware of it, but it's an incredibly annoying glitch related to chain loading scripts that might make the script after the first one refuse to load.

Well.. I might have found out why. It's related to the internal scripting w/o cutscenes method.

For example, this (usually) fail:

a:
iftrinkets(0,b)

b:
flash
iftrinkets(0,c)

c:
say(1)
Test

The solution is to make a third line in b, with whatever content you like (I usually use ifflag(work,around)).

Now, try to replace iftrinkets(0,c) with alarmon. This triggers the ship alarm!

So it seems that (something)Say is completely unneeded - but it's generally a quirk in script loading! It seems like it's loading the last line as an internal scripting command for some weird reason.

Now, the first thing I thought when doing this is that then the script should be possible to load using the internal command for iftrinkets() -- customiftrinkets(). Well, I tried, but it didn't do anything. Possibly the same thing that stops move() to work properly for this method?

Really? So the last line is always loaded as an internal command? Will it also be the first line that's executed in every script? It may be unnoticed because most of the time, the last line is text which belongs to a text box, or it's destroy(x), which works the same as an internal command. The only conflicting command which would be used at the end of a script is iftrinkets(0,x). I always fixed it by placing a text box at the end, which says an error occurred, just like you use iftrinkets(work,around).

[FIQ]

I just realized something.

You might not be aware of it, but it's an incredibly annoying glitch related to chain loading scripts that might make the script after the first one refuse to load.

Well.. I might have found out why. It's related to the internal scripting w/o cutscenes method.

For example, this (usually) fail:

a:
iftrinkets(0,b)

b:
flash
iftrinkets(0,c)

c:
say(1)
Test

The solution is to make a third line in b, with whatever content you like (I usually use ifflag(work,around)).

Now, try to replace iftrinkets(0,c) with alarmon. This triggers the ship alarm!

So it seems that (something)Say is completely unneeded - but it's generally a quirk in script loading! It seems like it's loading the last line as an internal scripting command for some weird reason.

Now, the first thing I thought when doing this is that then the script should be possible to load using the internal command for iftrinkets() -- customiftrinkets(). Well, I tried, but it didn't do anything. Possibly the same thing that stops move() to work properly for this method?

Really? So the last line is always loaded as an internal command? Will it also be the first line that's executed in every script? It may be unnoticed because most of the time, the last line is text which belongs to a text box, or it's destroy(x), which works the same as an internal command. The only conflicting command which would be used at the end of a script is iftrinkets(0,x). I always fixed it by placing a text box at the end, which says an error occurred, just like you use iftrinkets(work,around).

I don't know if it's always the case, but it's possible. And yeah, it's not weird that it has gone unnoticed.

[ToasterApocalypse]

aaaa, I need more help.

SCRIPT:

Code: [Select]

flash(5)
playef(10)
gotoroom(19,8)
createentity(70,80,26,0,0)
text(1,0,0,4)
say(2)
walk(left,10)
text(1,0,0,4)
say(5)
flipme()
flash(5)
playef(10)
hideplayer()
text(1,0,0,4)

WHAT IS SUPPOSED TO HAPPEN:
Flashes
Go to room 20,9
Giant warptoken is there
Go to the warptoken
Flip into it (hideplayer, playef(10))
Player hides.

WHAT ACTUALLY HAPPENS:
Flash
Goes to room 20,9)
Giant warp is there
go to warp
script abruptly stops

What is happening?

[Dav999]

flipme() and tofloor() don't always work, unfortuanately. I also don't know if there's a way to make sure it always runs, I also ran into that problem. Maybe FIQ knows of a fix for this?

[ToasterApocalypse]

flipme() and tofloor() don't always work, unfortuanately. I also don't know if there's a way to make sure it always runs, I also ran into that problem. Maybe FIQ knows of a fix for this?

Well, tofloor worked previously.
That's not the problem though, the problem is the script stopping abruptly after the walk() command

[FIQ]

flipme() and tofloor() don't always work, unfortuanately. I also don't know if there's a way to make sure it always runs, I also ran into that problem. Maybe FIQ knows of a fix for this?

Well, tofloor worked previously.
That's not the problem though, the problem is the script stopping abruptly after the walk() command

Try flip(player). You can also work-around it by using gotoposition(x,y,1) where x,y is coordinates. Assuming they're always the same, that is -- it seems like you're not specifying them.

[ToasterApocalypse]

Guys, lets discuss backgroundtext. I don't get that one. 

[FIQ]

Guys, lets discuss backgroundtext. I don't get that one. 

Backgroundtext can be used to make several textboxes appear on the screen at the same time. For example, terminals with a headline and a textbox.

It's used like this (in case you wonder, -1 in text(...) means "at the center"):

text(gray,-1,50,1)
Test
backgroundtext
speak
text(gray,-1,70,1)
More testing!
speak
endtext

[ToasterApocalypse]

Guys, lets discuss backgroundtext. I don't get that one. 

Backgroundtext can be used to make several textboxes appear on the screen at the same time. For example, terminals with a headline and a textbox.

It's used like this (in case you wonder, -1 in text(...) means "at the center"):

text(gray,-1,50,1)
Test
backgroundtext
speak
text(gray,-1,70,1)
More testing!
speak
endtext

How would that fit in a say(5) thing then?

[FIQ]

You know the "internal scripting without cutscene" thingy? Well, I found something interesting.

As already known, the script executes first. And, to my surprise, one of the commands that work (as discussed earlier, not all commands seem to work) is the text() command.
Now, what is the use of this?

Well... the internal script executes first, in the case above the text() command. text() is used with say(-1) to allow for several internal commands to run using say(N) at once by simply making the internal executer ignore some lines below it, including the converted say() command. See where I'm going?

But say(N) will make cutscenebars appear and a terminal sound playing!
It wont! By overwriting the commands that trigger them with the command text() as the internal command to run w/o cutscenes, it will not appear! text() triggers first, etc.

endcutscene and untilbars is missing from your example...
They aren't needed, as there are no cutscenebars. loadscript(stop) (or anything that isn't an internal script) is still needed, obviously.

Try this:

test:
iftrinkets(0,test2)

test2:
say(3)
alarmon
playef(10,10)
loadscript(stop)
text(1,0,0,4)