Map optimizer 3.9 comments

don't suppose it's posible to fix all the gui trigger's memory leaks with a tool like this?

I don't get what you mean,

Apparentally there is a bug with the new method, avoid to use it, I am going to fix it and release new version by tomorrow

bug: i still can open the optimized map in WE while i already disable "allow map preview" when optimizing ..

New version, 3.2 (Can't change thread name).

Some fixes and new method.

escpy: Which of the options is called "Make world editor crash"?

Nantuko_Husk said he had a compression code that was better than your optimizer.... Posted here So ask him for the code.. to check if it is better

when optimizing, i disable "allow map preview"
after optimized, i can open the optimized map in WE

What I mean is if you use gui triggers instead of JASS they have a bunch of memory leaks that need to be fixed by lines like "custom script call RemoveLocation( udg_tempPoint )" would it be posible to catch these leaks and automaticly add those lines?

When I optimize my map, it corrupts it. I cannot create any games because there are no player slots.

This only happens when checking 'Shortest variable / function names possible'. I guess this obfuscate method doesn't exactly get along with WEU?

well i actually said that removes some spaces vexorian's doesnt.

what are those 'spaces'?

this is how optimizer will make function a,right?

function a takes nothing returns string
return "string"
endfunction

but i noticed that even if it is like this will work.


function a takes nothing returns string
return"string"
endfunction

or with integers

function b takes nothing returns integer
return'A000'
endfunction

and such,but i havent made andtibj and such,and i wont make.

so i said because there should be a considerable amount of them in maps.

so it should remove 2-3kb

v3.2 bug: same as v3.1 .. i still can open my optimized map while i already uncheck "Allow map preview" during optimization

If you try to open it in WE. I'll tell that that won't work. But if your trying to open in it Warcraft thats another things, and I guess Vex's want to have a copy of your map then.....

But there no PM's anymore...... What about zipping the map and put a password.. so I can easly crack the password , but thats nothing I will do :P

Erm.
For some reason, vexorian optimiser gives me a "Error Opening File" error even when i run it with nothing checked.
The error happens after it tells me that a file C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\V110.tmp was saved successfully.
This only happens on a version of the map which was previously put through widgetiser with all options checked.
Can someone help me with this?

those are just some extra spaces on return values and I guess also if or exitwhen, compared with the reduction of Shortest names possible and the merge functions, the optimizer compresses the map script much better.

I would delete those extra spaces too, but I don't feel like that, I will see.


escpy, None of the options says "make sure WE won't open the map" , I made it so optimized maps may be opened with World Editor, they lose all the important data so nobody can watch triggers and saving would delete everything including imports.

The reason behind this is that a hacked version of the world editor is able to open the optimized map anyways, so better force the stuff to prepare the mappers to the fact that people may see their object data.

Although that issue is fixable by using Widgetizer.



qwertyui It is supposed to work on widgetized maps, are you sure that it only happens with widgetized maps, may you send me your widgetized map through email?

That wouldn't have any sense.

Please hexenlord pm your map's script through email.

By the way there is a bug when you check Shortest variable/function names possible' you also have to check the 'Make sure to clean every unused function' in order to make it work, in case you also use the 'Optimize BJ functions' options without 'Make sure to clean every unused function' it will surelly corrupt the map script,


There is no practical safe way of knowing if the pointer of a location is not saved, the same happens with any handle, it wouldn't be a good idea to make it remove leaks for the mapper, so let the people learn about memory leaks instead of expecting a program do their work.


Let's see a space per return value. That would be a byte per function with a return value like that.

2-3KB would be 2048 - 3072 bytes. So 2048 or 3072 functions with a return value of that kind?

Also Map script gets compressed with a compression similar to zip when added to the map so it is not really a big deal.

I will add that though, although some of the methods depend on the space removal method to be able to do their work correctly

BTW I meant a part of his code....... ..about the 2-3kB removing, maybe Nantuko_Husk likes making many functions?

no,i didnt say anywhere that is a big deal,i just said that those could be removed without causing any problems to the script.