Discussion Total JassHelper overhaul project

Should JassHelper be updated?

  • Yes

    Votes: 15 60.0%
  • No

    Votes: 6 24.0%
  • Wait for Vexorian

    Votes: 4 16.0%

  • Total voters
    25

Lyerae

I keep popping up on this site from time to time.
Why make #luck? That's stupid.
It can be used by other potential compilers to know that the code within gets ignored so it can be sent to the right compiler, rather than displaying errors 'cause it doesn't know the code.
 

Vestras

Retired
I'm seeing you're making this indentation based. I haven't read the thread, I don't mod wc3 and honestly I am not really interested in this project, nor am I interested in any other wc3 project, but if you want to see how I made my programming language indentation based, you can check out its source code at http://www.code.google.com/p/grape-sc2 under the tab Source.
 

SanKakU

Member
some of it looks nice but seeing as it's in luck which isn't entirely understood...won't bother updating until backwards compatible with vjass comes. in the meantime, i see nothing wrong with you writing it up...not like they suddenly gonna release jasshelper your version with jngp if they weren't releasing it before with updates not going to now.
The rest of the readability likely has to do with TimerUtils being multi-flavored. Have you ever tried reading it in vJass? It's a mess.
i agree but that's because of the static if fad. static ifs are a joke. they're entirely pointless.

what's the point of stocking up tons of code in a map only to have zero fun factor in the map? more code does not equal more fun. what each coder needs is the best bits of code and throw away the unnecessary parts.
 

tooltiperror

Super Moderator
Staff member
>i agree but that's because of the static if fad. static ifs are a joke. they're entirely pointless.
bahahaha this kid just makes my day.

>what's the point of stocking up tons of code in a map only to have zero fun factor in the map? more code does not equal more fun. what each coder needs is the best bits of code and throw away the unnecessary parts.
do you realize what you are saying? My map (mine = one that I worked on extensively) was on #2 played for approximately three years on battle.net and had thousands of lines of code, and many clans dedicated to it. It uses static ifs.
 

emjlr3

Change can be a good thing
Staff member
what is the problem with static ifs in a pre-made system?

obviously they make little sense in your own map, unless you plan on extensive changes in the future

but still, they are not pointless

and whats it matter what the .j looks like once compiled - who needs to read it anyway?
 

Sevion

The DIY Ninja
some of it looks nice but seeing as it's in luck which isn't entirely understood...won't bother updating until backwards compatible with vjass comes. in the meantime, i see nothing wrong with you writing it up...not like they suddenly gonna release jasshelper your version with jngp if they weren't releasing it before with updates not going to now.


i agree but that's because of the static if fad. static ifs are a joke. they're entirely pointless.

what's the point of stocking up tons of code in a map only to have zero fun factor in the map? more code does not equal more fun. what each coder needs is the best bits of code and throw away the unnecessary parts.
I'm sorry, I don't think you understand map making.
 

Sevion

The DIY Ninja
Hmm. "self"?

Why choose that over the already used and liked "this"?

If you're going to have "thistype", why not keep "this"? It just seems to flow better.

Otherwise, I like it! :D
 

Bribe

vJass errors are legion
"self" is easier to type from the native key position, making it less prone to typos than "this" would.

Now that "modules" can accept parameters there is no reason to use "thistype". I think I will omit that keyword in favor of getting people to really get a good feel for the name of their own class. It can lead you to think twice about an undefined, unreadable class name. I think "thistype" is bad practice and even Vexorian discourages its use.

Is "this" really so much better than "self"? I imagine it depends on your primary choice of language and that "this" is used in Java, JavaScript and so forth, but I've done a lot of comparisons with my Notepad++ syntax highlighter and "self" is way more aesthetically pleasing and adds readability ("this" seems to mesh).
 

Solmyr

Active Member
Here's a suggestion - in natives such as [ljass]ForGroup()[/ljass], [ljass]ForForce()[/ljass], [ljass]TimerStart()[/ljass], [ljass]EnumItemsInRect()[/ljass] and [ljass]EnumDestructablesInRect()[/ljass], allow the callback to take arguments.

So, when you have something like
JASS:
nothing damageUnits(unit sourceUnit, real damageAmount):
    UnitDamageTarget(sourceUnit, GetEnumUnit(), damageAmount, true, true, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_UNIVERSAL, WEAPON_TYPE_WHOKNOWS)

boolean onEffect():
    unit castingUnit = GetTriggerUnit()
    GroupEnumUnitsInRange(ENUM_GROUP, GetUnitX(castingUnit), GetUnitY(castingUnit), 500.0, null)
    ForGroup(ENUM_GROUP, function damageUnits(castingUnit, 200.0))

nothing onInit():
    trigger mainTrigger = CreateTrigger()
    TriggerRegisterAnyUnitEventBJ(mainTrigger, EVENT_PLAYER_UNIT_SPELL_EFFECT)
    TriggerAddCondition(mainTrigger, Condition(function onEffect))

it would compile to something like:
JASS:
globals
    /* Obviously, these globals would need unique and retarded names to prevent possible overwriting. */
    unit callbackTemporaryUnit = null
    real callbackTemporaryReal = 0.0
endglobals

function damageUnits takes nothing returns nothing
    local unit sourceUnit = callbackTemporaryUnit
    local real damageAmount = callbackTemporaryReal
    call UnitDamageTarget(sourceUnit, GetEnumUnit(), damageAmount, true, true, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_UNIVERSAL, WEAPON_TYPE_WHOKNOWS)
    set sourceUnit = null
endfunction

/* Or: */

function damageUnits takes nothing returns nothing
    call UnitDamageTarget(callbackTemporaryUnit, GetEnumUnit(), callbackTemporaryReal, true, true, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_UNIVERSAL, WEAPON_TYPE_WHOKNOWS)
endfunction

function onEffect takes nothing returns boolean
    local unit castingUnit = GetTriggerUnit()
    call GroupEnumUnitsInRange(ENUM_GROUP, GetUnitX(castingUnit), GetUnitY(castingUnit), 500.0, null)
    set callbackTemporaryUnit = castingUnit
    set callbackTemporaryReal = 200.0
    call ForGroup(ENUM_GROUP, function damageUnits)
    set castingUnit = null
    return false
endfunction

function onInit takes nothing returns nothing
    local trigger mainTrigger = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(mainTrigger, EVENT_PLAYER_UNIT_SPELL_EFFECT)
    call TriggerAddCondition(mainTrigger, Condition(function onEffect))
    set mainTrigger = null /* Nulling static triggers isn't really needed, but doing it wouldn't hurt either. */
endfunction

That would also allow the user to use non-static methods in those callbacks, as they implicitly take [ljass]integer this[/ljass] as an argument (or [ljass]integer self[/ljass], whichever you choose).

Perhaps something like a [ljass]callback[/ljass] keyword will be needed, and it may be a bit tricky to implement this with [ljass]TimerStart()[/ljass], as that would require the parser to reserve that global variable and not let any other callbacks overwrite it, because that would screw everything.

Also, please, make anonymous functions follow the same syntax as the current ones in Zinc. That way, you could also provide anonymous methods (Zinc does this as well).

All in all, this is really cool. :thup:
 

Bribe

vJass errors are legion
Timer parameters, if i were to do them, would involve many arrays and a timerutils-esque thing. I could do it but definitely not in the first release.

As far as anonymous functions are concerned, they will certainly borrow locals (readonly) from the containing function. So the "lambda nothing" and "lambda boolean" convention is a lot neater than a verbose way of pretending to add parameters to that code.

Zinc does anonymous (non-static) methods? It only does static methods as code arguments from all the tests I performed on it. Vex had said he would add locals as readonly to the anonymous functions declared within that function, but he never got around to it.
 

Solmyr

Active Member
As far as anonymous functions are concerned, they will certainly borrow locals (readonly) from the containing function. So the "lambda nothing" and "lambda boolean" convention is a lot neater than a verbose way of pretending to add parameters to that code.
Awesome and infinite times better than what I suggested (ironically, I had even screwed up the example code, but fixed it right before you posted).

Zinc does anonymous (non-static) methods? It only does static methods as code arguments from all the tests I performed on it. Vex had said he would add locals as readonly to the anonymous functions declared within that function, but he never got around to it.
Okay, I have no idea what I was thinking when I wrote that. You're right, it only supports function and static methods. Well, Zinc also supports function pointers in conjunction with anonymous functions, but I have no idea how it will be done in Luck.
JASS:
type myFunction extends function (unit);

function onInit() {
    myFunction callback = function(unit whichUnit) {
        KillUnit(whichUnit);
        BJDebugMsg("Killing a " + GetUnitName(whichUnit));
    };
    callback.evaluate(CreateUnit(Player(0), 'hfoo', 0., 0., 0.));
}

I'd really appreciate it if you shared your thoughts on the syntax for interfaces, structs, function pointers, loop constructs and so on and so forth.
 

Bribe

vJass errors are legion
I am undecided on how much I want to invest in interfaces, function pointers and polymorphism. The initial version of Luck will not have these as I want to save my brainpower for things that actually matter. Function pointers compile really badly and can encourage bad programming practice (like calling them a bunch of times from a projectile system, yikes!)

loop constructs:

Currently I am not including for-loops, the loop construct is this:

Code:
while true
    i--
    until i == 0
#Compiles to:
loop
    set i = i - 1
    exitwhen i == 0
endloop
#Or you could write:
while i != 0:
    i--
I haven't revealed this yet but I suppose now is a good opportunity. You can define your own codeblocks, because some structures can get REALLY complex and it's just easier to hide the bloat from the user.

Code:
lib MyLib:
    class myClass:
        codeblock myCustomLoop(int x):
            x = 15
            while x <= 0:
                codeblock.include() # I am not sure how I want to include the user's block, this kind of fits
                x--
        onInit:
            t = trigger.create()
            myClass.myCustomLoop(int i):
                t.onPlayerChatEvent(i.player, "", false)
                t.onPlayerUnitEvent(i.player, EVENT_PLAYER_UNIT_LOADED)
 

SanKakU

Member
what is the problem with static ifs in a pre-made system?

obviously they make little sense in your own map, unless you plan on extensive changes in the future

but still, they are not pointless

and whats it matter what the .j looks like once compiled - who needs to read it anyway?
static if in the premade system means various differences in achieving the same ends. comments are generally used to explain the differences very minimally. often the comments lack proper explanation. upon further examination, it can be found that static if can be replaced by a comment line.

a static if provides nothing new to the system. the only things it offers are this:
increase of standardization.
decrease in creativity.

i would never want to be party to a decrease in creativity.
 

Sevion

The DIY Ninja
Um. Static If's allow for more efficient settings and other stuff.

It does nothing to decrease creativity...

It's like if I'm using AIDS, I don't need that useless code to account for AutoIndex. When you use a static if, the compiled code only consists of the code that refers to AIDS and none of that if AIDS then AIDS syntax elseif AutoIndex then AutoIndex syntax.

I don't think you understand static if's at all.
 

Solmyr

Active Member
Okay, it doesn't really matter, but there are anonymous (non-static) methods in Zinc (so I wasn't wrong). However, they behave just like anonymous functions that take "this" as an argument. And what's more, they have to use a function pointer and have to be called with [ljass].evaluate()[/ljass] or [ljass].execute()[/ljass]. Pretty stupid, if you ask me.
JASS:
type testMethod extends function (integer);

struct testStruct extends array {
        
    private static testMethod anon;

    private static method onInit() {
        thistype this = testStruct(0x7FFFFFFF);
        anon = method() {
            BJDebugMsg(&quot;Calling an anonymous method; struct index: &quot; + I2S(integer(this)) + &quot;!&quot;);
        };
        anon.evaluate(this);
    }
}
 

Romek

Super Moderator
Staff member
I'm not too keen on the indentation based syntax either. I prefer a clearer way of defining 'blocks', with {}, end, or anything else, really. I can't even give an objective reason for it. It's just personal preference, really. :p
Good luck with your project anyway.
 

Sevion

The DIY Ninja
I agree that it might take some getting used to.

However, it's better than what it was before (original Luck syntax).
 

Weep

Godspeed to the sound of the pounding
Wait, wait, what's this about indentation/whitespace being syntactical? It should only be there for organization/visual neatness; parsers should ignore/remove whitespace.

And, tabs are much, much, much easier to work with than multiple spaces for indenting.

IMO.
 
General chit-chat
Help Users
  • No one is chatting at the moment.
  • The Helper The Helper:
    that sucks
  • jonas jonas:
    @midnight8 how is it looking
  • midnight8 midnight8:
    meh, me, wife and her friend thaty traveled with us all have covid, seems to be winding down some for me at least. Felt like complete shit, been sleeping a lot, just bieng lazy as hell. I feel like that today has probably been like 11 or 12 days since exposure. Have not had any fever today, and have not taken any meds, so hopefully by monday or tuesday I will be good to go, sadly have passed it on to our teen son, I guess that was pretty much unavoidable
  • The Helper The Helper:
    hope you get to feeling better and get vaccinated my friend
  • midnight8 midnight8:
    I will at some point, but so many vaccinated people still getting it. One of the bands we watch in vegas, all 4 had been vaccinated and are now positive.
  • Ghan Ghan:
    Symptoms?
  • Ghan Ghan:
    I think the symptoms are typically less severe if previously vaccinated.
  • midnight8 midnight8:
    I have had all of the symptoms, taste is slightly starting to come back, but smell, no. Honestly, just been a little miserable, have never felt in any danger from it. Being trapped at home sucks. lol
  • midnight8 midnight8:
    meh, got a little fever again this morning, guess gonna be a few more days
  • The Helper The Helper:
    I went to Comicon this last weekend I hope I dont get it I feel fine and I am not vaccinated and did not wear a mask
  • The Helper The Helper:
    Comicon really was not packed though like it was in the past. I am not really worried though it was the most people I have been around in a year.
  • tom_mai78101 tom_mai78101:
    Still, getting vaccinated is a good idea. We're getting Delta variant spikes here in Boston.
  • The Helper The Helper:
    I am not against vaccination at all I just have a serious procrastination problem I plan on getting vaccinated soon
  • midnight8 midnight8:
    was kinda same with me, I was gonna do it, and life got in the way.
  • midnight8 midnight8:
    we wore mask in some places, but at 118 degrees outside, little rough. :)
  • The Helper The Helper:
    yeah i had another friend in Vegas talking about that heat damn
  • The Helper The Helper:
    Well I do not think I got Covid from the Comicon
    +1
  • tom_mai78101 tom_mai78101:
    Pushed out a new Pokemon Walking algorithm build. With a new system in place, I'll probably start tackling triggers and NPCs,
    +1
  • Varine Varine:
    Is it fucking hot everywhere?
  • Varine Varine:
    What's a pokemon walking algorithm?
  • jonas jonas:
    it's an engine for pokemon games that closely emulates the walking behavior of pokemon red/blue/yellow
  • jonas jonas:
    basically if you wanted to implement pokemon yellow from scratch, and you'd want it to feel as close as possible to the real thing, you'd start with that
  • Varine Varine:
    Like from the Gameboy games? I'm not at all familiar with Pokemon.
  • jonas jonas:
    yeah
  • The Helper The Helper:
    I only played the Pokemon games on the Gamecube and Wii and such not on the portables my kids had all those games but I never really played on the portables. Now that I think about maybe once sooooo long ago.

    Staff online

    Members online

    Affiliates

    Hive Workshop NUON Dome
    Top