Thoughts on answering/fixing AI LLM-created garbage code?

Endianess typically happens on the cpu architecture level. Little endian effectively won back in the 90s so pretty much every box you can run Godot on will be little endian. And rightfully so because big endian is, well… rather stupid.

3 Likes

As if it were different in the era of quick googling + asking idiotic questions on StackOverflow :slight_smile:

Intrinsically AI has nothing to do with the inability of certain people to learn. Replace ‘AI’ with ‘book’ , ‘the Internet’ or whatever medium humanity has ever invented to facilitate learning - people will always seek shortcuts and only seek help if they are stuck. It’s human nature (“satisficing”) that doesn’t have anything to do with the medium .

To write a function in a strictly formalized language with a formal and openly available documentation is very different from writing another “War and Peace”. If it can be standardized/formalized/”algorithmized” - it can be done by machine. You can’t fight progress, but you can adapt.

Best quote Jensen Huang here: “You’re not going to lose your job to an AI, but you’re going to lose your job to someone who uses AI.”

1 Like

There’s an assumption here that is incorrect. You assume that there’s as much out there on GDScript as there is on C#, Java, C++, etc. There is not. In fact, this forum is one of the largest documentation sources that LLMs pull from. I know because I’ve asked them questions, then googled the question, and found pages that they basically ripped incorrect answers from verbatim. LLMs also much more often make up function names for GDScript that just don’t exist. They also suggest solutions that don’t work because LLMs only know how to code - they don’t understand for to use the Godot editor and provide a solution that already exists using Godot features.

Since LLMs mainly scrape this forum to answer GDScript questions, the more that incorrect AI-generated code is posted here, the more it will contribute to model collapse.

You cannot compare “all languages” with GDScript. They do not perform the same in LLM output.

Unless we hit AI winter number three of course..

1 Like

You didn’t really answer my question. The influx of stuck people has increased since this whole fashion of “learning” using “ai” came about. So it’s not “same as it ever was”.

Parroting “ai” corporate propaganda points from mid 2023 like “adapt to progress or die” or quoting Huang who’s probably the epicenter of the financial bubble - is just bad form, bro.

Isn’t the whole advertised benefit of “ai” that it’s trivial to use? No skills needed? Why would you present “adapting” to such a thing as some sort achievement attainable only to vanguards of progress, when it’s really meant to be sold to halfwit masses.

Dude, for anyone with software development experience “adapting” to “ai” is utterly trivial. There’s nothing for us to adapt to here. If I want to automate writing of a boilerplate function I can utilize an LLM better than you, because I can more easily see where it fucked up. I can also prompt better because I know all the relevant concepts. Framing our criticism of “ai” as some imaginary incapability to “adapt” is just silly. Our criticism is well informed, in contrast to your blind acceptance.

The people getting started have much more to lose relying mainly on “ai”. They get tricked into believing the “ai” is doing more for them than it really does, both in terms of learning and in terms of automation. The automation is full of errors and the learning boils down to collecting forgettable “how to” recipes.

4 Likes

It’s also quite funny quoting a guy who recently stated that AI “no longer hallucinates”.

2 Likes

From the above article:

But this distinction is anything but trivial. Hallucinations aren’t a bug you can patch away. They’re a byproduct of the probability-based architecture language models run on. This is exactly what makes companies slow to adopt AI: unreliable outputs, the need for human oversight, and unresolved security issues.

He builds the hardware and has a vested interest in people buying his hardware. But his company doesn’t actually make AI. So he is not, in fact, an expert on AI. He’s a Sales-CEO like Zuckerburg, Bezos and Musk.

4 Likes

“Parroting propaganda”, "bad form”, “better than you”, “silly”, “blind acceptance”.

Very civil, indeed.

Are you so out of counter arguments that you need to resort to desperate attempts of tone policing? By plucking individual words out of context no less? Let me return the favor:

“idiotic”, “crap”, “you’re going to lose your job”, “pearls of your enlightment”

4 Likes

Everything an LLM outputs is a hallucination.

4 Likes

Only way people are going to lose their jobs to AI right now is because their employers is unintelligent, lazy, or cheap enough to decide to “replace” your job, or make your job worse by making you do more work for less and with fewer people

Just like how self-checkout made things worse for people working in grocery stores, not actually replacing them just resulting in fewer people working the same amount of other tasks, or supervising the new feature (in the case of self-checkout, whenever it messes up, with AI having to go through all its crap output)

4 Likes

I have an excellent example of this from this morning.

Following a post from dragonforge:

I looked up what these endian’s were. A nice read.

Then I asked AI:

How can I check if godot is bigendian or littleendian?

It answered correctly enough and then gave me a function that does not exist.

Godot itself doesn’t have a “project‑wide endianness,” because it always uses the platform’s native endianness. But you can check it easily from GDScript or C++.

In GDScript
Godot exposes a simple constant:

gdscript
print(OS.is_big_endian())

So I responded with:

ERROR: res://testing.gd:4 - Parse Error: Static function “is_big_endian()” not found in base “GDScriptNativeClass”.

And it said:

Ah, that error tells me exactly what’s going on — and it’s a really common Godot “gotcha.”

Then went on to tell me:

Godot 4 exposes endianness through the PackedByteArray helper:

gdscript
var is_big = PackedByteArray().is_big_endian()
print(is_big)

Which is, of course, more nonsense.

Thanks AI. Really helpful stuff there.

I eventually came up with this:

func _ready() -> void:
	if is_big_endian():
		print('Appears to be Big Endian')
	else:
		print('Appears to be Little Endian')

func is_big_endian() -> bool:
	var x: int = 0x1 
	var arr := PackedByteArray()
	arr.resize(2)
	arr.encode_u16(0, x)
	return arr[0] == 0

Although with only limited knowledge of encode, packed bytes and hex ints I am not certain this works (I can’t test it on a BigEndian machine) so it appears to work. (Thats an hour of my life I won’t get back :slight_smile: but an interesting distraction.)

3 Likes
func is_little_endian() -> bool:
	return var_to_bytes(true)[4]

Reducing “ai” LOC by 400%

Although neither of those functions will test the endianess of the underlying cpu architecture. Godot’s binary serialization API always encodes in little endian, as stated in the docs.
You might as well do:

is_big_endian():
	return false
4 Likes

It may actually be impossible to test for endianess in GDScript. You’d need to write a GDExtension. Doing it in C is just a matter of casting an int pointer to a char pointer:

bool is_little_endian(){
    int x = 1;
    return *((char*) &x);
}

It’s a great example of why some languages are considered “low level”.

I was digging a bit and it turns out there’s only one place in GDScript that “knows” the system endianess. It’s FileAccess::big_endian. So the proper function would, oddly enough, require opening a file:

func is_big_endian() -> bool:
	return FileAccess.create_temp(FileAccess.WRITE, "endian", "test").big_endian
4 Likes

Well, Human arent AI and we arent a tool.

so as long as they asked nicely and try to be helpful too.

i think we are ready to help when we have time and energy.

yeah.. depends on their attitude, effort, and our availability.

If it’s this question here: Hey may I get sequrity related advice 😄? please don’t hijack this thread. I just added my own answer to your thread.

If you want to talk about AI related to that, well the answer is that AI can tear your game apart really fast. You cannot stop it. Stop worrying about it.

5 Likes

No this one is different..

I just want to ask.. if we pre define the number of functions, works and system in script to system and Also specify the number of codes and code lines with functions and Their limitations. And make command that of system sense anything outside of These all declaration then shut down the app or game..

Like in case someone try to break the encription while exe file is running??

I realize this thread has gone a lot of places, but even the really weird things are because someone said something that was related. You’re just hijacking the thread and asking an unrelated question. That’s poor forum etiquette.

That question is the same question from your own thread, slightly modified.

But I will answer it. In your thread.

6 Likes

Ok.. sorry. I was not familiar with this kind of hijacking techniques. Or whatever you say.. .. I will make sure not to do this next time.

1 Like

In this context, the term hijacking means to take something that is not yours (the thread) and use it for your own purposes.

4 Likes

Be careful here - moderation is very selective in which posts they delete. They will never delete the posts of “good guys” (in their view) regardless of how provocative their posts are.