| 11-19-2003, 10:29 AM | #1 |
Hey all. I was wondering if someone could lend me a hand with some optimizations. I'm currently playing around with a couple of testmaps (initially intended for a private group of lanparty players), trying to learn as much as I possible can about modding wc3. Before actually deciding on a big project, I just wanted to have some quick fun, so I downloaded a few skins and models here and there. Played around with most of the features that the WE has. Switched to UMSWE at some point, and incorporated tons of spells found in the Spell Vault thread (no worries, I'm not doing this for glory or credits, it's just a way to learn) After a while, things got a bit laggy in game, and at one point a simple ai vs. ai game would take more then 320MB memory, coming to a grinding halt. So I went into debuging and optimizing mode. First up was my own hero glow triggers which were responsable for most of the lag, but I also had a look at some other things. Sofar I did : - Nesting all my glow triggers into 1. - I had a couple of "If <specified> unit enters map, attach this mdx to his hand", which now destroy themselves after the weapon is attached (seeing as how these attachments stay on during the rest of the game) - Rewrote a couple of spells that were using PolarProjectionBJ, these now use either : Code:
function PolarProjectionNL takes location target, real distance, real angle returns nothing
call MoveLocation(target, GetLocationX(target) + distance * Cos(angle * bj_DEGTORAD), GetLocationY(target) + distance * Sin(angle * bj_DEGTORAD))
endfunctionCode:
function PolarProjectionNL2 takes location target, real distance, real angle returns location
return Location( GetLocationX(target) + distance * Cos(angle * bj_DEGTORAD), GetLocationY(target) + distance * Sin(angle * bj_DEGTORAD))
endfunction- Merged all the spells that had a trigger to check if the spell went up a level into 1 general trigger. - Starting replacing "triggering unit", "entering unit", etc with a variable per trigger, to speed things up bit by bit. Is there anything more I could do to optimize them ? I've read a couple of threads about optimizing, but at some point these become to advanced for me (at least, currently to advanced.... ;)) (In doubt whetter to link to the map or not. It's 4MB, and mixed with my own stuff and lot's of downloaded stuff. And while credits are sort of in place, they are pretty general at the moment) |
| 11-19-2003, 01:39 PM | #2 |
well, for the glows, u might try to edit "item attack bonus fire" (or something like that, it's the orb of fire ability) ability, and use triggers "if player color equal to blue, attach BLUheroglow to unit's origin" etc :) oops, forgot to explain about the ability editing :) (in case u don't know it) make a new ability of the one i mentioned, set all values to 0 and edit the model u want atached to u'r heroglow, and the "place" to origin... some say that if u use the black one (heroglow.mdx), it will change colors automaticaly for the owning player....some say it only happens when a NEW unit is built or trained, and not for pre-placed units... i suggest trying out that method, and if not, revert to triggers... so instead of creating a spec. effect, give it the ability, so when the unit dies and waits for reincarnation, the glow will dissapear, and appear when the unit comes to life... hope it helps :) |
| 11-19-2003, 01:51 PM | #3 |
Actually, the glow trigger mess wasn't really a problem anymore, it just was the one thing that got me into optimizing in the first place. If you check here, you'll see that the glows allready have been made working quite well. I was kinda hoping someone could make some more suggestions, other then the ones I allready listed, to remove even more of the lag/memory hogging. |
| 11-19-2003, 01:58 PM | #4 |
well, i add the heroglows the way i described it to you, and it doesn't lag that much...maybe not at all :) and i'm not sure if u need to create a variable for each triggering unit" "entering unit" etc, cuz they are general variables that are there so u won't have to create any other variable :) |
| 11-19-2003, 02:06 PM | #5 |
Triggering Unit is not a variable, it's a function, in JASS it's GetTriggerUnit() .... so putting the result in a variable, and just calling GetTriggerUnit() once is better, and does give some improvements. |
| 11-19-2003, 02:16 PM | #6 | |
Quote:
In fact that is relative, only do that when you are using a rather big trigger with a lot of lines that call triggeing unit. Otherwise it would just be an increase in disk space (and memory ) the trigger uses and will have contraproductive(?) results. Usually having a lot of triggers that use the Unit begins casting an ability event each one with an ability/unit type condition is innefficient. It is better to add an specific unit event to that trigger after the unit is created |
| 11-19-2003, 02:29 PM | #7 | ||
Quote:
Thanks for the confirmation on that, I was processing the biggers triggers first, but now I know that should be enough, as far as that part is concerned. Quote:
You know, I hadn't thought of that until now. Should work perfectly, since most of the spell-triggers are for hero spells that only 1 specific unit has. This should save tons I think :ggani: Thanks muchos for suggesting it! |