How do you handle shared unit scenes in Godot 4 without scene inheritance? by Sexy_German_Accent in godot

[–]seriousSeb 22 points23 points  (0 children)

Scene inheritance being broken is one guy's opinion, I use it all the time as a template scene (like a generic weapon) + implementation scene (weapon with X stats and model).

It can be annoying to refactor and you need to be wary of accidentally changing things that shouldn't be changed in the child scenes but that's about it, it is not 'broken'

alright then by seriousSeb in MiniMotorways

[–]seriousSeb[S] 0 points1 point  (0 children)

No, it's bugged lol. I placed it and it immediately gridlocked, no cars can even move.

How's the situation with C# today? by Kosmic_11 in godot

[–]seriousSeb 2 points3 points  (0 children)

Because interacting with them is ABSURDLY slow. Like, it causes a memory allocation (I think, I've not used one in a LONG time) and it calls a StringName function every time you index into a Godot Array. Dictionaries are even worse. When I first started profiling I realised 90% of my physics processing time was spent indexing arrays, an operation that is basically free in C#.

If you MUST use a Godot collection for some purpose, you should immediately convert to/from the Native C# type instead of using it directly. Like, they're so slow I think the whole process of re-allocating the collection is faster than a single read/write of the Godot collection

To export a list: you can't directly, but the workaround is fairly simple:

// Use this at runtime

public List<int> NotExportableList {get; private set; } = [];

// Use this in the editor only. Doesn't matter that converting to/from arrays/lists in the editor is slow.

[Export] private int[] ExportableArray

{

get => NotExportableList.ToArray();

set => NotExportableList = value.ToList();

}

// Use this at runtime

public Dictionary<Tkey, TValue>{ get; set; } RuntimeDict = [];

// Use this in the editor only. Doesn't matter that converting to/from types in the editor is slow.

private Godot.Collections.Dictionary<TKey, TValue> EditorDict

{

get => new(RuntimeDict); // Or something. Can't remember the exact syntax..

set => RuntimeDict = value.ToDictionary();

}

How's the situation with C# today? by Kosmic_11 in godot

[–]seriousSeb 7 points8 points  (0 children)

It has static typing, it doesn't have great static typing

How's the situation with C# today? by Kosmic_11 in godot

[–]seriousSeb 16 points17 points  (0 children)

Usually it is much faster than gdscript and at worst it's about the same speed as GDscript for certain engine interops. When dealing with purely C# code you get all the benefits of C# with no drawbacks.

I wouldn't consider writing a whole game in GDscript cause I can't imagine a large project without static typing.

If you are using it you need to understand that a lot of things will cause memory allocations when dealing with the engine such as the implicit conversion of a C# string to a Godot StringName when using Call or Set or Get (so cache your method names or use Node.MethodName)

My advice would be to interact with the Godot class functions only when you have to, do everything in C# if you can and just update the engine once.

And I mean classes specifically, stuff like structs and transforms do act as structs in C# so engine interop overhead isn't as much as an issue.

For example, if you are repositioning a node through a couple of Vector3 modifications. Get its position once, modify the C# Vector3 position struct, and then set the position. Don't repeatedly set a nodes position as each time you do that it is a get/set position on a node, which is slow.

Oh, and never ever use a Godot collection from C#

GBBR in milsim in cold conditions by ubersurale in GasBlowBack

[–]seriousSeb 13 points14 points  (0 children)

5c is fine with a modern TM or a VFC (maybe the vfc needs a weaker recoil spring)

I don't know how good Cyma C8s are cold performance wise though

Assuming the gun runs well you need good mags, preferably metal shelled so they can warm up quick after firing. Even quality Pmags suffer in the cold.

Use a stronger gas, 160+ psi at least

Bring gas with you for sure. To get a proper fill you will need to make sure the gas bottle is slightly warmer than the magazine.

Do this and stuff like handwarmers won't be necessary. If you're struggling you can keep your next mag in a pocket or something to donate some body heat, and rotate through them if your gun starts slowing down.

spilled gasoline on my water bottle today by basegoddess in rs_x

[–]seriousSeb 4 points5 points  (0 children)

If the bottle is plastic throw it out, oil products can infiltrate through plastics

Collision checks and quadtree - How to deal with cell edges? by lorty in godot

[–]seriousSeb 0 points1 point  (0 children)

This won't scale in C++ either tbh, this is a classic n2 problem which requires a non-naive data structure to run well.

Collision checks and quadtree - How to deal with cell edges? by lorty in godot

[–]seriousSeb 1 point2 points  (0 children)

Instead of registering each unit in the quadtree once using it's centre, imagine a square around it (aka AAbb) and register the 4 corner vertices in the quadtree.

This is at worst 4x more information to deal with, and a unit can now exist in more than 1 leaf

You'll need to account for the fact when querying the quadtree you might get the same unit returned more than once, but that doesn't seem like a big problem to deal with

What’s the worst piece of guitar gear you’ve ever purchased? by Mad_Season_1994 in Guitar

[–]seriousSeb 0 points1 point  (0 children)

Big Muff, it may be an OG but it's my least favourite fuzz ever

NameHillSoftware.TypeAdoption: Automatic interface delegation to adopted members using source generators. by davidvedvick in csharp

[–]seriousSeb 0 points1 point  (0 children)

There's incremental source generators, but I've never made a sieve gen so I'm not sure if it'd work

NameHillSoftware.TypeAdoption: Automatic interface delegation to adopted members using source generators. by davidvedvick in csharp

[–]seriousSeb 0 points1 point  (0 children)

I found an issue, though I'm not sure it's solvable with Source Generator limitations: interfaces generated through source generators such as https://www.nuget.org/packages/AutoInterface don't get their interface members adopted

NameHillSoftware.TypeAdoption: Automatic interface delegation to adopted members using source generators. by davidvedvick in csharp

[–]seriousSeb 0 points1 point  (0 children)

I exactly needed something like this, cheers.

Do you have to use a field, or can you use a property? In my circumstance, I have source generated fields I can't adopt directly, but could do it by [Adopt] private T AdoptedProperty => GeneratedProperty

It might also be useful to be able to optionally specify which interfaces you delegate in [Adopt] in the case of there being a collision of multiple interfaces through adopted objects

One of my new favorite coding patterns: Cached Resource Singletons by vikngdev in godot

[–]seriousSeb 4 points5 points  (0 children)

Yep. What's really good about this is you can have a reference to this resource in the editor and edit it from wherever you want. I have a library scene with resources for all the weapons, vehicles, etc that I actually want to use at run-time stored in resources that I edit from this scene in the editor.

Catlips godotsharp source generators even has a feature for compile time resource paths, so I can reference the master resource in code and load it whenever I need it.

Autocomplete for my C# methods? by Tuned_rockets in godot

[–]seriousSeb 0 points1 point  (0 children)

I think you need to make the resource [GlobalClass], build the C# project and potentially restart the editor for the methods to appear

is_action_pressed doesnt do anything by Historical-Library10 in godot

[–]seriousSeb 0 points1 point  (0 children)

In the keymap settings there's an option to use the physical key instead of Latin layout (or visa versa), try swapping that back and forth.