Internal commands

[FIQ]

I've been testing internal scripting in a differnt way, to see if it worked:

say(-x)
internal x times

I found a glitch, I'll tell details later.

You have piqued my interest... How far away is later?

Sorry, I've been busy. But it's almost what avengah said:

It only detects one internal command, but you see an empty text box as well.

Here's what I did:

I played a level, the last script being executed made sad and created a grey centered text box saying "Here's your cake" or something similar. I quitted without saving (because I had no way out, including suiciding).

After that, I created a level just for testing internal scripting. I created 3 scripts. One called script1 had this:

say(-1)
alarmon
(empty line)

Another called script2 had something like this:

say(-2)
playef(9)
(something I don't remember)
(empty line)

The last one, called script3 had someting like this:

say(-4)
flash(5)
gotoposition(1,1)
playef(10)
(empty line)

Here's what happened when I triggered script1 (I triggered every script in the editor):

turned sad, a centered grey text box with "Here's your cake" appeared and the alarm turned on.

When I triggered script2:

turned sad, a centered grey text box with "Here's your cake" appeared and a flash sound was played with neither the white screen nor shaking. If script1 was triggered earlier the alarm didn't turn off.

When I triggered script3:

turned sad, a centered grey text box with "Here's your cake" appeared and a flash with neither sound effect nor shaking and normal duration appeared. If script1 was triggered earlier the alarm didn't turn off.

I changed script3 slightly. I also changed script2 slightly but I don't remember how. Here's the new script3:

say(-4)
gotoposition(1,1)
flash(5)
playef(10)
(empty line)

Here's what happened when I triggered it:

turned sad, a centered grey text box with "Here's your cake" appeared and immediately disappeared form the place he/she was and appeared near the top left of the screen. If script1 was triggered earlier the alarm didn't turn off.

Then, I realized this: only the 1st line was executed. The same behavior happened with the new script2, IIRC.

It's likely that the reason to why an empty box appeared when avengah tested it is because avengah tested it immediately after he/she opened VVVVVV.

The fact that you need to play a level before testing to make a text box appear is similar to a glitch I've reported that isn't related to internal scripting. You need to make a mistake in scripting to reproduce this, though.

The fact that it only executes the 1st line might (or should) have been discovered before by FIQ (since he's the one who discovered the say(-1) glitch to execute int. scripting). Did anyone discover this before?

EDIT: This thread already has 330 replies!

Which I also did, that's why you use text(1,0,0,4) to make it able to use more than 1 line.

As I also said before, it doesn't matter if you have say(-1), say(-2) or say(-49251). It will only do 1 line anyway.

[blue626]

Do you mean this post?

I noticed somethiing: why do you need to write the following text before the internal commands?

say(-1)
text(1,0,0,4)
say(5)

Couldn't you use the following?

say(-4)
say(5)

Or even this last text?

say(-5)

And, why is the text command used above has a number instead of a color (like when you create text boxes with internal scripting)?

say(-4), say(-2403), say(-1), every of them works fine.

Since you said they worked fine, I thought that you meant that say(-1) execute 1 line of int. scripting, say(-4) executes 4 lines of it, say(-2403) executes 2403 lines, etc. If I thought you said that the only the first line is executed, regardless of the value of say (as long it's negative), I wouldn't ask the same question again after that post. Was that a mistake?

[avengah]

Have you tried just say(-)? Or even say(-0)? Or even simply say(0)?

[FIQ]

Have you tried just say(-)? Or even say(-0)? Or even simply say(0)?

I never got it to work with other stuff than negative numbers, but I didn't test everything either

[blue626]

I found a weird glitch:
gotoroom(x,y) acts differently in different ways of executing internal scripting! Consider methods A, B, and C.
Method A is this:

say(-1)
gotoroom(x,y)

Method B is this, which is not recommended to use:

say(-1)
text(1,0,0,4)
say
gotoroom(x,y)

Method C is the one mentioned in the 2nd post (or something similar...):

say(-1)
text(1,0,0,4)
say(5)
gotoroom(x,y)
endtext
endcutscene
untilbars
loadscript(stop)

Here's what happens when triggering the script with method A:

  goes to position x,y and falls upwards... but his/her feet are pointing down! Before you can move a centered grey text box with either the last script triggered in a level outside the editor or a line with costumposition(center) (the last only happens and always happens if you trigger the script with method B first) appears. When he/she touches a ceiling his/her feet suddenly point upwards... and he/she can't flip! I'm sure this is a glitch!

When triggering the script with method B:

  goes to position x,y, falls downwards and his/her feet are pointing down. Before you can move a centered grey text box with 4 lines of internal scripting appears. The 1st line was last line was a text command with weird values for x and y. When you can move and touch a floor, you can flip.

When triggering the script with method C:

  goes to position x,y, falls downwards and his/her feet are pointing down. No text box appears, you can flip. In other words, it works well.

 

However, in methods A and C you can't move until ≈1/2 second later. I thought it was because of the sound, but changed say(-1) to reply(-1) (in method C) and it didn't change anything. I realized later that it's because of the cutscene bars... I'm thinking about endcutscene and untilbars...

After discovering that only method C works well, I tested the x value of gotoposition, seeing exactely where went using backing. Here's how it works:

gotoroom(0,y) teleports so that he's centered in the 2nd tile's column, counting from left to right. Raising 1 in the value will result in 1 pixel to the right. Ex: gotoposition(4,y) will teleport Viridian 4 pixels to the right of being centered on the 2nd tile's column (as well as to the defined y position). I don't know what value is the right edge nor if it's possible to use negative values to get o the far left, for example, since I only tested with x=0-5. I don't know how to test y with precision since falls fast.

[FIQ]

I found a weird glitch:
gotoroom(x,y) acts differently in different ways of executing internal scripting! Consider methods A, B, and C.
Method A is this:

say(-1)
gotoroom(x,y)

Method B is this, which is not recommended to use:

say(-1)
text(1,0,0,4)
say
gotoroom(x,y)

Method C is the one mentioned in the 2nd post (or something similar...):

say(-1)
text(1,0,0,4)
say(5)
gotoroom(x,y)
endtext
endcutscene
untilbars
loadscript(stop)

Here's what happens when triggering the script with method A:

  goes to position x,y and falls upwards... but his/her feet are pointing down! Before you can move a centered grey text box with either the last script triggered in a level outside the editor or a line with costumposition(center) (the last only happens and always happens if you trigger the script with method B first) appears. When he/she touches a ceiling his/her feet suddenly point upwards... and he/she can't flip! I'm sure this is a glitch!

When triggering the script with method B:

  goes to position x,y, falls downwards and his/her feet are pointing down. Before you can move a centered grey text box with 4 lines of internal scripting appears. The 1st line was last line was a text command with weird values for x and y. When you can move and touch a floor, you can flip.

When triggering the script with method C:

  goes to position x,y, falls downwards and his/her feet are pointing down. No text box appears, you can flip. In other words, it works well.

 

However, in methods A and C you can't move until ≈1/2 second later. I thought it was because of the sound, but changed say(-1) to reply(-1) (in method C) and it didn't change anything. I realized later that it's because of the cutscene bars... I'm thinking about endcutscene and untilbars...

After discovering that only method C works well, I tested the x value of gotoposition, seeing exactely where went using backing. Here's how it works:

gotoroom(0,y) teleports so that he's centered in the 2nd tile's column, counting from left to right. Raising 1 in the value will result in 1 pixel to the right. Ex: gotoposition(4,y) will teleport Viridian 4 pixels to the right of being centered on the 2nd tile's column (as well as to the defined y position). I don't know what value is the right edge nor if it's possible to use negative values to get o the far left, for example, since I only tested with x=0-5. I don't know how to test y with precision since falls fast.

Remember that R (force respawn) freezes Viridian in place.

[blue626]

I probably can't press R exactly at the same time is teleported. I if could, then that would be precise enough.
EDIT: Wait, people probably only need precision in tiles (not pixels), as falling for ≈3 pixels isn't a problem (I think?). So if I press R ≈0,1 sec. after is teleported, then it woud be precise enough. Thanks!

Off-topic: It's better to erase the other part of the quote when you're just replying to part of the post. I've seen you quote the whole post when you're actually just replying to part of it several times. You should do this mainly when the post mentioned is large.

[avengah]

Don't forget the other way of executing internal commands; using say(12+). At least that way you don't need to keep putting extra say and text commands in. V2.1 only, of course, but I'm sure most of us are using that now.

[N]

I think this is the Number 1 Thread on the site!

[FIQ]

Don't forget the other way of executing internal commands; using say(12+). At least that way you don't need to keep putting extra say and text commands in. V2.1 only, of course, but I'm sure most of us are using that now.

How about Mac users? Are you just going to ignore them in case you do a level with internal commands?

Dav999 will be very happy when he hears about it

[RibShark]

How about Mac users? Are you just going to ignore them in case you do a level with internal commands?

Dav999 will be very happy when he hears about it

You ever heard of WINE? Well, VVVVVV 2.1 runs fine on it.

[Dav999]

How about Mac users? Are you just going to ignore them in case you do a level with internal commands?

Dav999 will be very happy when he hears about it

You ever heard of WINE? Well, VVVVVV 2.1 runs fine on it.

I know... I have Wine on my computer.

[N]

How about Mac users? Are you just going to ignore them in case you do a level with internal commands?

Dav999 will be very happy when he hears about it

You ever heard of WINE? Well, VVVVVV 2.1 runs fine on it.

I know... I have Wine on my computer.

That is the best program name ever

[allison]

How about Mac users? Are you just going to ignore them in case you do a level with internal commands?

Dav999 will be very happy when he hears about it

You ever heard of WINE? Well, VVVVVV 2.1 runs fine on it.

So, WINE supports converting Windows patches into Mac ones? Or is there some other way to run VVVVVV 2.1 without the 2.0 or whatever .exe or .app?

[Dav999]

How about Mac users? Are you just going to ignore them in case you do a level with internal commands?

Dav999 will be very happy when he hears about it

You ever heard of WINE? Well, VVVVVV 2.1 runs fine on it.

So, WINE supports converting Windows patches into Mac ones? Or is there some other way to run VVVVVV 2.1 without the 2.0 or whatever .exe or .app?

No, it runs Windows programs, so it runs the .exe. It doesn't convert it into a .app, or to a patch of a .app.