JNGPS Ultimate Libraries

[Dark_Dragon]

Hi guys!

As for thous who dont know I had to delete my JNGPS files coz I was told I had no right to upload it.

So I edited libs a bit and removed some EGUI code which was quite long but was unnecessary to vJass coders.

Let me list few good features from this ultimate group of libraries!

Dynamic Damage Detection (event) Unit Revive System Max Mana/Life Modifier Function Knockback System Custom (groupex) Type Which Is Easy To Use Object Fading Systems Timed Damage Deal Destructable Death Detection (event) Advanced String Functions Function (HtoI) returns always min id "sorted" (1,2,3,4...) Item Stacking and Combine Engine Fast Trigger Group (type: flock) Type (graphic) Advanced (effect) Type (can change pitch, pos...) An lot of easy math functions (usefull) Advenced Threading "StartThread(code), ExecuteCode(code)"...

and a lot more but this are main features.

I hope you guys enjoy using this libs!

Libraries.j

Regards!
~Dark Dragon

 

[Nestharus]

Everything should be sep'd out for modularity ><

 

[Dark_Dragon]

well it is true but since its all in one you can just import it and you are done.

 

[Nestharus]

Uh huh... so you're asking people to add 15 systems over adding 1 or 2?

People would rather use single systems than a pack of systems, modularity is better than packing it all together and saying all or none.

You could add flags for removing code if the user doesn't want it, but that's cJASS only ><.

So I suggest you modularize it : )

 

[azlier]

First of all, a megalithic systems meant to do everything for you are terrible.

Now, I will comment on the code itself.

Your function names are terrible, they break the Jass standards.

ExecuteCode is broken. You cannot use it in a function called via ExecuteCode, and GetEnumPlayer will actually return something.

StartThread is trash. It uses dynamic triggers for no apparent reason, and is very slow.

The hooks your system uses also slow down the rest of the map with no real gain.

TriggerAddConditionEx makes no sense. Blizzard's standard shows that adding 'Ex' to a function name means more arguments. Secondly, it is pointless. With the latest Jasshelper the user is free to omit Condition() and Filter().

Your ArrayId function is unsafe and hashes incorrectly. Hashtables are a much better option.

Your round function is... weird. Needs rewrite.

Your ipow and rpow functions... there is a Pow native. Which is faster.

For iabs and rabs, we have BJ functions that do the exact same thing.

Ugh. I could go on forever.

 

[Dark_Dragon]

its just simply that having one library over a lot small ones is good for making a map. if its single spell well then it might be crazy to use this large library for one spell... however for the whole map, its fine since you dont need to import a lot of libs. on the other hand you can pick libs which you want yourself and thats fine as well. think of this as group, timer and all other utils on one place. pick that what u want and enjoy!

k now ExecuteCode inside ExecuteCode is odd! there is really no reason for that and GetEnumPlayer... who cares does it return smth? you want to quickly execute code and thats the way to do it... StartThread is not slow and its good! dynamic trigger was supposed to be used since its for an single call where you can use sleep...

there is only one hook used and its DestroyTrigger! in order to destroy trigger actions and custom events correctly!

AddConditionEx is good coz it allows you to type code directly, nothing else, just that!

ArrayId... well i forgot to remove that, since vjass has 2D arrays anyway.
round is good and works...

ipow and rpow are to be used as int or real in specific way, but yeah you can always use Pow native. iabs and rabs are better then BJ-s!

there are indeed few funcs like ipow and rpow which i think could be removed but still i liked this and so i wrote them... its not like they have to be used.

 

[Kwah]

This is useless.

 

[azlier]

>>in order to destroy trigger actions and custom events correctly!
You should have a separate function for that.

>>there is really no reason for tha
Sure there is. You'd better document that flaw.

>>there is really no reason for that and GetEnumPlayer.
Flaws are flaws.

>>AddConditionEx is good coz it allows you to type code directly, nothing else, just that
If you read my post, you would know that you can do type just the function into TriggerAddCondition, too.

>>round is good and works...
Round is not done correctly.

>>iabs and rabs are better then BJ-s!
iabs and rabs ARE BJs.

>>dynamic trigger was supposed to be used since its for an single call where you can use sleep...
The dynamic trigger is not needed. At all. It only slows it down.

 

[thelifelessone]

This is useless.

I agree. It is pretty useless.
If someone really needed anything in this, they could just make it.

 

[Dark_Dragon]

I agree. It is pretty useless.
If someone really needed anything in this, they could just make it.

ofc just bring this whole thread down, why should anyone use anyones else libs?
ohh wait whats the purpose of THW? hmm...

>>in order to destroy trigger actions and custom events correctly!
You should have a separate function for that.

>>there is really no reason for tha
Sure there is. You'd better document that flaw.

>>there is really no reason for that and GetEnumPlayer.
Flaws are flaws.

>>AddConditionEx is good coz it allows you to type code directly, nothing else, just that
If you read my post, you would know that you can do type just the function into TriggerAddCondition, too.

>>round is good and works...
Round is not done correctly.

>>iabs and rabs are better then BJ-s!
iabs and rabs ARE BJs.

>>dynamic trigger was supposed to be used since its for an single call where you can use sleep...
The dynamic trigger is not needed. At all. It only slows it down.

1) i could but its a waste, and second... why where hooks added? to look at em...
2) if you really want to have func inside func, than just make it an normal func and call it the normal way! i added that ExecuteCode coz i needed speed and i dont care if it cant be called inside of ExecuteCode... lol

3) how is GetEnumPlayer() a flaw? why should it return null? if it returns player(0) how would the code bug? first of all you even should not use GetFilter/EnumAnything inside func, only in enum/filter funcs... if you know that its logical that you wont be using this in ExecuteCode...

4) i know u can use Filter/Condition but i want to do this: AddCondEx(trig, function test)
that function can return nothing as well!

5) then show me whats wrong, in which cases it does not work and how would it be correct, else i wont belive u!

6) every custom func is a BJ! question is... can it be coded better? do i like to see SomeFuncBJ and such a long names in my code? can i make it even faster? and such.

7) every action slows down PC, static triggs would just leak a lot here and really how much slow does it get? its more important to clear memory from leaks now to improve speed later than few nanoseconds here...

This is useless.

you are such a simple being...

---------------------------------------------------------------

btw there are a lot of systems and all that that use hooks, LeakHelper being one of em! but its approved so dont tell me i cant use 1 hook in large engine.

btw this whole library is modular, why would it not be? just coz its a group of libs does not mean its not modular... in fact thats great coz one uses another and it makes code more readable and faster. for example i made DamageDetection which only generates one main trigger. i could have do that for each trigger i needed in each lib, but that would leak events and would be slow...

i have already said this is great for making maps, saves time and is modular.

if there is an bug in code and func does not what it is supposed to then i would like to know about it. however comments like: omgz this takes 1 more nanosecond than it should have! i dont want to waste my time on this coz i have campaign to make and more important things than reading "this is useless!"

such constructive comments shall be ignored ofc.

i am not saying that this libs are "best code ever" but i know i made them and i know that they dont suck. if you cant find use for them that does not mean they are useless! coz i never found the reason to use a single library that is not made by me... that does not mean that libs are useless.

as i said before if someone founds bugs ill try to fix them asap, but i wont waste my time reading or answering on "funny" comments again.

Greets!
~DD

 

[azlier]

>>why should it return null?
How would you like it if GetTriggerUnit returned something in a timer callback?

>>i dont care if it cant be called inside of ExecuteCode...
I told you to put that you can't have one ExecuteCode function call in a function called via ExecuteCode in the documentation.

>>i want to do this: AddCondEx(trig, function test)
...

call TriggerAddCondition(someTrigger, function test)

That compiles. And conditions returning nothing cause Mac users to desync.

>>in which cases it does not work
I didn't say that I doubted it would work. I said that it could be much shorter and quicker.

This is freehanded.

function Round takes real r returns integer
    if r < 0 then
        return R2I(r - 0.5)
    endif
    return R2I(r + 0.5)
endfunction

>>can i make it even faster?
TESH can autocomplete the BJ names for you. Your argument is invalid.

>>static triggs would just leak a lot here
Nonsense.

Once again, freehanded.

globals
    trigger someTrig = CreateTrigger()
    triggeraction someAction
endglobals

function StartThread takes code c returns nothing
    set someAction = TriggerAddAction(someTrig, c)
    call TriggerExecute(someTrig)
    call TriggerRemoveAction(someTrig, someAction)
endfunction

Editelicious:

Why are you using constant handles at the top of your code? That is a terrible idea.

 

[Deaod]

And conditions returning nothing cause Mac users to desync.

Does that still hold true for 1.24c? I remember seeing a note in the changelog suggesting that this flaw has been fixed. Never tested that, though.

Once again, freehanded.

Sadly, thats still what id consider a dynamic trigger, as youre modifying the setup of the trigger at runtime. WHY THE FUCK DONT YOU USE FUNCTION INTERFACES? We dont NEED some script that starts a code variable in its own thread, when a simple ".execute()" can do that as well. PLUS, YOU CAN PASS PARAMETERS. Oh, and whining about RAM usage is about the worst thing you can do. Youll leak more by destroying groups than what static triggers will EVER eat up.
Its a fact that CPU time is a few times more valuable to us currently, than bytes of RAM are. Whatever you do, it wont fail because you filled the whole memory (unless you leak, in which case you deserve it).

Split the whole file up into multiple (digestible) pieces, so maybe parts of it can get approved. From what im seeing though, you wont get far with it (i mean, WHO would need a softcoded float struct?)

 

[azlier]

>>Does that still hold true for 1.24c?
Excellent question.

>>WHY THE FUCK DONT YOU USE FUNCTION INTERFACES?
Calm down, please. I have nothing against function interfaces, nor do I have anything against a StartThread function, although I dislike the latter.

>>PLUS, YOU CAN PASS PARAMETERS
That is the only reason I ever use function interfaces, anywhere else would be a waste in my opinion.

>>modifying the setup of the trigger at runtime
Destroying triggers can cause bugs like handle stack corruption, especially with triggeractions. Safety is more important than speed, but in this case his method is both slower and unsafe.

>>Split the whole file
At last! Sanity!

 

[Kwah]

>>WHY THE FUCK DONT YOU USE FUNCTION INTERFACES?

Calm down, please. I have nothing against function interfaces, nor do I have anything against a StartThread function, although I dislike the latter.

Clarified?

 

[Deaod]

Calm down, please.

Wasnt really directed at you, sorry for the misunderstanding. The yelling was mostly directed at Dark_Dragon.

 

[azlier]

Alrighty then.

 

[Dark_Dragon]

>>why should it return null?
How would you like it if GetTriggerUnit returned something in a timer callback?

>>i dont care if it cant be called inside of ExecuteCode...
I told you to put that you can't have one ExecuteCode function call in a function called via ExecuteCode in the documentation.

>>i want to do this: AddCondEx(trig, function test)
...

call TriggerAddCondition(someTrigger, function test)

That compiles. And conditions returning nothing cause Mac users to desync.

>>in which cases it does not work
I didn't say that I doubted it would work. I said that it could be much shorter and quicker.

This is freehanded.

function Round takes real r returns integer
    if r < 0 then
        return R2I(r - 0.5)
    endif
    return R2I(r + 0.5)
endfunction

>>can i make it even faster?
TESH can autocomplete the BJ names for you. Your argument is invalid.

>>static triggs would just leak a lot here
Nonsense.

Once again, freehanded.

globals
    trigger someTrig = CreateTrigger()
    triggeraction someAction
endglobals

function StartThread takes code c returns nothing
    set someAction = TriggerAddAction(someTrig, c)
    call TriggerExecute(someTrig)
    call TriggerRemoveAction(someTrig, someAction)
endfunction

Editelicious:

Why are you using constant handles at the top of your code? That is a terrible idea.

1) well it would be better if it returned null! ofc i am not saying it should return any player value... however if it can be faster than other methods i selected this one.

2) i will change that and say in comments it cant be called inside ExecuteCode

3) that round function is better than my and both work, so i guess ill change it the way you made it.

4) fair

5) well its k as u coded it but why is triggeraction not an local? its not slow to null it. as well ur example is same as my executecode... if i use this inside of another func i would create an loop which is (infinity^infinity) loop so basically infinity. the main problem is that in your example you cant use sleep. so just use execute_code as its faster. reason why i coded start_thread is coz i wanted to allow sleep usage with code param.

6) why is constant handles a bad idea?

7) this is most important and i CANT belive that code can become boolexpr... wtf? boolexpr is loaded in table of funcs and how can your code work and my:

boolexpr bx = function Trig_Init_Conditions

this does not work... i mean seriously blizz is making some crazy things...
anyway i did not know that "code" is typecasted to boolexpr only when passed to funcs which take boolexpr.

now for that i give u +rep. if possible i would like to know if it generates new id for that boolexpr and how can i destroy it?

TriggerAddCondition(t, function test)
DestroyBoolExper(function test)

that should be fine? ofc i know if i destroy trigger cond goes down as well but i mean when i use it in different funcs, this is just an example.

one more things is! nothing funcs as boolexpr cause desync to mac users? lol i will have to recode some part of my campaign, through not a lot but still...


anyway thanks for this few tips, i changed the code now.


@ Deaod

i see you still like static stuff, not that i have anything agains it but really wasting ram or cpu... in anyway u look at it stuff is a minor thing (i know destroying handles leaks a bit) but seriously no one will lose ram coz of it nor will cpu explode... i am saying this but it does not mean ur wrong. actually .execute() is awesome but as well if it has different argumens and return type it loads bunch of stuff. if you have same "func type" then it does not load so much stuff. anyway that start_thread was coded to make things dynamic and be able to use sleep. k now why? coz simply sometimes u need to call func only once and generating static trig for that is an lol! if you want you can always use .execute() if you know specific code is executed only once or really rare than use start_thread its just logical.

anyway about dividing this... should i fill this thread with a bounch of libs? its a wast since anyway they need one another so user will need to just search all around for them instead of just using //! import.

Greets!
~DD

 

[Nestharus]

This just needs to get gy'd

end of story


there's no way this will ever get approved ><

maybe sep as everyone keeps saying, but that's the only way -.-

 

[azlier]

The automatic conversion of code to boolexpr is a vJass feature.

And constant handles. They are not any faster. And, what happens when an optimizer goes ahead and inlines those constants...?

>>as well ur example is same as my executecode...
Mine does not cause infinite loops. Testing things is a good idea.

>>but why is triggeraction not an local?
I've already made it a faster global, why change it?

>>that should be fine?
Yes. But I have no idea why you are destroying static boolexprs like that.

 

[Dark_Dragon]

The automatic conversion of code to boolexpr is a vJass feature.

And constant handles. They are not any faster. And, what happens when an optimizer goes ahead and inlines those constants...?

>>as well ur example is same as my executecode...
Mine does not cause infinite loops. Testing things is a good idea.

>>but why is triggeraction not an local?
I've already made it a faster global, why change it?

>>that should be fine?
Yes. But I have no idea why you are destroying static boolexprs like that.

i see so its an vJass feature... did not know that, now its clear so thanks.

k i did not test so i thought its infinit loop but k if its not.

well since boolexpr's take ids i think i should clear memory...
they are as strings stored in tables so they dont leak but still they can be destroyed while strings cant. well i could leave it and not destroy it...

anyway thanks for this boolexpr thing i did not know about that feature.
Greets!
~DD

 

[Eccho]

Boolexpr created from the natives And(boolexpr a, boolepxr b) and Or(boolexpr a, boolexpr b) will leak and must be destroyed.

Boolexpr created from such thing as Filter(function something) will all referece to the pointer of that filter func. Assume you apply the same filterfunc on several boolrxpr's, destroying one of the boolexpr would cause a potential screwup in the code somewhere else. I had this issue, and tested it, it is confirmed.

 

[azlier]

I'm going to go ahead and graveyard this. But taking each library and submitting it individually is most certainly welcome.