Bug: The max loop limit can no longer be avoided serverside with a sleep.
 

In the past, this code would not have hit the max loop limit because of the sleep.

Now, the loop limit is hit on the next iteration after the sleep, regardless of the length of the sleep; the result is the same with a 0.1 second sleep and a 10 second one.

This bug exists on at least Era Dev, Era, and Kingdoms Debug.

I encountered this problem on Classic too.

I've never received a max loop error. Is that anything similar to how php breaks when it takes to long to execute a script? and times out?

or what exactly causes this problem? 1000 loops?

10,000 by default. I don't know exactly how it works, Stefan's said it's more complicated than just loop counters, but basically a loop exceeding 10,000 iterations is halted and the entire script stops.

Bump, also seems to happen clientside.

Is this of the same problem?

I added more for loops because it use to be only this.tempStaff, and 20 strings in the array..

Then the original code only had this one else if for loop checking through the staff. :/

It would then say there was an error in the RC but the level editor still worked.. I didn't really know how to fix the problem but to split the work out into different else ifs...

It still doesn't work all that well but does work.
Sadly, I think the RC will state a lot of errors, but the people will not know...


Is there a way to fix this, or is it the same error as everyone else?
I tried to fix it, but I thought the problem was going through all the arrays..
It just says reached a loop limit at 0, 0.

Original (20 people / levels)




Code now.

No, it's because you're attempting to use the same 'i' variable within loops contained within loops, which basically resets the first loop back to 0 and repeats infinitely until the engine cancels it.

The rest of the code is also terribly inefficient, can be accomplished by much easier means, and it doesn't really make sense that you're defining this. variables as if they're a temp. variable while using a prefix in the name. Those arrays should be set one time onCreated.

Oh boy

e: You could also forgo the scheduleevent, but triggers have their own per-frame limit (10 or so).
e2: but at least if you do it will fail silently! :D

Ahh, didn't see the same 'i' being used, I'll have to add temp later.
My much easier means that I thought of was doing the .index() but I didn't know how. ^.^; didn't feel like bothering you so I did it with a for loop.

Also, they are temp since most of the staff will be deleted after the LAT contest. o.O; I put temp for my own purposes.


I believe this was all I had to do. ^.^;;
I don't know why I used 'i' twice. Late at night I do stupid things.
Added temp. as well, not sure why I left that out either.
Thank you all, lets see if it works on the fourth. o.O;;
I guess my problem was stupidity and drowsiness.

-EDIT-

However, my friend is trying to create a baddy using a specific algorithm and he is having problems with maxing out the loop only if he doesn't add a sleep .05 in..

I believe he wants something like an onTimeout calling an onTimeout right after the end of checking... Perhaps that is the same problem? I don't know. I doubt he will post on the forums though..

Do you realise you have 2 conditions which are exactly the same?
If you were to remove the first line of player.account in this.tempStaff, it would still work.

player.level is an object rather than a string, the correct value to check is 'player.level.name'.

It's a bad practise to loop through non-changing arrays and use .size(); for every cycle, as the function will occur every time rather than once, this can generate a lot of overhead with very large arrays. The array size can be defined as a temporary variable beforehand, which can then be used in the loop condition.

onTimeout(); occuring within function onTimeout(){} without any specification for it would run infinitely until cancelled by the engine/NPC-Server.

Yes, I did that so if the first part didn't check, it wouldn't have to do the for loop, I assumed it would speed up what ever else it is doing if the first part was not correct.

The second part is only to add +1 to whatever the i is for the level, which I believe I could do with .index() but don't know how...


I have been told this many times, and I still don't quite understand it since the results are always the same. :[

for instance temp.num = something.size(); and stick that in the loop?
I shall do that!

I'll ask you later, he says it does not work but I don't know what he had done. All I know is he had many loops inside of his and said it kept maxing out or something...

He is not on for me to ask. :[

-Correction-
He gave it to me to see, but I don't know if I have the right to expose it. :X
So I must ask.

I feel like I've explained this before to you. Objects are typically coerced into strings (using their name property) when you abuse them like strings. It's better to compare the strings yourself for clarity.

You probably have and I still don't get it..
They just equal the same things in testing, unless I see an error of some kind giving physical evidence why it shouldn't be used I'll probably never fully understand. D:



ZeroG's algorithm I'll explain but won't show. It checks every tile within 32x32 of a level spreading out from the NPC. It finds the nearest path to the player, and comes back to it self in the check. After that it moves once...

This process repeats over and over and over until it moves towards the player.

It uses MANY for loops in the timeout, however, at the end it seems to NOT work if you do not have a sleep(.05); and having that makes it seriously slow...

Yet this algorythm works fine on another game that he is making in Simple. He doesn't want me to post it because he doesn't believe anyone else has tried it, nor does he believe anyone can fix it.

Is Graal not fast enough to do these type of things?

He uses V5 and it slowly comes to him, I use V6 and it seems to do the loop about 3 times before stopping.. if it finds me and I'm close to it then it will move to me once or twice... if I'm about 6 tiles away the finding part of the gets to me and stops... if I'm farther it stops in the same spot too..

If this cannot be helped without images or code than it is fine.

Output:

NPC Code:

---

Object one is 'SomeObject'

Object two is 'SomeObject'

Object keys: 'hi', 'foo'

Objects are different

Object names are equal

---

When the objects are coerced into strings, you get the object names only typically. In this example, it results in two objects appearing to be the same (because their object names are the same) even though we have just proven them to be different.

This is something you MUST be aware of when coercing objects into strings in GScript. It doesn't always work how you expect.

Sorry, I know you are trying to help, but I'm confused as to what any of that means..

Can you do it in layman's terms and possibly actually use levels?
Also, why are levels objects and not only strings?
I thought levels were only names of a textfiles converted to .nw..

Levels are instances of TServerLevel objects.

Level files are parsed/processed and loaded into memory as TServerLevel objects.

player.level refers to the TServerLevel object the player is currently in.

D: So why is .name added to it?
Does it make a difference for levels?

Well, player.level is an object which represents the level, so player.level.name gets the name attribute of the level object. The name attribute is already a string, so it does not result in the object being coerced (the example I posted above shows why relying on object-to-string coercion is a really bad idea).

Perhaps a good example would be the 'player' object. Within your script you're using player.account, 'player' being an object which can have variables written to and functions invoked on it, '.account' being a string/text value. If you can recognise that it is correct to use player.account instead of just 'player', you should also recognise it as correct to use level.name instead of just 'level'.

So ".level" isn't suppose to be a string for level, or it needs to convert it to a string while if I just add ".level.name" it saves it stress from doing it itself?


My problem is that if I don't use .account it will not work.. for whatever I might be trying to do, yet on level it does.. which is why I don't understand...

It is like some people saying why not keep some scripts GS1 for some parts if those parts still work and don't necessarily need to be fixed. I think that is a good metaphor?

In crude terms, yes. You should not expect that coercing an object to a string actually does what you think, so don't rely on it just because it "sometimes works".

Well, with all that stated, I'll definitely try to remember to correct these and future level.name checks. :]

Thank you both, much appreciated.

Bumping this as I'm also running into this problem clientside.