As long as I know, the wall tiles and building tiles are transformed into actual 3d shapes, but the sprites remain 2d but it stand on the ground.
MV3D - 3D rendering for RMMV with Babylon.js
● ARCHIVED · READ-ONLY
-
-
@Fyoha did you try to put in the event's notetags for it to have pass(o)? I know it isn't mentioned there, but I do remember it being one of the things said to have been added, so we could have things like butterflies that are passable (I said this because it is just what Parallax Panda used in the request for earlier, a butterfly flying through the forest that won't go through walls but that can be walked through). Maybe that works for platforms too?
EDIT: Just checked, and neither o or * made the floating chicken in the test map passable... so yeah, this and the platform thing could be good things to add, @Dread_Nyanak
@Karbonic as far as I can see, despite using the 2d map as a base it is real 3d. The camera can be moved everywhere as long as it is already rendered, unlike with raycasting, the one you mentioned, that renders it every frame. -
Hm, I have some questions about slopes which I'm sure has been brought up before but...
How do I write the tileset tag to specify what the sides of the slope will look like? And to be able to place a slope on top of an elevation (on a cliff/roof/whatever), does it need to be a B, C, D or E tile? -
@Parallax Panda
The sides of the slopes are defined the same way as any other tile, with side().
And you don't need to use B+ tiles, A tile slopes can also have elevation, but the cliff side will use the same texture as the side of the slope. If you want it to use a different side texture then it needs to be B+ (or one of the special A tiles which go on an upper layer)
@Waterguy
All event platforms are supposed to be walkable, so something like pass(o) isn't needed.
collide(false) will let you walk through events similar to pass(*) and will also turn off platform. platform(false),collide(0) will also behave like pass(*)
And events with collision but not platform will behave similar to pass(x), preventing you from walking over them even if walk off edges is on.
Actually I suppose I could add pass for events as a sort of shorthand so you won't need to remember these interactions. pass(o) turns on platform, pass(x) turns off platform while keeping collision, and pass(*) turns off platform and collision. I think I'll do that.
@Fyoha
Thanks, these are some pretty serious bugs.
Update 0.4.4.1
Fixed airship takeoff and landing
You can now walk on platform events over impassable terrain
Fixed bug that prevented airship from flying over certain events
Platform finding now uses collision height instead of sprite height
Added pass() for events as shorthand for collide and platform -
@Waterguy Yeah, I forgot to mention that I also tried using <pass(o)> for the events, but it didn't work like it did for setting it in a new region ID. My (b) method is what I will roll with for now. If I feel like I will run low on region IDs (which we have 254ish), a third method would be to create a duplication of the water tile or anything that is set to be not passable and make THAT passable and just place them under events accordingly.
Also, wouldn't the Through checkbox in the event options let your walk through the butterfly/chickens? I'll have you know when I was testing, I checked that little box for my bridge and fell right through down into the water! (I smell hidden trap door events incoming).
@Karbonic Like people are saying already, in short, it is 2.5d. This plugin is very revolutionary for this engine and has a lot of potential in my opinion.
EDIT: disregard some of what I said since I posted moments after new patch notes were posted. -
It's great to witness this amazing plugin taking shape. I made further tests, especially in Dungeon Crawling mode.
(Thought it would help not to see our MC, to avoid the game breaking visual glitch/corruption when trying the game on iOS web export, but I forgot every events were affected haha.. Anyway, even when trying the same "ftp-uploaded demo" on Chrome the shadows under events are missing too, something might be wrong for this specific kind of export idk. A bit worrisome.)
I got an idea so the player could still play the first person view with a mouse or touch screen (currently if you click the screen you can only go forward basically), so the solution could be a touch/click sensitive area around the screen, I made a screenshot to better explain: (of course that ugly thing would be invisible in game)
The 4 blue areas would be the arrow keys, and the red could even be for optional strafe etc.
The “green large middle area” would be perfect to validate, like in front of a treasure box, to open it.
Good to see you added the option to turn the plugin OFF by default. :)
Here are some extra observations:
* When adjusting the camera with a plugin command during gameplay, if you save your game and reload, the camera resets to the original parameters. No big deal but good to know.
* Took me a while to realize many important plugins don’t work with MV3D, like those from GALV. For example, the one to use more than 3 frames for characters, and especially the one to move diagonally is messing up the directions/controls in game. Usually it’s possible to adjust plugin's positions to make things work again but those 2 are quite specific haha, like the diagonal one has to be under the multiframes one and it’s impossible to do in that situation because MV3D would “need” the opposite in order to work. (The multiframes plugin makes every events disappear.)
* Another big one, the plugin from Yanfly to let the player config the keyboard, in first person view we’ll strafe instead of rotate if that plugin is ON. In third person view it will just be impossible to rotate the camera. Just in case, I’m on an AZERTY keyboard even if it’s unlikely to be a problem.
I think it might be better to focus on problems like that before going further adding even more features and complexity. If it becomes usable, I’ll be more than happy to purchase a commercial license or something, dynamic shadows look awesome. Keep up the great work!
(Another extra “idea”: would be super impressive to be able to procedurally animate the fog, some kind of subtle fractal noise could go a long way to add a nice ambiance and bring some life.) -
@Parallax Panda
The sides of the slopes are defined the same way as any other tile, with side().
And you don't need to use B+ tiles, A tile slopes can also have elevation, but the cliff side will use the same texture as the side of the slope. If you want it to use a different side texture then it needs to be B+ (or one of the special A tiles which go on an upper layer)
@Waterguy
All event platforms are supposed to be walkable, so something like pass(o) isn't needed.
collide(false) will let you walk through events similar to pass(*) and will also turn off platform. platform(false),collide(0) will also behave like pass(*)
And events with collision but not platform will behave similar to pass(x), preventing you from walking over them even if walk off edges is on.
Actually I suppose I could add pass for events as a sort of shorthand so you won't need to remember these interactions. pass(o) turns on platform, pass(x) turns off platform while keeping collision, and pass(*) turns off platform and collision. I think I'll do that.
@Fyoha
Thanks, these are some pretty serious bugs.
Update 0.4.4.1
Fixed airship takeoff and landing
You can now walk on platform events over impassable terrain
Fixed bug that prevented airship from flying over certain events
Platform finding now uses collision height instead of sprite height
Added pass() for events as shorthand for collide and platform
You still seem to be able to ignore stair threshold within 0.99 with z events as long as Walk off Edge is on for both players and same as/above events, rest seem fixed though. Boat vehicle seems to be unable to move through water if you set water to passable, only in tileset though.
Oh and it's only flat z events, seems fixed for other shapes. Actually it does work on other event shapes but only if the event is set to below. If it's set to same as/above for other shapes it actually makes it so it can't move under it if set to any z higher than 1 height difference. Went back to test again, it actually does work for above, but same as you can't walk under it at any height, even z(99) it can't walk under. -
Latest version seems to have broken my project. Reverted back to previous release, back to working.
Game has encountered a bug. Please report it.
TypeError: this.setupParameters is not a function
at Object.setup (mv3d-babylon.js:901:997)
at Function.Graphics._createCanvas (mv3d-babylon.js:901:24574)
at Function.Graphics._createAllElements (rpg_core.js:2336:10)
at Function.Graphics.initialize (rpg_core.js:1769:10)
at Function.SceneManager.initGraphics (rpg_managers.js:1822:14)
at Function.SceneManager.initialize (rpg_managers.js:1811:10)
at Function.SceneManager.run (rpg_managers.js:1802:14)
at Function.SceneManager.run (YEP_CoreEngine.js:1371:32)
at window.onload (main.js:8:18) -
Latest version seems to have broken my project. Reverted back to previous release, back to working.
Game has encountered a bug. Please report it.
TypeError: this.setupParameters is not a function
at Object.setup (mv3d-babylon.js:901:997)
at Function.Graphics._createCanvas (mv3d-babylon.js:901:24574)
at Function.Graphics._createAllElements (rpg_core.js:2336:10)
at Function.Graphics.initialize (rpg_core.js:1769:10)
at Function.SceneManager.initGraphics (rpg_managers.js:1822:14)
at Function.SceneManager.initialize (rpg_managers.js:1811:10)
at Function.SceneManager.run (rpg_managers.js:1802:14)
at Function.SceneManager.run (YEP_CoreEngine.js:1371:32)
at window.onload (main.js:8:18)
I'm pretty sure that happens when you replace the plugin in files but don't update it in plugins manager with new important settings, just hit refresh or change a setting and back. Also I recommend backing up before doing it, my demo corrupted when I first tried to just change the files. -
@KaYsEr when in first person view you cannot see the mc, but you need to turn followers invisible by hand. To use it set the camera distance to 0, either through map notes or a plugin command.
I'd like to give more ideas about your first person touch screen... you see, this plugin allows you to look up and down with page up and page down (if you set it to do so on plugin parameters), and straffing, that is walking to the side without turning. So while that is a good idea if you won't use these, what about for letting the player do those too?
Personally, I'd think it is better to focus on finishing the plugin before dealing with compatibility with other plugins. But I myself did a small compatibility patch for QSprite and a version of QAudio, am currently trying a patch for SRD's CCEx and am planning on doing a version of QInput, so take what I say with a grain of salt. Truth is, many plugins being incompatible in 3d mode is kinda expected since this changes things like how events are shown - they are not sprites, but a new class called Characters that take some things from sprites but not everything, if your plugins are under IIFEs like Galv's are they won't work (actually many other plugins become incompatible with plugins with IIFEs, had myself to remove them from a few Galv plugins for a few friends - that was all I did though so doubt it would be considered a big deal, if this is the first one you met this happened with consider yourself lucky). Not only that, plugins dealing with keys and directions are also expected to have problems - this plugin changes the input so that if you turn the camera pressing left is read as pressing up, for example. Also, the directions were moved to wasd and straffing went to q and e, while default keys are the arrows and q and w for page up and down. Yanfly's plugin, the one you mentioned, considers the default keys and the ones added by his own plugins.
The "fog" here is not really a fog, it is more like those old ps1/n64 fogs to hide the edge of the rendered poligons. Probably actual fog plugins would work fine with it?
Holy walls of text batman! Sorry, a bit out of my mind trying to do the ccex patch I mentioned earlier. Will try to fix this later.
@glaphen I don't understand the problem... from what you said earlier you changed the stairs threshold? Is this problem with the usual threshold or only your new one? Could you send a video or something of what you mean, because I read and read it and don't get it... -
@KaYsEr when in first person view you cannot see the mc, but you need to turn followers invisible by hand. To use it set the camera distance to 0, either through map notes or a plugin command.
I'd like to give more ideas about your first person touch screen... you see, this plugin allows you to look up and down with page up and page down (if you set it to do so on plugin parameters), and straffing, that is walking to the side without turning. So while that is a good idea if you won't use these, what about for letting the player do those too?
Personally, I'd think it is better to focus on finishing the plugin before dealing with compatibility with other plugins. But I myself did a small compatibility patch for QSprite and a version of QAudio, am currently trying a patch for SRD's CCEx and am planning on doing a version of QInput, so take what I say with a grain of salt. Truth is, many plugins being incompatible in 3d mode is kinda expected since this changes things like how events are shown - they are not sprites, but a new class called Characters that take some things from sprites but not everything, if your plugins are under IIFEs like Galv's are they won't work (actually many other plugins become incompatible with plugins with IIFEs, had myself to remove them from a few Galv plugins for a few friends - that was all I did though so doubt it would be considered a big deal, if this is the first one you met this happened with consider yourself lucky). Not only that, plugins dealing with keys and directions are also expected to have problems - this plugin changes the input so that if you turn the camera pressing left is read as pressing up, for example. Also, the directions were moved to wasd and straffing went to q and e, while default keys are the arrows and q and w for page up and down. Yanfly's plugin, the one you mentioned, considers the default keys and the ones added by his own plugins.
The "fog" here is not really a fog, it is more like those old ps1/n64 fogs to hide the edge of the rendered poligons. Probably actual fog plugins would work fine with it?
Holy walls of text batman! Sorry, a bit out of my mind trying to do the ccex patch I mentioned earlier. Will try to fix this later.
@glaphen I don't understand the problem... from what you said earlier you changed the stairs threshold? Is this problem with the usual threshold or only your new one? Could you send a video or something of what you mean, because I read and read it and don't get it...
Turn on Walk off Edge in parameters, make a below flat event with z setting for its height, if less than 0.99 difference between its height and your current/any same/above event walking it can walk on top of it regardless of stair threshold. Make an event any shape at all, and set it to same as with any z setting, same as events walking can't go pass it at all, also seems player can't walk through it either unless set to flat. Just tried again you don't even need Walk off Edge this time for same as problem, belows needs it though.
Oh and I forgot it also works on flat above with z but only for the player, if not for that it could be ignored if you only ever used z with above events. -
@Dread_Nyanak I've been playing around with the Airship some more and have something to say about it.
I noticed that the drop speed of it has increased when navigating off of high terrain since the patch with platform events was introduced. You used to be able to fly off the cliff and quickly fly back onto it before you drop below the surface of it. With more testing, I also figured out that whatever the elevation is set for the airship (2 by default), you can no longer fly over a narrow pit that is deeper than the elevation that the airship is set.
For example:
Say you are in the airship with the elevation set to 2 in the plugin params and you are on a tile/terrain with the height set to 6.
The next tile over is terrain at normal height at 0.
The third tile past that is terrain with a set height to 4.
Somewhere before the first platforms patch was delivered, you would be able to soar over onto the tile that is set to <height(4)> from the tile that is set to <height(6)> with the pit in between set at 0.
Now, you simply drop straight down into the pit because the height difference of it and the other side is 4 which is greater than the elevation setting of the airship (2).
I don't know if this is considered a bug, an implementation of gravity, or a preferred change in code, but I noticed this change just recently when I was flying around in the demo and couldn't fly onto the roof of the shop with the ladder/chest from the mountain cliff anymore. Instead, just dropping down in between them.
To summarize with my screenshot below, you can't fly over some gaps anymore if there is a height/depth greater than the elevation height of the airship. Pumping up the elevation may be un-tasteful for some as you may be hovering too high than preferred. -
I think the latest updates broke the player transfer system. When I'm on a map with 3D off the game doesn't transfer the player from one place to another like it's supposed to. 3D maps work fine but for my project I don't want the effect on anything that doesn't constitute overworld terrain.
EDIT: This is in the 0.4.4 branch in case it helps. -
@Fyoha no you wouldn't. At least, last time I used the airship on a demo, from before 0.4, if you wanted to go to somewhere with height above the airship's flight you had to go somewhere a bit higher to get it high enough - that is, if the airship has over height 2 you could get over a height 2 terrain, going to height 4, and from there to a height 6, but not to a height 5 or 6 right away. That is how some parts of the mountain near the demo town were blocked after all.
Unless that was changed in a later version and put back now, but that is how it worked. -
Not sure if I'm missing something or doing something wrong, but when I load up the demo project it just flat out doesn't work. Everything just renders in 2D as if the plugins aren't there.
-
@Waterguy Yezzir, I understand how you have to climb in intervals of 1 or 2 height blocks that is equal or less than airship elevation to get to higher places, but what I'm saying is that the "soar" effect is gone now. You used to be able to clear a pit if you moved fast enough before the 0.4 patch. Now you just drop. Its like there is a hidden entity that represents your placement with the airship on the ground that isn't totally synced with the actual graphic of the airship and that entity is instantly dropping to the ground while the airship's graphic catches up with it? I don't know how to explain it. I uploaded a quick video on YT to help explain what I mean by the "soaring" effect and how its gone now. I kind of liked it, but idk how complicated the codes are now for having the possibility of bringing it back.
-
@Waterguy Yes the plugin seems to remap a lot of keys, creating many potential problems and breaking other plugins, hopefully it can get better in further versions. (Another thing I noticed is sometimes in the demo when entering a cave in 1st person from the main big island for example, your character can automatically strafe like you’re still pressing the key, might have something to do with that remap thing as well.)
But yes I know we're not supposed to see the MC in.. 1st person ;) all good here, I was talking about the fact all events are messed up if you simply upload the demo to an FTP and try it on any Apple device using Safari (iPhone or iPad), it's quite easy to reproduce the problem. (And even on Windows Chrome, shadows will be missing. Speaking of shadows, I see they can easily break when transferring between maps if the plugin is OFF by default and you manually activate the 3D effect on a per-map basis.)
Sure, the click/touchscreen thing is just a base and we could for example use the 2 red top squares to strafe L/R and the bottom ones to adjust the pitch U/D, we could also not use the red areas to extend the blue since the bare minimum for it to work is the blue and green parts.
Yes you're right it's not the same kind of "fog", It's more like an alpha fog indeed like in good old Turok on N64 to hide the culling, and I love the effect. So yes it's true it's not like for example in the "Khas" fog plugin, maybe we can't "animate" that thing at all, it was just an idea in case there's some kind of witchcraft possible in order to add a fractal noise in that thing to make it look like it's an actual fog.
I wish Drea_Nyanak good luck with the plugin, it’s already very impressive and maybe in time we’ll be able to use it in combination with regular 2D in a game with only occasional 3D maps, like people who just want it for a worldmap or dungeons etc. -
@BreakerZero
Actually it seems like events are broken in general on 2D maps. The modded functions were being called instead of the original ones. Should be fixed now.
@Fyoha
In the new update ascent/descent speed is the same as the gravity, so you can change the speed the airship moves up and down by changing its gravity.
The reason for not being able to fly over pits is flying characters check for collisions at their target elevation in addition to their current elevation.
I'll add a new plugin parameter to restore the old gliding behavior.
Update 0.4.4.2
fixed broken events on 2D maps
added Allow Glide parameter. -
Hm, yeah i'm still trying to figure things out with height. The base height of the map is zero but for my actual map (that the player can walk on) it's 31. Something I'm using regions set in the plugin parameter to achieve. I do have problems with placing objects and structures on top of my elevated ground though.
I thought placing B, C, D and E tiles would be placed on top of elevated ground THEN have their own height applied but apparently not as can be seen with my attempt of placing a headge on the screenshot below:
The hedge is set to have a height of 0.5 unless I'm mistaken (it works on non elevated ground so I think it's correct). However what seems to happen is that that 0.5 height gets overwritten because of the height elevation of 31 and becomes 31 (thus get lowered into the ground).
I guess it might be possible to make a special region for height 31.5(?), but is there a better solution for this? As you can see, there's elevation on top of the cliff as well so if I made special regions I'll have to make a lot of them to be able to place hedge (and other objects) on all different elevation differences. It would be a bit of a mess. -
Hm, yeah i'm still trying to figure things out with height. The base hight of the map is zero but for my actual map it's 31 (i'm using regions set in the plugin parameter to achieve that. I do have problems with placing objects and structures on top of my elevated ground though.
I thought placing B, C, D and E tiles would be placed on top of elevated ground THEN have their own height applied but apparently not as can be seen with my attempt of placing a headge on the screenshot below:
The hedge is set to have a height of 0.5 unless I'm mistaken (it works on non elevated ground so I think it's correct). However what seems to happen is that that 0.5 height gets overwritten because of the height elevation of 31 and becomes 31 (thus get lowered into the ground).
I guess it might be possible to make a special region for height 31.5(?), but is there a better solution for this? As you can see, there's elevation on top of the cliff as well so if I made special regions I'll have to make a lot of them to be able to place hedge (and other objects) on all different elevation differences. It would be a bit of a mess.
I don't think the height in that image is right, it's just height, not height(0.5),.