Making the most advanced TileMap plugin Devlog #1

[stiff hare]

In Godot 3, I could just build my plugin "BottledTileMap" on top of the existing TileMap system. However, Godot 4's system forces me to rebuild the WHOLE TileMap system from scratch. Here's my progress :
Simple drawing + hold click + see preview of where the tile is gonna be placed + sneak peak of the new interface with the tiles sorted into custom groups.
This is but an humble beginning, the first step toward turning Godot into the most advanced 2D level editor with powerful Autotiling Rules, advanced patterns drawing, interface thought through to optimise workflow,...
If you have any feature idea on how to make TileMaps better, tell me !

[storm minnow]

Neat. One thing I wish the new tile map did was to check for auto tile connections in the whole map and change every tile to follow the rules. instead of what is happening now where you can place a tile beside another and the old one won’t update for some reason

[weary elbow]

make them not shit pls
that would definitely make them better

[stiff hare]

It's probably not that hard but what if you set tiles with autotiling off because you don't want a bunch of them to connect together, it's gonna mess it up

[stiff hare]

That's my first goal

[weary elbow]

i know that would be very hard but i am sure you can do it

[stiff hare]

If you have more specific ideas, tell me

[weary elbow]

yeah, sorry for flooding

[stiff hare]

I mean I complain about G4 Tilemaps all the time but if you want your voice heard, now's the time to talk

[storm minnow]

1. You can do that? And 2. Who would use an auto tile and then not use it as auto tile?

[stiff hare]

There's a button to disable autotiles to place tiles manually. I used it from time to time.

[storm minnow]

hm well then just check for tiles directly around the placed one instead of all of them

so that new connections are formed when a tile is placed, but it won't mess that other one up

[stiff hare]

So, the way it was in G3, right ?

[storm minnow]

pretty much, yeah. it's just pretty annoying that you have to paint over every tile three dang times just to connect it to something

[stiff hare]

@weary elbow

[weary elbow]

perhaps thing i am most furious about is the tileset system
working with tilesets through the editor is fine, but when you try to generate them at runtime (e.g., when you use external level editor or loading mods or whatever) things become incredibly hard, clunky and ugly
first this dumb thing that tilemaps can't have more than one tileset: tileset is tile set, its not a damn TileSetSourceAtlas-set or even TileSetSourceSceneCollection-set (or whatever its called, i don't use it). tile maps should directly have a simple array of tile sets, which directly have a simple array of simple tile definitions (i.e., their "default" properties), no shit like custom source and tile ids (though i think tile ids are fine, just not as it is done in G4 tilesets)
literally zero exposure of internal apis is one thing i think i'll never understand; have you ever used all these TileMap.get_cell_*() methods? seems useful, huh? but actually: NO, ITS F***ING NOT! i have no idea what could be a reason to completely hide TileMapCell, tons of useful small classes like PhysicsLayer, missing array properties like TileSet.custom_data_layers_by_name (search in gh repo for that, it is not exposed to gds) from GDScript api and lots, lots more, making it times harder to work with them code-wise.
i also hate this infinite "get position -> do self.to_local -> do map.local_to_map -> finally get your dumb cell" stuff. i personally see why local coords might be needed, but why add another complexity layer? no answer

as far as i see (though i admit i see not very far), current g4 tile system is tied very, very directly to the editor and relies on it as much as it can; current api is not convenient, requires lot of work for simple things (while not making hard things easier) and forces you to hardcode and/or store a lot of values like layer names, indexes, tile and cell coords in several coord systems (because the only way of configuring all this at runtime with current api is to stupidly iterate over whatever layers or tiles you have and check if their ids/coords/names are correct, which is obviously not efficient)
in the end i must say that i am not a godot hater or some random angry kiddo that bullies everyone because he cant make gta6 with one line of code: rather, godot is my favourite and the only game engine i use with pleasure and i am gratefully thankful to everyone who made this possible, including the guy who made the current tilemap system. i understand that nothing can be perfect and there are always tradeoffs, but tilemal api is so much different from the rest of the engine that when i first looked at the docs i was literally thinking if i was somehow redirected to unity docs - that's how much more unintuitive current tile system is (for a beginner in this area, at least). what im saying here is not "g4 tiles are bad go fix", but rather that g4 tiles are overly complex (and messed, perhaps?..) for what they propose, compared to the rest of the engine. that's it for me, thanks.

@stiff hare literally a damn book lmao

i was freaking out about tile system several hundred times on other guilds, now im shitposting here. i wonder what's next

github pr to nuke tile system altogether? xd

[storm minnow]

That sounds like a lot of stuff that isn't actually solvable via plugin

[stiff hare]

@weary elbow I agree. It took me 2 weeks to get to the basic stuff I showcased here, that's how complex it got to build something from the Tilemap.
From what you said, I get that what you want is some functions to make stuff quicker. Maybe I can do that. Though the whole tile ID shit with source and coords will stay because yeah...

[storm minnow]

well could you provide some utility methods? like getting specific metadata of a tile. or getting the tile at a position, ex: the tile that the player is standing on (in top down and side view). or getting the "source" or "origin" tile of a tile that stretches over two or more tiles (don't know the name of those). Since their origin is the bottom most tile and the other parts of it don't have that data for some reason

[stiff hare]

Yeah
Though that's the kind of features I'd typically do last

[weary elbow]

Oh, you're building your plugin on top of existing TileMap?