Can't harvester just remove the kraken?

[Clockwork13]

I understand why the kraken may be hard to fix, but what if it's just a tiny error in the code? That's what created Heartbleed.

[Bobnova]

I don't think I have ever played a 3d game that involved two entities colliding (you running into a wall, two space ship parts hitting each other, etc.) that didn't have clipping errors every once in a while.

Times when you get stuck in an object, times when object1 is violently ejected from object2, falling through the floor, etc.

Physics engines have limitations, even if you multiply by a million before you do your calculation you're going to run into rounding issues from time to time. If you're lucky the rounding issue will be small enough that it doesn't matter. Usually it is.

Other times, you come back from the calculation to find that one fuel tank is inside another fuel tank. The simple solution to this fuel tank issue is to crash. Nobody wants that, especially not when you're doing things like time compression where you can't check to see if there is an impact constantly.

The next solution is to move the parts away from each other, because clearly they cannot be in the same space. Now the fuel tank that gets moved is inside the engine on the far side of it. That won't work either (crash).

etc.etc.etc.

Eventually most games settle on giving a part that goes inside another part some velocity away from the part it's inside's center, and waiting to see if the problem resolves itself.

Then you just end up with parts violently ejecting each other.

Here's a wonderful example from iRacing (A simulation that is both completed and in constant development with a massive budget and a lot of geniuses):

A physics engine is just a model of the real world. It will never perfect exactly the same way the real world does.

We don't know why the real world behaves how it does, so even given an arbitrarily powerful CPU/etc. we can't model it.

Also, you people need to stop using "kraken" to describe multiple things. It confuses the issue mightily.

If you simply MUST use the word "kraken" please describe exactly which bug you're referring to when you say "kraken".

[LaytheAerospace]

I understand why the kraken may be hard to fix, but what if it's just a tiny error in the code? That's what created Heartbleed.

Sage advice. KSP bugs, unlike other bugs, are probably just caused by "tiny errors in the code." Now that you've pointed that out, I'm sure the developers can have them all fixed by lunch time. I don't think they'd have thought to check in the code for the bugs without your help.

Seriously dude, just stop talking. You have no idea what you're talking about.

[Daid]

Warning: main should return int.

And it's "Hello World!". Don't forget the exclamation mark. And the proper include. (I've seen so many people screw up the "look, you can write bug free code, here is a bug free 'hello world'")

Coding is hard.

[Clockwork13]

Sage advice. KSP bugs, unlike other bugs, are probably just caused by "tiny errors in the code." Now that you've pointed that out, I'm sure the developers can have them all fixed by lunch time. I don't think they'd have thought to check in the code for the bugs without your help.

Seriously dude, just stop talking. You have no idea what you're talking about.

This is about, specifically, krakens. It's usually the smaller bugs that are harder to fix cause you often have to nerf something. That goes with big bugs like krakens too, but I don't think you get that not every bug is some huge combination of 50 code errors and other issues

[LaytheAerospace]

And it's "Hello World!". Don't forget the exclamation mark. And the proper include. (I've seen so many people screw up the "look, you can write bug free code, here is a bug free 'hello world'")

Coding is hard.

I'm not even sure what language that's supposed to be. Looks kind of like C, but missing basically...everything.

#include <stdio.h><stdio.h><stdio.h>

int main() {
    printf("Hello, World!\n");
    printf("This time, it compiles!\n");

    return 0;
}

</stdio.h></stdio.h>

[Clockwork13]

And it's "Hello World!". Don't forget the exclamation mark. And the proper include. (I've seen so many people screw up the "look, you can write bug free code, here is a bug free 'hello world'")

Coding is hard.

Actually, it makes no difference if it's "hello world" or "Hello World!" cause all it does is print a message based on whats inside the quotes.

[Daid]

Multiply by the base ten of your precision, perform calculation, divide by the base ten of your precision. Out of memory? Break up all formulas into single expression operations using just two numbers. This is the standard approach in the finance industry where decimal creep from binary operations would really ruin your day.

I hope you do not actually work on software. As that didn't really make sense. Not to mention you do not want to do odd stuff like that in your software. If you work with big numbers and need 100% precision, you have big-number libraries to do the work for you.

Not that that would for for KSP, due to the whole scaling issue. You can get down to the cm, on a giga-meter scale. That is just hard.

[cpast]

This is about, specifically, krakens. It's usually the smaller bugs that are harder to fix cause you often have to nerf something. That goes with big bugs like krakens too, but I don't think you get that not every bug is some huge combination of 50 code errors and other issues

"Kraken" has no meaning; it is not a subcategory of "bug". It is a term that formerly referred to one bug, which was fixed a long time ago. Any use that isn't that specific bug is worse than useless - you are trying to distinguish between "bugs" and "krakens", and use "kraken" to refer to a class of bug, and that doesn't work. If you start using terms that mean something that everyone can agree upon, you'll get your point across better.

It is indeed true that some bugs are tiny errors in the code. That still doesn't help; before you can fix a bug you have to find out what causes it, and that is normally the hard part of debugging. Some bugs are small mistakes. Others are consequences of design decisions, and fixing them requires redesigning substantial parts of the code (the Kraken, i.e. the specific bug that is the only sort of objective meaning to the word, was in this category - the fix was to zero out position and velocity of the current ship when they went past certain thresholds, and move the universe around the ship). Others are consequences of the unexpected interaction between multiple parts of code. There is no way to know without extensive work isolating a bug, which may be in a section of code that seems unrelated to the symptoms. Isolating bugs is extremely hard, fixing them is generally much easier. But you can't fix them without isolating them.

Edited July 21, 2014 by cpast

[KasperVld]

A stern reminder from my end to stay respectful towards other users. Trolling, harassment and insulting will not be tolerated.

[FleetAdmiralJ]

yes, players fix things that squad implements.

It makes me believe that the squad team has reached their limit. They are not capable to do much more with the unity engine.

Not that the unity engine does not have more to offer, just that they are incapable to do anything more.

And the multithreading was half a joke. But I would not be surprized if someone in this community managed to do that.

They didn't "fix" anything with 64-bit. The modders had just figured out and put a fix out for something that Squad had already figured out but had decided wasn't release-worth yet.

As for multiplayer...I'm not exactly sure you can call the multiplayer mods as they exist right now as a "fix." It's more like shoehorning multiplayer into a game not designed for it. Sure they're cool to play with, but they're buggiest things I've ever used, partly because the base game isn't actually designed to be multiplayer, which is what Squad will be working to fix when it implements the feature.

Edited July 21, 2014 by FleetAdmiralJ

[NFUN]

main()

{

print "Hello World";

}

Java:

public static void main(String[] args)

{

System.out.print("Hello World!");

}

Why is Java so much more complicated in such ways (I know the code can be simplified a little, but this is the basic way).

[Chrisd857]

"Kraken" has no meaning; it is not a subcategory of "bug". It is a term that formerly referred to one bug, which was fixed a long time ago. Any use that isn't that specific bug is worse than useless - you are trying to distinguish between "bugs" and "krakens", and use "kraken" to refer to a class of bug, and that doesn't work. If you start using terms that mean something that everyone can agree upon, you'll get your point across better.

It is indeed true that some bugs are tiny errors in the code. That still doesn't help; before you can fix a bug you have to find out what causes it, and that is normally the hard part of debugging. Some bugs are small mistakes. Others are consequences of design decisions, and fixing them requires redesigning substantial parts of the code (the Kraken, i.e. the specific bug that is the only sort of objective meaning to the word, was in this category - the fix was to zero out position and velocity of the current ship when they went past certain thresholds, and move the universe around the ship). Others are consequences of the unexpected interaction between multiple parts of code. There is no way to know without extensive work isolating a bug, which may be in a section of code that seems unrelated to the symptoms. Isolating bugs is extremely hard, fixing them is generally much easier. But you can't fix them without isolating them.

+1 to pretty much all of this.

And then there are the bugs where the cause is simple, but resolving it conflicts with a number of other requirements. Or the bug exists in someone else's codebase. Or you can never reproduce it (but the person complaining can). Software isn't easy.

[Commissioner Tadpole]

I'm ignorant, how? It's not impossible to remove krakens.

I feel like your post is more ignorant than my posts anyway

Well, I never really said that I cannot be ignorant.

But yes, as someone else has alterady said, my post wasn't in the best condition. Apologies for that.

[HarvesteR]

I'm not entirely sure what this thread is about, or even what the OP is about either... For one, 'The Kraken' is really not descriptive of any bug we know of at the moment.

Also, bugs aren't a thing you can just pick up and remove, or even see clearly for that matter. Most often, bugs are caused by things which aren't happening when they should have, instead of things which do happen when they shouldn't. Even the examples given here are greatly oversimplified compared to the average bugs we get.

I think there is nothing left to say on this. I'm closing this thread before it devolves into something worse.

For future reference though, here's a good rule of thumb for any questions related to software development: If your question contains the words 'can't you just', the answer is automatically 'no'.

(if we could just, we would have done it long ago wouldn't we?)

Cheers