Player Number Bug (FIXABLE!)

Subject: Player Number Bug (FIXABLE!) Fri Feb 06, 2009 6:46 pm

Alright, Zync. Me and Pythagoras did a few tests trying the limits of loops. Here's what we found:

A loop, with just a single call to DisplayTimedTextToPlayer(), is able to iterate to about 10,000 times.
Each extra process put within the loop decreases this iteration cap. A TerrainDeformCrater() call reduced the iteration count by about 1/3.
Operations put outside the loop also affect how long the function will last, but it doesn't affect it nearly as much as if you would put it inside the loop.
The iteration is based slightly on the player's processing power (on their computer). The difference basically would be that the shittiest computer that can play WC3 would be capped at about 9,200 iterations with the call to DisplayTimedTextToPlayer().
When a loop hits its iteration cap, the function no longer executes. This is what is likely causing the Player Number bug, because you are likely using many loops in a single function to set up all the variables at map initialization.

Pythagoras is currently working on a system that will tell you how much you can iterate a specific loop... I don't know how he's doing it, but he is. I think that a solution to your problem would be to loop and initialize variables in different functions, using a timer to call the other functions. This should reduce the payload that the map puts on computers during the map init so that any players can play the map safely.

You can now set it back up to 12 players again once you fix it in this manner, and it's also why it didn't always happen.

UPDATE

Scratch Pythagoras's method to check the iteration cap. It's ineffective and constantly crashes the game, even with a single function call.

Subject: Re: Player Number Bug (FIXABLE!) Fri Feb 06, 2009 9:23 pm

Yeah well that's not because of the JASS operation limit, that's because your RAM and GPU don't like rendering 10000 unit models or displaying 10000 lines of text 20 times per second.

The reason this may effect Zync's map is if he uses a lot of initialization loops and then at the end of the function after all the looping is done, tries to use EnableTrigger or something like that, it will never get that far and won't call it.

I'm not sure how you initialize everything Zync, so blame Sin if this theory is completely wrong Razz

Upon initial inspection of M&M's code, I suspect that there are not enough operations on map init to cause these kinds of problems. But I found something pretty nasty

Code:: function my_Clear takes player p returns nothing
local integer i=0
loop
call DisplayTimedTextToForce(GetForceOfPlayer(p),1," ")
set i=i+1
exitwhen i>15
endloop
endfunction

could be replaced by

Code:: function my_Clear takes player p returns nothing
if(GetLocalPlayer()==p) then
call ClearTextMessages()
endif
endfunction

Upon futher inspection, the InitMultiboard function may be causing the problem.

Upon even further inspection, the InitMultiboard function is called after a delay, so unless it causes enough operations on its own to prevent the next timer from being started then it isn't the cause. The test for this would be whether or not the new/load dialog buttons appear when the error occurs, if they do not, the operation limit is causing the problem.

Subject: Re: Player Number Bug (FIXABLE!) Fri Feb 06, 2009 11:03 pm

The dialog box does not appear when the bug occurs. The -new chat command doesn't work either.

Subject: Re: Player Number Bug (FIXABLE!) Fri Feb 06, 2009 11:49 pm

Then the RefreshMultiboard function breaches the operation limit with too many players.

The reason the -new command doesn't work is because the playerstructs are initialized in CustomInit_Action_2, just like the new/load dialog buttons, which is the function that is timed 0.25 seconds after the RefreshMultiboard is called, but the timer is never started if there are too many players to loop through and the operation limit makes it fail.

The -new command is registerred as recieved, but it references an uninitialized player variable, which just stops the thread.

Btw Zync, i'm not sure which option you'd want to click on your map protector, but obfuscation of your function and variable names makes it a hell of a lot harder for people to find out how to cheat up your map. Although at the same time it would make it harder for me to tell you where your error occurred so you could find it in un-obfuscated code.

Subject: Re: Player Number Bug (FIXABLE!) Sat Feb 07, 2009 4:32 pm

Well, I don't EnableTrigger(), only check for the conditions to DisableTrigger(). And these calls never happen during initialization, but a fraction of a second or more after initialization ( and are very few ).

Although, in the next version, I am going to separate the multiboard initializing timer with the player initializing timer, while limiting the number of loops the multiboard can make in its attempt ti initialize.

I still think I'll keep the number of players to 9 for now, since it too has been show to crash due to this bug. If we can go for a while without issues, then I will begin to increase the number of players once more.

Subject: Re: Player Number Bug (FIXABLE!) Sat Feb 07, 2009 4:56 pm

Excellent.

Subject: Re: Player Number Bug (FIXABLE!) Sat Feb 07, 2009 5:39 pm

Oh wow, I didn't notice you use BJ multiboard functions...

Code:: function MultiboardSetItemStyleBJ takes multiboard mb, integer col, integer row, boolean showValue, boolean showIcon returns nothing
local integer curRow = 0
local integer curCol = 0
local integer numRows = MultiboardGetRowCount(mb)
local integer numCols = MultiboardGetColumnCount(mb)
local multiboarditem mbitem = null

// Loop over rows, using 1-based index
loop
set curRow = curRow + 1
exitwhen curRow > numRows

// Apply setting to the requested row, or all rows (if row is 0)
if (row == 0 or row == curRow) then
// Loop over columns, using 1-based index
set curCol = 0
loop
set curCol = curCol + 1
exitwhen curCol > numCols

// Apply setting to the requested column, or all columns (if col is 0)
if (col == 0 or col == curCol) then
set mbitem = MultiboardGetItem(mb, curRow - 1, curCol - 1)
call MultiboardSetItemStyle(mbitem, showValue, showIcon)
call MultiboardReleaseItem(mbitem)
endif
endloop
endif
endloop
endfunction

Because of the inefficient way Blizzard put these functions together, your RefreshMultiboard function has a loopcount of f(n)=420*(n+1)^2 where n is the number of players in the game.

If you set up a loop that calls a single Multiboard BJ function, the operation limit is reached at about 450 iterations. With 9 players your function attempts to call it 350 times, along with other function calls its pretty easy to see how it could cause problems.

I'd recommend a local multiboarditem and avoiding using the BJ's by setting it and releasing it yourself.

Subject: Re: Player Number Bug (FIXABLE!) Sat Feb 07, 2009 7:43 pm

Well I never looked that into the Multiboard functions before. And you're more than right. I will remake the Multiboard system for the next release ( it is getting close ) which will hopefully fix the player number bug once and for all.

Subject: Re: Player Number Bug (FIXABLE!) Wed Feb 11, 2009 9:29 pm

With the Beta 6.1 release, I started a 12 player full house just fine. If anyone else runs into trouble please post it here, otherwise, I will lock this topic soon.

Thx Pythagoras.
PS Do you know Big-O notation? Or do you just code on the side?

Subject: Re: Player Number Bug (FIXABLE!) Wed Feb 11, 2009 11:57 pm

Pythagoras doesn't program in anything but JASS, is what I'm led to believe.

Subject: Re: Player Number Bug (FIXABLE!) Thu Feb 12, 2009 12:57 am

Naw, nothing but JASS right now, I'm taking a class on Flash atm and I have the means and will probably have the motivation soon to teach myself C++

Subject: Re: Player Number Bug (FIXABLE!) Thu Feb 12, 2009 1:25 am

Good. You certainly have the devotion for programming. Debugging has always been my weakness, as well as the weakness of many. If you can hone that skill, you'll always have work, even during ( what will most likely become ) a depression!

Subject: Re: Player Number Bug (FIXABLE!) Thu Feb 12, 2009 2:55 am

I'm working on C++ atm, but the class is 16 weeks and being at the community college, it moves slow as hell.

Subject: Re: Player Number Bug (FIXABLE!) Thu Feb 12, 2009 3:21 am

I know C++ (though I haven't used it at all outside of class), but I don't know JASS. I'd like to learn it (and the GUI) though if I can find the time.

Subject: Re: Player Number Bug (FIXABLE!) Thu Feb 12, 2009 3:25 am

I actually work in C++, although I must admit that I am not that familiar with the standard library ...

JASS is actually quite simple. I find its syntax is very similar to JavaScript.
vJASS is a little more difficult, throwing in things like Structs and Function Interfaces ( basically function pointers, but handled more simply than a C++ void* ).
Honestly, I learned most of vJASS before I ever took a programming class. I'm sure you guys won't have a problem. The JassNewGenPack really is a fine IDE and provides a good API.

Subject: Re: Player Number Bug (FIXABLE!) Thu Feb 12, 2009 4:20 am

Yeah, the great thing about JASS is how simple the syntax is to catch on to. The real trouble is finding all the efficient and effective ways to do things, as evidenced in this thread. I didn't even know the BJ functions were that awful until I looked into it. I mean you can make pretty much anything you can do in JASS happen with the GUI trigger system, its just that the GUI trigger system does it in a horribly inefficient way with a horribly ineffective method of input.

The major recommendation: Get NewGen if you're going to do anything with JASS. My worst experiences ever were having regular worldeditor crash on me when i tried to save because I forgot to double my escape characters in filepath strings and not closing all my if-thens.

And thanks for the encouraging words Zync

» Player Number Bug
» New Player
» Just another MM&M player