• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Multiboard glitches

Status
Not open for further replies.
Level 26
Joined
Aug 18, 2009
Messages
4,097
WaterKnight proudly presents... a new kind of Blizzard fail

Recently, I wanted to implement an ingame display to show the amounts of all currently allocated struct types for debugging.

After the kind of linked list worked and the multiboard was set up, two abnormatilities occured. Scrolling through the pages, some rows would suddenly become blank and another one got this phenomenon:

134387d1397668656-multiboard-glitches-mbfail.jpg


two wo..., one c... -> two words, one cell. Well actually two rendered strings.

A test map would reveal some of the behavior. Multiboards totally screw up if you shrink them in rows or columns and extend them again. I have not completely understood the system but decreasing the size too fast, meaning going from 10 rows to 1 row for example, will render some of the cells useless, you cannot set their properties anymore, respectively cell coordinates could be exchanged, you would control another multiboard item.

As for the parallel texts, I found that the game caches the cells being rendered. That means if you set items, shrink the board and re-extend it, the former contents will be restored. But that is only if those contents have been rendered -> need to insert a wait. Now if you do the re-extension immediately (after shrinking), it redraws the cells but does not adjust the property memory -> you can write something else in there because the game thinks it's empty.


See test map (vJass)
 

Attachments

  • mbfail.w3x
    15.6 KB · Views: 63
  • mbfail.jpg
    mbfail.jpg
    17.5 KB · Views: 263
Yeah, multiboards are rather strange. Thankfully, Zwieb came up with a solution to it a while back.

To fix that whole issue, just reduce rows 1 by 1. You shouldn't have to do that for columns, though. Here is my implementation in my system:
JASS:
method operator rows= takes integer count returns nothing
    local integer i = .rc - 1
    if count > .rc then
        call .cacheItems(.rc, count, 0, .cc)
        call MultiboardSetRowCount(.board, count)
    elseif count < .rc then
        call .releaseItems(count, .rc, 0, .cc)
        loop
            call MultiboardSetRowCount(.board, i)
            exitwhen i == count 
            set i = i - 1
        endloop
    endif
    set .rc = count
endmehtod

Ignore the side things like caching and releasing. ".rc" is a variable that holds the row count. Basically, if the row count is being incremented (count > row count), then just set the rows directly. If the row count is less than the current row count (count < row count), then you just run a loop and set the row count down by 1 each iteration (until you reach 'count').
 
Status
Not open for further replies.
Top