How do I create teleports in my levels like in the campaign?

[IxGamerXL]

I'm currently trying to implement some form of teleporter in my custom level via the external level editor VED, but for some reason whenever I try to do so via internal scripts it always points to the top left corner of the map, which is the complete opposite of where the teleporter is, and other teleporters can't be found.

Is there a way to properly implement campaign-like teleporters in my custom level, even if it goes beyond using internal scripting? I'd really like this kind of teleporter in my level!




This is the code in the internal script that spawns in the teleporter. The script box envelopes the entire room.

createentity(68,52, 14)

[Desgracias]

I don't know how this works normally, but maybe try and look into the scripts of other people's levels.

From Uli, 12 years old.

[Dav999]

I don't think that's supported very well right now... Native big round teleporters in custom levels might get added to a later version of the game though (like 2.5 or 2.6).

The only level I can immediately think of, that currently has round teleporters that you can freely choose between, is Desert Ruins. It uses the teleportscript(x) command to override the normal map screen, and recreates its own map screen from scratch by using tiles and sprites:



Other than that, I think levels have mainly used terminals teleporting to and from a central hub, or used round teleporters only as decoration or one-way at the end of a zone.

[IxGamerXL]

After a while of trying things out, I realized I could improvise the fact that teleporters always go to room 0,0 and make that room into a series of warp tokens, each one only unlocking if you've went in their respective room (which turns on the respective flag).

I accomplished this by using teleportscript(x), which makes the teleporter skip the prompt of where to go and just teleports you. I couldn't figure out how to make the inserted script do anything, it doesn't seem to accept simplified nor internal. I'm probably not doing it right (I'm using the script name for the 'x' parameter) but at least I got it working somewhat.

I really hope dedicated round teleporters appear in a future VVVVVV update and soon! It'd be amazing to just hop into the level editor and place teleporters which players can hop around to and from with, especially for longer levels which have a lot of spots, whether they be distant or tedious to reach. No longer needing to spawn teleporters with scripts would save a lot of time too!

[Desgracias]

You could use VVVVVV CE. Also, I've been playing 2.4 recently, and I've been really enjoying it though I miss CE. Fun fact about teleporters, they are the largest entity in the game covering 144 tiles (arranged in 12x12), or 9216 pixels (arranged in 96x96)!

From Uli, 12 years old.

Hi Dav, I am genuinely very sorry for continuously advertising in my topics. I just want you to understand that I am a 12 year old autistic boy who feels really upset about his topics not being looked at much. I don't do this because I am an internet beggar, I genuinely love this game and it is my favourite ever made. That being said, I am very sorry for my actions and I'll try not to do it again.

thank you.

[Dav999]

I accomplished this by using teleportscript(x), which makes the teleporter skip the prompt of where to go and just teleports you. I couldn't figure out how to make the inserted script do anything, it doesn't seem to accept simplified nor internal. I'm probably not doing it right (I'm using the script name for the 'x' parameter) but at least I got it working somewhat.

I think it's because you need to add custom_ before the script name - so if your script is called applebapple, you need to write teleportscript(custom_applebapple) for it to work. (I think if you want to use internal scripting in it, you need to do another iftrinkets(0,myinternalscript) inside applebapple)

You could use VVVVVV CE.

VVVVVV-CE is only of historical interest - it requires downloading an outdated and abandoned different version of the game.

[Ally 🌠]

What Dav said is right -- although I have a bit to add on;

I realized I could improvise the fact that teleporters always go to room 0,0

0,0 is the default location (the "first" teleporter in the game) which means if you've unlocked no teleporters (something that doesn't normally happen) instead of crashing it lets you select the first teleporter.

Teleporters are hardcoded at the moment -- including their destinations, so you have the main game's teleporter locations to work with. Unfortunately, because of that, if you explore a room that a main game teleporter is in, AFAIK that'll unlock that destination as well... meaning you can't always rely on 0,0 being the only option.

I'm probably not doing it right (I'm using the script name for the 'x' parameter) but at least I got it working somewhat.

As Dav said, it'll load a script, but since it was only intended for the main game, you'll have to trick it into loading a CUSTOM script rather than a main-game script!

Thankfully that isn't that hard though, as all scripts are stored in the same place -- custom scripts are just prefixed with "custom_". Unfortunately custom scripts are always ran as simplified, so you'll have to do the internal exploit after. (Thought it'd be interesting to explain in more detail haha)

I really hope dedicated round teleporters appear in a future VVVVVV update and soon! It'd be amazing to just hop into the level editor and place teleporters which players can hop around to and from with, especially for longer levels which have a lot of spots, whether they be distant or tedious to reach. No longer needing to spawn teleporters with scripts would save a lot of time too!

I'm not home right now but I'll show a video of my concept when I DO get home (in around an hour) -- no promises it'll stay this way (or get into 2.5 even... might have to wait longer) but I do have custom teleporters programmed and done!

[Ally 🌠]

I forgot I got home. Anyways this is my current concept, could use a little bit of polish (ex. Viridian should snap to the grid if you hold shift maybe?)

[IxGamerXL]

It's incredible how you make it so intuitive. As for the grid snap, I think it'd be simpler if Viridian and the arc handle both snapped to the grid by default, with shift disabling the grid snap.

The main game does not use the edentity system (this is possible to change, but...)

I assume the reason why it's complicated is because of how many teleporters there are, or maybe even the fact that ALL entities would have to be changed... I dunno, I'm not that aware of the game's structure.

There's certain glitches that speedrunners/TASes use, and I don't know much about glitchrunner mode, so I think someone else should do that part.

Well if we're concerned about potentially patching glitches on accident, is it possible to make a copy of the round teleporter object that's more dynamic, while the original remains hard-coded?

This will likely pose different problems to solve, but it'll definitely avoid accidentally breaking old physics (and maybe even fix the edentity system problem).

[Ally 🌠]

It's incredible how you make it so intuitive. As for the grid snap, I think it'd be simpler if Viridian and the arc handle both snapped to the grid by default, with shift disabling the grid snap.

That's true -- I'll try both and see what feels better/more intuitive

The main game does not use the edentity system (this is possible to change, but...)

I assume the reason why it's complicated is because of how many teleporters there are, or maybe even the fact that ALL entities would have to be changed... I dunno, I'm not that aware of the game's structure.

"edentities" (EDitor ENTITIES) are data in level files basically -- which is just grouped instructions on what the game should actually spawn in when you load the map. For example, edentity 19 (script box) doesn't even spawn an entity, it places down a gamestate trigger with some special handling. The main game is just data inside of code files, so the edentity system isn't needed at all (and would instead limit things further); it seems very unlikely we'd actually convert the main game to use it, despite one of my goals being allowing more main game things to be used in the editor.

There's certain glitches that speedrunners/TASes use, and I don't know much about glitchrunner mode, so I think someone else should do that part.

Well if we're concerned about potentially patching glitches on accident, is it possible to make a copy of the round teleporter object that's more dynamic, while the original remains hard-coded?

This will likely pose different problems to solve, but it'll definitely avoid accidentally breaking old physics (and maybe even fix the edentity system problem).

So actually, teleporters in the main game are hardcoded to run different gamestates depending on a bunch of variables. What I did for custom teleporters was make a "generic" gamestate which just follows a three-point bézier curve. The problem I talk about is already solved basically; I was just explaining why I don't make the main game use the new system. It'd break a lot of stuff. (The main game doesn't even use bézier curves -- it just manually offsets the player every frame (with one gamestate dedicated to each offset))

[IxGamerXL]

Thanks for the insight! Thank god neither of those problems I mentioned appear to be in the way of implementing the teleporters.

Here's to hoping that it'll be added in 2.5 and that 2.5 doesn't take very long from now to release (looking at the frequency of updates, it's likely that the next update will release in either May or June, but I can't be sure).

Also, I was wanting to try out your concept but I unfortunately suck at compiling anything involving 'cmake', so if it's possible for you to create a release on your fork of VVVVVV that allows trying out the concept without the need of compiling, that'd help a whole bunch.

[Dav999]

Here's to hoping that it'll be added in 2.5 and that 2.5 doesn't take very long from now to release (looking at the frequency of updates, it's likely that the next update will release in either May or June, but I can't be sure).

It's likely there will be an update in May or June, but it'd be 2.4.3 and just have some minor fixes (not teleporters). Major updates like 2.5 actually take a bit longer - this year is thinkable but no promises! (Also no promises whether teleporters end up making it in, but I'd like to see it too)

[Ally 🌠]

Here's to hoping that it'll be added in 2.5 and that 2.5 doesn't take very long from now to release (looking at the frequency of updates, it's likely that the next update will release in either May or June, but I can't be sure).

Unfortunately, 2.5 will most likely not come out for a while. The important big feature of this update is touch input support (for phones, mainly) which I've written, but the pull requests are massive and haven't really been reviewed yet. Pair that with Ethan (the game's maintainer) having far, far more important things to do (like holding up the entire indie game industry with his work) and you'll be looking at many months at least.

I DID want teleporters to be the big "custom level feature" for 2.5 but the touch input stuff is far more important...

Also, I was wanting to try out your concept but I unfortunately suck at compiling anything involving 'cmake', so if it's possible for you to create a release on your fork of VVVVVV that allows trying out the concept without the need of compiling, that'd help a whole bunch.

Sure, here's a MAKE & PLAY build: https://cdn.nyako.gay/VVVVVV-teleporters-20a0fbe-MAP.exe

This is only the exe, so drop it in your game directory beside the normal VVVVVV exe and it should run fine. This is built off of the latest commit (which does have a few bugs!) so please only use this for testing teleporters -- and I'd strongly recommend against making an entire level including them! Not only because of bugs, or future changes, but also because we don't even know if teleporters are going to make it in! As Dav said.

(Also, of course, this doesn't include the grid snapping thing yet.)