Internal commands

[FIQ]

Okay, flipme and tofloor don't always work, but I discovered that you can just use 'flip' to flip either way, that always works. Why didn't anyone discover that earlier?

I knew there was something that did work as I found it earlier, then I forgot that command ._.

Anyway, there's a flaw with the command -- you can't detect flip state properly, so you can't make Viridian always be on the floor.

[Dav999]

Okay, flipme and tofloor don't always work, but I discovered that you can just use 'flip' to flip either way, that always works. Why didn't anyone discover that earlier?

I knew there was something that did work as I found it earlier, then I forgot that command ._.

Anyway, there's a flaw with the command -- you can't detect flip state properly, so you can't make Viridian always be on the floor.

You can also place the flip script on the ceiling, and the normal script on the floor.

[FIQ]

Okay, flipme and tofloor don't always work, but I discovered that you can just use 'flip' to flip either way, that always works. Why didn't anyone discover that earlier?

I knew there was something that did work as I found it earlier, then I forgot that command ._.

Anyway, there's a flaw with the command -- you can't detect flip state properly, so you can't make Viridian always be on the floor.

You can also place the flip script on the ceiling, and the normal script on the floor.

Sure? What if the user approach the floor script while flipped, by flipping right before?

[Dav999]

Okay, flipme and tofloor don't always work, but I discovered that you can just use 'flip' to flip either way, that always works. Why didn't anyone discover that earlier?

I knew there was something that did work as I found it earlier, then I forgot that command ._.

Anyway, there's a flaw with the command -- you can't detect flip state properly, so you can't make Viridian always be on the floor.

You can also place the flip script on the ceiling, and the normal script on the floor.

Sure? What if the user approach the floor script while flipped, by flipping right before?

Yes, you still have to place the scripts in such a way so that isn't possible.

[Chillius]

flipme is actually used in the real game. but i don't think it works. it doesn't for me.

[Dav999]

flipme is actually used in the real game. but i don't think it works. it doesn't for me.

Yes, all three ('flipme', 'tofloor' and 'flip') are used apparently. Only 'flip' can be used reliably. When I tried to test flip, it always worked, and it worked either way. I also tried flipme and tofloor, flipme didn't work, tofloor did.

Is there also a way to make crewmates flip to the floor? I know you can flip them to the ceiling, but to the floor?

[Dav999]

Okay, I looked in the binary again, and I don't think 'flipme' has anything to do with flipping . It's in between 'backgroundtext' and 'speak' in a script of a terminal, and you don't flip there. Does it have something to do with text boxes?

Also, endtext_fast was wrong, it should be endtextfast.

[blue626]

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.

Let me just understand this. Are you saying that sometimes iftrinkets(x,script) doesn't work when it's at the end of the script even if that script (or the one inside iftrinkets) hasn't got internal scripting?!? Wouldn't flash and ifflag confict too (becuase if converts to costumifflag)?
I once executed this script:

script1:
iftrinkets(0,script2)

script2:
flash

Of course both have an empty line at the end. It worked although I only tried it once.

Is this off-topic?

[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).

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.

Let me just understand this. Are you saying that sometimes iftrinkets(x,script) doesn't work when it's at the end of the script even if that script (or the one inside iftrinkets) hasn't got internal scripting?!? Wouldn't flash and ifflag confict too (becuase if converts to costumifflag)?
I once executed this script:

script1:
iftrinkets(0,script2)

script2:
flash

Of course both have an empty line at the end. It worked although I only tried it once.

Is this off-topic?

What happens if you replace the flash by alarmon? Maybe the last line is first loaded as an internal command, and then the script runs normally and runs the last line again at the end, but as a simplified command this time?

(And no, this is not off-topic, it's about internal commands anyway)

[FIQ]

Try to have 2 lines in script2, having the latest line being the command you want to test. Make sure to have no more than 1 empty line below the last line in script2.

[ToasterApocalypse]

Lets do this:

changetile(x) sprite IDs.

[FIQ]

Lets do this:

changetile(x) sprite IDs.

View in the data directory for VVVVVV, sprites.png. From left to right, up to down

[Dav999]

Lets do this:

changetile(x) sprite IDs.

View in the data directory for VVVVVV, sprites.png. From left to right, up to down

And some sprites are bigger than the others, those actually consist of multiple pieces so you might also get the top left part of the bus or a teleporter, for example...

[FIQ]

I was creating an user interface abusing backgroundtext heavily showing various dialogs at screen. I found out the hard way that VVVVVV seems to have a hard limit on the amount of dialogs shown before things must reset. What reset means is something I don't know, but having 11 dialogs which reload themselves (even after "endtext") crashes VVVVVV after 3 runs (and glitches after 2). I believe the hard limit is 20.

You can work around this by using endtextfast (NOT endtext) and a delay of at least 3. However, dialogs doesn't become as seamless then.

Point is: don't abuse backgroundtext too much, unless you're fine with a work-around that may make things not look too nice.

[Dav999]

I was creating an user interface abusing backgroundtext heavily showing various dialogs at screen. I found out the hard way that VVVVVV seems to have a hard limit on the amount of dialogs shown before things must reset. What reset means is something I don't know, but having 11 dialogs which reload themselves (even after "endtext") crashes VVVVVV after 3 runs (and glitches after 2). I believe the hard limit is 20.

You can work around this by using endtextfast (NOT endtext) and a delay of at least 3. However, dialogs doesn't become as seamless then.

Point is: don't abuse backgroundtext too much, unless you're fine with a work-around that may make things not look too nice.

I wonder how you can create a user interface with only one button and barely any conditional things...

Oh, and maybe textboxactive can help. It's clears all dialogs on the screen except for the last one created. So if you create 3 text boxes to be displayed at the same time, when you use endtext or endtextfast, all three will be cleared at once, but if you use textboxactive, only the first two are cleared, and the last one remains on the screen!