It lets you scale SVGs in real-time with really good results, so yeah microscope-level zooming on SVGs look fantastic. I haven't tested performance yet but it seems totally fine on smaller games and GUI apps.

Unfortunately it works for everything EXCEPT tilemaps. There's a PR that fixes it but it's slated for after 4.5 (so likely 4.5.1)

That said, once that gets fixed I'll try to do a fully SVG game. See the video in the PR for how it looks.

proper SVG support

How proper?

or <real-time scaling/skewing objects> without performance issues? Or only simple usage via svgtexture?

I would be fine with the mesh rendering approach too, though for full control*: polygonal SVGs made via Inkscape probably don't outweigh just creating polygons via Godot** itself (allowing in-engine animation, multi-node editing) for me.

* if curves are approximated, I'll not use those and instead go for aesthetic** and minimalism.

** or, 3D (probably via Blender) already supports that better with vertex colors (texture need not be applied) plus more flexibility in materials/shaders.

🤣

Oooh! Now I get the reference! LOL 😆😆😆😆

Wishlisted! Looking forward to it. :)

Also can you add an easier egg if you name your sub a certain name AND play with a controller you have a chance to implode when you hit that same depth they did? I think it would be funny.

You can! Although the range of movement is limited (you cant move away from the wall).

In fact I'm testing the game with a controller

Cool! Can you pilot the sub with a PlayStation controller?

I'm the same vein, it is highly recommended to type literally everything: variables, arguments, return types, etc. This not only makes the autocomplete better, but also helps the editor identify bugs before you even run your game!

Thank you so much! This is enormously helpful.

Question 1: The editor gives hints when it knows the type. You can use static typing. For the demo, you'd want something like var mob: Node2d = mob_scene.instantiate(). or RigidBody2D? Depending on what it actually is.

I'm not sure if there is a vim binding plugin. Editing in an external editor without integration works fine, you just have to confirm to reload when you focus godot.

For neovim integration you'd have to use the external editor feature. You just set up a command to run with the proper args when you choose to edit a file. In practice you set up neovim to listen over a pipe, and godot sends the command to open a file and go to a line. It's not trivial to set up but it's possible.

This tutorial seems good: https://simondalvai.org/blog/godot-neovim/

For beginner godot tutorials, I recommend Brackeys: https://www.youtube.com/playlist?list=PLPV2KyIb3jR7ecat0FBEMv2EZgsDg6Wcv

Yup, it has a lot of great changes and fixes that I'm anticipating. Things like tilemap collision chunking, better UI scaling, proper SVG support, big 3D improvements, etc.

Is 4.5 that significant an upgrade over 4.4? 4.3 -> 4.4 was such a huge one for me personally

I'm waiting too, I actually imported a smaller project I have and the text editor now shows warnings which I love. Can't wait to convert my main project! Haha

Wannabe? JetBrains make Kotlin…

Tribalism

PyCharm was quite nice back when I was using it. Glad to see them supporting Godot.

What's sad about it?

JetBrains IDEs have been my preferred for a decade now, I’ve used IntelliJ, WebStorm, Rider, and Pycharm at home and at work, glad to see support from them!

Shame that they also announced to be actively not supporting/banning Linux users, which probably rules out a lot of users who are familiar with Godot.

Also, I'm not familliar with all the dev companies BF has so I may be wrong, but I don't think I see any of them in the Godot sponsors list.

I know that's not how FOSS works, but it still sucks in this case. But, at least it will introduce new generation of modders to Godot, so that's a plus.

color_rect.set_instance_shader_parameter should work, as long as the color_rect is unique to each instance of the card, rather than being reused. If you assigned it in the node editor you could check the "Local To Scene" checkbox. Assuming cards are defined as separate scenes you instantiate. Otherwise you could duplicate() the resource in code.

The same would be true for color_rect.material.set_shader_parameter for the ShaderMaterial. If you could ensure it's unique per card, it should work. However, duplicating the material might not be as ideal, especially since the other option is also available.

A little tip: You could try print debugging with the get functions before and after you use set to see what the value was before (and notice that it might be the same as the previous set call from another card) and that it was correctly set afterwards. (Assuming I'm correct about diagnosing the problem.)

edit: Actually, my advice is only true if color_rect was a resource, but I think it's a node, specifically a sub-class of CanvasItem or GeometryInstance3D, so it should already be unique for each instantiated card. So without more information I'm not sure why set_instance_shader_parameter is not working.

Update: I fixed it I just had a issue with the path when adding it as a child, I should have added it in the same place as my multiplayer spawner spawn location mb

@MorrisRF is he in scene or is he only added only with instantiation?he needs to be added as a child of some scene.btw you need to be more specific about what's going on.

As I said in the post, the player that joins cannot see anything besides the default godot grey background and no inputs are detected from the player that joined.

He can't see and he can't walk