[Snippet] Multiboard

[Nestharus]

This resource has moved here.

--

gone

 

[kStiyl]

thank you; i had tons of problem with multiboard at thehelperrr

 

[Luorax]

set this.board.display=GetLocalPlayer()==this.owner

This won't cause desyncs, will it? Because it seems okay for me, but I can't test it.

If it won't, I might move to this.

 

[Bribe]

Just by looking at it, I can see it is much easier to use than any of the others I've seen.

And thanks for using solid variable names, this is the first readable thing to see from you in a while

 

[Nestharus]

Luorax, that will not cause desyncs.

//display board to a single player or a group of players
if (GetLocalPlayer() == targetPlayer) then
    set board.display = true
endif

= )

 

[Luorax]

Very well then, my map is open at the moment, I think I'll go and replace Board with this Let's see how much speed I can gain.

 

[Nestharus]

Eh, didn't exactly write this for speed, but rather simplicity ^)^.


It's obviously way easier to use than Board is. Also, all memory in this is cleaned up (handle refs, etc). Because of the static table use, cleaning memory is O(n), so a very, very large multiboard could be quite a bit of operations to destroy : ).

 

[Bribe]

I have intent to approve this, however I will need to review it in more detail when I am in the right frame of mind, before I feel confident to approve it.

 

[Luorax]

Well, it should still be faster than Board I think

However a few things I was missing:

//Struct MultiBoard
method operator width= takes real percent returns nothing
    call MultiboardSetItemsWidth(board[this], percent)
endmethod
static if LIBRARY_ARGB then
    method operator titleColor= takes ARGB color returns nothing
        call MultiboardSetTitleTextColor(board[this], color.red, color.green, color.blue, color.alpha)
    endmethod
endif
//Struct MultiBoardItem
static if LIBRARY_ARGB then
    method operator color= takes ARGB color returns nothing
        call MultiboardSetItemValueColor(table.multiboarditem[this], color.red, color.green, color.blue, color.alpha)
    endmethod
endif

 

[Bribe]

Those wrappers look pretty good.

 

[Nestharus]

Ah, forgot about the width thing, but I don't use vex's ARGB lib ;o.


I'll add the width thing asap.


edit
Added width


Thought I had gotten all the natives in there, but guess I missed one : p.

 

[Luorax]

It's okay that you don't use ARGB, but there're many users that do; that's why I placed them in a static if block. It's a pain in the neck to write this:

local ARGB color=0xFFFF97
call this.board[10][5].setColor(color.red,color.green,color.blue,color.alpha)

if it can be done like this:

set this.board[10][5].color=0xFFFF97

ARGB doesn't have to be a requirement, but its support would be great.

Additionally, I'd place this at the end of Multiboard's allocator:

call MultiboardSetItemsStyle(board[this], true, false)

Icons should be hidden by default.

 

[Laiev]

As I said at MSN:

(02:41) Luk: *In the future, Nes will make a Multiboard system because all the other systems is broken*

The prophecy was fulfilled.

 

[Magtheridon96]

Nice

Just a few tips:

        method operator display takes nothing returns boolean
            return IsMultiboardDisplayed(board[this])
        endmethod
        method operator display= takes boolean b returns nothing
            call MultiboardDisplay(board[this], b)
        endmethod
        method operator minimize takes nothing returns boolean
            return IsMultiboardMinimized(board[this])
        endmethod
        method operator minimize= takes boolean b returns nothing
            call MultiboardMinimize(board[this], b)
        endmethod

These aren't very user-friendly :/

Couldn't they be this:

        method operator displayed takes nothing returns boolean
            return IsMultiboardDisplayed(board[this])
        endmethod
        method operator displayed= takes boolean b returns nothing
            call MultiboardDisplay(board[this], b)
        endmethod
        method operator minimized takes nothing returns boolean
            return IsMultiboardMinimized(board[this])
        endmethod
        method operator minimized= takes boolean b returns nothing
            call MultiboardMinimize(board[this], b)
        endmethod

Because Multiboard.minimize returning a boolean that checks whether the board is minimized or not is illogical :/
Same for Multiboard.display returning a boolean that checks if it's displayed.

 

[LuizBills]

oh great

 

[Bribe]

oh great

Elaborate.

 

[Nestharus]

Actually Multiboard.display makes sense. If you want to display the multiboard, set it to true. If not, set it to false, lol. If you are currently displaying the multiboard, then that value will be true. If not, it will be false ;p.

 

[Magtheridon96]

Could you add alternate wrappers for people like me? :C
Maybe something like:

method show takes nothing returns nothing
method hide takes nothing returns nothing
method operator shown takes nothing returns boolean
method operator hidden takes nothing returns boolean

method minimize takes nothing returns nothing
method maximize takes nothing returns nothing
method operator minimized takes nothing returns boolean
method operator maximized takes nothing returns boolean

Some people would find these better, others wouldn't, either way, they all get inlined.

You could put them in a module and add an optional library requirement

edit

@Bribe:

You guys might find this a little far-fetched and very unlikely and I know it's going to sound wierd, but maybe just maybe,

Spoiler

he think it's great.

 

[Nestharus]

I think I'm going to just stick with as simple an API as possible : ).

 

[Magtheridon96]

Yeah, I guess I could easily change the API if I were to implement this into one of my maps. Or, I could simply implement this:

library MultiboardExtendedAPI

    module MultiboardExtension
        method show takes nothing returns nothing
            set this.display=true
        endmethod
        method hide takes nothing returns nothing
            set this.display=false
        endmethod
        method operator shown takes nothing returns boolean
            return this.display
        endmethod
        method operator hidden takes nothing returns boolean
            return not this.display
        endmethod
        method minimize takes nothing returns nothing
            set this.minimize=true
        endmethod
        method maximize takes nothing returns nothing
            set this.minimize=false
        endmethod
        method operator minimized takes nothing returns boolean
            return this.minimize
        endmethod
        method operator maximized takes nothing returns boolean
            return not this.minimize
        endmethod
    endmodule

endlibrary

 

[Berb]

You say that Board has the overhead of a rhino and the usability of a platypus, but it's not hard to make a system without any functionality. Board provides WAY more functionality than this. It also gives you useful feedback which this system does not.

Anybody can write wrappers for natives. Board does more. This is not what I would use if I wanted a multiboard.

It's obviously way easier to use than Board is.

Actually for the simple things your Multiboard does the implementation is pretty much exactly the same. The only difference is your 2D array syntax (which is nice). This 2D array syntax is also present in Board when you're obtaining a specific item/column/row in the multiboard though.

No idea how you felt that Board wasn't sufficient so you had to write an overly simplified version and call it Multiboard. Then you go and say other systems don't match your standards so you re-write those too. It's starting to sound like you just re-write other people's work so you can call it your own.

and then looking at Board over at wc3c and finding out that it had the overhead of a rhino and the ease of use of a platypus, I wrote this.

It's a multiboard. The overhead doesn't make an ounce of difference. That's like whining about the overhead on one of those functions that WC3 generates that is only called at map initialization. Multiboards are occasionally used objects that rarely get updated unless there is a significant event, such as a hero dying. This would change ONE multiboard element. Overhead is negligible.

 

[Nestharus]

Ahem, I really don't care. I spent 1 hour trying to get the one at TH to work (which it didn't), and then I looked at the one at wc3c and went wtf at the API (I hated it) and the size of the lib. I then wrote this -.-. All I wanted was a multiboard wrapper, nothing else... I don't need lollipops shooting out of canons... if I wanted that, I'd get a script that shot damn lollipops out of damn canons.


what is up with you guys and libraries that do 1001 and one things????? A library should have absolutely bare minimum functionality. Additional functionality should be written in additional libraries. That is the art of modularity >.>. I don't need a massive library, I only need a simple multiboard wrapper. The one at wc3c failed to address that. The one at TH didn't even work. Neither of them had the simple API of this as well (I wanted this style API, and I was going to have it no matter what).


And using a Multiboard wrapper is much nicer and easier to read and easier to deal with than using the Multiboard natives directly -.-, hence the wrapper.



I am seriously getting tired of people playing the hate game. If you don't like the lib THEN DON'T USE IT, end of story. If you see something wrong with the lib, then say something. You obviously found nothing wrong with this lib. The only thing you said was, Board does more, and I essentially said, I don't care. As it said in the original post, This Is a Multiboad Wrapper.


If you have a problem with the goal of this lib, then don't even bother responding >.>. The lib accomplishes that goal and you can't argue with that -.-. Furthermore, no other lib currently accomplishes that goal successfully. If you know of a lib, go ahead and prove me wrong by linking it.



This is the only I don't like this lib that I'm responding to. If you want to continue this discussion, either link a lib that has the same goal as this one or point out something that is wrong with this lib. You can even point out some API elements that you don't like (like Mag did). If all you are going to do is say, I don't like this lib or this other lib rocks and yours is totally ghey, then don't even bother because I frankly don't care.

Have a nice day.

 

[Berb]

Ahem, I really don't care. I spent 1 hour trying to get the one at TH to work (which it didn't), and then I looked at the one at wc3c and went wtf at the API (I hated it) and the size of the lib

So you put absolutely no effort into trying to learn their API, but you have resources on here that would take FAR longer to understand than that. His API is an object-oriented API, and makes a lot of sense. I picked it up in about 2 minutes.

All I wanted was a multiboard wrapper, nothing else... I don't need lollipops shooting out of canons... if I wanted that, I'd get a script that used the simple Multiboard wrapper.

If by "lollipops and canons" you mean "useful error messages and error-checking to ensure proper functionality" then I completely agree with you.

    public method operator icon= takes string val returns nothing
        local integer k = Mod(integer(this), 10000)
        local Board board = Board((integer(this) - k) / 10000)
        local integer row = (k - Mod(k, 100)) / 100
        local integer col = Mod(k, 100)
        local multiboarditem mbi
        
        if board.bBoard == null then
            debug call ErrorMsg("BoardItem[" + I2S(col) + "][" + I2S(row) + "].icon=", "The board this item belongs to does not exist anymore")
            return
        endif
        
        if row >= board.bRowCount then
            debug call ErrorMsg("BoardItem.icon=", "The board has been shrunk to no longer include this item. Will resize the board.")
            call MultiboardSetRowCount(board.bBoard, row + 1)
            set board.bRowCount = row + 1
        endif
        if col >= board.bColCount then
            debug call ErrorMsg("BoardItem.icon=", "The board has been shrunk to no longer include this item. Will resize the board.")
            call MultiboardSetColumnCount(board.bBoard, col + 1)
            set board.bColCount = col + 1
        endif
        
        set mbi =  MultiboardGetItem(board.bBoard, row, col)
        
        call MultiboardSetItemIcon(mbi, val)
        
        call MultiboardReleaseItem(mbi)
        
        set mbi = null
    endmethod

The only reason all his scripts for functions are longer is because he actually does error-checking. Error-checking isn't "extra garbage" in a library, it's very important.

what is up with you guys and libraries that do 1001 and one things?????

It's not 1001 things, it's "as many things as necessary to ensure the library is useful". I'm sorry that your library is a useless excuse for submitting something. You're scrutinizing the overhead in other libraries but then you're explaining that you want overhead from wrappers...

A library should have absolutely bare minimum functionality.

The library should contain as much functionality as required to make the library useful. If all you've done is given natives a different name then you haven't done anything. You're taking the Blizzard natives and giving them a different interface without providing the user with anything more than he/she already had. Why was this approved.

That is the art of modularity >.>.

Modularity doesn't mean you should make 4 libraries where 1 will suffice.

I don't need a massive library, I only need a simple multiboard wrapper.

Then why was this approved. It clearly does not meet the requirements of being useful beyond what is already available. If it doesn't, then it doesn't meet the bare minimum for functionality. Why would I want to use a library that provides some of the functionality from the library it was based on and then slacks off? You took Earth-Fury's system and simplified it, but I don't see any credit.

The one at TH didn't even work. Neither of them had the simple API of this as well (I wanted this style API, and I was going to have it no matter what).

Well then it should have stayed on your computer, and not on the resources section of this site. Since when was the requirements for approval "Nestharus likes it".

And using a Multiboard wrapper is much nicer and easier to read and easier to deal with than using the Multiboard natives directly -.-, hence the wrapper.

Yea thanks. You tell me you don't like overhead on other systems but you're willing to provide overhead for a system that doesn't provide any additional functionality.

Libraries should provide something beneficial. The time taken to learn this system's API and the Board API is almost the same, this one perhaps would take a couple of minutes shorter because you have less functionality. In the grand scheme of things though, those few extra minutes to learn a few extra functions would save you tons of time in implementation.

If you want to apply a certain property to a column you should be able to talk to the multiboard struct and let it do the work, not loop through the indices of the column and make it yourself. You talk about modularity like you know something but clearly you do not understand the fundamentals behind object orientation.

 

[Nestharus]

You took Earth-Fury's system and simplified it, but I don't see any credit.

I did not take Earth-Fury's system and he deserves 0 credit. I don"t give credit to previous systems simply because they already existed. If I had actually looked at his system for ideas and used any of those ideas, I would have given him credit. I only give credit where credit is due, and Earth-Fury is due 0.


As I said, this is a simple Multiboard Wrapper and nothing more. That is the goal of this. You are looking at it as if the goal is different and I keep telling you that the goal of this was to be a Multiboard Wrapper. It does not slack off, it just wraps up the current natives from JASS. Well, it does do a little bit extra by storing multiboard items in a table for the quick [][] stuff, but this goes for the simplest possible API and ease of use.


By Overhead, I wasn't talking about speed, but rather all of the extra stuff that was in that lib. I didn't even bother reading it because I didn't want to. When I saw the size of the lib, I pretty much said, screw that, I'm making my own.


However, thank you for pointing out things that you felt were wrong with the lib. I would have to say that your last post was not purely a hate post ^)^, hence why I'm responding to it : ).


I believe that this multiboard wrapper is fine as is as it accomplishes its goal in a minimalistic and intuitive way. I'm not one for protecting users against themselves.

 

[Berb]

I did not take Earth-Fury's system and he deserves 0 credit.

You deserve 0 credit.

By Overhead, I wasn't talking about speed, but rather all of the extra stuff that was in that lib

That isn't overhead. Performing logical checks is a necessity, not "extra stuff".

However, thank you for pointing out things that you felt were wrong with the lib. I would have to say that your last post was not purely a hate post ^)^, hence why I'm responding to it : ).

Good to see you're happy.

As I said, this is a simple Multiboard Wrapper and nothing more. That is the goal of this. You are looking at it as if the goal is different and I keep telling you that the goal of this was to be a Multiboard Wrapper. It does not slack off, it just wraps up the current natives from JASS. Well, it does do a little bit extra by storing multiboard items in a table for the quick [][] stuff, but this goes for the simplest possible API and ease of use.

I believe that this multiboard wrapper is fine as is as it accomplishes its goal in a minimalistic and intuitive way. I'm not one for protecting users against themselves.

I could make a platypus accomplish a goal, that doesn't make it useful. If you are only making these resources for yourself then maybe they should stay on your home computer. Nobody needs all these syntax wrappers in the JASS section. I have to say I couldn't even find anything useful without scanning through a few pages of re-written systems.

 

[Nestharus]

Nobody needs all these syntax wrappers in the JASS sectio

Working with Multiboard wrappers is easier than working with Multiboard natives ; ). You can't say that this lib isn't much easier to work with and isn't much more intuitive than the JASS natives ;o.

You deserve 0 credit.

Explain to me why systems that already existed should get credit for simply already existing. That'd be like me giving credit to every save/load system that was already done simply because they were done, even if I'd never heard of them or looked at them. That to me sounds pretty messed up. About the only thing I knew about Board was the name of the script and how long it was, so why exactly should it get credit? Simply because Earth-Fury wrote it? If that's not the case, why shouldn't the broken one at TH get credit too? It exists as well after all. In fact, why shouldn't I have to research every single Multiboard system ever written and give them all credit simply because they were written? Or is it just Earth-Fury that gets credit because he's apparently so awesome? That is what you are saying to me, and that is why I'm saying no.

 

[Berb]

Working with Multiboard wrappers is easier than working with Multiboard natives ; ). You can't say that this lib isn't much easier to work with and isn't much more intuitive than the JASS natives ;o.

It is, but I shouldn't be able to submit a script in 5 minutes that does the exact same thing except providing a different syntax implementation. Yours does the exact same thing as his, and his is not much more complicated than this one is. That's all there is to it.

If users put a tenth the effort they did in implementing your wacko interfaces they would be able to use Board to its full extent. Sure, not everybody on The Hive knows who Earth-Fury is or have his system, but that's why we give credit.

 

[Nestharus]

no, if they need more complex functionality, they should make some functions to accomplish that functionality. For example, they could create 2 new row and column structs in 2 new libs ; ). That is what I would personally do.


I do have a map and it follows this exact philosophy. Because it follows this philosophy, it happens to be extremely easy to maintain =).



Now, I don't know how his is written because I didn't bother to really look. What I do know is that it strangely has macros in it and all sorts of other nonsense. That is why I stated that his had a lot more overhead/complexity to it. Even if i had added in lots and lots of debug messages, mine wouldn't come anywhere near his script size.



They both have different styles of API and they both do their things different ways and have different methodologies. You can't compare apples and oranges. For people who like Board's style, they can use Board. For people who like this style, they can use this. I personally like this style, so this is the one I'd personally use. You personally like Board's style, so you can just go ahead and keep on using Board. Don't try forcing people to use what you personally like. That's pretty messed up. Just let everyone use what they want to use.

Now if 2 scripts are just about identical or one is plainly worse than another (buggy etc), that's a whole other story. As far as I can tell, the code in this lib is very different from Board's code.

edit
Btw Berb, people here don't go rampaging at other people's resources even if similar resources exist. We help out those current resources and sometimes, multiple resources that do the same thing get approved so long as they are of different styles. Perhaps the reason you are getting such negative response here is because you are not fitting in with what the community does. I know when someone makes a resource that's like one of mine I don't rampage at it and freak out like you do. I help them improve their own resource. If, in the end, it turns out that both resources end up being identical, or one of them outshines the other, then one of them gets rejected. If the resource in question was written entirely wrong, then I just say give up and try again ; P

For example, my save/load with snippets resource replaced every save/load system on this site, including the one I wrote (which took me like 3 months to write btw /sad face). Also, there are 2 UnitIndexers, one by Bribe and on by me. There are also currently 2 InCombatState resources that do the same thing, one in Spells and one in JASS. However, the one in JASS section is still better, but has some flaws ;p.

Relax a bit.

 

[Berb]

no, if they need more complex functionality, they should make some functions to accomplish that functionality. For example, they could create 2 new row and column structs in 2 new libs ; ).

Your create method is hilarious. You talk modularity but then you go ahead and put dynamic properties into the constructor forcing them as static properties, which is not modular coding style. I completely overlooked this at first glance.

I do have a map and it follows this exact philosophy. Because it follows this philosophy, it happens to be extremely easy to maintain =)

Well that's great Nestharus, but that doesn't help the rest of us. You can follow your philosophy all you want and create some small programs all by yourself, but when you've got to deal with different learning patterns and styles your philosophy does not work.

They both have different styles of API and they both do their things different ways and have different methodologies.

Actually his is just more modular than yours is.

For people who like Board's style, they can use Board. For people who like this style, they can use this.

What about the people who don't have a preference, but just want to be able to have a system that does what they need it to in a relatively simple way. Sure, your system is great for setting the title of the multiboard, but anything beyond that is more complicated with your approach.

You personally like Board's style, so you can just go ahead and keep on using Board. Don't try forcing people to use what you personally like.

You remake everybody's systems using your preferences and claim they are better than the originals.

But really, the one who is at fault is not you Nestharus, it is the moderators who accept this crap onto the public domain. You should know better than that, is all I'm saying.

As far as I can tell, the code in this lib is very different from Board's code.

You couldn't even get Board to work, according to you. But then you quickly admitted that you simply gave up. Remember?

Do I really want someone who can't even spend 2 minutes trying to adapt to someone else' style telling me that I should be more open to other styles, and that your interface is different than his? You just said you don't know his interface, and now you say they are different. They are almost identical.

Don't try forcing people to use what you personally like. That's pretty messed up. Just let everyone use what they want to use.

You re-write other people's work and call it your own. That's pretty messed up.

 

[Nestharus]

You couldn't even get Board to work, according to you. But then you quickly admitted that you simply gave up. Remember?

I never said I couldn't get Board to work. I said I couldn't get the one at TH to work, lolz.

You just said you don't know his interface, and now you say they are different. They are almost identical.

The code (from the quick glance I saw with the macros) looked very different. If the code is actually identical, that just tells you how little I looked at Board before I was fed up with the size and API.

You re-write other people's work and call it your own. That's pretty messed up.[

I don't take other people's work and rewrite it. I write my own version if I don't like their version.

Your create method is hilarious. You talk modularity but then you go ahead and put dynamic properties into the constructor forcing them as static properties, which is not modular coding style. I completely overlooked this at first glance.

How are they static? You can easily change row and column count whenever. You can't have a board with 0 rows/columns, hence why they are in the constructor.



In finality, stop trying to force people to use libs you think are nice. Just let people use what they want to use. Lighten up bro.

We have already agreed that this one has a simpler API, which was the goal of this lib. You have failed to link to any other lib that has the same goal as this one and accomplishes that goal. You have failed to point out anything wrong with this lib. Your entire defense has hinged on extra methods that a user may or may not need and my entire point of this lib was about minimal functionality. Your entire attack on this is that it has minimal functionality -.-.


1. It doesn't protect users from themselves.
2. It doesn't have extra methods that aren't JASS natives that the user may or may not need.
3. Apparently other libs were written before this that you like more, so you auto want this one rejected because this was written later. Furthermore, because those were written first, I apparently stole them. I apparently also stole save/load system code because my save/load stuff came later, and I stole UnitIndexer code, and UnitEvent code, and etc. Apparently nothing I write is my own, I just cnp it all and slap my name on it. And I bet stuff like TradeEvent was stolen too. Someone probably wrote it and I hacked their computer. Plus, I bet my whole header style was stolen.


Man, give up with this nonsense. I (at least) already get where you are coming from. The fact is that I don't like Board and I have already stated the reasons why. I released this system so that people would have another option for Multiboards. If you don't like giving options to people, then you are at the wrong community.

 

[Berb]

I never said I couldn't get Board to work. I said I couldn't get the one at TH to work, lolz.

and then I looked at the one at wc3c and went wtf at the API (I hated it) and the size of the lib

You're right. You didn't. You said you went "wtf" at the API. The API is pretty much the same as yours. So your just not aware of what you're talking about.

Yours

struct Tester extends array
    private static method init takes nothing returns nothing
        //bugless and easy to use, that's my kinda board
        local Multiboard board = Multiboard.create(2,2)
        
        call board.setStyle(true, false)
        
        set board[0][0].text = "00"
        set board[0][1].text = "01"
        set board[1][0].text = "10"
        set board[1][1].text = "11"
        
        set board.display = true
        
        set board.rowCount = 3
        set board[2][0].text = "20"
        set board[2][1].text = "21"
        
        set board.rowCount = 2
        set board.rowCount = 3
        
        call DestroyTimer(GetExpiredTimer())
    endmethod
    private static method onInit takes nothing returns nothing
        call TimerStart(CreateTimer(),0,false,function thistype.init)
    endmethod
endstruct

His

scope TesterScript initializer init
    public function initDelayed takes nothing returns nothing
        local Board brd = Board.create()
    
        call brd.all.setDisplay(true, false)
    
        set brd.row.count = 2
        set brd.col.count = 2
        
        set brd[0][0].text = "00"
        set brd[0][1].text = "01"
        set brd[1][0].text = "10"
        set brd[1][1].text = "11"
        
        set brd.visible = true
        
        set brd.row.count = 3
        set brd[2][0].text = "20"
        set brd[2][1].text = "21"
        
        set brd.row.count = 2
        set brd.row.count = 3

    endfunction
    private function init takes nothing returns nothing
        call TimerStart(CreateTimer(), 0, false, function initDelayed)
    endfunction
endscope

His actually functions better, if you test both of these. His API makes more sense to because he looks at rowCount as a member of row, rather than of the multiboard itself (which isn't modular).

The code (from the quick glance I saw with the macros) looked very different. If the code is actually identical, that just tells you how little I looked at Board before I was fed up with the size and API.

If you'll please refer to above, you clearly don't know what you're talking about. The API is good, and the size is necessary. If you still think the API sucks, then maybe you should try to change your own API because (as I have shown above) it's the exact same thing, but from an object oriented point of view it makes a whole lot more sense.

I don't take other people's work and rewrite it. I write my own version if I don't like their version.

So you take Board, get rid of half the functions, add your own little versions of the same thing with your own preferences on how you like to group things in your head (instead of what is common), maybe shorten a variable name and claim yours is more efficient. Yea you've got me convinced.

How are they static? You can easily change row and column count whenever. You can't have a board with 0 rows/columns, hence why they are in the constructor.

I did not see that you could set them, but that doesn't change the point. You don't need to construct a multiboard with row/column input. The fact that you tie these two actions into one contradicts your view of making everything modular, that was the point.

You can't have a board with 0 rows/columns, hence why they are in the constructor.

I believe that this multiboard wrapper is fine as is as it accomplishes its goal in a minimalistic and intuitive way. I'm not one for protecting users against themselves.

So here you are protecting the users from themselves, when before you were against the notion. At the same time, you're ruining modularity which you claimed is important. You just kind of throw computer science terms around whenever it benefits your abstractly different point of view.

You're taking full credit for systems that have been mastered before by more credible users than yourself. You're not even putting the full effort into it either you're just doing what you feel like doing and then submitting it here, where it is immediately accepted without any real examination.

Earth-Fury's script exceeds the quality of yours in every aspect that you told me you considered important, but you still think yours is better. I've got nothing left to say to you.

 

[Nestharus]

So here you are protecting the users from themselves, when before you were against the notion. At the same time, you're ruining modularity which you claimed is important. You just kind of throw computer science terms around whenever it benefits your abstractly different point of view.

Mate, I didn't include rowCount and columnCount in the constructor to protect users from themselves... I included it because they are 100% necessary for a board, meaning that you'd have to set them for every board, meaning that it's easier to set them in the create method when creating the board than below it >.>.

You're taking full credit for systems that have been mastered before by more credible users than yourself. You're not even putting the full effort into it either you're just doing what you feel like doing and then submitting it here, where it is immediately accepted without any real examination.

Earth-Fury's script exceeds the quality of yours in every aspect that you told me you considered important, but you still think yours is better. I've got nothing left to say to you.

Thanks for showing the API. His documentation sucks >.>.

So you take Board, get rid of half the functions, add your own little versions of the same thing with your own preferences on how you like to group things in your head (instead of what is common), maybe shorten a variable name and claim yours is more efficient. Yea you've got me convinced.

When on earth did I take Board? You are accusing me of cnping Board and modifying it to my own needs when I barely took a glance of it.

If you'll please refer to above, you clearly don't know what you're talking about. The API is good, and the size is necessary. If you still think the API sucks, then maybe you should try to change your own API because (as I have shown above) it's the exact same thing, but from an object oriented point of view it makes a whole lot more sense.

Ok, now that I see the API as demonstrated by you, it's ok ;p, but his documentation is horrendous enough to make me not want to even look at it.

His actually functions better, if you test both of these. His API makes more sense to because he looks at rowCount as a member of row, rather than of the multiboard itself (which isn't modular).

I constructed this with the layout of JASS natives in mind. With JASS natives, there are no rows/columns. You can't set a row. This is the reason why I have a rowCount and a columnCount. Furthermore, setting rows/columns like his does is not always necessary, which makes them extraneous methods and just adds complexity to an otherwise very simple script. Row/Column structs could just as easily be made as a separate resource.


Also, now that I look at it, there are other little wtf things as well
-> requires ARGB

private constant function B2S takes boolean b returns string
    if b then
        return "true"
    endif
    return "false"
endfunction

The stuff below adds complexity, which was what I almost did in my first design

    public method operator x takes nothing returns integer
        return Mod(Mod(integer(this), 10000), 100)
    endmethod
    
    public method operator y takes nothing returns integer
        return (Mod(integer(this), 10000) - Mod(Mod(integer(this), 10000), 100)) / 100
    endmethod

And I am sure there are more. This all proves my point of extraneous functionality and complications of otherwise simple scripts.


You keep claiming that the scripts are nearly identical. The script designs are fundamentally different and the philosophies behind them are fundamentally different.


You keep claiming that I somehow stole his script. Let me ask you this then... how did I steal his script when I didn't even know his API?


You are right. This conversation is over. The two scripts have very different background designs, making them both entirely different. The APIs, I will agree, seem almost identical now that you have shown me Board's API. Would I have likely used his Board script in my map if he had documentation I could read? Yes as writing this would not have been worth it. However, this is written now. It has a different style of code in the background, which is frankly simpler than the one Board uses.

 

[Bribe]

Looking over at the code Board generates, the code length is problematic, about 3x longer than what Nestharus has written. I am not counting comments there, only code itself.

When implementation goes from intimidatingly long to "simple and easy to understand", I think there is a fundamental improvement that's gone on. The utility here is much easier to grasp. I knew how everything in this system would work just by checking over the code.

 

[Berb]

Would I have likely used his Board script in my map if he had documentation I could read?

Documentation

//==============================================================================
// Board v0.2.01
//==============================================================================
// Credits:
//------------------------------------------------------------------------------
// Written By:
//     Earth-Fury
//------------------------------------------------------------------------------
// I don't care if you credit me or not if you use this. However, you must not
// misrepresent the source of this library in any way. This includes, but is not
// limited to claiming yourself to be the sole contributor to a map which uses
// this library.
// 
//==============================================================================
// Introduction:
//------------------------------------------------------------------------------
// Board is a library which provides decorators for multiboards. Basically, the
// Board library gives you multiboards with a more manageable API. You can not
// mix usage of the Board class and usage of the multiboard natives. You can
// have multiboards which in no way use the Board library, as well as ones that
// do.
// 
// Board does not impose limits on the number of boards, columns, rows, or
// items within boards. You can create an arbitrary number of boards with an
// arbitrary number of rows and columns, without running in to problems with
// the array size limit.
// 
//==============================================================================
// API Guide
//------------------------------------------------------------------------------
// The API for this library is very big. However, most of the methods do the
// exact same thing as their native counterparts. As well, methods which share
// the same name do the same thing, with some minor differences.
// 
//------------------------------------------------------------------------------
// An Important Note:
// 
// All of the array access methods (That is, the [] methods) which return a
// BoardRow, BoardColumn, or BoardItem, will accept values greater than the size
// of the Board. They will resize the board so that it contains the requested
// item.
// 
// Note that if you have a BoardItem, BoardRow, or BoardColumn object, and
// destroy the board they point to, weird things can happen if you use them. So
// please try to make sure you don't use BoardItem/Row/Column objects if the
// Board they belong to has been destroyed.
//
// The values of BoardRow, BoardColumn, and BoardItem instances can and will go
// above 8190. They are not suitable for use as array indexes. Instances of the
// Board struct itself are suitable for that use.
// 
//------------------------------------------------------------------------------
// The Board struct:
// 
// local Board board = Board.create()
//     When created, a Board object will have 0 columns and 0 rows. It will have
//     no title. The default settings for items are set such that new items will
//     display only text, not icons, and will have a width of 0.
// 
// set board.title = "string"
//     Sets the title of the multiboard. Identical to the native.
// 
// set board.titleColor = 0xFFFF00
//     Sets the color of the title of the multiboard to the given ARGB color.
// 
// 
// set board.visible = true
//     Makes the board visible for all players if set to true, and hidden for all
//     players if set to false.
// 
// set board.visible[Player(0)] = false
//     Makes the board visible/hidden for the given player
// 
// local boolean b = board.visible[Player(0)]
//     Returns true if the board is visible for the given player; false otherwise.
// 
// 
// set board.minimized = true
//     Minimizes/restores the board for all players.
//
// set board.minimized[Player(0)] = false
//     Minimizes/restores the board for the given player only.
// 
// 
// call board.clear()
//     Removes all items from the board. The same as the native.
// 
// 
// local BoardItem it = board[x][y]
//     Returns the BoardItem located in column x, row y.
// 
// 
// local BoardColumn col = board.col[x]
//     Returns the BoardColumn object for the given column of the board.
// 
// set board.col.count = 10
//     Resizes the board such that it has the given number of columns.
// 
// local integer i = board.col.count
//     Returns the number of columns a board currently has.
// 
// 
// local BoardRow row = board.row[y]
//     Returns the BoardRow object for the given row of the board.
// 
// set board.row.count = 10
//     Resizes the board such that it has the given number of rows.
// 
// local integer i = board.row.count
//     Returns the number of rows a board currently has.
// 
// board.all
//     Using board.all, you can modify the item properties of all items at once,
//     as well as change the default properties for items in new rows and
//     columns. Example:
//     
//     set board.all.width = 0.03
//     
//     See the "Item Manipulation" section for information on the methods that
//     board.all has.
//------------------------------------------------------------------------------
// Item Manipulation:
// 
// This section details the methods which all structs this library provides has.
// Namely, the methods that modify the properties of board items.
// 
// When these methods are called from a row, they modify all of the items in
// that row of the board.
// 
// The same for columns.
// 
// When called on BoardItems, they only modify the given item.
// 
// When called from board.all, they modify all the items on the board, and
// change the default properties for newly added items. (Items are added by the
// board gaining rows and columns.)
// 
// Explanation of the methods follows:
// 
// local BoardItem it = board[0][0]
// 
// set it.text = "string"
//      Changes the displayed text for the given item/row/etc.
// 
// set it.color = 0xFFFFFF
//      Changes the colour of the displayed text.
// 
// set it.icon = "ReplaceableTextures\\..."
//      Changes the icon of the item/row/etc.
// 
// set it.width = 0.04
//      Changes the width of the item/row/etc. These width values are the same
//      as those used by native multiboards.
// 
// call it.setDisplay(shouldDisplayText, shouldDisplayIcon)
//      The same as the MultiboardSetItemStyle() native. The first parameter
//      determines if the text for the item/row/etc. will be displayed.
//      The second parameter determines if the icon will be displayed.
//
//------------------------------------------------------------------------------
// The BoardRow and BoardColumn structs:
// 
// Note that these both have the exact same methods. The difference is, of
// course, one represents a row of items in a Board, while the other represents
// a column of items. BoardRow is used below, but it is fully interchangeable.
// 
// local BoardRow row = board.row[10]
// 
// local BoardItem it = row[y]
//      Returns the BoardItem that is in the row, at column y. For a BoardColumn
//      object, it takes the row as it's parameter instead of the column.
// 
// local integer whatRow = row.position
//      Returns the row or columns position in the board. That is to say:
//      board.row[10].position is equal to 10.
// 
// The BoardRow and BoardColumn structs have all of the methods listed in the
// "Item Manipulation" section.
// 
//------------------------------------------------------------------------------
// The BoardItem struct:
// 
// local BoardItem it = board[0][1]
// 
// local integer itemsColumn = it.x
//      Returns the item's x position in the board. (The ID of the column the
//      item is in.)
// 
// local integer itemsRow = it.y
//      The same as it.x, but it returns the row.
// 
// The BoardItem struct has all of the methods listed in the "Item Manipulation"
// section of this API guide.
//
//==============================================================================
// There is nothing to configure.
//==============================================================================

Clearly his documentation is at the top in plain English. This is what you actually call documentation. He puts a description of absolutely everything right at the top, for you to scan through. You say the documentation is bad? You guys are full of shit.

Let's take a look at the documentation you provide in your systems:

Nestharus Sorry Excuse for Documentation

//2.0.1.1
/////////////////////////////////////////////////////////////////////////
    //function CreateEvent takes nothing returns integer
    //function TriggerRegisterEvent takes trigger t, integer ev returns nothing
    //function RegisterEvent takes boolexpr c, integer ev returns nothing
    //function FireEvent takes integer ev returns nothing
    
    //struct Event extends array
        //static method create takes nothing returns thistype
        //method registerTrigger takes trigger t returns nothing
        //method register takes boolexpr c returns nothing
        //method fire takes nothing returns nothing
/////////////////////////////////////////////////////////////////////////

You guys are ridiculous. His documentation is 100x better than yours is and you say you can't learn his system but then you can write something that does the same thing with less documentation. Put a fucking sock in it.

Here, this is great. This is your documentation for BigInt.

BigInt Documentation

*************************************************************************************
*
*   Used for creating very large integers in any base. Stores in linked list.
*
*************************************************************************************
*
*   */uses/*
*
*       */ Base /*         hiveworkshop.com/forums/submissions-414/snippet-base-188814/
*
*************************************************************************************
*
*   struct BigInt extends array
*
*       Base base
*           -   The current base of the integer
*           -   Changing this value will convert the BigInt value into another base
*
*       integer digit
*           -   Specific digit within BigInt
*       readonly BigInt next
*           -   Used for iterating over digits
*           -   Goes from first placehold to last
*           -   Looping through 10 would be 0 to 1
*       readonly BigInt previous
*           -   Used for iterating over digits
*           -   Goes from last placeholder to first
*           -   Looping through 10 would be 1 to 0
*       readonly boolean end
*           -   The head, the pointer that represents the BigInt
*           -   Does not store a value, exit loop when this is true
*
*       static method create takes Base base returns BigInt
*           -   Creates a new BigInt in a base
*           -   Semi small operation
*       method destroy takes nothing returns nothing
*           -   Destroys a BigInt. Must pass in the integer pointer or this
*           -   will bug the rest of the system.
*           -   Very small operation.
*
*       method add takes integer value, integer extraPower returns nothing
*           -   Integer will be added as base 10 integers, meaning that they will
*           -   be converted into the base. If wanting to add integers in the same
*           -   base, convert it before hand. 0x and 0 notation for hexadecimal
*           -   and octal are very useful as well as they work with the integers
*           -   in an already converted state.
*           -
*           -   value and extraPower must be greater than 0
*           -
*           -   extraPower          refers to value^(1+extraPower)
*       method multiply takes integer value returns nothing
*           -   Multiplies an integer. Value is treated as a base 10 integer.
*       method divide takes integer value returns integer
*           -   Divides an integer by an integer. Value is treated as a base10 integer.
*           -
*           -   Returns remainder
*       method mod takes integer k returns integer
*           -   Returns the modulo of a BigInt given k as a divisor.
*
*       method addBig takes BigInt integerToAdd, integer extraPower returns nothing
*           -   Adds BigInt integerToAdd to BigInt
*       method multiplyBig takes BigInt integerToAdd returns nothing
*           -   Multiplies BigInt by BigInt integerToAdd
*
*       method push takes integer value returns nothing
*           -   pushes a base 10 integer on to the right side of BigInt
*           -   and converts that base 10 number into the BigInt's base
*           -   smallest digit*
*       method pop takes nothing returns integer
*           -   pop does the reverse of push and returns the popped digit
*           -   (see pop @google)
*       method enq takes integer value returns nothing
*           -   pushes base 10 integer to the left side of the number
*           -   biggets digit*
*       method deq takes nothing returns integer
*           -   deq does the reverse of enq and returns popped digit
*       method rl takes nothing returns nothing
*           -   Rotates number left
*       method rr takes nothing returns nothing
*           -   Rotates number right
*
*       method copy takes nothing returns BigInt
*           -   Returns a copy of the BigInt
*
*       method toString takes nothing returns string
*           -   converts an integer into a string (extremely useful)
*           -
*           -   if working in hexadecimal and there was a value like
*           -   C1H4, it'd actually return "C1H4"
*           -
*           -   string conversions use the actual Base to perform the
*           -   character conversions
*       method toInt takes nothing returns integer
*           -   returns the value stored in the BigInt as an integer.
*           -   only use when the value can be stored within an integer.
*           -   one common use might be retrieving the last value in a save/load
*           -   code.
*       static method convertString takes string value, Base base returns BigInt
*           -   converts a string into an BigInt
*           -
*           -   if working with hexadecimal and inputted "C1H4", it would
*           -   return an BigInt containing C1H4.
*           -
*           -   Returns 0 if the string value contains invalid characters
*
*************************************************************************************
*
*   Error Messages
*
*       Thread crash error messages output the trigger that crashed.
*       Feel free to post a message up for the resource about the crashed trigger
*       including the trigger name.
*
*       To find the specific method that crashed, do CTRL+F trigger name two times
*       (should be at the onInit method). From there, look at the method that's
*       added to the trigger and then CTRL+F that method.
*
*       Finding t-
*           private trigger t = CreateTrigger()
*           call TriggerAddCondition(t, Condition(function thistype.cl))
*           private static method cl takes nothing returns boolean
*
*       Overflow errors have to do with too many allocated digits. If running into these, the numbers
*       are just too large. This has been tested with 61*62^120 (base 62 number) converted to binary and
*       back, so it can handle extremely large digits (binary number was over 700 digits)
*
*************************************************************************************/

/************************************************************************************
*
*   Code
*
*       if you want to read the code, my suggestion is to not do it
*       this system performs operations digit by digit, meaning the algorithms
*       are ugly
*
*       the code is optimized, meaning the variable names aren't descriptive
*       the point is that it works and it's optimization is based on a balance
*       between minimizing counts towards the op limit and actual speed
*
************************************************************************************/

You put "the code is optimized" in the documentation, nobody fucking cares. You have more useless information in this documentation and stretch it unnecessarily. It's about as long as Earth-Fury's documents except the system is simple and for simple purposes. You can't read through Earth-Fury's but you type this shit up?

Are you just going to keep throwing bullshit at me until I leave you alone? You are just straight up lying. First his API sucks, but I show you its similar to yours. Now you say its his documentation, but his documentation is far better than your documentation.

 

[Nestharus]

Mate

// Written By:
//     Earth-Fury
//------------------------------------------------------------------------------
// I don't care if you credit me or not if you use this. However, you must not
// misrepresent the source of this library in any way. This includes, but is not
// limited to claiming yourself to be the sole contributor to a map which uses
// this library.
//
//==============================================================================
// Introduction:
//------------------------------------------------------------------------------
// Board is a library which provides decorators for multiboards. Basically, the
// Board library gives you multiboards with a more manageable API. You can not
// mix usage of the Board class and usage of the multiboard natives. You can
// have multiboards which in no way use the Board library, as well as ones that
// do.
//
// Board does not impose limits on the number of boards, columns, rows, or
// items within boards. You can create an arbitrary number of boards with an
// arbitrary number of rows and columns, without running in to problems with
// the array size limit.
//
//==============================================================================
// API Guide
//------------------------------------------------------------------------------
// The API for this library is very big. However, most of the methods do the
// exact same thing as their native counterparts. As well, methods which share
// the same name do the same thing, with some minor differences.
//
//------------------------------------------------------------------------------
// An Important Note:
//
// All of the array access methods (That is, the [] methods) which return a
// BoardRow, BoardColumn, or BoardItem, will accept values greater than the size
// of the Board. They will resize the board so that it contains the requested
// item.
//
// Note that if you have a BoardItem, BoardRow, or BoardColumn object, and
// destroy the board they point to, weird things can happen if you use them. So
// please try to make sure you don't use BoardItem/Row/Column objects if the
// Board they belong to has been destroyed.
//
// The values of BoardRow, BoardColumn, and BoardItem instances can and will go
// above 8190. They are not suitable for use as array indexes. Instances of the
// Board struct itself are suitable for that use.

//------------------------------------------------------------------------------
// Item Manipulation:
//
// This section details the methods which all structs this library provides has.
// Namely, the methods that modify the properties of board items.
//
// When these methods are called from a row, they modify all of the items in
// that row of the board.
//
// The same for columns.
//
// When called on BoardItems, they only modify the given item.
//
// When called from board.all, they modify all the items on the board, and
// change the default properties for newly added items. (Items are added by the
// board gaining rows and columns.)
//
// Explanation of the methods follows:

I can read my documentation style infinitely more easily than I can read Earth-Fury's... and Event is a poor example as I don't use that style anymore -.-.


Even this crap is an eyesore, lolz

// set it.color = 0xFFFFFF
//      Changes the colour of the displayed text.
//
// set it.icon = "ReplaceableTextures\\..."
//      Changes the icon of the item/row/etc.
//
// set it.width = 0.04
//      Changes the width of the item/row/etc. These width values are the same
//      as those used by native multiboards.
//
// call it.setDisplay(shouldDisplayText, shouldDisplayIcon)
//      The same as the MultiboardSetItemStyle() native. The first parameter
//      determines if the text for the item/row/etc. will be displayed.
//      The second parameter determines if the icon will be displayed.

Especially when compared to this

*       Base base
*           -   The current base of the integer
*           -   Changing this value will convert the BigInt value into another base
*
*       integer digit
*           -   Specific digit within BigInt
*       readonly BigInt next
*           -   Used for iterating over digits
*           -   Goes from first placehold to last
*           -   Looping through 10 would be 0 to 1
*       readonly BigInt previous
*           -   Used for iterating over digits
*           -   Goes from last placeholder to first
*           -   Looping through 10 would be 1 to 0
*       readonly boolean end
*           -   The head, the pointer that represents the BigInt
*           -   Does not store a value, exit loop when this is true
*
*       static method create takes Base base returns BigInt
*           -   Creates a new BigInt in a base
*           -   Semi small operation
*       method destroy takes nothing returns nothing
*           -   Destroys a BigInt. Must pass in the integer pointer or this
*           -   will bug the rest of the system.
*           -   Very small operation.

The fact is, I didn't want to read it, hence why I didn't know Earth-Fury's API. I assumed Earth-Fury's API was bad because of the glances at the code (with the macros etc), which made me go wtf. Furthermore, I was already in a pissed off mood from the one at TH when I was looking at it, so I just didn't want to deal with it.


Good documentation lets me get to learning how to use the system immediately instead of feeding me a lot of stuff I don't care about. Notice how I always write a very small description and have a neatly organized API. For struct descriptions, they are also very small. The indentation makes the methods and descriptions stand out more. Furthermore, any extra notes I have go below the API -.-. For some systems, like this one, I also include examples of how to use so that you don't even have to look at the API if you don't want to >.>.


So you tell me Earth-Fury's is so easy to read, but I beg to differ >.>. I don't like to read through a whole bundle of text. I prefer to just go straight for the API and be done with it (I don't even usually need any of the descriptions of the methods etc).


Finally, I didn't steal Earth-Fury's system in any way. I don't care how almost 100% identical the two APIs appear to be, I didn't even do more than a glance at Earth-Fury's script >.>. Earth-Fury deserves 0 credit for this since I coded this entirely on my own without looking at any other previous resource for its design. I don't care how much you whine, that's how it is. Now grow up.


I'll retract my statement about Board's stuff in the first post if that makes you happy >.>. I didn't take the time to read through Earth-Fury's documentation or examine Earth-Fury's code, making my statements pretty bleh ;p. However, I have, as of last night, examined Earth-Fury's code and documentation. I still say that the code size is pretty bleh (it's ok -all the debug stuff) and that the two scripts look remarkably similar when you get rid of the row/column structs. I am still particularly hateful of the documentation, which is why I brought it up in the last post. If you enjoy the globs of text all over the place, then good for you ; P. I know that I personally just like an API with minimal text ; ). And the reason I didn't even look at the API was because I didn't want to search for it -.-. I saw the glob of text at the top and was already ready to just start writing my own. I was ready to look for the API via the code, which is why I glanced at the code. However, finding that the API would not be easy to get via the code either, I said screw it and wrote this >.>.

And the reason the script size was a wtf to me was because I just wanted a simple wrapper, nothing more. The script seemed much too large to be a wrapper, so I assumed that the system included a bunch of extra useless stuff I didn't want, which helped strengthen my belief that the system also had an overly complicated API.


Now, we can nitpick at this every day, but I've already retracted my unwieldy statements about Board ;p, so it's kind of pointless, unless ofc you are still claiming that I stole Earth-Fury's code.

 

[Berb]

I can read my documentation style infinitely more easily than I can read his

That's because you wrote it.

The fact is, I didn't want to read it, hence why I didn't know his API. I assumed his API was bad because of the glances at the code (with the macros etc), which made me go wtf. Furthermore, I was already in a pissed off mood from the one at TH when I was looking at it, so I just didn't want to deal with it.

That doesn't make this submission acceptable. I was able to understand his, and hundreds of other people who used his system were able to understand it, but you weren't. That just shows an inability on your part, not on his documentation.

It would be nice if you didn't point fingers at him when you're admitting now that you didn't want to learn or put any effort into using his system, you just wanted to make one and pretend you invented the idea.

Good documentation lets me get to learning how to use the system immediately instead of feeding me a lot of stuff I don't care about.

Well then no matter how good the documentation is it won't be good enough because you won't even bother to spend 30 seconds trying to learn it.

Notice how I always write a very small description and have a neatly organized API.

His has small descriptions of each of the features and an organized API.

Furthermore, any extra notes I have go below the API -.-. For some systems, like this one, I also include examples of how to use so that you don't even have to look at the API if you don't want to >.>.

I really don't care how you do your documentation. Everybody has their own way of doing it, but each way should provide a way to learn the system. His provides this better than most of your documentation. The inability of you to read a paragraph is your problem, not his.

So you tell me Earth-Fury's is so easy to read, but I beg to differ >.>

"The fact is, I didn't want to read it" - you didn't want to read it. Of course you're not going to find it easy to read lines of text that you don't even want to read in the first place because you don't even care to learn his system.

I don't like to read through a whole bundle of text. I prefer to just go straight for the API and be done with it (I don't even usually need any of the descriptions of the methods etc).

Yea well that's what happens when you read code that isn't just sticks and stones. Welcome to the real world of coding.

It isn't even that hard to force yourself to read through the text... takes maybe 2 minutes unless you're autistic.

It's good to know that you don't even spend a minute looking at other people's resources but then you throw around your own resources (which typically already existed before you made them) as if they were torn from the Bible itself.

 

[Nestharus]

Well then no matter how good the documentation is it won't be good enough because you won't even bother to spend 30 seconds trying to learn it.[

It isn't even that hard to force yourself to read through the text... takes maybe 2 minutes unless you're autistic.

I spent about 15 seconds learning Bribe's Table. That is the extent of my laziness to learn new resources. If it has globs of text, there is a guarantee that I am not going to even bother with it :\.


I didn't make this to say that I came up with the idea etc -.-. I already told you precisely why I made it. Stop trying to say otherwise >.<. I know why I made this resource. I don't care about fame etc >.>.

 

[Luorax]

If I had to quute the most popular phrase of this thread, it'd definitely be "I don't care"

 

[Berb]

I spent about 15 seconds learning Bribe's Table. That is the extend of my laziness to learn new resources. If it has globs of text, there is a guarantee that I am not going to even bother with it :\.

It took me about 30 seconds to learn Bribe's Table. It's the exact same as Table by Vexorian. Took me about 4~5 minutes to learn Board. You've put far more effort into making code yourself than learning other people's code. That makes me question whether or not you really know what you're doing or just jamming ideas together without thinking them through.

"If doesn't have my name on it, there is a guarantee that I am not going to even bother with it."

I didn't make this to say that I came up with the idea etc -.-. I already told you precisely why I made it. Stop trying to say otherwise >.<

Yea, you told me you made it because you don't want to put your 2 cents into learning from someone else. Instead you would rather just insult their work as if you know better than they do (without even fucking reading it).

 

[Magtheridon96]

I'm going to be totally honest:
Every system on wc3c.net has a lot of documentation that's extremely descriptive and great
for the user, but the problem is that they're always very unreadable.
Using comment delimiters makes documentation 1000x easier to read in the editor because the
API gets highlighted and the annoying green color doesn't show up. Other than delimiters,
documentation could make use of dashes, asterisks and tabs to make things much easier to read.
I can read Nestharus' documentations and understand the entire API in under 30 seconds. (For Large systems)

edit

When you're studying for a test, it's going to be easier for you study the ideas in point-form, not some large
paragraph that discourages you to continue studying.

 

[Nestharus]

Instead you would rather just insult their work as if you know better than they do

I never said I knew better than they do. After examining Board's code, I'd still prefer using this than Board because I am not a fan of all of the debug stuff or the row/column structs. If I needed row/column stuff, I'd make a separate resource to use them.

That makes me question whether or not you really know what you're doing or just jamming ideas together without thinking them through.

lol, I do spend my time learning new concepts. Learning new resources is another thing altogether ;p. For example, I know many, many advanced data structures and spent my time learning them and even put up the tutorials I found that explained them so that other people could learn them ; ). One pretty simple one that's up there, for example, is the Kd-Tree ;o. Computational Geometry has been the most useful thing that I have learned for computer science to date : D.

 

[Magtheridon96]

Too bad KD-trees are impractical in Wc3.
We're talking O(n!) man :l

 

[Berb]

I never said I knew better than they do.

You made some stupid remark involving a platypus. If you think you are able to make these dumb remarks then clearly you think your word is better than his, because you stated as a fact that his system is lacking in more ways than one. That implies that you think you know what makes the system lacking, when clearly the only thing that is lacking is your ability to read.

There's a difference between being able to do something, and being able to do something well.

And yea, as Mag said, why are you bringing up KD trees now? Data-structures aren't even close to the most important thing you learn in computational geometry either, I would have to say vector algebra and calculus is. So... are you just trying to throw words at me?

 

[Magtheridon96]

Berb, relax dude, all he did was state a fact.
Yes, it's a fact that Board has more overhead than it should, but he's not trying to insult anyone, he's just pointing out that they could've been written in a certain way to be faster and generate less map code.

 

[Nestharus]

There's a difference between being able to do something, and being able to do something well.

/agree ^)^.


Anyways, this is already coded. My only real defense on this is that Board and this script have different mentalities -> extra features belong in dif libs. However, the size of those extra features is rather small, so you could just as easily say that you might as well inline them in the original lib. I could also say that you could do them as optional modules, which is what I was thinking of doing later on ;o.


So anyways, yea I wrote this script because I didn't want to read a glob of text due to my extreme laziness with documentation ;p. I tested myself and could easily handle mag's SoundTools docs. I just don't like the style that was employed by Earth-Fury ;p.


As far as speed goes, speed doesn't really matter with a multiboard system so w/e. This one is probably a bit faster for everything but changing row/column counts, but that doesn't really matter as it is a multiboard.

As far as script size goes, both are comparable when you remove the debug stuff.


Quality depends on how you look at it. For non JASS resources, I am all about debug stuff and protection and total ease of use above all else. For map specific resources, I am all about debug and protection and total ease of use above all else. For general public resources, I am all about maximized speed and efficiency as well as ease of use. Thus quality depends on how you look at things ;p.

You may say that you think the quality of the documentation that Earth-Fury did is better, but I beg to differ. I personally can't handle that style.

This script is slightly easier to use due to the create method (hence why I only say slightly). Really, there are only very minor improvements.

The mechanics between the two are quite different.


You're just comparing two different styles ; ). I'd say to leave both up, primarily for the ARGB lib use in the other one. If people use ARGB, then they'll find the other one better for them. If not, then they might as well use this one. That's my big thought atm >.>.

If people care about mechanics and want the debug features, I'd def say Board. If they wanted the slight speed boost with the multiboard item caching, I'd say this one. They both have their pros and cons >.>. In cases like that, I say keep both up. If one was a clear winner, I'd say reject one and keep the winner >.>, lol.


There really rarely is a perfect solution for anything. It all depends on what a person wants and values. That is why options are important.



Anyways, that's all.



edit
If everyone prefers to use ARGB with Board and I'm the only one who'd end up using this, then I guess might as well just gy it ;p. Just put it up as I figured I''d might as well share it.

 

[Berb]

If people care about mechanics and want the debug features, I'd def say Board. If they wanted the slight speed boost with the multiboard item caching, I'd say this one.

You just said that speed makes no difference in a multiboard system (which I agree with) and the item caching only compliments the speed, it isn't an added bonus. I'm pretty sure that Board item lookups are done in constant time as well, so there isn't any significant difference in the speed of either. The only difference (which I've been saying all along) is the ability of the system.

I'm going to let up here. Traversing this recursive heap of excuses is a waste of time.

API --> Documentation --> Style --> API --> {insert comment about efficiency} --> ...

 

[Bribe]

I think it has to do with the fact that Courier New or Monospace or whatever font, is not very easy to read with long descriptions. Short overviews tend to work better with this font.

It makes more sense to put the long description outside of the JASS tags anyway, and I tend to read those descriptions 100% of the time versus reading comment header things maybe 50% of the time, depending on what kind of mood I am in.

With normal text you have access to BBCode and all that good stuff. But the way things are has spawned a minimalist approach rather than a fully-expanded commentary.

I mean, with description, how much are you going to include? I think listing the API with a brief on how to use each API is the most minimal description possible, and taking it a few steps further is encouraged, but I don't really want to read a book when I'm looking through JASS code, I want to read JASS code.

 

[Berb]

If I plan on using a system, or I am in need of a system, I will read as much as possible to ensure I am not doing things in ways that could be improved later because that often leads to having to re-write entire portions of code rather than changing a few instructions in the implementation.

 

[Bribe]

All the same, I have made a big point in recent months to try to not approve resources until the API is for the most part settled.

I could read the users' documentation as much as I want, but you need substance, not just style. I learn as much as I need just by reading the code, and it helps to have an API list at the top for quick reference.

 

[Berb]

Unless you're not familiar with the set of actions that could be performed. If you did not know what a Stack was then little API headers at the top like:

//* push() - pushes data onto stack
//* pop() - pops data from stack

You would still be clueless because you don't know what is being pushed and what is being popped. A little description of what a stack is may be required. Apply that concept to a far more complicated structure than a stack.