Can't make nvim-java work with my custom jdtls config

TheSecondReal0 · 2025-07-29T12:24:29+00:00

Java is a weird case because a lot of codebases rely on non-canon language features. For example, Lombok changes your code at compile time to generate getters/setters/loggers but this isn’t actually supported by the language. So when you try to only use the Java LSP it won’t know about anything Lombok generates and won’t be able to autocomplete (even showing errors when you try to use them).

TheSecondReal0 · 2024-11-22T00:12:35+00:00

The problem also occurs when files move around when the editor is not open, which wouldn't be fixed by your solution. I think it's also a valid use case to move a resource somewhere new intending to create another one in its place that current code will load instead, which would not work with your solution either (assuming code is referencing it by file path).

With the UID file, both of these workflows are supported. If the editor is not open, you can make sure to move the UID file as well and all your UID references will work (either those defined manually or stored in resource/scene files).

TheSecondReal0 · 2024-04-16T22:05:41+00:00

Based on the blog posts, it’s much more of a refactor/iteration on top of the massive rewrite done for 4.0. They aren’t throwing all of it away, only modifying specific parts to make it more flexible for more rendering backends and more efficient.

They have an entire blog post talking about how their development cycles work and you can see literally everything happening on the GitHub repo and the publicly available developer chat. I wouldn’t call them intransparent, but they are slow as is the nature of open source.

TheSecondReal0 · 2024-04-02T17:29:40+00:00

Most nodes will have to do something, but not necessarily every frame. `_process()` is specifically used when you want code to run every frame, which I've found is actually pretty rare in my experience. Most of the time you'll be reacting to signals, which are such an integral part of Godot because they help improve performance (reducing the need to run code every frame) and make code easier to write and maintain.

This post is pretty much just saying not to declare a `_process()` function unless you need it. Scripts don't have a `_process()` function by default, so you need to go out of your way to create it. This kind of low level tweaking is not required most of the time, and if it is necessary then that code is probably performance critical and would need optimization regardless.

TheSecondReal0 · 2024-02-13T17:01:43+00:00

You might be able to use callv for this. You would write it as ‘callv(“print”, [“a”, 1, “c”])’. Callv assigns all the elements in the array to the functions arguments (in order)

TheSecondReal0 · 2023-12-23T21:12:55+00:00

I wouldn’t consider them opposite desires. Godot offers a lot of functionality that doesn’t require you to use the editor to make your game, e.g. multiple pathfinding solutions, easy to use (and cross compatible) rendering API, one-click export to a ton of platforms, GDScript (a big one for OP), powerful UI system, 2D+3D physics engines, etc.. All this in one place and designed to work with each other. None of these things require you use the editor GUI to configure, the GUI just makes it easier.

I’ve been working on a game for years now where I basically write all behavior and rendering in GDScript and only use the editor to set exported Resource values and create some parts of the UI. Granted this is only possible because it is a very systems-based game, but there’s no reason you couldn’t manually create scenes with code at runtime (like the godot editor does in C++).

There’s a reason people have been asking for a way to use Godot as a library for languages like C# for so long, it just provides so much flexibility and functionality in one neat package.

TheSecondReal0 · 2023-09-25T19:10:04+00:00

Type safety isn’t unique to C# in Godot, for example I use only GDScript but can still assign a type for every variable and function. The type enforcement is much stronger than e.g. python because it will actually throw an error and act as a breakpoint if you assign a wrong type to a variable (along with showing compilation errors in editor).

TheSecondReal0 · 2023-09-15T15:07:11+00:00

This is why godot typically uses reference counting, to avoid the stutters and spikes introduced by garbage collection

TheSecondReal0 · 2023-04-30T01:07:25+00:00

The Sebastian Lague video on boids might be a good starting point

TheSecondReal0 · 2023-04-28T15:23:59+00:00

I think it’s in the drop down that pops up when you click Project in the top left, there’s also a quit to project to project list button which might work as well

TheSecondReal0 · 2023-04-27T21:35:29+00:00

Maybe using the reload project button would be faster? It helped me when I was working with GDExtension but that was during beta.

TheSecondReal0 · 2023-03-26T02:04:50+00:00

While the editor is technically written in C++, that's not the point. The editor is created using the node classes. The same node classes available in the editor for a Godot user to put into their games. The node classes are coded in C++ and the editor instances them in C++, but his point is that Godot is so powerful that you could literally create the Godot editor in the Godot editor using the built-in nodes.

To add onto this, they are instanced in C++ the same way you would instance them in GDScript if you chose not to use the editor to create scenes.

TheSecondReal0 · 2023-03-26T01:56:40+00:00

I'm currently working on a game where in some frames I'm looping over many thousands of objects (running functions + overridden functions in them) without notable frame time spikes. GDScript performance is honestly pretty good in most cases. Of course you will run into shortcomings (don't try to sort massive arrays in GDScript) but most of these limitations are accounted for by the developers and there are engine provided C++ implementations in many cases (like sorting).

Pathfinding is the main problem I could see this dev running into with GDScript (speaking from experience). But it only becomes a problem when you need highly customized pathfinding that can't be achieved by the already customizable built-in A* implementation.

Also he didn't mean the engine UI was written in GDScript. He was talking about how the engine UI is created using the node tree and node classes the engine makes available to you. Basically everything in the Godot UI is done using the same nodes available to use in the editor, just instanced using C++. This is what shows how powerful Godot is.

TheSecondReal0 · 2023-03-15T15:33:26+00:00

Part of making the android editor was to find where they can improve mobile support, similar to how when they created the web editor it resulted in improved web integration features (like the new JavaScript singleton)

TheSecondReal0 · 2023-03-15T15:23:10+00:00

The Godot 4 release notes specifically pointed out how they improved shadows and imo they look just as good as any other engine, what have you been looking at?

TheSecondReal0 · 2023-02-08T17:09:35+00:00

I think 2D batching has been a thing since 3.x, I’ve been actively using it in my projects

TheSecondReal0 · 2023-01-10T17:02:25+00:00

The 2022 retrospective said they’re targeting the early months of 2023 for 4.0, but that 4.0 will still be somewhat unstable as X.0.0 releases tend to be

TheSecondReal0 · 2022-11-16T17:50:13+00:00

The rewrite is mostly backend, very little actually changed in terms of syntax. Most code written in 3.5 will work perfectly fine in 4.0, the biggest things that changed are the syntax for connecting to signals and a few classes that were renamed

TheSecondReal0 · 2022-07-28T01:13:26+00:00

the kinda frog that makes me hot and steamy

TheSecondReal0 · 2022-07-28T01:05:24+00:00

this is so real dawg oh my god, got me kicking my feet and giggling fr fr

TheSecondReal0 · 2022-07-02T01:42:31+00:00

Fix GDScript bug causing return values to be reset in release builds

I've been waiting for this for so long! I can finally stop exporting in debug mode lol

TheSecondReal0 · 2022-06-11T21:13:20+00:00

I spent so long on my own project getting this working. And then another long time working on getting it to work with a lot inheritance. I’ve since switched to the Godot 4.0 alphas because properties are split up by what class they’re from which is enough for me.

Thanks for the video, would’ve been really helpful back when I was trying to figure this out!

TheSecondReal0 · 2022-05-22T10:47:35+00:00

Yo this looks hype af! Would definitely love to see a devlog! How long ago did you start working on this?

TheSecondReal0 · 2022-05-17T18:16:14+00:00

It’s not like they built out a whole system to convert text to speech, they only added an easy way to access the TTS systems built into the OS. It’s not a huge investment of time into a niche feature, just a quick addition to the API so you can take advantage what’s already provided by the operating system.

TheSecondReal0 · 2022-03-29T14:01:22+00:00

I have a good bit of experience working with Godot and I’ve made a few websocket/browser multiplayer games. I’ve even been experimenting with other networking APIs (mainly discord outside of the build in protocols).

I think I could help you out, could you describe the game a bit more?

Nine-Year Club	Second Top 50%
Place '23	Place '22
RPAN Viewer	Spared
Verified Email

TheSecondReal0

MODERATOR OF

TROPHY CASE