did you try also ervius' ui_string_finder_allargatore?

I tried, but error appears:

Yes man.. Vista problems . works fine with XP

@christ.2004: I think the "offset" is because the buttons on the right side are not in the resolution directory, but in the common directory. I'm afraid you'll have to edit the skin manually for those - at least for now .
@miruim: It didn't work for me under XP, it simply quits after trying to scan the archive directory. I did look at his scripts and understood what he's doing: it's automated patching (like all the patches Gurjon has). I think that might force you to use a particular skin that has what the scripts expect, but I might be wrong.

Ok thank you I'll watch it manually.
A +

Yes man.. Vista problems . works fine with XP

No Vista, XP Pro...
It seems like user rights problem. I'm not run as administrator.

--
Due to fact that most of images and scripts in gurjon skin are in common directory, I converted (multiple x2) this directory too. Much better. Handwork required, but less.

--
Addition to ui rules:

Code: Select all;gurjon stuff:
dQuickPlace1 |ifnumber:scaleY
dQuickPlace2 |ifnumber:scaleY
dQuickPlace3 |ifnumber:scaleY
dQuickPlace4 |ifnumber:scaleY
cellw= |ifnumber:scaleX
cellh= |ifnumber:scaleY

@arkoko: Thanks for the new rules. Can you give me examples of bitmaps from common folder that are used, and the corresponding lines in script? Ideally you should be able to use them still, and do resizing via w=N,h=N attributes in the script, instead of resizing the actual bitmaps. As far as I can tell, bitmaps from common folder have a $ in front of the name.
Now, do they only need to be scaled for bmp="<$name>", or are there any others I should look at, like iconspr="<$name>"? I don't think icons can be scaled this way, since it would scale the entire button instead.

http://www.uploadjockey.com/download/79672/iGoSkinWizard_1.zip
http://w18.easy-share.com/1903045845.html
http://www.megaupload.com/?d=VQGF01MO
http://depositfiles.com/en/files/ueznxc9hb

ChangeLog:
- "resizing" of bitmaps in "common" folder using "w=<width>" setting in .ui scripts: if skin authors want to resize the bitmaps, they should copy them to each resolution directory and change the scripts accordingly - it's a designer's decision that I may support/automate if asked, but don't think it's a priority
- support for .ini files conversion (laneinfo_signpost)
- you can now define your bitmap (i.e., Photoshop) and script (I recommend http://www.wolosoft.com/en/superedi/) editor, and even compare the before/after scripts using http://winmerge.org/downloads/
- various GUI and bug fixes

The first two new features above are experimental, please post feedback.

To revise arkoko's Gurjon settings (edit file Rules.ui, at the end):

Code: Select alldQuickPlace1 |ifnumber:scaleY
dQuickPlace2 |ifnumber:scaleY
dQuickPlace3 |ifnumber:scaleY
dQuickPlace4 |ifnumber:scaleY
cellw=|ifnumber:scaleX
cellh=|ifnumber:scaleY
vgjSpeedCamPozX.set |ifnumber:scaleX
vgjSpeedCamPozY.set |ifnumber:scaleY
vgjSpeedCamPozX > |ifnumber:scaleX
vgjSpeedCamPozY > |ifnumber:scaleY

- "resizing" of bitmaps in "common" folder using "w=<width>" setting in .ui scripts: if skin authors want to resize the bitmaps, they should copy them to each resolution directory and change the scripts accordingly - it's a designer's decision that I may support/automate if asked, but don't think it's a priority

I am not sure how to do that with the skin wizard. Is there something I need to add to the rules.ui?

Can you give me examples of bitmaps from common folder that are used, and the corresponding lines in script?

I'm now not sure, do you still want examples? Your new version already implemented this "resizing" feature.

Anyway, one example. All bmp="$4scr... stuff in gurjon is better ro resize. Otherwise buttons will be too small.
navigatemap_400_240.ui code:

Code: Select all<BUTTON btnNMB_Detour template=btn_map bmp="$4scr_route.bmp#2"     y=53  text="Detour"   onrelease='nextstate st_Detour' onlongclick='run d_recalculate, playsound "!button"'> ;sc_BtnRecalc_onclick d_recalculate
<BUTTON btnNMB_Cursor template=btn_map bmp="$4scr_use_cur1.bmp#2"   y=89  text="Cursor"  onrelease='nPlaceForPos.set 0, run sc_btnNMB_Use_OnRelease' onlongclick='run sc_BTKeyb'>
<BUTTON btnNMB_Pos  template=btn_map   bmp="$4scr_use.bmp#2"    y=89  text="Pos."    onrelease='nPlaceForPos.set 1, run sc_btnNMB_Pos_OnRelease' onlongclick='run sc_BTKeyb'>   
<BUTTON btnNMB_Nav2D template=btn_map  bmp="$4scr_map.bmp#2"    y=125   text="2D"     onrelease='run sc_btnBMC_Compass_OnRelease' onlongclick='run sc_mute_onoff, playsound "!button"'>
<BUTTON btnNMB_Nav2DN template=btn_map  bmp="$4scr_NorthUp.bmp#2"     y=125 text="2D"  onrelease='run sc_btnBMC_Compass_OnRelease' onlongclick='run sc_mute_onoff, playsound "!button"'>
<BUTTON btnNMB_Nav3D template=btn_map  bmp="$4scr_cock.bmp#2"     y=125    text="3D"       onrelease='run sc_btnBMC_Compass_OnRelease' onlongclick='run sc_mute_onoff, playsound "!button"'>
<BUTTON btnNMB_ExOv2D template=btn_map bmp="$4scr_map.bmp#2"    y=125   text="2D"       onrelease='map.SET_OVERVIEW 0' hide>
<BUTTON btnNMB_ExOv3D template=btn_map bmp="$4scr_cock.bmp#2"    y=125    text="3D"     onrelease='map.SET_OVERVIEW 0' hide>
<BUTTON btnNMB_Menu  template=btn_map  bmp="$4scr_menu.bmp#2"     y=161   text="Menu"    onrelease='run sc_btnNMB_Menu_OnRelease' onlongclick='run d_ExitHide'>

I know that better idea is to create correct bitmaps in resolution directory and edit scripts to use them, but this too much work for quick result

Mirror for v.0.7:
http://rapidshare.com/files/178109950/iGoSkinWizard_v.0.7.zip

@Specter: The current version opens the bitmaps in the "common directory, reads the bitmap width and adds a scaled "w=[scaled width]" in the corresponding script line, if not already there (if it's there, the rules already scale it). That makes iGo scale the bitmap internally. This is only done for the bitmaps in the "common" directory of the skin, not for the ones in the data.zip's "common" directory. It would take a non-trivial amount of work for me to offer the following option: when a bitmap is in the "common" directory, the used is asked if they want to make a copy in the desired resolution directory, take out the "$" in front of the name and scale it appropriately. The problem is, I don't know what the appropriate scale it, I just assume the "source" resolution looks ok, and apply the same scaling factors as for the other bitmaps, but that may not always be the case. What I'm saying is that the skin designers should decide to do that on an individual basis, for each bitmap. That means: when you see a bitmap you want resized explicitly (as opposed to my "resizing" method using iGo's internal scaling), you make a copy of it, resize it with your preferred bitmap editor, then change all references to it to no longer have "$" in the name and the "w=[width]" attribute. I know it's a lot of work, but it gives the designer more control over the skin. You just need to do this before compressing the bitmaps again with iGoSkinWizard. To aid this I could add a new tab or provide a special option in the scripts, but first I need enough designers to tell me that it's something they absolutely can't live without.
@arkoko: Thanks for the examples. I guess my question is: have you used my new "resizing" and are unhappy with its results for some reason (are bitmaps not scaled/really too small)? And don't you think it should be the skinner's decision to pick the bitmaps they want resized? If I do what I said above, it would mean changes to the original resolutions as well, not just the new resolutions made by iGoSkinWizard, and people would start putting out their versions of skins with different bitmaps resized differently.

gps4blackjack,
I'm not tried your last version yet. Last couple of days I spent all my time to tuning previously converted gj 5.4 skin and learning wonderful word of scripts language.
I still do not know what is z=... meaning.

I think z is the depth, so layers with larger depth are behind layers with smaller depth (or the other way around). You shouldn't need to mess with it when changing resolutions.

@Specter: I saw your message on i-go8.com. Can you explain the effect of/difference between vga=1 and highres=1?
Just to confirm: are you saying that unless I put highres=1, iGo will not scale bitmaps even though I set the proper width w=[scaled width] in the .ui files?

@Specter: I saw your message on i-go8.com. Can you explain the effect of/difference between vga=1 and highres=1?
Just to confirm: are you saying that unless I put highres=1, iGo will not scale bitmaps even though I set the proper width w=[scaled width] in the .ui files?

I need to check into this further. I want to be sure I can give you an exact bmp file and all its details so it will make sense. Don't worry about trying to fix anything now. I may have screwed up. I will post details as soon as I get a chance to do some testing. It sounds like it shoud work perfectly from your fix. I bet I did something wrong.

Thanks. BTW, are bitmap sizes still rounded up to 1 pixel more than they need to be?