Internal commands

Started by Hilbert, July 28, 2012, 01:23:29 PM

Previous topic - Next topic

FIQ

Quote from: Dav999 on January 20, 2013, 08:16:24 PM
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

Quote from: FIQ on January 20, 2013, 08:39:13 PM
Quote from: Dav999 on January 20, 2013, 08:16:24 PM
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

Quote from: Dav999 on January 20, 2013, 08:45:02 PM
Quote from: FIQ on January 20, 2013, 08:39:13 PM
Quote from: Dav999 on January 20, 2013, 08:16:24 PM
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

Quote from: FIQ on January 20, 2013, 09:27:04 PM
Quote from: Dav999 on January 20, 2013, 08:45:02 PM
Quote from: FIQ on January 20, 2013, 08:39:13 PM
Quote from: Dav999 on January 20, 2013, 08:16:24 PM
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

Quote from: Chillius03 on January 21, 2013, 10:13:17 AM
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 :viridian:. 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

Quote from: FIQ on December 10, 2012, 10:22:05 PM
Quote from: Dav999 on December 10, 2012, 09:41:03 PM
Quote from: FIQ on December 10, 2012, 05:40:05 PM
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

#518
Quote from: blue626 on January 25, 2013, 07:38:55 PM
Quote from: FIQ on December 10, 2012, 10:22:05 PM
Quote from: Dav999 on December 10, 2012, 09:41:03 PM
Quote from: FIQ on December 10, 2012, 05:40:05 PM
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

Quote from: ToasterApocalypse on February 02, 2013, 10:20:48 PM
Lets do this:

changetile(x) sprite IDs.
View in the data directory for VVVVVV, sprites.png. From left to right, up to down

Dav999

Quote from: FIQ on February 03, 2013, 12:50:23 AM
Quote from: ToasterApocalypse on February 02, 2013, 10:20:48 PM
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

#523
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

Quote from: FIQ on February 04, 2013, 12:13:36 PM
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!