It's better to make the tile layers children of Node2D instead of Node. Node does not have Canvas which means it has no modulate to inherit nor visibility. So if you want to make a scene invisible anything childed to Node will not inherit the ancestors visibility state.
It was pointed out to me that Node is probably better than Node2D (and they’re right) if you just want it to act like a folder. If you need additional functionality, Node2D might be necessary
I really like this change actually. As you said, dividing the tilemap layers into its own node makes it more inline to the overall Godot node hierarchy design.
I never used the tilemap layers feature, I just made separate tilemaps for Background Midground and Foreground. I made each tilemap's Z index a lower or higher value. So this new feature just makes my work easier.
Seconded. I've only spent a few hours playing around with tilemaps in Godot and found them quite fiddly. My immediate reaction to seeing this video was "thank the gods, that's much better."
I can only agree to this. Rather new to Godot and I also found it quite confusing, but TileMapLayers makes so much more sence! I guess its a question of habit?
Another really nice benefit with working directly with the TileLayers is that it's now less of a hassle to work with Parallax. Simply drop in a TileLayer into a ParallaxLayer and now you can add distant hills or foreground clutter, or perhaps the view of the distant ground in a top-down like Zelda: Link to the Past when atop the mountain.
@@baconandgames To be fair, I haven't actually checked if it works yet. But I see no reason at all for why it wouldn't. To the point that I'd call it a bug if it doesn't for some obscure reason.
I started learning godot very recently and Ive already ran into the "oh no I painted the tiles on the wrong layer" issue you mentioned. I agree with everyone else about this change making things simpler, faster, less prone to mistakes, and overall, more coherent with the node design philosophy of the engine. 10/10 update. And it doesn't look like any features where removed/lost which apparently needs to be worried about in today's age. It's always nice to see a gem that cares about the product and the users. It might have something to do with it being open source and developed by said users but what do I know 🤷♂
If you can apply different materials to different layers, then this is a WIN, because previously shader affected whole tilemap and it was not very usable for something like "fog of war"
Well looks like I’ve got some rewrite to do. I like this idea a lot. It also means you can make layer specific scripts, which is really nice for reducing bloat in a parent script. My biggest gripe with tilemaps is that there isn’t wildcard and either or tile matching for the autotile system. I’ve got tiles where it doesn’t care what tile is in the corner next to it. And I’ve got some that want either of two options out of 4 possible. That second one would be an amazing addition. I know there’s ways to do it by making duplicate tiles and having a different rule on each but then for each time it should be used, you need to add another tile, and that means I’m at least doubling all tilesets
Oh yeah, that's a really interesting case I hadn't considered. You could probably set custom data on your auto-tiles to handle those rules and then loop through your tiles on init or ready to swap out any incorrectly drawn tiles but I already hate this idea as I'm typing it 🤣 But I'm with you on the bloat - any time you can break code into smaller chunks I'm here for it.
I was also sceptical at first, but then I started to tinker around with the layers and its so much easier. Not only can you attach a separate script to handle custom interactions for each layer, which is more organized megascript for all layers. You can apply modulation, and other effects to each layer separately, or even shift a single layer by an offset. It's really neat. (both in the sense of tidy and cool)
I'm a fan of the new Tilemap Layers, I've definitely run into the same issue as you where I think I was painting on one layer only for it to have been on a completely different layer, can't wait till they're brought to the stable branch!
Thanks for covering this up. Tilemap Layers is way more intuitive than original Tilemap. It's not my case but imagine someone using 10 layers and finding/switching in that nested Tilemap UI.
Honestly, i really like this, at a glance i was misled to thinking it was unecessary but the amount of times i painted a tile to the wrong layer is uncoutable
I now understand the update much better and actually prefer it this way - the split reactions left me feeling unsure of the change at first. This discussion video was also very clear.
I spend quiet some time creating code that will load and save tile map at runtime, in addition to generating map dynamically. I have to redo lots of work because of this. However if I am doing a new project this would make things easier to work with.
I have recently started learning Godot, and I am trying to work with a tilemap, this seems SO much more intuitive than the original system. But I do wonder whether this will be easier or harder to work with in scripts. For example my first little exercise with tilemaps is a little editor for something, and in most tilemap functions it asks you for a layer, which makes it very easy to work with multilayer stuff, guessing this will be slightly harder with these.
I suspect it is about the same working with scripts. The API will have changed, of course, new node - but they’re reported to be quite similar. Good luck with your godot journey and your project(s)!
I'm not against this, but it is going to cause some re-writing for me. I have a script on a Tilemap that has all of the indexes of the layers as constants, and it uses several functions that currently require the layer index as the first argument. For example, I am going to have to change all of these and more: get_cell_tile_data(OBSTACLE_LAYER, cell) set_cell(MOVEMENT_LAYER, cell, MOVEMENT_TILESET_SOURCE_ID, MOVEMENT_ATLAS_COORDS) set_cells_terrain_path(MOVEMENT_LAYER, current_path, PATH_TERRAIN_SET, PATH_TERRAIN) clear_layer(GRID_LAYER) I'm sure there are other people that are going to have to do more work than just clicking a button to do the conversion.
Yeah. There’s bound to be some breaking changes as APIs and tools evolve over time. This is why they deprecate rather than remove. There’s no need to adopt the new format for your current project unless you need the new functionality, which you probably don’t since the gains here are all editor-side. But when you finish this project, depending on how far out that is, you’ll have a decision to adopt the new method or not.
That’s true though that’s one of those features that feels a little buggy to me because it doesn’t always update the icon which makes me wonder how stable it is.
Layers are great been using the beta its just more godoty the tilemap has so much in it that is just split up into the layers making it way simpler to customize
I started just now to work with phantomCamera2D and im using my tilemap to limit the camera… do you know how its done with these new tilemap layers? I need to select one tilemaplayer that have the largest size?
I'm not seeing the "split" in the people. Please, don't start using drama as a clickbait for Godot. We have a nice community, let's keep it clean from fake controversy.
That’s a really fair point. It’s a wonderful community. To be honest… I wasn’t trying to create clickbait or stir up controversy. I had been hearing mixed feedback from a few other godot users and so I threw that title up there with that in mind, while rushing to get this out before the weekend. Not an excuse really, but an explanation nonetheless. My apologies. I’ll do better in the future. Most people are saying they like in the comments, but there have been a handful of gripes that have been interesting to read.
Also the “fight!” Was speaking to the nodes battling, not the people, which in retrospect makes no sense because TileMap Layer has already won 🤣. Man, I bungled this one 🤦♂️
That was not clickbait. The title is "People Seem Split on this New Godot 4.3 Feature". It's fair to assume some people are split because that happens when anything is changed no matter how miniscule or beneficial the change is. At no point does the title imply that there's some kind of civil war going on the community. Your comment is more sensationalist than the title.
@sergeantsapient I appreciate the defense but also see their point. I felt a little odd about it when I wrote it. The original title was going to be something like “I really love this new feature… what do you think?” but I changed it at the last second because I wasn’t sure if I really do love it because I haven’t used them much, as mentioned in the video. Thought this title was more middle of the road, opening up to opinions on both sides. I dunno, YT is hard and I’m still figuring this out as I go. I appreciate everyone’s feedback 🙏
@@baconandgames keep up the good work. I just started getting back into Godot after a long learning hiatus and tilemaps are one of the key features I wanted to use so I'm glad to see they're getting something that makes them more manageable. My point is changes in anything always cause a stir. This seems to be particularly common in the Godot community because a lot can change between versions. In this case I'm glad they decided to deprecate the tilemap node and not just remove it and it was a good choice.
You can stream-line the actions at 4:28-4:42. Just right-click the TileMap and pick "Change Type". Now you can pick Node2D and it'll convert the node to that type, and keep all settings that carries over, like visibility, transform, etc. This is very helpful, especially when working with a scene root as you can change your enemy from a generic Node2D to a CharacterBody2D for instance.
That’s a good point. I always get a little nervous about that because Godot doesn’t always seem to recognize the change (the icon doesn’t always update) and if you have a script attached extending the node then you have to be extra careful to update the base class. But you’re right, that would have been a lot quicker 🤣 Sometimes I feel like my brain slows down while I’m trying to narrate what I’m doing while recording. 🙃
@@baconandgames Yeah, the script needing to be changed is an issue that it should probably warn you about at least. I believe it works if you go down the hierarchy though, so from Node to Node2D.
Well you can't please everyone. Software like GODOT needs to advance and improve. That means that sometimes you may have to change the way you do something or update old code. You can not expect them to bog the software down with old features that most don't use anymore. You are getting a great piece of software for free.
This TileMapLayer looks more useful than old TileMap nodes, but I'll wait a bit before making the upgrade, as I prefer working with more stable versions. Also, good job on setting up your consulting services. I'm rooting for you!
@@baconandgames It's a good thing I'm not using them for the current game I'm making, and honestly the TML will be more useful to create 3D levels than regular TM (since you'd need to create layers yourself and make sure they all act as intended, etc... while the TML are nodes, thus more easily rearrangeable.) The bit on the collision layers is still relevant, at least, so that video wasn't made in vain. Keep up the great work! I'll go back to my shaders (which is the main reaosn I'm not switching up to 4.3, because of a possible lack of compatibility.)
@@baconandgames This channel isn't for videos, and I haven't made any devlogs yet. However, I can explain what I discovered by myself with shaders and how to efficiently make one (using pre-existing tutorials.) If you want a good channel about shaders on Godot, I suggest FencerDevLog who makes some incredible visual and functional shaders: www.youtube.com/@FencerDevLog
@@baconandgames I just realized my response had a link, so it's probably in your spam/moderated comments. For shaders, I advise the channel of FencerDevLog, who does a lot of great Godot visual shaders, and even show how to convert from Shadertoy to Godot's shading language.
I could be wrong, but this kinda seems like it's just how Tilemap worked before layers were implemented, except they changed name to TilemapLayer. I haven't touched Tilemaps in ages, tbh, but I don't dislike this. In fact, I've always had the feeling that Tilemaps didn't need layers in the first place, simply because you could already layer several Tilemap nodes to achieve the effect.
Also yes I think this is a bad move and a good move. It's a good move in that at least it is attempting to address a problem. It's a bad move because it is creating a new problem. Larger projects that make more use to layers will now run the chance of cluttering the hierarchy. As each layer is now technically capable of being a scene, this means there can be unique logic again this is a positive and negative. I think the solution could have been to use both at the same time and to have cleaned up the ui. So selecting the active layer via heirarchy or inspector would work the same. You keep the tile map and you get the ability to add tilemap layers as scenes to a tilemap.
Oh interesting… excellent point. See, this is exactly the kind of stuff I was hoping folks would bring up because people do seem divided on it. For the small games I tend to make, I thankfully probably wouldn’t run into this issue but… I totally could too. Thanks for the thoughts!
This is largely my issue with the new implementation. There's now no single node to house, manage, or add these new layers and make global edits to them. It's just gonna clutter up the UI and make it a bit of a hassle to work with them. Like you said, the better solution would have been to keep a version of the TileMap node and require the TileMap Layers to be children of it. That way you get the granular controls with each layer while having a root TileMap node that can add new layers as children and make global edits to every layer under it.
@pixels_per_minute yeah, that hybrid approach would have been neat. The parent map would set the “master values” and then the layers would either choose to inherit or override, pretty much the way control nodes work.
I have almost no experience with godot, and actually no experience making a "real", game yet, but this feels a lot nicer to work with! I wonder if they are doing the same with stuff like animation players?
I think what Joe was asking is whether other more complex features, like the AnimationPlayer, will get broken down to more digestible versions of themselves. Tilemaps and AnimationPlayer are among the most intimidating features to newcomers because they have so many menus and sub-menus, many of which are contextual and not all of which interfaces are super intuitive. While I wouldn’t call the TilemapLayer a huge leap forward in simplifying Tilemaps, it does seem to remove one layer of complexity (no pun intended 🤣)
What advantage do these have over using multiple TileMap nodes? I don't dislike the change, but it's effectively the same workflow as before they added layers to tilemaps.
I would guess it’s the first step in a larger refactoring as the basis for future improvements, but no haven’t looked at the source code. So while it may not look all that different yet, it’s likely easy to build upon that the TileMap node it will be replacing.
In my opinion, TileMap as node gives many advantages over the old way. In this way, we can access the TileMap Layer straight from the Scene Tree without the need to access the TileMap properties to get the TileMap layer. To delete all the Prop layer? Easy. Que free the Prop TileMap node. Done
You were able to do this with the previous Tilemap node too. I know this because I did it, it would've been $TileMap.clear_layer(2) 2 being the array index of the prop layer.
I don't like this way of managing layers. I would prefer each layer to be just that, a child layer of the tilemaplayer node but currently, each layer is a tilemaplayer node on its own. TilemapNode -> all features of a tilemap (main node) ----TilemapLayer -> layer features (children node) ----TilemapLayer2 -> layer features (children node) ---- ... With this current system it is like the old tilemap node in godot 3.x.
I was chatting about this with someone in another comment, actually. It might be worthwhile to model it after Control nodes, in the way that the parent sets defaults and then child inherits or overrides. 100% That might cut way down on how much needs to be set on each layer. Excellent point! Thanks for the comment 🙏
Will this make it possible to display tilemaps in a 3D scene? I've wanted to do that for the longest time, to make a sort of Pilotwings (or F-Zero!) homage.
Oh, I’m not sure if these would work like that 🤔 but you should look into this mode 7 shader. gist.github.com/Jellonator/0686c6e74d06745957de5a96fa00ec6c I LOVED Pilotwings! If you ever make your own version, please let me know 🥰
I am currently refactoring my game to use the new TileMapLayer. How can I ensure common functionality is shared between nodes efficiently? For example, I have a mouse_to_tile() function: func mouse_to_tile(mouse_position: Vector2): return local_to_map(to_local(mouse_position)) I want every layer to share this function without redundancy. One option I considered is using a parent node to handle this, but that approach seems suboptimal since already my parent node takes care of other more general functions. I also thought of creating a custom class that extends TileMapLayer. What would be a better solution?
Tough to say without knowing you project, but generally I’d extend TilemapLayer to add the functionality I need OR build something through composition that can be attached to nodes that need it. th-cam.com/video/74y6zWZfQKk/w-d-xo.htmlsi=jcj06VNx1eyrMYZm
Man I just started using the current tilemap and already had to move things hetween layers due to how many mistakes I've made. I can't say im not in favor of this change
@samuraikina5908 oh no bother at all! Ooooooohhhhh, I know what you were referring to. That’s a picture of my niece- she’s on my consultancy page. She made her own Link costume for Halloween and wanted to show it to me when I came to visit (in February). I thought it was super cute so I put it on the website. I’m with you now. 👏👏👏
I think the devs did a nice job with the feature and the rollout. Change can be jarring, no matter how hard people try to make the transition easy. I’ve seen some valid complaints about the new system but overall I think it’s squarely in the net-positive camp. Thanks for the comment and for checking the video out. I appreciate you 🙏
@@baconandgames I'm making a voxel style extraction game, single player shooter with top down view. I'll share some videos once I have something decent.
The "feature" people seem to be actually split about is the fact that you no longer can just do "if something != null" to check if you can still use that specific thing and instead you have to do much more verbose "if is_instance_valid(something)"
@@UltimatePerfection GDScript has duck-typing, so these values are cast into booleans for the "if" evaluation. You can test it with the following snippet: var a = null var b = Node if a: print("this evaluates to false") if b: print("this evaluates to true") It's kinda the same reason you don't have to typecast variables into strings before you try calling print() on them.
There's pretty much no sane programming language that even has something like is_instance_valid(). Godot is this bizarre outlier that has reference counting and yet still teaches (let alone allows) people to queue_free() their nodes and introduce crashes deliberately. If your reference is ever supposed to point to an object that could be freed, you should use Weakref
There is no valid complaint, unless you are a professional complainer on Twitter, this is objectively better and I was avoiding using the 4.0 tile map because it just had so much to learn
I’m definitely of a mind that it’s an improvement. There have been some interesting gripes in the comments that I’d not considered (one being how it gets cumbersome in larger games with lots of layers) The TileMap node does have a lot of settings 😳
I'm still on 4.2, I'm curious if they retained the PageUp/PageDown functionality to move up and down the layers? Or if there's a generic Godot hotkey that moves to the next/previous selected node that I'm not aware of.
I don’t know for sure but my guess is that this is the first step in a larger refactor. In the same way we tend to refactor our projects and break things into smaller responsibilities, I SUSPECT that this change will make futures updates to how tiling works easier. I could see a world where there’s a parent node that controls high level settings for the children (sort of like how Control nodes work) allowing layers to inherit or override certain values specific to their tiles. I don’t know that they’re looking at doing anything like this, but breaking things down into more parts COULD indicate this. 🤷
Isn't this the exact same thing as what we had back in godot 3 where you just had multiple tilemaps where you had one for background, one for props etc... like what's the difference?
I wasn’t using Godot as much back then so I’m not sure how it differs on the finer points. From what people have been saying it certainly seems similar.
I don't think there was a problem with the old way tilemap layers worked other than the fact that the interface was trash. Like, it _could_ have worked. I could definitely see a version where the integrated layers were somehow more useful and tighter than having a new node for each different layer, but it needed polish.🤷
I suspect it will continue to evolve, especially with a vocal community and it being open source. It’s one of the things I really love about godot. The users actually have a chance of being heard 😬
I’m not sure they’re actually invisible. They might just be outside the camera bounds. But if they’re set up as Scenes, you can just set visible = false in the ready() function. There’s probably a way to do it with tiles as well, I’m just blanking on that off the top of my head.
Maybe some people don't like managing lots of nodes in the editor and this adds more to their project, but to me that just says they need to structure their nodes better. Which they should be doing anyway.
I feel that. I like a nice tidy project. And often, if you have too many nodes in one tree you might need to breaking responsibilities into smaller components.
For one, you can apply logic to a TilemapLayer in ways that weren't possible before. This also means you can modulate layers individually as well. But besides that, I think we're seeing a shift in "ideology" by breaking things down into smaller parts, just as is wise to do when making a game with Godot. We're seeing this shift with Parallax nodes and I suspect we'll see it with others as well. Godot has a bit of a nesting problem; menus within menus within menus, which make editing and organizing your project cumbersome. Can you do a TON now that you couldn't do before, no. But there may also be some stuff under the hood being done to prepare for future updates that will be significantly less cumbersome with these, rather than the old TileMaps as the base. That last bit is just speculation on my part though.
I actually haven't messed with that feature yet. I did a little digging and based on the lack of mention in their build notes and the way this thread (see below) ended, I'm going to GUESS it hasn't been resolved yet. But if I find out for sure, I'll update you here. github.com/godotengine/godot/issues/72611
This is the purpose for deprecating versus removing it. Using the Tilemap won't break anything for quite some time. It's a transitional change, not a breaking change... but I understand what you're getting at.
Anyone able to help me? I’m trying to get into game dev, but I’m unable to drag my assets into godot, I was watching brackys vid. Is it a computer setting issue?
What kind of assets? Sound files? 3D models? 2D sprites? This is a pretty open-ended question. You might have better results posting a more complete question on the Godot forums. forum.godotengine.org/
I think you would have to have a LOT of layers before the number of nodes contributing to your game’s overhead would be impacted by TileMaps. But in truth, and I’m saying this without looking at the Godot source code, I don’t imagine it’s all that different in terms of overhead because the data being tracked hasn’t changed much. They’re just changing whether one TileMap is responsible for multiple layers or if those layers manage themselves. Generally speaking, yes the more nodes you have the more overhead, but I don’t think this change is likely to be the first failure point.
I think, aside from using tiles of the same multiples (32x32, 64x64, 128x128, etc), it’s extremely rare to have tile sets of different “sizes” in the same project. So I don’t expect that’s a problem they’re trying to address. Typically tilesets within a game adhere to some kind of standard that makes them fit together. If they don’t, that’s where you end up using Sprite2D.
@@baconandgames yeah, I agree, my project has 8px and 16px tileset sizes, I need tham that way because both have autoterrain at 8,16 sizes, and I have to use both sizes, and I would have loved something that works with both in the same layer
@c64cosmin I’m pretty sure you can do that now. You can have tiles of different sizes in one tile set. Then you’d just make your grid 8x8 and paint as you normally would.
I don’t believe an exact release date has been announced but their latest dev snapshot is saying “around a month”. If that holds then it’ll be some time in July, though that’s dependent upon how bug fixing goes.
Can you create a tutorial (((gathering???)) cut trees (the tree shakes if the player cuts them) has a cut (cut trees) action limit (example: 5 times a large tree, 3 times a medium tree, 2 times a small tree) when it reaches the limit (tree aga animation (fall) and objects falling to the tree after (falling tree)
Have the Godot devs not taken clues from other engines like Unity and Unreal Engine? Unity is so full of deprecated crap, you don't know what to use, unless you read a book on the current version. Instead of leaving old broken crap in the code, which could potentially bug things out, why not just download w/e version had that old feature? If they can back port fixes, that's great, but dam, please don't wind up like Unity, or even Unreal Engine that is so full of old, broken or obsolete crap.
I don’t think it’ll be around forever but you’re right, they would be wise not to leave depreciated features around for too long. After too many it can get bloated. But some transition time can be beneficial. You can also toggle off nodes you don’t want to turn up in the node search/add window, which I realize isn’t a solution but might be helpful for you during the transition.
Godot does remove things it deprecates. The point of deprecation is to give people room to migrate and then remove them eventually. Godot 4 removed a shitton of things that were deprecated in 3
I actually wished for a rather different change regarding the layers in the TileMaps. When I draw a level, I don't want to be constantly switching between layers manually or checking whether I'm on the right layer. Instead, I want to be able to tell the individual tiles in the TileSet which layer they belong to. That an item sprite always lands on the item layer and a level tile on the level layer accordingly. Now you have to create several TileSet graphics in order to distribute them for the new TML, which at least provides an overview.
It's better to make the tile layers children of Node2D instead of Node.
Node does not have Canvas which means it has no modulate to inherit nor visibility.
So if you want to make a scene invisible anything childed to Node will not inherit the ancestors visibility state.
Oh yeah, that’s a good point. I was moving too fast when recording this video 😬
So you want to use a Node for the parent of tile layers?
@@Dunkable A node2D
just being able to set a difference in position for a single layer makes this change perfect
It was pointed out to me that Node is probably better than Node2D (and they’re right) if you just want it to act like a folder. If you need additional functionality, Node2D might be necessary
I really like this change actually. As you said, dividing the tilemap layers into its own node makes it more inline to the overall Godot node hierarchy design.
I’m glad I’m not the only one who likes it!
I never used the tilemap layers feature, I just made separate tilemaps for Background Midground and Foreground. I made each tilemap's Z index a lower or higher value.
So this new feature just makes my work easier.
As someone who doesn't have too much experience using the original Tilemap node - this makes a lot more sense to me!
Oh yeah? That’s good perspective. Thanks!
Seconded. I've only spent a few hours playing around with tilemaps in Godot and found them quite fiddly. My immediate reaction to seeing this video was "thank the gods, that's much better."
I can only agree to this. Rather new to Godot and I also found it quite confusing, but TileMapLayers makes so much more sence! I guess its a question of habit?
Another really nice benefit with working directly with the TileLayers is that it's now less of a hassle to work with Parallax.
Simply drop in a TileLayer into a ParallaxLayer and now you can add distant hills or foreground clutter, or perhaps the view of the distant ground in a top-down like Zelda: Link to the Past when atop the mountain.
Oh dang, yeah that’s great! I think I saw someone else’s comment here asking whether that would work. Thanks!
@@baconandgames To be fair, I haven't actually checked if it works yet. But I see no reason at all for why it wouldn't.
To the point that I'd call it a bug if it doesn't for some obscure reason.
@Sylfa If you test is out, please let us know what you find (here or we’d love to have you in the Discord).
oh man thats a great idea. Definitely on board with this change now
@@baconandgames Hey, not OP, but I tested it and it works. TileMapLayers does work with the new Parallax2D.
Tested with Godot 4.3 beta 1.
I started learning godot very recently and Ive already ran into the "oh no I painted the tiles on the wrong layer" issue you mentioned. I agree with everyone else about this change making things simpler, faster, less prone to mistakes, and overall, more coherent with the node design philosophy of the engine.
10/10 update.
And it doesn't look like any features where removed/lost which apparently needs to be worried about in today's age. It's always nice to see a gem that cares about the product and the users. It might have something to do with it being open source and developed by said users but what do I know 🤷♂
That’s really nice of you to say. Hopefully someone who has contributed to the projects sees your message 🥲
If you can apply different materials to different layers, then this is a WIN, because previously shader affected whole tilemap and it was not very usable for something like "fog of war"
Oh you know what… that makes perfect sense but had not occurred to me. 🎉😍
Well looks like I’ve got some rewrite to do. I like this idea a lot. It also means you can make layer specific scripts, which is really nice for reducing bloat in a parent script.
My biggest gripe with tilemaps is that there isn’t wildcard and either or tile matching for the autotile system. I’ve got tiles where it doesn’t care what tile is in the corner next to it. And I’ve got some that want either of two options out of 4 possible. That second one would be an amazing addition. I know there’s ways to do it by making duplicate tiles and having a different rule on each but then for each time it should be used, you need to add another tile, and that means I’m at least doubling all tilesets
Oh yeah, that's a really interesting case I hadn't considered. You could probably set custom data on your auto-tiles to handle those rules and then loop through your tiles on init or ready to swap out any incorrectly drawn tiles but I already hate this idea as I'm typing it 🤣
But I'm with you on the bloat - any time you can break code into smaller chunks I'm here for it.
I was also sceptical at first, but then I started to tinker around with the layers and its so much easier. Not only can you attach a separate script to handle custom interactions for each layer, which is more organized megascript for all layers. You can apply modulation, and other effects to each layer separately, or even shift a single layer by an offset. It's really neat. (both in the sense of tidy and cool)
Boy do I love some good wordplay. "neat" Freakin' nailed it 💪
Love that you are discussing new features. Keep up the great work.
Thanks! 🙏
It is a UI improvement and fits better with the node-based component strategy.
I agree 😀
I'm a fan of the new Tilemap Layers, I've definitely run into the same issue as you where I think I was painting on one layer only for it to have been on a completely different layer, can't wait till they're brought to the stable branch!
Shouldn’t be too long now…
Looks good, I needed to have multiple tilemaps sometimes for more complex setups anyway, now they can just be layers
🙌
It's DEFINITELY much better. I found Godot tilemaps terrible. The layers are much better and offer much more intuitive control.
Agreed. It does seem like a cleaner way to do it, at least for the way my brain works.
Thanks for covering this up. Tilemap Layers is way more intuitive than original Tilemap. It's not my case but imagine someone using 10 layers and finding/switching in that nested Tilemap UI.
I think so too!
Honestly, i really like this, at a glance i was misled to thinking it was unecessary but the amount of times i painted a tile to the wrong layer is uncoutable
Same 🤜🤛
This Is really good. The more we lean into node & scene composition, the better. Composing the tree is king! 👑
🤜🤛
Developing a mmo style tilemap game and layers are a great improvement.
I now understand the update much better and actually prefer it this way - the split reactions left me feeling unsure of the change at first. This discussion video was also very clear.
Well that’s great!
I spend quiet some time creating code that will load and save tile map at runtime, in addition to generating map dynamically. I have to redo lots of work because of this. However if I am doing a new project this would make things easier to work with.
I have recently started learning Godot, and I am trying to work with a tilemap, this seems SO much more intuitive than the original system.
But I do wonder whether this will be easier or harder to work with in scripts.
For example my first little exercise with tilemaps is a little editor for something, and in most tilemap functions it asks you for a layer, which makes it very easy to work with multilayer stuff, guessing this will be slightly harder with these.
I suspect it is about the same working with scripts. The API will have changed, of course, new node - but they’re reported to be quite similar. Good luck with your godot journey and your project(s)!
I’m well excited about this change. Almost as much as the new dynamic music features!
I haven’t looked the music stuff yet but I will now! 😍
I'm not against this, but it is going to cause some re-writing for me. I have a script on a Tilemap that has all of the indexes of the layers as constants, and it uses several functions that currently require the layer index as the first argument. For example, I am going to have to change all of these and more:
get_cell_tile_data(OBSTACLE_LAYER, cell)
set_cell(MOVEMENT_LAYER, cell, MOVEMENT_TILESET_SOURCE_ID, MOVEMENT_ATLAS_COORDS)
set_cells_terrain_path(MOVEMENT_LAYER, current_path, PATH_TERRAIN_SET, PATH_TERRAIN)
clear_layer(GRID_LAYER)
I'm sure there are other people that are going to have to do more work than just clicking a button to do the conversion.
Yeah. There’s bound to be some breaking changes as APIs and tools evolve over time. This is why they deprecate rather than remove. There’s no need to adopt the new format for your current project unless you need the new functionality, which you probably don’t since the gains here are all editor-side. But when you finish this project, depending on how far out that is, you’ll have a decision to adopt the new method or not.
4:28 - You can just RMB the "Tile Map" node and "Change Node Type" into Node2D
That’s true though that’s one of those features that feels a little buggy to me because it doesn’t always update the icon which makes me wonder how stable it is.
God-dang-it, that's a good news. I was so annoyed with current TileMap layers. Good explanation!
🙌
Yeah this makes sense.
Layers are great been using the beta its just more godoty the tilemap has so much in it that is just split up into the layers making it way simpler to customize
I agree!
I started just now to work with phantomCamera2D and im using my tilemap to limit the camera… do you know how its done with these new tilemap layers? I need to select one tilemaplayer that have the largest size?
Oh, I don’t know. That’s a good question. I would probably just write a little utility that does just that and call it a day.
I'm not seeing the "split" in the people. Please, don't start using drama as a clickbait for Godot. We have a nice community, let's keep it clean from fake controversy.
That’s a really fair point. It’s a wonderful community. To be honest… I wasn’t trying to create clickbait or stir up controversy. I had been hearing mixed feedback from a few other godot users and so I threw that title up there with that in mind, while rushing to get this out before the weekend.
Not an excuse really, but an explanation nonetheless. My apologies. I’ll do better in the future. Most people are saying they like in the comments, but there have been a handful of gripes that have been interesting to read.
Also the “fight!” Was speaking to the nodes battling, not the people, which in retrospect makes no sense because TileMap Layer has already won 🤣. Man, I bungled this one 🤦♂️
That was not clickbait. The title is "People Seem Split on this New Godot 4.3 Feature". It's fair to assume some people are split because that happens when anything is changed no matter how miniscule or beneficial the change is. At no point does the title imply that there's some kind of civil war going on the community. Your comment is more sensationalist than the title.
@sergeantsapient I appreciate the defense but also see their point. I felt a little odd about it when I wrote it. The original title was going to be something like “I really love this new feature… what do you think?” but I changed it at the last second because I wasn’t sure if I really do love it because I haven’t used them much, as mentioned in the video. Thought this title was more middle of the road, opening up to opinions on both sides. I dunno, YT is hard and I’m still figuring this out as I go. I appreciate everyone’s feedback 🙏
@@baconandgames keep up the good work. I just started getting back into Godot after a long learning hiatus and tilemaps are one of the key features I wanted to use so I'm glad to see they're getting something that makes them more manageable.
My point is changes in anything always cause a stir. This seems to be particularly common in the Godot community because a lot can change between versions. In this case I'm glad they decided to deprecate the tilemap node and not just remove it and it was a good choice.
As someone still using 3.5, this just looks like how I do things in 3.5.
I’ve been hearing that a lot 😜
You can stream-line the actions at 4:28-4:42.
Just right-click the TileMap and pick "Change Type". Now you can pick Node2D and it'll convert the node to that type, and keep all settings that carries over, like visibility, transform, etc.
This is very helpful, especially when working with a scene root as you can change your enemy from a generic Node2D to a CharacterBody2D for instance.
That’s a good point. I always get a little nervous about that because Godot doesn’t always seem to recognize the change (the icon doesn’t always update) and if you have a script attached extending the node then you have to be extra careful to update the base class. But you’re right, that would have been a lot quicker 🤣 Sometimes I feel like my brain slows down while I’m trying to narrate what I’m doing while recording. 🙃
@@baconandgames Yeah, the script needing to be changed is an issue that it should probably warn you about at least.
I believe it works if you go down the hierarchy though, so from Node to Node2D.
@Sylfa Your tip is still a good one! We just have to be mindful of failure points when it’s done that way. 🤜🤛
I use the tile map pretty heavily and this is a dream.
Well you can't please everyone. Software like GODOT needs to advance and improve. That means that sometimes you may have to change the way you do something or update old code. You can not expect them to bog the software down with old features that most don't use anymore. You are getting a great piece of software for free.
Amen to that 👏
Honestly I like how they did this, way more intuitive
I think so too! I’ve heard some folks saying that in large games it gets cumbersome but no solution is perfect, right?
This TileMapLayer looks more useful than old TileMap nodes, but I'll wait a bit before making the upgrade, as I prefer working with more stable versions.
Also, good job on setting up your consulting services. I'm rooting for you!
I’m usually a wait and see guy myself. I totally forgot TileMaps were going away when I made the last video.
@@baconandgames It's a good thing I'm not using them for the current game I'm making, and honestly the TML will be more useful to create 3D levels than regular TM (since you'd need to create layers yourself and make sure they all act as intended, etc... while the TML are nodes, thus more easily rearrangeable.)
The bit on the collision layers is still relevant, at least, so that video wasn't made in vain. Keep up the great work! I'll go back to my shaders (which is the main reaosn I'm not switching up to 4.3, because of a possible lack of compatibility.)
@kaiserkreuz4155 do you have a channel? Shaders are such a blind spot for me. Always looking for more good shader tutorials 😬
@@baconandgames This channel isn't for videos, and I haven't made any devlogs yet. However, I can explain what I discovered by myself with shaders and how to efficiently make one (using pre-existing tutorials.)
If you want a good channel about shaders on Godot, I suggest FencerDevLog who makes some incredible visual and functional shaders: www.youtube.com/@FencerDevLog
@@baconandgames I just realized my response had a link, so it's probably in your spam/moderated comments.
For shaders, I advise the channel of FencerDevLog, who does a lot of great Godot visual shaders, and even show how to convert from Shadertoy to Godot's shading language.
I could be wrong, but this kinda seems like it's just how Tilemap worked before layers were implemented, except they changed name to TilemapLayer. I haven't touched Tilemaps in ages, tbh, but I don't dislike this. In fact, I've always had the feeling that Tilemaps didn't need layers in the first place, simply because you could already layer several Tilemap nodes to achieve the effect.
Yeah, that’s a good point. I guess the devs agree because that’s basically how it now works 😀
Also yes I think this is a bad move and a good move. It's a good move in that at least it is attempting to address a problem. It's a bad move because it is creating a new problem.
Larger projects that make more use to layers will now run the chance of cluttering the hierarchy.
As each layer is now technically capable of being a scene, this means there can be unique logic again this is a positive and negative.
I think the solution could have been to use both at the same time and to have cleaned up the ui.
So selecting the active layer via heirarchy or inspector would work the same. You keep the tile map and you get the ability to add tilemap layers as scenes to a tilemap.
Oh interesting… excellent point. See, this is exactly the kind of stuff I was hoping folks would bring up because people do seem divided on it. For the small games I tend to make, I thankfully probably wouldn’t run into this issue but… I totally could too. Thanks for the thoughts!
This is largely my issue with the new implementation.
There's now no single node to house, manage, or add these new layers and make global edits to them.
It's just gonna clutter up the UI and make it a bit of a hassle to work with them.
Like you said, the better solution would have been to keep a version of the TileMap node and require the TileMap Layers to be children of it.
That way you get the granular controls with each layer while having a root TileMap node that can add new layers as children and make global edits to every layer under it.
@pixels_per_minute yeah, that hybrid approach would have been neat. The parent map would set the “master values” and then the layers would either choose to inherit or override, pretty much the way control nodes work.
@@baconandgames And you still get the ability to add scripts to each layer, independent of the TileMap control node.
I have almost no experience with godot, and actually no experience making a "real", game yet, but this feels a lot nicer to work with! I wonder if they are doing the same with stuff like animation players?
I guess we’ll see 🤔
The difference is that animations and their libraries are resource files, not nodes.
I think what Joe was asking is whether other more complex features, like the AnimationPlayer, will get broken down to more digestible versions of themselves. Tilemaps and AnimationPlayer are among the most intimidating features to newcomers because they have so many menus and sub-menus, many of which are contextual and not all of which interfaces are super intuitive. While I wouldn’t call the TilemapLayer a huge leap forward in simplifying Tilemaps, it does seem to remove one layer of complexity (no pun intended 🤣)
What advantage do these have over using multiple TileMap nodes? I don't dislike the change, but it's effectively the same workflow as before they added layers to tilemaps.
I would guess it’s the first step in a larger refactoring as the basis for future improvements, but no haven’t looked at the source code. So while it may not look all that different yet, it’s likely easy to build upon that the TileMap node it will be replacing.
What i am most curious about is the ability to add these new tilemap layers to a parallax layer. That would make everything worth it for me.
Oh interesting 🤨 never thought about that
I think they will keep it in until the release 5.0 as this is pretty major compatibility breaking change
That’s fair. I will probably stick with 4.2 a while muself
In my opinion, TileMap as node gives many advantages over the old way. In this way, we can access the TileMap Layer straight from the Scene Tree without the need to access the TileMap properties to get the TileMap layer.
To delete all the Prop layer? Easy. Que free the Prop TileMap node. Done
Well said 🫡
You were able to do this with the previous Tilemap node too. I know this because I did it, it would've been $TileMap.clear_layer(2)
2 being the array index of the prop layer.
@@Gatrehs Oh. I don't know about that before this. Thanks for the information.
That’s news to me as well. Thanks for the tip!
I still end up painting tiles on the wrong layer with the tilemap layer nodes lol.
I think I like the new nodes regardless
I’m sure I’ll still make that mistake sometime too 🤣
I don't like this way of managing layers.
I would prefer each layer to be just that, a child layer of the tilemaplayer node but currently, each layer is a tilemaplayer node on its own.
TilemapNode -> all features of a tilemap (main node)
----TilemapLayer -> layer features (children node)
----TilemapLayer2 -> layer features (children node)
---- ...
With this current system it is like the old tilemap node in godot 3.x.
I was chatting about this with someone in another comment, actually. It might be worthwhile to model it after Control nodes, in the way that the parent sets defaults and then child inherits or overrides. 100% That might cut way down on how much needs to be set on each layer. Excellent point! Thanks for the comment 🙏
Will this make it possible to display tilemaps in a 3D scene?
I've wanted to do that for the longest time, to make a sort of Pilotwings (or F-Zero!) homage.
Oh, I’m not sure if these would work like that 🤔 but you should look into this mode 7 shader.
gist.github.com/Jellonator/0686c6e74d06745957de5a96fa00ec6c
I LOVED Pilotwings! If you ever make your own version, please let me know 🥰
Oh hey! Look what I just stumbled upon in my “watch later” playlist!!!
th-cam.com/video/ND2bHrm9REk/w-d-xo.htmlsi=4YS_mgLNSJaRiEY8
@@baconandgames Nice find! I'll definitely have to tinker with that next time.
I am currently refactoring my game to use the new TileMapLayer. How can I ensure common functionality is shared between nodes efficiently? For example, I have a mouse_to_tile() function:
func mouse_to_tile(mouse_position: Vector2):
return local_to_map(to_local(mouse_position))
I want every layer to share this function without redundancy. One option I considered is using a parent node to handle this, but that approach seems suboptimal since already my parent node takes care of other more general functions. I also thought of creating a custom class that extends TileMapLayer. What would be a better solution?
Tough to say without knowing you project, but generally I’d extend TilemapLayer to add the functionality I need OR build something through composition that can be attached to nodes that need it. th-cam.com/video/74y6zWZfQKk/w-d-xo.htmlsi=jcj06VNx1eyrMYZm
Man I just started using the current tilemap and already had to move things hetween layers due to how many mistakes I've made. I can't say im not in favor of this change
😬
Hey you have a nice daughter , always protect her and always b there for her mate. I hope you the best 🤙
You either have me confused with someone or I’m not getting the joke 🤣 I do have two puppies though.
@@baconandgames i though i seen a girl in the video, sorry to bother was not intended. Its all good
@samuraikina5908 oh no bother at all! Ooooooohhhhh, I know what you were referring to. That’s a picture of my niece- she’s on my consultancy page. She made her own Link costume for Halloween and wanted to show it to me when I came to visit (in February). I thought it was super cute so I put it on the website. I’m with you now. 👏👏👏
I agree 100% visually it's just works better. Godot folks should use this video everytime someone protests for this change, can't explain it better.
I think the devs did a nice job with the feature and the rollout. Change can be jarring, no matter how hard people try to make the transition easy. I’ve seen some valid complaints about the new system but overall I think it’s squarely in the net-positive camp. Thanks for the comment and for checking the video out. I appreciate you 🙏
@@baconandgames I appreciate your work and now I have someone I can consult too when my project is a little more advanced. cheers!
@hawkgamedev awesome! What are you working on? I always love hearing with other devs are up to.
@@baconandgames I'm making a voxel style extraction game, single player shooter with top down view. I'll share some videos once I have something decent.
@hawkgamedev extraction game? Is that like mining? I don’t think I’ve heard a game described that before. Tell me more 🫢
The "feature" people seem to be actually split about is the fact that you no longer can just do "if something != null" to check if you can still use that specific thing and instead you have to do much more verbose "if is_instance_valid(something)"
Oh well that’s not great 🤨
You can just do "if something:", which is much less verbose
@@lauroaranha That doesn't make any sense. A Node, for example, is not a bool.
@@UltimatePerfection GDScript has duck-typing, so these values are cast into booleans for the "if" evaluation.
You can test it with the following snippet:
var a = null
var b = Node
if a: print("this evaluates to false")
if b: print("this evaluates to true")
It's kinda the same reason you don't have to typecast variables into strings before you try calling print() on them.
There's pretty much no sane programming language that even has something like is_instance_valid(). Godot is this bizarre outlier that has reference counting and yet still teaches (let alone allows) people to queue_free() their nodes and introduce crashes deliberately.
If your reference is ever supposed to point to an object that could be freed, you should use Weakref
There is no valid complaint, unless you are a professional complainer on Twitter, this is objectively better and I was avoiding using the 4.0 tile map because it just had so much to learn
I’m definitely of a mind that it’s an improvement. There have been some interesting gripes in the comments that I’d not considered (one being how it gets cumbersome in larger games with lots of layers) The TileMap node does have a lot of settings 😳
You can push and move something painted in a tile? I didn't even realize that... how??
It’s just a regular scene, but it’s painted in through the tilemap
I'm still on 4.2, I'm curious if they retained the PageUp/PageDown functionality to move up and down the layers? Or if there's a generic Godot hotkey that moves to the next/previous selected node that I'm not aware of.
Oh, I dunno. I’ll take a look next time I fire up 4.3 👍
Yes, there are hotkeys to select the next/previous layer node in the tree.
Omg I love this!
Is the "split" thing supposed to be a wordplay about the tiles? 😶
If only I were that clever… 😬
Was it more resource intensive to use a different tilemap for each layer, or some other reason that wouldn't be a good idea?
I don’t know for sure but my guess is that this is the first step in a larger refactor. In the same way we tend to refactor our projects and break things into smaller responsibilities, I SUSPECT that this change will make futures updates to how tiling works easier. I could see a world where there’s a parent node that controls high level settings for the children (sort of like how Control nodes work) allowing layers to inherit or override certain values specific to their tiles. I don’t know that they’re looking at doing anything like this, but breaking things down into more parts COULD indicate this. 🤷
Thank you for this. I'm wondering what the notable API changes are.
🤔 if they’re interesting enough, maybe I’ll do a video on those.
maybe this update is good for most people but I prefer the old ways anyway even if the update make the life easy.
Well, the TileMap isn’t going anywhere any time soon so you don’t have to sweat it 😊
That's a good change for sure
📝 one more for “good” 😀
Isn't this the exact same thing as what we had back in godot 3 where you just had multiple tilemaps where you had one for background, one for props etc...
like what's the difference?
I wasn’t using Godot as much back then so I’m not sure how it differs on the finer points. From what people have been saying it certainly seems similar.
I don't think there was a problem with the old way tilemap layers worked other than the fact that the interface was trash. Like, it _could_ have worked. I could definitely see a version where the integrated layers were somehow more useful and tighter than having a new node for each different layer, but it needed polish.🤷
there is a problem the navigation mesh just ignores any layer except layer 0
I suspect it will continue to evolve, especially with a vocal community and it being open source. It’s one of the things I really love about godot. The users actually have a chance of being heard 😬
Oops. Have you reported that issue?
This is an excellent change.
🫡
I'm all for it
🙌
I'm sorry to change the subject but: ¿How do you make your invisible wall "x" tiles look like that in the editor but make them invisible in game?
It’s just a red x sprite 😬
I’m not sure they’re actually invisible. They might just be outside the camera bounds. But if they’re set up as Scenes, you can just set visible = false in the ready() function. There’s probably a way to do it with tiles as well, I’m just blanking on that off the top of my head.
@@baconandgames Thanks for taking the time and for the idea! I will be doing some of that visible = false thing
@franco2796 🫡
There's a Godot 4.3 now? these version coming and going a bit too fast for me ^^
It’s in beta right now.
Maybe some people don't like managing lots of nodes in the editor and this adds more to their project, but to me that just says they need to structure their nodes better. Which they should be doing anyway.
I feel that. I like a nice tidy project. And often, if you have too many nodes in one tree you might need to breaking responsibilities into smaller components.
You look like Edward Snowden.
Abort. My cover is blown. My cover is blown. Stupid bargain plastic surgeons…
Fundamentally how is this different from having multiple TileMaps, with one layer each?
For one, you can apply logic to a TilemapLayer in ways that weren't possible before. This also means you can modulate layers individually as well. But besides that, I think we're seeing a shift in "ideology" by breaking things down into smaller parts, just as is wise to do when making a game with Godot. We're seeing this shift with Parallax nodes and I suspect we'll see it with others as well. Godot has a bit of a nesting problem; menus within menus within menus, which make editing and organizing your project cumbersome. Can you do a TON now that you couldn't do before, no. But there may also be some stuff under the hood being done to prepare for future updates that will be significantly less cumbersome with these, rather than the old TileMaps as the base. That last bit is just speculation on my part though.
Does the new tilemap layer clip children function work? I tried using it in the 4.0 tilemap and nothing happened.
I actually haven't messed with that feature yet. I did a little digging and based on the lack of mention in their build notes and the way this thread (see below) ended, I'm going to GUESS it hasn't been resolved yet. But if I find out for sure, I'll update you here. github.com/godotengine/godot/issues/72611
Can we fricking stop with the tilemap breaking changes back to back maybe, then we might stop having a divide.
This is the purpose for deprecating versus removing it. Using the Tilemap won't break anything for quite some time. It's a transitional change, not a breaking change... but I understand what you're getting at.
can you do a tutorial on how to use Lua/Luau for godot please?
I don’t think I’m the right person for that job, unfortunately. I do see some tutorials out there on that subject though.
I like this better
how about working with plugin BetterTerrain on a new version?
Oh I don’t know. I’ve never used that plugin.
Anyone able to help me? I’m trying to get into game dev, but I’m unable to drag my assets into godot, I was watching brackys vid. Is it a computer setting issue?
What kind of assets? Sound files? 3D models? 2D sprites? This is a pretty open-ended question. You might have better results posting a more complete question on the Godot forums.
forum.godotengine.org/
I thought that nodes had overhead, so more nodes = worse performance.
So isn't this new way of doing it, worse in terms of performance on the game?
I think you would have to have a LOT of layers before the number of nodes contributing to your game’s overhead would be impacted by TileMaps. But in truth, and I’m saying this without looking at the Godot source code, I don’t imagine it’s all that different in terms of overhead because the data being tracked hasn’t changed much. They’re just changing whether one TileMap is responsible for multiple layers or if those layers manage themselves. Generally speaking, yes the more nodes you have the more overhead, but I don’t think this change is likely to be the first failure point.
That is nice but I think it still doesn't solve the issue of having multiple sized tilesets.
I think, aside from using tiles of the same multiples (32x32, 64x64, 128x128, etc), it’s extremely rare to have tile sets of different “sizes” in the same project. So I don’t expect that’s a problem they’re trying to address. Typically tilesets within a game adhere to some kind of standard that makes them fit together. If they don’t, that’s where you end up using Sprite2D.
@@baconandgames yeah, I agree, my project has 8px and 16px tileset sizes, I need tham that way because both have autoterrain at 8,16 sizes, and I have to use both sizes, and I would have loved something that works with both in the same layer
@c64cosmin I’m pretty sure you can do that now. You can have tiles of different sizes in one tile set. Then you’d just make your grid 8x8 and paint as you normally would.
@@baconandgames Have to try this asap then, or maybe I missed it in the version I am currently using
where are the examples of "People Seeming Split" on the feature?
that's why i clicked on this video.
Yeah, sorry. That wasn’t meant to be clickbait. I’ve just been hearing mixed things from other Godot users.
I pinned a comment that brings up some good points, if you’re curious. This is the kind of stuff I’ve been hearing here and there.
@@baconandgamesstrangely, I can't see a pinned comment (or any self-comments - just incase it's not just my device not showing it)
@generrosity that’s weird. It’s a comment by dibaterman. Not sure why that didn’t pin 🤔
do we know when the full 4.3 release is coming
I don’t believe an exact release date has been announced but their latest dev snapshot is saying “around a month”. If that holds then it’ll be some time in July, though that’s dependent upon how bug fixing goes.
Can you create a tutorial (((gathering???))
cut trees (the tree shakes if the player cuts them) has a cut (cut trees) action limit (example: 5 times a large tree, 3 times a medium tree, 2 times a small tree) when it reaches the limit (tree aga animation (fall) and objects falling to the tree after (falling tree)
Check out this video. Might be all you need! th-cam.com/video/74y6zWZfQKk/w-d-xo.htmlsi=jcj06VNx1eyrMYZm
I would learn faster with a video about what I'm looking for, the one he gave me I don't understand much
@Necrincito Alright. Well I’ll keep my eye out. Your request is a little specific to suit my channel but if I come across something I’ll let you know.
@@baconandgamesok. Thanks ❤
@@baconandgames
I am stuck on the topic in question, until I learn to do it I cannot move forward.
my ver 4.2 already has layers.I wish there was a 2D and 3D Water node.
It’s very possible that 4.3 introduced the deprecation and not the feature. Wouldn’t be the first time I mixed a detail like that. 😜
Have the Godot devs not taken clues from other engines like Unity and Unreal Engine? Unity is so full of deprecated crap, you don't know what to use, unless you read a book on the current version. Instead of leaving old broken crap in the code, which could potentially bug things out, why not just download w/e version had that old feature? If they can back port fixes, that's great, but dam, please don't wind up like Unity, or even Unreal Engine that is so full of old, broken or obsolete crap.
I don’t think it’ll be around forever but you’re right, they would be wise not to leave depreciated features around for too long. After too many it can get bloated. But some transition time can be beneficial. You can also toggle off nodes you don’t want to turn up in the node search/add window, which I realize isn’t a solution but might be helpful for you during the transition.
Godot does remove things it deprecates. The point of deprecation is to give people room to migrate and then remove them eventually. Godot 4 removed a shitton of things that were deprecated in 3
This is 10x as intuitive. The old method was totally unnecessarily poorly designed.
🙌
I actually wished for a rather different change regarding the layers in the TileMaps. When I draw a level, I don't want to be constantly switching between layers manually or checking whether I'm on the right layer. Instead, I want to be able to tell the individual tiles in the TileSet which layer they belong to. That an item sprite always lands on the item layer and a level tile on the level layer accordingly. Now you have to create several TileSet graphics in order to distribute them for the new TML, which at least provides an overview.
Oh interesting! that’s not an stories I’ve heard suggested before 🤔