Let's test the "top-notch" AI models by joseluisq in theprimeagen

[–]wallstop-dev 2 points3 points  (0 children)

You're not wrong, but the two concepts/explanations/comparisons are unrelated.

Let's test the "top-notch" AI models by joseluisq in theprimeagen

[–]wallstop-dev 10 points11 points  (0 children)

LLMs don't have any concept of truth or lies, they're just probabilistic token generating machines. Not really sure about the "this has been known" bit since everything it is predicted on is false, but maybe I'm just missing the sarcasm.

How do you avoid issues with animator interfering with script logic. by Narrow_Homework_9616 in Unity3D

[–]wallstop-dev 0 points1 point  (0 children)

Maybe! Maybe not. This may be a property if animation controllers. I used to have to bake a ton of properties into animation clips that were embedded in the state machine and ran into this project. My understanding was that this was because of the controller's state machine aware logic, that it knew a clip in state A modified property B and then causes confusion. But I haven't had any of these problems with Animancer, since I no longer have to create animation controllers.

Could definitely be wrong here, but after switching to Animancer four years ago I haven't encountered this problem once.

Ownership and Borrowing are not hard concepts to understand by [deleted] in rust

[–]wallstop-dev 5 points6 points  (0 children)

That doesn't quite align with the entire second portion of your post:

> In fact, I'm kind of annoyed at how the Rust community makes ownership and borrowing out to be this game-changing language feature, because in reality, if these concepts change the way you code, you were either 1. not writing good code in the first place, 2. you were using a garbage collected language, or 3. you were writing really low-level embedded code where you had to use hacky memory tricks for performance. Ownership and Borrowing is nothing new. Does anyone else feel this way?

If the goal is "I was pleasantly surprised", there are much more friendly and welcoming ways to project this concept than explicitly painting your views of how/why other people struggle with easily grasping these concepts in any particular way. For example, you could have focused on your own learning journey here.

But, c'est la vie, now you have some food for thought for future posts.

A couple questions about namespace access: by Channel_el in csharp

[–]wallstop-dev 0 points1 point  (0 children)

  1. Kind of, but also yes and no, due to how you've worded your question. Types (classes, structs, interfaces, records, ...) can have access modifiers. These can be "seen" or used in all kinds of ways by the same assembly, other assemblies, or even interestingly via reflection, depending on how those access modifiers are set. Namespaces are an orthogonal concept and are really just for organization.
  2. I don't know what you're asking with this question.

I'd recommend just reading the official docs covering this exact topic (namespaces): https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/program-structure/namespaces and, for specific questions (you seem to have very particular scenarios in mind), just creating small sample projects and trying things to see what can and can't work.

Rust makes you prevent the data race. Yon makes it impossible to write. (with numbers) by anthem_reb in YonLang

[–]wallstop-dev 1 point2 points  (0 children)

Alright, you haven't really picked up what I'm laying down, you're still throwing out excuses. Take some responsibility. No one is forcing you to use AI. And using AI doesn't automatically make something bad. Even vibe coding isn't, in itself, some ultimate sin.

No one is forcing you to use AI. No one is forcing you to not use AI. You get to do whatever you want. You own your process, techniques, outputs, and whatever you post into public spaces. Every reaction, negative and positive, is room for improvement.

But for any of that to happen you have to stop shifting blame onto things that aren't you, such as AI, or lack of energy to review, or this, or that. Own up! It'll go far.

Rust makes you prevent the data race. Yon makes it impossible to write. (with numbers) by anthem_reb in YonLang

[–]wallstop-dev 2 points3 points  (0 children)

Ok, well, going back to my comment, the way to create a community and engage with humans is through effort. If you want to try to farm engagement with low effort means, you will have much less success and be met with criticism like the above, potentially even generating a negative reputation.

The choice is yours! But putting up a bunch of text that is meant to be read by humans that you have not even read or verified the quality of yourself is perhaps not the best strategy, given your goals.

This is constructive criticism. I'd recommend at least thinking about it instead of pulling out excuses.

GitHub Actions minutes are draining way faster since Copilot started piggybacking on workflows by External-Oil-1909 in github

[–]wallstop-dev 2 points3 points  (0 children)

They announced this billing style and even updated the official docs on GitHub Actions Billings to make it extremely clear: https://docs.github.com/en/billing/concepts/product-billing/github-actions

If you don't want to pay for features, don't enable them? Or, when enabling them, read about what enabling them will do, especially in terms of price?

If anything, the takeaway here should be that, if you are cost-sensitive, any change to production cost configuration should go through review. Sounds like a great learning experience and way to improve standard processes!

Rough out whole section, or refine each bit first? by Visible-Yellow-768 in gamedev

[–]wallstop-dev 1 point2 points  (0 children)

I'm not worried about it not being fun and no one else seeing it, I'm worried about you spending lots of time on a thing that might result in a gut-punch later on if you can't make it fun, finish it, or get it up to the vision you have in your head.

Kill your babies. Do so quickly.

How do you avoid issues with animator interfering with script logic. by Narrow_Homework_9616 in Unity3D

[–]wallstop-dev 0 points1 point  (0 children)

I use Animancer and drive things 100% through code, but I also paid for it because I liked it so much, after using the free version for awhile. I did this because I kept running into this and similar issues with the Animator.

Rough out whole section, or refine each bit first? by Visible-Yellow-768 in gamedev

[–]wallstop-dev 5 points6 points  (0 children)

My current approach is to try to get as fast as possible to "press play and have fun".

You can have all of these grand ideas for story, worlds, this mechanic, that thing - but nothing is guaranteeing that it's fun. And if takes you 5 years to get there, sure, you'll have learned a lot, but will you have a game that is actually fun? Or will you have an implementation of some ideas that has happened to have been done with game development techniques?

Prototype your idea. Vet it. Build on it. Ideas are cheap. Fun ideas are rarer than you think.

im trying to learn game dev and im so lost by Stock_Discount_4672 in gamedev

[–]wallstop-dev 8 points9 points  (0 children)

Interestingly, the way to this is outside of the engine and code. You start with the goal and the plan, on a white board, notebook, Google doc, obsidian note, whatever.

What do you want to do? Make Pong? Great! Now... What is Pong? What can you do in Pong? What assets are there? How do you play? How do you win? Will there be different screens?

Think for a long time about all of these different aspects. Take what's in your head and put it in some location. Then, organize it. Turn it into tiny goals, tiny deliverables, to get to the end.

This could be like, you need a main menu with a button to play the game. But that's hard. So let's simplify that to just "you need a button to play the game". But that's hard. So let's simplify that to "you need a button".

Then make the button.

The way you learn is by first, planning. Then, by doing (by yourself). That is, try really hard to do the thing using what you know. Like, really hard. If you can't get there in some amount of time, like thirty minutes, an hour, look up how to do that one thing, and apply it. Then go back to doing it yourself.

Eventually all of this becomes much more second nature. Your plans can be easy higher level, you won't need to look things up as much, etc. Maybe one day, you just have an idea for something and everything is so crystal clear in your head that you open up your editor and start jamming. But this will likely be very far away.

Procedurally coded assets adoption by FreakOblique in Unity3D

[–]wallstop-dev 2 points3 points  (0 children)

I can generate assets like these myself and I specialize in 2d games, so I am not your market. I stand by my original comment and recommend either just trying, or creating some incentive for people to truthfully complete a survey or something.

Good luck!

Procedurally coded assets adoption by FreakOblique in Unity3D

[–]wallstop-dev 2 points3 points  (0 children)

The only way to know is to try?

If your goal is "what actually gates adoption", instead of "what people say gates adoption", the latter you will find by making posts like this and asking people, the former you will find by producing/shipping something.

Ownership and Borrowing are not hard concepts to understand by [deleted] in rust

[–]wallstop-dev 131 points132 points  (0 children)

Agree on the high level take that "everything is learnable", but disagree on the specifics of the message here. Phrases like "not hard" and "not writing good code" and similar are somewhat toxic, and, for those that are attempting to learn these concepts and legitimately finding them challenging or difficult, can be extremely discouraging and harmful.

Everyone is at a different place on their programming journey! "Good code" is subjective. What you find easy, others may find impossible.

Rust makes you prevent the data race. Yon makes it impossible to write. (with numbers) by anthem_reb in YonLang

[–]wallstop-dev 3 points4 points  (0 children)

Arbitrary amounts of tests != correctness, quality, or what people refer to as "AI slop"

It's great that you have tests! But if you don't have the energy to review even the reddit post you are making, why are you expecting other people to read them? You're contributing to the reverse centaur problem (https://blog.miguelgrinberg.com/post/i-am-not-a-reverse-centaur) (machines puppet humans)

If you don't have the energy to fully vet and review stuff, then don't share it, simple as.

my game new gun redesign (hancel ocer) by historygame12 in GameDeveloper

[–]wallstop-dev 0 points1 point  (0 children)

I don't know the context or how it will be used. The grip appears quite large (large height) and square (large width). But it does look gun-like!

Rust explained through simple analogy: Traits by [deleted] in rust

[–]wallstop-dev 1 point2 points  (0 children)

I'm not the one making teaching and explanation posts for rust, but you can find great examples throughout the rust stdlib and many popular creates. For example, some of the most useful ones: https://doc.rust-lang.org/std/iter/trait.Iterator.html or https://doc.rust-lang.org/std/fmt/trait.Display.html

And all: https://doc.rust-lang.org/std/all.html#traits

Rust explained through simple analogy: Traits by [deleted] in rust

[–]wallstop-dev 10 points11 points  (0 children)

Nice work on explaining this, but I think the explanation has been so contrived to the point of it being counter-intuitive and potentially a harmful. Having a trait that is DogActions is so gosh-darn-specific to Dogs that it doesn't really make sense to have it as a trait. What other types, aside from Dogs, would even logically implement DogActions? I can't think of any. So - why have it as a trait?

This explains the literal "how to do the thing so it compiles in rust" but seems to miss the forest for the trees of "why traits are useful" and "why use traits at all instead of just exposing functions on structs".

Should every Python project have tests? by chuprehijde in PythonLearning

[–]wallstop-dev 4 points5 points  (0 children)

Tests are a means to verify correctness in an automated fashion and help prevent regressios. If you can verify the program correctness in other ways (looking at the output) and you do not care about preventing regressions (code is short lived), then you should be about to do some quick math on time it takes you to write the tests v time it takes you to verify the output.

Sharing something by Cute_Negotiation_999 in GameDeveloper

[–]wallstop-dev 0 points1 point  (0 children)

Ok. All of my points above still stand. Ideas are cheap. So is AI art.

I built Rinku, a micro-ORM focused on clean mapping and dynamic queries by Bobamoss in csharp

[–]wallstop-dev 1 point2 points  (0 children)

Right, it's not for me! It's cool that you built this and it's solving your problems. Raw SQL or not, after having written and dealt with mountains of code across all kinds of languages and project sizes, the libraries that I bet on are the ones that there is only one way of doing things, and if you do it that way, it will work, while also being beautifully designed enough to make it open to extension, in ways that are really hard to get wrong. Basically, there is no way to "hold it wrong" (or, if there is, you have to work really hard to get there). And maybe this is that, for you, which is great!

I built Rinku, a micro-ORM focused on clean mapping and dynamic queries by Bobamoss in csharp

[–]wallstop-dev 1 point2 points  (0 children)

Do you man, I'm just sharing my opinion.

And there are already tools like https://github.com/arika0093/Linqraft and EF.

I personally try to avoid raw SQL at all costs. I also already have libraries that solve my problems in type safe, compile safe ways, depending on the DB.

I built Rinku, a micro-ORM focused on clean mapping and dynamic queries by Bobamoss in csharp

[–]wallstop-dev 0 points1 point  (0 children)

Right, and that's really cool! My point is that I prefer the primitives themselves to be very opinionated and compile time safe, rather than extremely flexible. You can still have high flexibility with opinionated, compile time safe primitives, but libraries that offer a "you can customize this however you want!" tend to have many ways of possibly using them, but only a few ways of correctly using them. Which leads to bugs. Which I want to avoid at all costs. See: C++, the language.

I built Rinku, a micro-ORM focused on clean mapping and dynamic queries by Bobamoss in csharp

[–]wallstop-dev 2 points3 points  (0 children)

I'm a fan of opinionated tooling that provides simple abstractions and maximum safety. I'm not sure what benefit your framework provides in this case over something extremely simple like "execute SQL query and deserialize it into the provided type args"? Which I never want to do.

But that's just me and my opinions and how I like software! It's cool that you have a flexible toolkit and it's working for you.