Jetbrains being amazing as usual. Their tools are the best in the business. There are entire languages that are only usable because of their work.

I just wish they hadn't gone all-in on AI. I know it was either that or lose IDE market share, but they should at least have made the AI features opt-in.

This is good.

The asset library has needed an overhaul for a while.

Reviews and tags will help a lot, the currently existing search features... well you basically have to know the name of what you are looking for, and even still, I've run into things that literally have the exact same name, but are made by different people.

My dream is that we see an economy of "parts makers" flourish thanks to this, but this will live and/or die based on who exactly starts filling up the store - and with which assets.

But a little harder to feed the kiddo's with your contributions to it. I know there's a few folks who survive that way with Unity, so I'm excited for the feature.

Free store is best store

Note that the store does not allow buying or selling yet; that's item 2 on the roadmap.

Still cool! But currently mostly a replacement for the asset library.

Hey, cool!

I started godot pretty recently as well. I simply cannot see a world where I'd ever go back to unity.

I'm getting much farther with much less effort.

IMO this is a great case for Finite State Machines. Unfortunately I can't provide a GDScript example since I write in C#, but I think there are some assets for this in the asset library. The basic idea is that you define states, and valid transitions between those states (e.g. for a drag'n'drop system given the states idle, dragging and dropped it makes sense for the user to go idle -> dragging, dragging -> dropped and dropped -> idle, but not from idle -> dropped). Then you can separate the state transition logic from the main handler for each state, which I think is what you want, right?

This pattern can also easily be made reusable, either by having no dedicated logic in the state machine (-> everything is handled through events), or by using an adapter interface that components create and pass into the state machine.

Let me know if you have questions, or would like to see an example - I can at least provide pseudo code :)

I love when I have to use ZX for actions on German keyboard layout /s

Between QWERTZ vs QWERTY the Z and Y keys are swapped, which gives YX quite the big spread.

yea honestly JaN0h4ck's advice by moving the input check into is probably what you'd want to have a crack into trying otherwise for cleaning up code I would recommend 100% using Godot's actions so instead of doing an if statement for checking InputEventMouseButton and if its pressed or not and then checking the button index, just use an event.is_action_[pressed/released], or you check if the event is an action type and then call a separate function passing the event in to check the action just to make your _input function a little cleaner by only having the logic for the non button events happening in there

also considering how much youre calling camera.get_global_mouse_position() and whatnot, I feel like you may as well just set a variable at the top of the func for it, having the space for that would also help if you were to look into any other "mouse" position stuff such as touch screen inputs or virtual pointers from a controller

I highly, highly recommend using the built-in system for receiving inputs. From there you can build whatever abstraction you want on top of it.

Haha, yeah it feels wrong but im pretty not an experienced programmer so its all I know.

I am thinking if I could figure out how to put each type of command into its own function. The main input handling loop could just be calling a single line in response to an input event and that would be more managable. However im stuck because a lot of the logic requires multiple input events.

All the godot tutorials keep talking about state and after waiting 8 I still have no idea how to use state to control this.

inside there I have a ton of elif statements

I don't even use godot and I can already tell you this is not how you want to do it.

The reason for checking keys is it is the only way i know how to do it. This input handling script is what im finding the most trouble with, a lot of the lines are added because I read a 6yr old reddit comment that said to use it and im not sure if I should remove it because then bugs start appearing.

The reason for unhandled input was the first input handling code example I saw and honestly I forgot about input(). I'll look into the creating input actions but at a glance it doesn't seem like it could work for my game. This game is pretty much left click right click on a 2d space and depending on what tool is selected.

I really do want to move some of the code into other functions but im not sure how to make a function that handles the input over multiple different states.

For example dragging a box. needs to check for the left click then check for the dragging state and draw on drag then check for a release. I have a lot of tools that will need to implement this so I'd really like to get this logic out of the main function and into a nice reusable block.

	elif selected_type == "command":
		if selected_item == "structure_dict_growing":
			if is_dragging and event is InputEventMouseMotion:
				var grid_pos = tilemap.local_to_map(camera.get_global_mouse_position())
				var local_pos = tilemap.map_to_local(grid_pos)
				drag_end = local_pos + Vector2(32, 32)
				cam_drag_end = get_viewport().get_mouse_position()
				gui.queue_redraw()
				get_viewport().set_input_as_handled()
				return
			elif event is InputEventMouseButton and not event.pressed:
				if event.button_index == MOUSE_BUTTON_LEFT:
					is_dragging = false
					gui.queue_redraw()
					get_viewport().set_input_as_handled()
					MessageBus.rpc_id(1, "request_zone_growing", selected_item ,drag_start, drag_end, multiplayer.get_unique_id())
					drag_start = null
					drag_end = null
					return
			elif event is InputEventMouseButton and event.pressed:
				if event.button_index == MOUSE_BUTTON_LEFT:
					is_dragging = true
					#to snap to grid
					var grid_pos = tilemap.local_to_map(camera.get_global_mouse_position())
					var local_pos = tilemap.map_to_local(grid_pos)
					drag_start = local_pos - Vector2(32, 32)
					cam_drag_start = get_viewport().get_mouse_position()
					gui.queue_redraw()
					get_viewport().set_input_as_handled()
					return

Good point, this probably also allows players to remap inputs if they want.

if you hardcode letters for keys, you can't handle alternate keyboard layouts. without rebinding, that means some users will have to be contortionists to play.

recommend using godot's action system instead of checking for specific button inputs https://docs.godotengine.org/en/stable/getting_started/first_3d_game/02.player_input.html#creating-input-actions since it can more easily allow for controller support and remapping, unless there's a reason you are checking for specific keys? also is there a reason to using _unhandled_input() over _input()? Otherwise I would also recommend moving some of this logic into separate functions as a start

I just dump a lot of if statements into _process. One thing good about it is that it gets rid of some nesting and shortens it a bit

I'm mostly experienced in c++ and python, but I would use a dictionary/map/associative array/whatever name you call it, where you put keypress/event/... as key, and a function with the result you want as value (as a first version, there's other more specialised ways, but this will be enough for most cases).

If there's a case/switch statement in gdscript (that's what you're using I think?), you could also look into that, though I think it's likely just syntactic sugar for either what you're already doing or what I suggested, but it might be easier to read, so there's that.

Edit: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#match

Gdscript calls it match operator, and I think it works like your elif tree but just a bit cleaner and easier to read

Yeah, I made the script check whether it's a child of a Node2D before accepting its parent as its component.

Some other solutions might be:

• removing the @tool modifier (not applicable in my case)
• making the user manually assign the component (not necessary in this case)

Did you end up figuring out the solution?

Oh, yes quite smart and maybe also computing the distance between the player and the object, to avoid making transparent objects that are in player's sight but very far away

My bad. This is a tool-type ECS component (a component that affects an entity, usually - and in this case - its parent). It seems to have been adopted by a node of the editor tree, leading to infinite recursion.

I dont get whats going on I think the post needs more information