Jesus4Lyf

Insanity is just another word for those who make no sense and do completely random things without reason.

Sometimes this lua stuff can be a real time saver.

I wrote something that takes an external file, processes stuff like "AHav avatar" into "call Register('AHav' , "avatar")" and imports it into the proper place. Makes making long lists of specific spells cake.

Oh yeah. I figured that one out ages ago, though.

@Azlier AceHart?

I was browsing da intranets when I saw someone familiar. Is this as new to you as it is to me?

Thanks... but how do you use vectors in Jass? Like you're going to set a unit's position?

Hmm... what are vectors?... I'm only 12 so I don't know.

I succeeded in only crashing their Warcraft. I made the Soul Gem item called "Sexy Item", "Click and target self for sexy actions!". Then I told them to select their hero portrait to get it back. Then:

"Waiting for Players:
[ ] Player XXX"

Wait. Now it crashes their wc3 only T_T
Not their CPU

Dear Jesus4Lyf,

I am most upset as to how SoulGem target self and click didn't crash other people computer. My friend told me only I lagged out. God damn him. Everyone else was fine. Lucky I was in windowed mode.

SO what do I do?

From Mr. Apple Juice

Well, I can't really complain if you agree. Unfortunately, some in the TheHelper community have wound up obsessed with "performance" and benchmarking things that don't need to be benchmarked. It's like some systemic problem over here.

Anyway, about benchmarks. I thought you might find it interesting to know that all the work that AutoIndex does when a unit enters the map adds 7% to the amount of time unit creation takes. Each AutoCreate implementation (which adds TriggerEvaluate + function calls + other work) also increases the time by about 2%. If you do some precise benchmarks for AIDS, perhaps we can see what the differences are.

Any processing capacity in excess of what's required at any given moment is just wasted. Nothing matters until you actually hit the point where framerate goes down, and that is totally impossible to reach for modern PCs without bottlenecks or poor code design. The incredible volume of code my physics engine was able to run on 200 units at 40 updates per second was enough to see that. There's also the corollary of this observation, which is that nothing matters performance-wise unless it's executed periodically (or has some other persistent effect, like increasing memory usage).

With that in mind, the value of usability vs performance swings distinctly in the favor of usability, and that has big implications on the design of systems. The goal should be to create an awesome API and work backwards from there, without exposing any of the implementation details to the user.

Even if you got rid of all of those minor "optimizations" and the convoluted coding style in Rain, it wouldn't affect the framerate. In the demo map, it's entirely dependent on the user's graphics card and how many of those rain SFX it can handle onscreen.

Anyway, this is just indicative of the whole issue. Your code often (not always) compromises its design in order to go after imaginary performance boosts. The only time performance should overrule design is in a very few cases where it will actually affect the user's experience, not just for the hell of it.

The only reason I bother to flame you is because many of your systems are useful in concept, but they often wind up with a lame API or mangled internal code. I know that you see those design choices as the best compromise to ensure maximum performance, and I used to think along the same lines a couple of years ago, but then I realized that the common fallacy that all these minor opimizations somehow add up is really flawed.

From grim002 (part 1):

Your coding philosophy of "mangle the code as badly as possible in the name of efficiency" is insane. The systems you create often have APIs that force the user to jump through hoops just to compensate for the way it's coded.

The fact is that none of the lengths you to go in the name of 'efficiency' are actually going to increase the framerate that a person playing a map will experience. Since you have never made anything that actually pushes WC3 to its limits performance-wise (like a physics engine), you apparently don't understand what the actual performance bottlenecks are. They certainly aren't the things that you encourage people to worry about.

From grim002 (part 2):

Following your efficiency guidelines simply makes it less likely that people will properly finish or maintain a map. Instead they'll double their development time worrying about pointless nonsense like: how to avoid declaring local variables, how to avoid declaring too many triggers, and how to deliberately avoid using higher level features like function interfaces, etc. None of which will actually increase the framerate of the finished map.

If professional programmers thought like this, it'd take 10 years to develop a game since they'd be doing it in assembly language.

Hey Jesus4Lyf,

I was just reading over the "knockback" system that Dr. Jack wrote. In the thread you talked about using Event to fire off triggers at the end of a knockback.

I was just wondering what you thought the correct way to go about this was.

I had two options in mind (the first of which I thought was the most sane).

1.


or:

2.


What are your thoughts on the matter?

Hey, you reckon you can check in on the last few posts of the Linked List Module thread and suggest improvements, as I am pretty sure you have a better way of doing the things I did.

I wanted to modify some of the statistics on all of the buildings at once. I used an ObjectMerger lua thing to register all the buildings so that future changes wouldn't need so much time to perform.

Compiles in the blink of an eye.

It took me an hour to register the rawcode of every building in WC3.

I'm loving this external block lua stuff. It compiles so quickly and makes development so much faster.