Godot 4.0 will discontinue visual scripting • Hacker News Board

Re: Godot 4.0 will discontinue visual scripting

#111

Post by Natsu » Fri, Aug 26, 2022, 3:18 AM UTC

kroltan wrote: post #109

Natsu wrote: post #100

Earlier quoted context omitted.

You can put IDs in the nodes and order by ID, but you still have to be a little careful in how you do that or people can add/delete the same node and create lots of changes too. I think YAML works out pretty good as a serialization format because it doesn't create a lot of overhead unlike, say, XML which is ugly for that. You also want to have clear standards for how you pass parameters around (some use a dictionary…

Yep, in my case it was a storytelling tool for visual novel games, so there wasn't much data to pass around, most nodes were either modal interactions or affecting changes upon the game world. It's also a pretty constrained domain so a lot of the bookkeeping could be done internally rather than needing to be exposed to the narrative designer. A lot of the problems you mention just didn't need to exist. In terms of ho…

I agree with that, a few specialized types that are understood by all your nodes can be really helpful in a more limited domain. And it's definitely better suited to relatively simple things where it gives you a sort of high-level flowchart and the nitty-gritty details can happen within the nodes themselves.

Otherwise you get a lot of low level logic of type conversion or other small details instead of a very high level view of the logic. It also helps if you can box up existing flows into a single black box as it were, since that can help you reuse code.

If you do have complex nodes that let you make it into a simplified flow chart of what the application is doing and that allows you to look inside the nodes which might have a more complex, specialized configuration, those end up being a lot nicer to program in than in something that's trying to be a general programming language with lots of low-level nodes dealing with trivial things like data conversion.

Re: Godot 4.0 will discontinue visual scripting

#112

Post by lewispollard » Fri, Aug 26, 2022, 11:19 AM UTC

bluescrn wrote: post #78

Antshockey wrote: post #75

Earlier quoted context omitted.

Godots support for C# is excellent out of the box to be honest. I've not found anything I can't do in C#. There are one or two things that are harder to find but they are few and far between

Yet the default Godot download is a 'standard edition' without Mono support? What's the reasoning behind the two separate builds? Is it just about build/download size, or are there potential licensing issues with Mono or something?

Godot's system for exporting games/apps/projects as binaries is that the same codebase/build system that generates the editor binary (the Godot "tools") can be built with the "tools" parts omitted, and the resulting non-tools release binary is bundled up with your project scripts/resources as the binary API for your exported game.

The general philosophy for Godot's build/compilation system is that most things are just linked statically, and features and modules can be turned on and off via build flags, so that they can be as portable as possible - indeed it's usually pretty painless and quick to export a game to a binary from the editor on most platforms because of this.

With Mono there are 2 sticking points that make this a bit more difficult - first is that this non-tools binary has to bundle the Mono runtime with it to be portable, this adds a bunch of bloat, and Godot's style has always been to be as light as possible. For mobile apps for example, that extra ~40mb of stuff can be a real problem.

Additionally, the development machine has to have a fairly modern dotnet SDK installed (ideally .NET 6 SDK + dotnet cli these days) as well as the app host targeting packs in order for the mono-enabled editor binary to run at all (as it contains some CLR/native interop code and nuget packages for the editor tools to copy into your project, etc that fails without these things). So the export template (the non-tools godot API binary) with Mono can't be understood by the editor tools without Mono enabled.

Recently direct .NET 6 interop support has replaced the Mono integration in Godot 4, and this might in the future change the above - since it will be able to use the new AOT stuff to publish exported games in a more direct way. It's definitely a stated intention to eventually ship just one engine binary for everything, but it's still a way off happening yet, maybe in Godot 4.1 or 4.2.

Re: Godot 4.0 will discontinue visual scripting

#113

Post by sylware » Fri, Aug 26, 2022, 12:28 PM UTC

account42 wrote: post #80

sylware wrote: post #74

godot has a c++ toxicity issue to solve for elf/linux game binaries, I did report to them the issue, and indeed, they reasonably cannot do anything, only the gcc devs (glibc devs should be safe now) can do something (or godot would have to move to good and plain C, or similar). Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose…

> Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. That is not a requirement at all. There is nothing wrong with linking against libc or other glibc libraries as long as you com…

This is clearly what I was saying, missing out the "internal" glibc symbols issue due to the static libstdc++ (I have not got into the details of those symbols, they may be benign since lazy binding is the default), and I would rather favor a "less worse" than "best" terminology to be fair, since it is still causing issues with games, the major users of the binary-only distribution.

We all know the only way to remove properly this "dirt", is too aim "explicit" (libdl) than "implicit" (elf dynsym section), which it seems to become the "normality" in many areas, like smp locking and high level syntax (was a target for python syntax).

And that would open the road for alternative elf/C runtime... ofc glibc zealots won't like that at all, expect a lot of resistance and "mauvaise foi".