Reaction score

Profile posts Latest activity Postings Experience Resources About

  • In response to your post in the "RegisterAnyUnitEvent" thread, the condition does not need to return true, because this will run just fine and print "Hello\nWorld":

    trigger t = CreateTrigger();
    TriggerAddCondition(t, Filter(function ()->boolean
    return false;
    TriggerAddCondition(t, Filter(function ()->boolean
    return false;

    The only time when the trigger's return value matters is where triggeractions are concerned or when you need the return value of TriggerEvaluate.
    Well when you normally reference "data.member" it compiles to "member[data]", but when you use delegates it turns into "member[delegate[data]]" thereby adding an array lookup.

    Honestly, you'd be better off extending a struct.
    I removed the slide system ;P
    I implemented it a very long time ago before I knew using interfaces and shit like that creates a lot of script.
    I had many spells that used structs extending the slide struct =P

    I replaced it with a simple knockback system that I wrote myself ^.^
    No it isn't more intuitive, it doesn't make sense that it actually doesn't keep the relative order but reverse it.
    What do you need updated? Just adding a RecycleMissileEx that only releases the missile after a period of time?
    Dirac think about two targets just shooting at each other, or a battle going on with multiple units. Maybe if you only play DotA where people are kiting all day you might have this idea about targets moving 90% of the time, but that is really a misconception. Targets are very often standing still, and in my experience it's more about 70-80% of the time the target is not moving. I had been playing this game since about 3 months after the release of RoC.

    Some things, like the arc/gravity of a missile, can be precalculated just once, especially for non-homing missiles.

    For colliding missiles, you should have a method named "onCollide" if the user wants it. And instead of calling "onImpact" you would call "onCollide" for people who don't want collision support in their structs you can have a "static if thistype.onCollide.exists" for that entire collision block.
    One good advice is to not re-calculate all the values unless the target has moved from its previous spot. Currently you keep re-calculating even if the target is standing still.

    You can also pre-calculate arc and things, without calculating them each time per loop.
    Add me on my second skype (because I can't use my normal skype right now >.<)

    Nothing much ;p
    Just trying to jailbreak my iPhone :eek: (Apple still won't accept anything other than American Express cards :/)
    I don't have forum settings control, just thread control. That power rests with Rui or Ralle, and none of them have gotten back to me regarding this issue.
    I can post new threads, and I don't see why a moderator would have a different permission setting. I will look into it.
    It's either that or use the destruction method Nestharus showed you, however the method will pretty much never be called (it is just there for completeness).

    I can just inline the destruction of each individual trigger into that loop and combine it with Nestharus' method. I probably will it's just I haven't gotten to it yet.
    That RegisterEnterRectEvent in the Small Code Snippets should it's own resource :D
    You can also add a RegisterLeaveRectEvent :)

    I find it very useful.
    No basically I'd either want the one you have or the one I made. I'd call mine LinkedListLite for example.
    I wouldn't waste methods like that. Map file size is very important and JASS code adds a lot of it unfortunately (really bad MPQ compression).
    I understand the function but I don't understand why something like "clearNode" or the "prev" operator has to be generated when I don't want it. Well that's why I code my own stuff, because you want a modular thing and I want a lightweight thing.

    I recommend you make the "head" member public then. And make all the members public as well. It makes sense because of the way you're treating things, and it will help cut down on the verbosity of the code.
    You forgot onInit, and all your method operators. Yes they inline but Vexorian's optimizer doesn't always remove inlined functions which sux.

    Your naming convention is weird. The name "Node" should represent a node within a list, but you use it to represent the list itself.

    Does .flushNode destroy the head node? It looks like it does, because you set .head to false. If it does, its name should be back to the original deleteList.

    In your Advent mockup you don't use .clearNode, so that is one useless method.

    The LinkedList which I wrote would also work great for Advent. Two methods and two method operators, and no unwanted features.

    Your "create" method should define whether it is a node or a list that is being created. Your "destroy" method should also work whether it's a list or whether it's a node. These changes will help you cut back on overhead functions.
    Yeah I know, that's why I sent a VM so that we can keep the thread from going too much off-topic. I just thought I would let you know so it doesn't come as a surprise later.
    Your backpack library will bug with charged items. You could drop a charged item after using one charge, add it to the backpack and then the item has full-charges when you retrieve it.
    Pharaoh_ sent me a PM with a link to that quote, but I had to delete all my PMs because for the third time, my PM box was full :x
    Then I have to do trigger recycling which takes up a lot of handles in inventory :/

    I think using ExecuteFunc is the best way to handle it overall. Just with a disclaimer they can't use concatenation if they use the optimizer. Frotty needs to release his system soon so we don't have to do this madness!

    ExecuteFunc doesn't use any handles, which is 100% awesome.
    I suppose it could take code but then you'd be dealing with either:

    1. Hashtable lookups to remember the triggers via the boolexpr that remembers the code value (which is doable but I think adds an unnecessary overhead)
    2. Adding/removing conditions dynamically which is way sucky on performance.

    Either way is worse than just using a module to initialize a trigger once, like this:

    module Missile
    private static method onHitProxy takes nothing returns nothing
    call thistype(GetEventMissile()).onHit()
    private static method onInit takes nothing returns nothing
    static if thistype.onHit.exists then
    local trigger t = CreateTrigger()
    call PreRegTrig(t, function thistype.onHitProxy)
    set t = null

    It's too bad "code array" does not compile. That would make this whole thing WAY easier.
    I was using ExecuteFunc but when I wrote it, it was in vanilla JASS where you don't have to worry about private prefixes. The vJass one would end up having to use a module where I initialize a certain function to a trigger, just to avoid function interfaces.
    Dirac it looks pretty good however it can be simplified, for example you don't need an "Asin" every loop.

    I will upload my missile library to pastbin later so you can see what I've got. I think my code is a little bit longer, maybe because it supports more stuff like "onImpact", but it's the most lightweight missile system I could make because everything else was too much for my crappy CPU.
    Not if you use them for things like variables, modules or structs. If you use them on struct methods or normal functions, however, they will cause problems.
    Until we can make a Quantum measurement, you are and aren't a deceased physicist who's into Jass Programming.
    Congratulations! According to the universe, you are validly dead ;D

    I was reading a few articles on Quantum Theory and totally understood everything ;o
    Or did I!?! According to Quantum Mechanics, I did and didn't :ogre_hurrhurr:
    And in some other universe, I got hit by a giant pickle while reading the article, and I'm in the hospital -> But at that point, the universe branches to satisfy all the possibilities: - Ambulance crashed and did not crash
    - Giant pickle hit ambulance and did not
    - Ambulance hit giant pickle and did not
    - etc..

    Ain't quantum mechanics a kick? :ogre_hurrhurr:
    Reputation (+4):
    (Post) basically, if ur going to use a function which will return the same values, its better to set the returned value of that into variables first...
    You can do as you'd like. I don't mind having competition or anything, and mine is more of an extension of Nes's Damage System so I think you'd actually have more feedback/competition from Nestharus than me. :p
    It's not that T32 is bad, it's that CTL is faster :D
    T32 is perfectly fine, but what it does wrong is keeping the timer on even with no instances :p
    Yeah, I suppose that is a nice perk to using triggers. :) Although, I'm not exactly sure why someone would want to rename onDamage to something else aside from just preference. xP
    If you never set it to a local the (nonexistent) local does not have to be nulled.
    I can see that ;)
    You seem to have lots of popularity on TheHelper :p
    Over there, I suck D:
    I'm just this random guy that would go around failing like a boss xD
  • Loading…
  • Loading…
  • Loading…
  • Loading…
  • Loading…