Search results

Such as? Admittedly the switch from using dynamic triggers to using static triggers takes some getting used to (especially if you've used the former for a good period of time, personal experience), but once you do change over, using static triggers for everything actually seems the more...

TimerUtils is perfectly okay to use. I doubt you'll have 60 5-second-stuns running at the same time... And besides, for most applications you won't exceed the timer limit. To recycle the timers yourself you do this: struct stun timer t static method create takes nothing returns stun...

How is this system different from Joker's? Anyway, have you considered using //! ObjectMerger to generate the necessary object data? Makes implementation a lot easier. You're better off using TimerUtils for this, or just recycling the timers with the struct instances as you go along. From what...

Why register events for every unit in every trigger? You could just as well work with a single trigger with the registered events for every unit. That saves on the handle count - which is good when using some systems. Anyway, take a look at this: it's a damage detection snippet that's very...

Would string leaks break this? For example, if it's used in a map that constantly has random strings generated.

Well, there's a lot of it, and I didn't think it was relevant. It's some pretty straightforward linked-list stuff anyway, and I'm positive the problem isn't there. I narrowed the problem down to this bit too, so...

Is there anything in here that could potentially cause a crash? static method display takes unit subject returns nothing local object o = .Objects[GetUnitIndex(subject)] // GetUnitIndex() is working fine. Objects is a normal, static struct array. local string final = "" loop...

I think you've misunderstood - this doesn't fix the problem with Ammorth's original incarnation of the script. I can't see how units automatically removed by the game upon decaying would fire events with the code above. Surely you tested Ammorth's version? Side note: why would you want to...

Not for small/medium maps. It's viable. You shouldn't create them so densely, though. A problem with trackable-filled maps: it's hard/impossible to issue unit orders. So, you have to detect everything via mouse movements and mouse-clicks. A possible workaround/substitute for a trackable-filled...

CSData + CSSafety = TimerUtils. Why not use that? :P This could actually run with no external systems and a single timer, if you want. But then, I suppose lots of people use TimerUtils. Flare is right; you don't need the wrapper function. Good work, I guess.

The NewGen WE won't work on Mac at the moment, and I've never heard of any plans to make it compatible. Maybe you could try running JassHelper (the program that preprocesses the map script) from command line? I recall people having problems with it, but it might work for you. I don't own a Mac...

Hmm, it does seem like it wouldn't matter much. Anyway, I saw that 4.0 was out at WC3C before the recent downtime, so it should be posted here as well soon.

To elaborate, .create() returns an instance of a struct. Structs that use .create() aren't static, therefore (methods/members can be static, however, but that's another topic); each instance of a struct you create has its own (initialized) members, in a way "attached" to that struct. Recycling...

Is it? Do you mean how the callback function Handler does nothing when no functions are assigned?

Not necessarily. vJass syntax can cause all kinds of compile errors with the normal WE. In my experience, this is usually the case.

Have you looked at the JassHelper manual?

DestroyTrigger() causes problems when a trigger is destroyed without having finished execution. It bugs triggers with waits, for that reason. From what I've read, if you really have to use dynamic triggers, destroy them only when you're absolutely sure they've finished execution (avoid using...

Ahh, I see, thanks for the help.

(Seriously fast.) Doesn't work, I did try. After all, t is reassigned immediately after.

(That was fast.) But aren't handle indices recycled? That's the reason for nulling/reassigning locals, isn't it?