Author Topic: Internal commands  (Read 257548 times)

FIQ

  • Captain
  • *****
  • Posts: 810
  • https://github.com/FredrIQ/
    • View Profile
    • FIQ
Re: Internal commands
« Reply #525 on: February 04, 2013, 06:23:57 AM »
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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
Regarding textboxactive -- problem is that you have to clear *all* dialogs and wait some minimal time for them to get away from screen to "reset" the hard limit dialog amount. Also, sure you don't mean speak_active?

This hard limit, I believe it's what causes textboxes to be completely empty after a very long dialog, an issue even outside internal scripting.

And, the lack of real conditionals doesn't make it impossible, just a bit more complex :P

The total amount of scripts in my user interface ended up being 35 and it used 8 flags. In that state, everything was working properly without issues.
« Last Edit: February 04, 2013, 06:30:33 AM by FIQ »

Dav999

  • Global Moderator
  • Captain
  • *****
  • Posts: 2173
    • View Profile
    • The Open Level Project
Re: Internal commands
« Reply #526 on: February 04, 2013, 06:36:40 AM »
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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
Regarding textboxactive -- problem is that you have to clear *all* dialogs and wait some minimal time for them to get away from screen to "reset" the hard limit dialog amount. Also, sure you don't mean speak_active?

No, I meant textboxactive. Still, it might be handy if you have one dialog with the menu.

This hard limit, I believe it's what causes textboxes to be completely empty after a very long dialog, an issue even outside internal scripting.

So, does it appear at the 20th text box?

FIQ

  • Captain
  • *****
  • Posts: 810
  • https://github.com/FredrIQ/
    • View Profile
    • FIQ
Re: Internal commands
« Reply #527 on: February 04, 2013, 06:43:16 AM »
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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
Regarding textboxactive -- problem is that you have to clear *all* dialogs and wait some minimal time for them to get away from screen to "reset" the hard limit dialog amount. Also, sure you don't mean speak_active?

No, I meant textboxactive. Still, it might be handy if you have one dialog with the menu.

This hard limit, I believe it's what causes textboxes to be completely empty after a very long dialog, an issue even outside internal scripting.

So, does it appear at the 20th text box?
I made an isolated test case with the following script

Code: (test) [Select]
say
1
say
2
say
3
say
4
(...)
say
42
say
43

The 21th textbox fails to appear. Then, dialogs appeared again until the 42nd one. This confirms what I said earlier.

If you proceed to insert a delay(10) like this:

Code: (test) [Select]
say
20
delay(10)
say
21
the 21th dialog appears normally. Though, it will not look too nice compared to the other transistions between dialogs, but it's the only way I know of to avoid this issue.

Dav999

  • Global Moderator
  • Captain
  • *****
  • Posts: 2173
    • View Profile
    • The Open Level Project
Re: Internal commands
« Reply #528 on: February 04, 2013, 09:18:21 AM »
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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
Regarding textboxactive -- problem is that you have to clear *all* dialogs and wait some minimal time for them to get away from screen to "reset" the hard limit dialog amount. Also, sure you don't mean speak_active?

No, I meant textboxactive. Still, it might be handy if you have one dialog with the menu.

This hard limit, I believe it's what causes textboxes to be completely empty after a very long dialog, an issue even outside internal scripting.

So, does it appear at the 20th text box?
I made an isolated test case with the following script

Code: (test) [Select]
say
1
say
2
say
3
say
4
(...)
say
42
say
43

The 21th textbox fails to appear. Then, dialogs appeared again until the 42nd one. This confirms what I said earlier.

If you proceed to insert a delay(10) like this:

Code: (test) [Select]
say
20
delay(10)
say
21
the 21th dialog appears normally. Though, it will not look too nice compared to the other transistions between dialogs, but it's the only way I know of to avoid this issue.

So only the 21st, 42nd, etc. don't appear? If you make each text box appear twice, all boxes should show up! One of them eventually becomes the 21st dialog, but the other one still appears.

FIQ

  • Captain
  • *****
  • Posts: 810
  • https://github.com/FredrIQ/
    • View Profile
    • FIQ
Re: Internal commands
« Reply #529 on: February 04, 2013, 09:42:24 AM »
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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
Regarding textboxactive -- problem is that you have to clear *all* dialogs and wait some minimal time for them to get away from screen to "reset" the hard limit dialog amount. Also, sure you don't mean speak_active?

No, I meant textboxactive. Still, it might be handy if you have one dialog with the menu.

This hard limit, I believe it's what causes textboxes to be completely empty after a very long dialog, an issue even outside internal scripting.

So, does it appear at the 20th text box?
I made an isolated test case with the following script

Code: (test) [Select]
say
1
say
2
say
3
say
4
(...)
say
42
say
43

The 21th textbox fails to appear. Then, dialogs appeared again until the 42nd one. This confirms what I said earlier.

If you proceed to insert a delay(10) like this:

Code: (test) [Select]
say
20
delay(10)
say
21
the 21th dialog appears normally. Though, it will not look too nice compared to the other transistions between dialogs, but it's the only way I know of to avoid this issue.

So only the 21st, 42nd, etc. don't appear? If you make each text box appear twice, all boxes should show up! One of them eventually becomes the 21st dialog, but the other one still appears.
What do you mean with making every textbox appear twice? Once a textbox doesn't appear, no further textbox will appear unless you let go of all textboxes (which can only be done properly without user action manually with a delay)

Dav999

  • Global Moderator
  • Captain
  • *****
  • Posts: 2173
    • View Profile
    • The Open Level Project
Re: Internal commands
« Reply #530 on: February 04, 2013, 10:38:22 AM »
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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
Regarding textboxactive -- problem is that you have to clear *all* dialogs and wait some minimal time for them to get away from screen to "reset" the hard limit dialog amount. Also, sure you don't mean speak_active?

No, I meant textboxactive. Still, it might be handy if you have one dialog with the menu.

This hard limit, I believe it's what causes textboxes to be completely empty after a very long dialog, an issue even outside internal scripting.

So, does it appear at the 20th text box?
I made an isolated test case with the following script

Code: (test) [Select]
say
1
say
2
say
3
say
4
(...)
say
42
say
43

The 21th textbox fails to appear. Then, dialogs appeared again until the 42nd one. This confirms what I said earlier.

If you proceed to insert a delay(10) like this:

Code: (test) [Select]
say
20
delay(10)
say
21
the 21th dialog appears normally. Though, it will not look too nice compared to the other transistions between dialogs, but it's the only way I know of to avoid this issue.

So only the 21st, 42nd, etc. don't appear? If you make each text box appear twice, all boxes should show up! One of them eventually becomes the 21st dialog, but the other one still appears.
What do you mean with making every textbox appear twice? Once a textbox doesn't appear, no further textbox will appear unless you let go of all textboxes (which can only be done properly without user action manually with a delay)

Oh, I forgot that you have to clear all text boxes (because if you use say, it automatically uses speak_active, and I forgot about that)

ToasterApocalypse

  • Captain
  • *****
  • Posts: 1010
  • le lenny face
    • View Profile
Re: Internal commands
« Reply #531 on: February 04, 2013, 11:20:14 AM »
Is there a way to make  :viridian: move during a script?

Dav999

  • Global Moderator
  • Captain
  • *****
  • Posts: 2173
    • View Profile
    • The Open Level Project
Re: Internal commands
« Reply #532 on: February 04, 2013, 11:27:17 AM »
Is there a way to make  :viridian: move during a script?

walk(left/right,tiles)

ToasterApocalypse

  • Captain
  • *****
  • Posts: 1010
  • le lenny face
    • View Profile
Re: Internal commands
« Reply #533 on: February 04, 2013, 11:30:14 AM »
Is there a way to make  :viridian: move during a script?

walk(left/right,tiles)

Be controlled*

Dav999

  • Global Moderator
  • Captain
  • *****
  • Posts: 2173
    • View Profile
    • The Open Level Project
Re: Internal commands
« Reply #534 on: February 04, 2013, 11:53:52 AM »
Is there a way to make  :viridian: move during a script?

walk(left/right,tiles)

Be controlled*

Oh, so that you can control him while running a script?

Unfortunately not. :(

FIQ

  • Captain
  • *****
  • Posts: 810
  • https://github.com/FredrIQ/
    • View Profile
    • FIQ
Re: Internal commands
« Reply #535 on: February 04, 2013, 12:15:25 PM »
You can emulate the behaviour though. There was a member earlier who posted a seizure-prone level that switched colors (a bit like the final level did). By abusing flags you can make a script run in "background" by executing some stuff, turn on a flag, then gotoroom(<the room you are in currently>). This will trigger the script again, and so on. Keep in mind that you cannot have moving stuff in the room (enemies, platforms, conveyors, etc) and you can't make the script take up the whole room as it will prevent you from going to another room. This is the closest you can come to fully emulate VVVVVV gamestate behaviour with just scripting. However, this is very cumbersome to script and not really worth it, usually. Also, some things which may look very simple to emulate (like the dialog in the background in Comms Relay in the main game) will take a very large amount of flags and hundreds (maybe even thousends, depending on how fast VVVVVVscript really is) of scripts. What are you trying to achieve?

EDIT: Here's a proof of concept of what I mean, below. Go to the bottom right to see it in action.

The script re-runs once per tick, and has 11 "sub scripts". What happens is that a text box appears and disappears continuosly while maintaining player control. Flag preserving isn't optimal (in fact only 4 flags would be needed), but I just made this rather quickly.
« Last Edit: February 04, 2013, 12:40:42 PM by FIQ »

Hilbert

  • Captain
  • *****
  • Posts: 574
  • Yup. This is my name. Not Black, Hilbert.
    • View Profile
Re: Internal commands
« Reply #536 on: February 05, 2013, 04:35:51 AM »
Also, some things which may look very simple to emulate (like the dialog in the background in Comms Relay in the main game) will take a very large amount of flags and hundreds (maybe even thousends, depending on how fast VVVVVVscript really is) of scripts.
That's a hardcode. It's gamestate()ed.

FIQ

  • Captain
  • *****
  • Posts: 810
  • https://github.com/FredrIQ/
    • View Profile
    • FIQ
Re: Internal commands
« Reply #537 on: February 05, 2013, 07:41:02 AM »
Also, some things which may look very simple to emulate (like the dialog in the background in Comms Relay in the main game) will take a very large amount of flags and hundreds (maybe even thousends, depending on how fast VVVVVVscript really is) of scripts.
That's a hardcode. It's gamestate()ed.
That was the point. Gamestates is basically scripts (at least most of them are) but they run in the background. Many of the states are dialogs, and prevent you to move by themselves, though. The only way to emulate this part of gamestate behaviour is as I described above.
« Last Edit: February 05, 2013, 07:43:19 AM by FIQ »

blue626

  • Captain
  • *****
  • Posts: 672
  • I changed my avatar!
    • View Profile
Re: Internal commands
« Reply #538 on: February 05, 2013, 01:13:20 PM »
I was creating an user interface abusing backgroundtext heavily showing various dialogs at screen. (...)

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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
(...)

And, the lack of real conditionals doesn't make it impossible, just a bit more complex :P

The total amount of scripts in my user interface ended up being 35 and it used 8 flags. In that state, everything was working properly without issues.

 :vitellary: ???
How can you make it so that the arrow keys affect a script (I guess those are the other 2 buttons)?
Didn't see any command that does that in the 2nd post.
Not that I'm going to use it in a level but... :o

You can emulate the behaviour though. There was a member earlier who posted a seizure-prone level that switched colors (a bit like the final level did). By abusing flags you can make a script run in "background" by executing some stuff, turn on a flag, then gotoroom(<the room you are in currently>). This will trigger the script again, and so on. Keep in mind that you cannot have moving stuff in the room (enemies, platforms, conveyors, etc) and you can't make the script take up the whole room as it will prevent you from going to another room.

Note: I didn't play that level (although I did read that post and saw the attachment).
Why do you need to turn a flag on? ???
If I'm understanding this well, you coulddo it in another way, without gotoroom... Try to find out for yourself. :P There's actually even another way without gotoroom, which is how I thought the level worked, although this one only works for a limited number of times.

EDIT: Wait, how do you switch colors with what you described? I guess I misunderstood and what I rote above isn't correct. :victoria: Still, it works for doing things repeatedly... which is what gotoroom(current room) does... :-\

EDIT 2: I'm going to play that level later to see if I understand this...
« Last Edit: February 05, 2013, 01:21:51 PM by blue626 »

Dav999

  • Global Moderator
  • Captain
  • *****
  • Posts: 2173
    • View Profile
    • The Open Level Project
Re: Internal commands
« Reply #539 on: February 05, 2013, 01:41:56 PM »
I was creating an user interface abusing backgroundtext heavily showing various dialogs at screen. (...)

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!
You have 3 buttons actually.
Look at my screenshot in Back to VVVVVV :P
(...)

And, the lack of real conditionals doesn't make it impossible, just a bit more complex :P

The total amount of scripts in my user interface ended up being 35 and it used 8 flags. In that state, everything was working properly without issues.

 :vitellary: ???
How can you make it so that the arrow keys affect a script (I guess those are the other 2 buttons)?
Didn't see any command that does that in the 2nd post.
Not that I'm going to use it in a level but... :o

I figured it out myself: you can put :viridian: in a specific spot with one script box to the left and one script box to the right, and another one above him. If you walk to either side, you trigger the script where the dialogs are displayed on screen, flags are changed, and :viridian: is teleported back to the original spot. I first thought the flipping part wouldn't work, because not using endtext after a script with normal dialogs meant that the dialog would not dissappear, and :viridian: wouldn't be able to flip while the text box is on the screen. However, this only applies to text boxes without backgroundtext.

I also made two examples of a level with a sort of interface, the first one has the 20-dialogs-cap-bug, which only occurs if you repeatedly move back and forth between the buttons more than 8 times. The second one doesn't, because you select in a different way (you just press left or right to directly 'click' a button, without first highlighting it and pressing action).

As always, please ignore the __MACOSX folder in the zip it's a hidden folder I can't change that etc etc.
Also ignore the typing error in the script (saing instead of saying)
« Last Edit: February 06, 2013, 01:19:30 AM by Dav999 »