Player Triggering Change Issues
Moderators: Flumminator, Zomis
Player Triggering Change Issues
Hi all,
I was playing around with the PTC ref. element, and just discovered a nice way to trick the RnD engine
Here is the archive:
http://www.zomis.net/rnd/download.php?id=553
The first level is called The Room of Infinite Teleporting... well, it is not infinite, anyway, but since it "stops the time" (at least for the RnD engine) it goes close to that
Better that you take a look to the tape, to see the tricked engine
Now the second level: Teleporting YamYams... you won't believe me, but I was able to show the Player Triggering Change element on the level during the gameplay! Again, see the tape to have the proof. (Hey, I know, it's quite easy to do so, but I didn't mean "by putting it directly on the map" )
Well, this is more a change request than a bug report: I'd like to have an editor that forbids me to put more than a PTC in an Extended Change Target.
Since they work also inside of normal elements like YamYams and Amoebas, it would be nice to avoid those special elements to be put inside of these normal elements.
Maybe it's matter of tastes, but those "permissions" could lead to additional compatibility code, in the future, if someone has the nice idea to use them to make tens of levels...
I was playing around with the PTC ref. element, and just discovered a nice way to trick the RnD engine
Here is the archive:
http://www.zomis.net/rnd/download.php?id=553
The first level is called The Room of Infinite Teleporting... well, it is not infinite, anyway, but since it "stops the time" (at least for the RnD engine) it goes close to that
Better that you take a look to the tape, to see the tricked engine
Now the second level: Teleporting YamYams... you won't believe me, but I was able to show the Player Triggering Change element on the level during the gameplay! Again, see the tape to have the proof. (Hey, I know, it's quite easy to do so, but I didn't mean "by putting it directly on the map" )
Well, this is more a change request than a bug report: I'd like to have an editor that forbids me to put more than a PTC in an Extended Change Target.
Since they work also inside of normal elements like YamYams and Amoebas, it would be nice to avoid those special elements to be put inside of these normal elements.
Maybe it's matter of tastes, but those "permissions" could lead to additional compatibility code, in the future, if someone has the nice idea to use them to make tens of levels...
Anyway, by the way, have fun!
Francesco
Francesco
I was reading this topic, that is about the restart of the level after reloading. It also mentions the doubled player, which is exactly what happens in my first level above. I don't really know if there is some link between the two things, just noticed the similarity.
Again from the first level above, it is quite clear that the screen is being updated more than once in a frame. In a first time I thought that this would have been a bottleneck for tape reloading, but then I realized that it shouldn't apply to it, because the screen is not updated in that faster reloading... so, again, I don't know. In any case, I don't see the need for updating the screen more than once per frame, but I fear it would make no difference changing this.
Hope that these thoughts could be useful in some way
Addon to my first post above: it should be forbidden also to put more than one single "normal player" element, in the ECT, not only the PTC. I think it could work as just it already works on the map: if you put a second yellow player, the first yellow player is removed.
Again from the first level above, it is quite clear that the screen is being updated more than once in a frame. In a first time I thought that this would have been a bottleneck for tape reloading, but then I realized that it shouldn't apply to it, because the screen is not updated in that faster reloading... so, again, I don't know. In any case, I don't see the need for updating the screen more than once per frame, but I fear it would make no difference changing this.
Hope that these thoughts could be useful in some way
Addon to my first post above: it should be forbidden also to put more than one single "normal player" element, in the ECT, not only the PTC. I think it could work as just it already works on the map: if you put a second yellow player, the first yellow player is removed.
Anyway, by the way, have fun!
Francesco
Francesco
Well, sometimes you want to have the ECT be:
(where "Yellow Player" may be "Player Triggering Change" instead)
This ensures that the yellow player (or PTC) gets teleported to the lower right location, unless that location is blocked by something indestructible. Then it will try other locations.
(where "Yellow Player" may be "Player Triggering Change" instead)
This ensures that the yellow player (or PTC) gets teleported to the lower right location, unless that location is blocked by something indestructible. Then it will try other locations.
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
Yes Daniel, that technique can be used, but I see it more like a buggy thing used as a feature, than a real feature.
For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.
Furthermore, the need of such a "try this, then try that", looks like a badly designed level: it's quite easy to ensure that the destination tile is free for teleporting the player.
For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.
Furthermore, the need of such a "try this, then try that", looks like a badly designed level: it's quite easy to ensure that the destination tile is free for teleporting the player.
Anyway, by the way, have fun!
Francesco
Francesco
Well... you could use "Set engine scan mode = reverse"Francesco wrote:For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.
Even though it's indeed a bug to show the "PTC" in your testlevel #2, what else should be shown instead? Since the player is already dead, he shouldn't be ressurected again, right? So should there be empty space or the famours question mark '?'?
Yes, you're right. But what if I'd wanted the middle-left to be the final destination, and if it were occupied, any of the other? Read below.Zomis wrote:Well... you could use "Set engine scan mode = reverse"Francesco wrote:For example, what if I want the player to be teleported in the top-left tile, and if that's not possible, to try the other tiles? It would be not achievable using the same "multiplayer" ECT.
That was just a side effect of being able to put such a special element in a normal element like a YamYam.Zomis wrote:Even though it's indeed a bug to show the "PTC" in your testlevel #2, what else should be shown instead? Since the player is already dead, he shouldn't be ressurected again, right? So should there be empty space or the famours question mark '?'?
To be sincere, most of the knowledge I have about such games (BD, EM and so on) is limited to RnD. But I don't think there is any kind of teleporter in the original versions.
The issue is more about being able to put more than a player element in a ECT, or to be able to put it inside a normal element like the amoeba. In my opinion, it should be avoided.
I don't really see the need of such a multiple-destination teleporter, also because, as it is now, it tricks the graphical engine. Also, try putting the yellow player inside of the amoeba, you will see another example of the tricked engine.
Anyway, by the way, have fun!
Francesco
Francesco
OK, that's a point, but what if you aren't particular about which side the player comes out? In multiplayer games, it would make it harder for one player to keep another from using the Player Teleportation Unit.Francesco wrote:[...]but I see it more like a buggy thing used as a feature, than a real feature.
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
I don't know if my last work applies to your argumentation, Daniel.
I still think that shouldn't be allowed more than a player element in a ECT.
In any case, I've just made a MP level where the first player that collects 25 gems wins (and gains the freedom). The fake open door is not a safe place to stand nearby, furthermore because the player should be inside of the cage collecting gems
http://www.zomis.net/rnd/download.php?id=555
I still think that shouldn't be allowed more than a player element in a ECT.
In any case, I've just made a MP level where the first player that collects 25 gems wins (and gains the freedom). The fake open door is not a safe place to stand nearby, furthermore because the player should be inside of the cage collecting gems
http://www.zomis.net/rnd/download.php?id=555
Anyway, by the way, have fun!
Francesco
Francesco
Haven't missed it (just not replied yet), but thanks anyway. :)
Well, yes. The "player relocation" stuff is handled independently from the rest of the engine (as all player actions), so it's not the whole playfield that is updated more than once per frame, but only all player the locations. In this case, all relocation stuff is handled before the engine continues. (It's most probably easy to do infinite loops, which is probably a bad thing.)
And yes, if you put "player triggering change" elements into normal elements, it could cause them to be displayed in the game, which should probably be prevented.
But I think it does not cause much harm (besides looking strange), so one should probably just not use them in such circumstances. But maybe it's indeed wise to technically prevent this...
Well, yes. The "player relocation" stuff is handled independently from the rest of the engine (as all player actions), so it's not the whole playfield that is updated more than once per frame, but only all player the locations. In this case, all relocation stuff is handled before the engine continues. (It's most probably easy to do infinite loops, which is probably a bad thing.)
And yes, if you put "player triggering change" elements into normal elements, it could cause them to be displayed in the game, which should probably be prevented.
But I think it does not cause much harm (besides looking strange), so one should probably just not use them in such circumstances. But maybe it's indeed wise to technically prevent this...
Well, completely forbidding to put these elements in certain drawing areas may not be the best solution, but instead handling them accordingly by the game engine.
For example, if you cannot draw elements in a drawing area, this surely feels "wrong" -- you would at least have to display an error message to make this clear.
Preventing to add more than one element of a kind into a certain drawing area could also be misleading (for example, if you wanted to delete the others a few seconds later anyway).
For example, if you cannot draw elements in a drawing area, this surely feels "wrong" -- you would at least have to display an error message to make this clear.
Preventing to add more than one element of a kind into a certain drawing area could also be misleading (for example, if you wanted to delete the others a few seconds later anyway).
I beg your pardon, but isn't it the way that the map works when you try to add more than one player start location? What's misleading there? I feel it as the normal behaviour... well, maybe I have expressed it in the wrong way: putting a duplicate in a ECT should result in the removal of the previous duplicates, just like it works for the map.
About putting special elements in a normal element, an error message would be good indeed, unless you think that it could be used as a feature, then you could leave it as it is now. Killing one YamYam and being teleported to its death-ground could have its interesting aspects and usages
About putting special elements in a normal element, an error message would be good indeed, unless you think that it could be used as a feature, then you could leave it as it is now. Killing one YamYam and being teleported to its death-ground could have its interesting aspects and usages
Anyway, by the way, have fun!
Francesco
Francesco