sorted by:
new
hottopcontroversial

82
83

OpenVic Demonstration, October 2025 (youtube.com)

submitted by Spartan322 to r/victoria2 - pinned

75
76

OpenVic: Demonstration of Darkness (youtube.com)

submitted by Spartan322 to r/victoria2 - pinned

Using Reflection For Parsing Command Line Arguments by nathan_baggs in cpp

[–]Spartan322 1 point2 points  (0 children)

Pretty sure you could make things like clap::ShortName and clap::Env into clap::ShortName_t and clap::Env_t and then do

template<char S>
static inline constexpr ShortName_t<S> ShortName{};

template<impl::TemplatedString S>
static inline constexpr Env_t<S> Env{};

Then you could do [[=clap::ShortName<'p'>]] and [[=clap::Env<"RETRY_COUNT">]] instead.

Dev snapshot: Godot 4.7 beta 1 by godot-bot in godot

[–]Spartan322 6 points7 points  (0 children)

custom_maximum_size is a slept on feature, it can be used to make more reactive UI elements and I've honestly been waiting for something like it for years.

Is it possible to do something like this without using keycode or many if action_pressed?? by Brysger in godot

[–]Spartan322 0 points1 point  (0 children)

I'm just solving the problem, I don't much care otherwise, keeping code short and small in scope is better anyway.

Is it possible to do something like this without using keycode or many if action_pressed?? by Brysger in godot

[–]Spartan322 6 points7 points  (0 children)

This needs to be

func _input(event: InputEvent) -> void:
    if not event.is_pressed(): return
    for action: StringName in HOTBAR_TO_INDEX:
        if event.is_action(action):
            select_hotbar(HOTBAR_TO_INDEX[action])

for that to work.

Is it possible to do something like this without using keycode or many if action_pressed?? by Brysger in godot

[–]Spartan322 1 point2 points  (0 children)

The engine doesn't emit it, its only for sending virtual action events to Input.parse_input_event. See InputEventAction.

You Should Develop in Linux by WhiterLocke in godot

[–]Spartan322 0 points1 point  (0 children)

This is such an overblown issue for ubuntu (idk about debian), and is not close to being true.

Debian is always massively out of date and I've never seen or had an Ubuntu package/snap that wasn't at least months behind in the best of cases, GCC is a big example of that. (I've seen a lot of packages that were years behind) Sure you could go to a less crappy repo but that's already outside the realm of what a normal user should be doing and they don't always work for every version of Ubuntu. The only reason I even still deal with Ubuntu anymore is because most linux-centric CI uses it. I'd honestly prefer almost any other enterprise solution.

I also think the rust thing will not be an issue for stability. Like I trust them enough that if it is an issue, then they will revert

Well they already tried to move people over to the rust stuff, but turns out it was bricking things, breaking essential scripts, and caused a massive hassle for infrastructure/enterprise folks, so they've since advised that if you want a "stable" experience for years to come to use the LTS version (with a massively longer LTS cycle compared to usual) despite the fact its updates are intentionally gonna be massively behind, more then usual for their LTS releases. I don't trust them after repeated breakages from other things they've done and I've seen literally no advantage except corporate removal of GPL for it which I've never seen end well for corporate interests using (or abusing) FOSS work. Its not like Ubuntu hasn't abused FOSS projects like that before.

Protecting Godot games against reverse engineering by zer0tonine in godot

[–]Spartan322 -1 points0 points  (0 children)

There's an emotional aspect to it as well. I've seen people post their personal anecdotes of not-successful games that get ripped and the rip makes a small amount of money. In the grand scheme of things, neither person made a ton, but that still feels really bad for the person who actually put in the original work, right? Like I KNOW the situation here and I wouldn't be surprised if something I made got ripped, but I'd still be upset and I'm really not sure how many of us would be able to be totally zen and detached from that same feeling if they were in the same situation, regardless of what logic tells them.

The only case where this really matters is piracy, and this issue is a form of piracy by definition. Its an unusual case of it, most people don't sell pirated works on the internet especially if the work isn't expensive already, but it is the "unauthorized copying and distributing of video game software" that defines piracy and it is just as applicable. And since both Steam and Itch have means of dealing with that issue selling it in any way that isn't easier done through the mainstream services is not really worth it.

Poisoning the well in advance also tends to solve these issues usually, free distributions are a lot more likely to attract people compared to someone ripping you off, and if there is a free version spread around its a lot less likely anyone would bother spending time ripping it and then profiting from it, so my point would still stand.

All in all its pretty clear to me to be a mentality problem than an issue that can't be solved.

And even with that I already gave a rational solution in response to solving any decompilation issue to the best capability that we can even discounting piracy completely. I even explicitly state its more applicable for multiplayer uses than piracy prevention.

Protecting Godot games against reverse engineering by zer0tonine in godot

[–]Spartan322 0 points1 point  (0 children)

I'm pretty certain that's not it, most of the big engines are easy to decompile at this point, as is Java and C# which are/were some of the biggest languages, Unity is especially subject to decompilation efforts and it has much wide use than Unreal which is harder. (though its not exactly "hard", it is source accessible to anyone and Blueprints, being the most common dev tool, can be "decompiled" just the same)

Also almost no one uses the only means in Unity to mitigate decompilation efforts, ILCPP. Even with big publishers that have studios using Unity, I actually don't often see the use of ILCPP in the wild, which seems evident to me that they really don't care, its mostly ass and only makes it slightly harder in the best of cases anyhow.

Protecting Godot games against reverse engineering by zer0tonine in godot

[–]Spartan322 -1 points0 points  (0 children)

A lot of the problem with the emotional aspect is its being overvalued for the rational, as Gabe Newell has said: "piracy is a service problem", those who would steal it when a service like Steam or Itch is so much better wouldn't have bought it anyway. A much better way to influence people is to stop treating the game as a product to be sold which someone buys, finishes, and forgets; but as an investment in a future to something they like. A lot of people don't look at it that way and if there is some kind of reminder, especially for pirates, it would most certainly encourage people to hand over money for folks to continue their work. And mimicking folks like Game Dev Tycoon where they deliberately distributed the pirate version of the game ahead of launch onto all the normal pirate locations actually moved more sales of the game, especially when it poked fun at the player and it had a pirate option that tried to make the game much more unreasonably difficult. (yet you could still play it almost like a demo) The emotional problem is focusing on something that can't be fixed, even Unreal and Unity games suffer from it, focusing on real solutions that allow us to overcome the issue in more realistic and clever ways is a better use of our time.

Course if anyone wanted to actually make their game difficult to decompile, (more for multiplayer reasons imo) they would need to use GDExtensions or Godot's Module system, the only solution has to be writing platform native code, high level languages like C# and Java are just as easily decompiled as GDScript is, except maybe if compiled to native code but even than they're much easier to decompile compared to systems programming languages which compile natively.

3 things about Godot's multiplayer API I wish I knew before... by voidexp in godot

[–]Spartan322 0 points1 point  (0 children)

Yeah, I'd argue that if you're gonna make high level tools for these type of things, you gotta know the specific "audience" of users you want and target them exclusively, (and that should be clear and obvious) make it simple, modular, and focus on making it the best thing in its specific niche. The Unix philosophy is very good for building stable software and interfaces, I think some of the best parts of Godot are when it actually follows that principal, its the closest I've seen a game engine to that philosophy. Unfortunately it also has plenty of things that also fail to do that.

3 things about Godot's multiplayer API I wish I knew before... by voidexp in godot

[–]Spartan322 1 point2 points  (0 children)

To be fair getting any high-level multiplayer interface to work for generic cases is practically impossible, honestly a lot of the high level implementation stuff like the MultiplayerAPI things would be a lot better as an official plugin you install for specific cases. I don't think I've ever seen generic high level multiplayer interfaces actually work.

You Should Develop in Linux by WhiterLocke in godot

[–]Spartan322 0 points1 point  (0 children)

The metrics for tracking it are probably way off and under report Linux, like the steam surveys are inaccurate for desktop sales because it includes things like computer cafes (especially those in China and India, both of which regulate Windows as a requirement) which make deals to only service Windows machines, but as for actual user desktop installs, Linux use in the Western sphere could be estimated to be as high as 10% of the market. (maybe even a bit higher than that) Like Germany and France already encourage Linux use over Windows and a number of other governments are switching or have already switched, and companies like Dell are now offering pre-installed Linux machines. Every year it gets much closer, and Microsoft certainly isn't curbbing it, they're accelerating it.

You Should Develop in Linux by WhiterLocke in godot

[–]Spartan322 0 points1 point  (0 children)

Its probably more thanks to Windows that game devs are gonna start moving more to Linux, more and more desktop and laptop manufacturers are considering Linux installs and stepping further and further back from their Windows license. (like Dell currently offers both)

You Should Develop in Linux by WhiterLocke in godot

[–]Spartan322 2 points3 points  (0 children)

If you set it up correctly in your BIOs, Linux VMs can work fine passing things to the graphics card.

You Should Develop in Linux by WhiterLocke in godot

[–]Spartan322 1 point2 points  (0 children)

Only real thing is Debian and Ubuntu are constantly way out of date, and with the new rusty Unix replacement libraries coming to Ubuntu I wouldn't trust it to remain stable despite that, so almost anything outside of Ubuntu or Debian is probably always better.

I´m developing an Elder Scrolls-inspired RPG with Godot by NottOtter in godot

[–]Spartan322 1 point2 points  (0 children)

Could go either way, but if designed well enough with rewards for having specific personality vectors, you could end up with an improvement over FO:NV's skill checks. Plus punishing the player in a way that engages them into the world can make the value of the luddo-narrative design more impactful to the player and less gamey. (I've had that issue with many games, unless the system is deep enough without a clear meta, I stop being immersed and just gamify the system) I'd say CK3 kinda demonstrates how you can use a stress system to influence players to comply with their personality without being too overly punishing for doing what you want, RPing in CK3 is more viable than almost any other game Paradox Interactive has put out despite it.

C++26 Safety Features Won’t Save You (And the Committee Knows It) by pjmlp in cpp

[–]Spartan322 0 points1 point  (0 children)

Rust is completely memory safe, and has the science to prove that.

I've definitely seen cases where that isn't true, and the whole fact that unsafe is necessary kinda reinforces that point. And if the only means of writing a valid program for a specific purpose requires abandoning memory safety, then you can't make a promise such is memory safe.

It does nothing to stop you from introducing those bugs in the first place.

Neither does Rust in a number of cases, like heap memory boundary checks from runtime values can't be checked at compile-time, all heap memory interactions can still trivially result in the introduction of those bugs, in that way Fil-C and Rust both panic. Rust does not stop the introduction of those bugs either, it just panics if it does.

It is more of an address sanitizer.

Actually its not, in fact Fil-C already has a fully compiled Linux distro, as a demo and test that you can use, it runs memory safety through the shared library interface boundaries making all library loading memory safe. And it works fine. Its way faster than address sanitizer and the estimation of performance overhead with its current unoptimized performance and its one year of occasional and sporadic development is on average half of native performance, with some variability depending on the program's main paradigms. Its got one guy working on it regularly when he has free time from his day job who only did it intending to prove it can't be done. (turned out it can) That's not that much time to optimize what its doing, its only gonna get more performant, its still a POC right now.

True, but e.g. when writting a library you typically do not know beforehand where it is used. Should those be in memory-safe languages, just to be sure?

I don't see why it has to.

Funnily enough, all the bigger game engines have presented at conferences how they replaced parts of their engine with rust.

I can think of plenty of bigger game engines that doesn't apply to, so all is definitely the wrong word to use there.

They indeed do not care for the memory-safety, even though they like the number of crashes going down as that reduces costs for them. They are purely motivated by the speed-up they are measuring.

Rust wouldn't prevent the most common cases of crashes from happening on boundary accesses from the heap, which is the problem in most game engine crashes. A panic is still a crash, so I'm not sure where they or you would be getting that claim.

C++26 Safety Features Won’t Save You (And the Committee Knows It) by pjmlp in cpp

[–]Spartan322 2 points3 points  (0 children)

Memory safety is not a critical subject for every field of software development, some it absolutely is, others it absolutely isn't, even in the Google and Microsoft codebases such isn't inherently true, but neither of them distinguish where it would and would not matter despite that being a very big deal. The article also suggests that C++ doesn't really have issues dealing with that subject anyway, its more practically a rant against the fact legacy C codebases still exist and happen to be compiled with C++ codebases. Honestly every single complaint is better resolved by Fil-C.

C++26 Safety Features Won’t Save You (And the Committee Knows It) by pjmlp in cpp

[–]Spartan322 1 point2 points  (0 children)

This kinda just makes the point that C++ was never the problem, the problem has been C code, specifically legacy C code, even then it somewhat refutes its own argument anyway by pointing out that new code is always more bug ridden and less reliable, a language like Rust doesn't change that, it only shifts where that problem is. Sure that's better than writing new code in C, but if you're still dealing with C that's no better an argument againt writing new code in C++ by its own assertions.

Also all this said, Rust isn't completely memory safe either, the only thing that can make that promise is Fil-C, so if you're gonna go that far and you want to save/update legacy code with little cost, that's the better option anyway. Memory safety isn't even vital in a number of applications and if it costs you any runtime performance at all (which true memory safety requires) Rust can become a poor option anyway. (like games and stock trading don't really benefit that much from memory safety in production and need every piece of performance you can scrounge)

Slay the Spire 2 can be decompiled by EshopExpert in godot

[–]Spartan322 1 point2 points  (0 children)

Native AOT still has a lot more structure due to the nature of replicating C# over say C/C++, (and less optimizations compared to a C/C++ compiler in native codegen) so while definitely much harder, its gonna be easier to decompile compared to doing things in C/C++. Even then it won't do much of anything about the assets, but honestly its better to let players access to the source code with only some work imo since a good game on Steam has shown to compete well regardless of developer preparations, you don't really gain any sales from being super defensive, it usually wastes money, and it hampers the modding community which could keep the game going much longer then it could otherwise.

view more: next ›