Not a Question but a tutorial(Kinda)

I am sure anyone who uses akice knows the recursion memory leak issues. I have just found a work around that does not triger the memory leak. What you do is have 2 copys of a method linking each linking to the other copy. It is a endless loop without using a loop or using amethod that leaks memory. I found this out doing an experiment with endless loops today.

[x2495iiii]

How do you know it doesn't cause a memory leak? It's still a computer process which uses processor power, which typically causes memory leaks when used in excess in Alice.

[jediaction]

I have no diea what you king Gamer just said

Ok, I will make an example.

Method 1 Code
increase world.variable ++ 
print world.variable
[METHOD 2]
Method 2 Code
increase world.variable ++ 
print world.variable
[Method 1]

If you run the methods it creates an infinite loop. To adress X it obviusly creates some leak but doesn't create the infinite loop and while leaks.

[x2495iiii]

Well, I suppose if there was a copy of Alice that glitched when while statements were used it could be useful.

Originally Posted by King Gamer(gorit)

I am sure anyone who uses akice knows the recursion memory leak issues.

Are you saying that Alice does not deallocate the memory after closing a running world, or that your running world crashes after a while when using infinite recursion?

[x2495iiii]

Originally Posted by flats

Are you saying that Alice does not deallocate the memory after closing a running world, or that your running world crashes after a while when using infinite recursion?

The second one. Alice is infamous for getting clunky and slow when too many complex infinite loops are used.

I'd love to see someone test this and see if using several complex commands with this iteration method doesn't cause lag.

I do have to admit it has not been thourgholy test it and I am going to use this in my comp game. I think it may experience minor lag when going from method to method but will not make the glitchs that occur with infinite loops.

Originally Posted by x2495iiii

The second one. Alice is infamous for getting clunky and slow when too many complex infinite loops are used.

This isn't a even really a bug. Unless you really know what you're doing, you shouldn't ever use infinite recursion.

In short, there's a special bit of memory called the Call Stack that every program gets. The call stack keeps track of what the program is doing, what methods called what, so the program knows when to hand control to what bit of itself.

Imagine you have a ball of red thread - that's your call stack. Every time you talk to a friend, you hold the end of the string and hand them the ball. If you finish your coversation, the friend hands you the ball back. If you get interrupted, you friend holds onto a bit of string, hands the ball to the person that interrupted him, and they start talking. Then there's another interruption, and the string gets passed again.

The first case is a normal method call. The second is a recurive one. If your friends keep interrupting one another, eventually you'll run out of red string to trace the conversation back to how it started. This is a stack overflow, which is why Alice crashes when you use infinite recursion.


In general, if you can write a method just as well (or even almost as well) without using recursion, you should. A computer will always be better at a while loop than a recursive method.

[x2495iiii]

I was actually talking about infinite loops, not necessarily recursive methods.

The problem is that some program elements require infinite loops. For example, RP has an infinite loop for the zombies' motion. This is because unless the game is paused or if you've won, the zombies have to keep moving. Another example would be collision detection, which has to constantly monitor the distance the moving object is from other objects in order to prevent the moving object from passing through other objects.

True, there are ways to limit the times which loops are used, like only having certain collision methods kick in when the moving object is reasonably close to a certain object, but otherwise certain elements of game-design require infinite loops.