PyGrp

Help - Resources - Discussion
User avatar
ShadowFlare
Posts: 15
Joined: Tue Apr 15, 2008 7:23 am

Postby ShadowFlare » Sat Nov 07, 2009 6:51 am

[quote name='bajadulce' post='8041' date='Nov 6 2009, 11:30 PM']I spend about 99.9% of the time compiling, but occasionally need to decompile a file. About the only inconvenience here is browsing around for different palettes when switching from one family of .grps to the next. The program defaults to the folder where the .grp was opened from rather than from the directory where the last palette file was loaded. I usually just copy/paste the palette file I will need to use into the .grp folder to get around this, but I rarely do any decompiling anyways, so this isn't a big deal. PyGrp's palette window/directory is a nice feature on the other hand in comparison.[/quote]
You are talking about that it doesn't go back to the palette folder each time you've opened the program, right? I suppose I could add some kind of registry setting to store the last path used for images and the last path used for palettes. Currently the program has no settings it stores for anything. Even just going to the last place you opened a grp is something that Windows is doing on its own.

I also noticed that .grps can be converted from .bmps of different dimensions as well? Is this something new?

I think I added this feature at least within the first couple versions of the program, possibly without anyone even requesting such a feature. For compressed grp images it will automatically center smaller frames within the area needed by the larger frames. For an uncompressed grp it will align all smaller images to the upper-left corner. The difference in behavior is of course because the compressed ones are usually centered, approximately, and the uncompressed ones are typically placed at the upper-left corner.
User avatar
poiuy_qwert
Posts: 548
Joined: Sun Jan 13, 2008 2:14 am

Postby poiuy_qwert » Sun Nov 08, 2009 4:13 pm

[quote name='bajadulce' post='8023' date='Nov 6 2009, 04:14 AM']One funny thing to report. Not necessarily a "bug", but a way to crash the thing. If you deselect the "show preview" button for whatever odd reason one would do this, reopen a .grp, and then press the move frames down button, you'll get this:

Code: Select all

Exception in Tkinter callback
Traceback (most recent call last):
  File "Tkinter.pyc", line 1404, in __call__
  File "PyGRP.pyw", line 226, in <lambda>
  File "PyGRP.pyw", line 799, in shift
TypeError: unsupported operand type(s) for +=: 'NoneType' and 'int'
[/quote]
This has been fixed. If you have the source version, open PyGRP.pyw and replace all occurrences of "self.frame = None" (no quotes) with "self.frame = 0" (again no quotes)

[quote name='bajadulce' post='8035' date='Nov 6 2009, 07:52 PM']I wanted to change to that first green in units.pal, but was having a hard time counting that far in my photoshop palette window. "16,32,64... bah forget it. Hey, wait, didn't I see that pyPAL lists the indexes if you hover over the color?" :) Ok so I got index 117 as the first green in units.pal by using pyPal. I entered this value in the transparent index box, but it displayed the .grp as still using a black background and all the colored border boxes were really screwed up? Did I input those numbers correctly?[/quote]
Ah, I found the problem with the "boxes". Its because I created a new cached GRP handler for quicker loading and forgot to code in the transparent index stuff for it, so it fills the "blank" areas with 0 :S This is fixed for the next version, I can send you my fixed GRP.py if you want before the new version is out.

[quote name='ShadowFlare' post='8040' date='Nov 7 2009, 12:35 AM']As far as palettes, there are 4 formats my converter supports, two which are supported internally by my grp library and two that the converter adds. The original two supported were .act palettes from Photoshop (also same format as .ppl from WarCraft 2) and the .wpe files from StarCraft. The other formats that the converter supports are RIFF (a binary format) and JASC (a text format), both of which use the .pal extension typically.

When opening a palette, my converter ignores the extension, only looking at the contents to figure out the format. First it checks for RIFF, which starts out with "RIFF" for the first four bytes, then a 4 byte value indicating the size of the file - 8 (excludes the RIFF tag and the size field), then the 4 byte text string "PAL ". There's some more to the format, but that's basically how the program checks for that format. If that was not a match then next it checks for the JASC palette format, which starts with the "JASC-PAL" tag. After this, the converter passes control to the function in my grp library for loading palettes. That code first checks for whether the file is exactly 1024 bytes (256 entries times 4) for the .wpe format that StarCraft uses. This format simply uses a flat array of RGB values stored as 4 bytes each. Lastly, if all other checks failed, it assumes it is a .act/.ppl palette, which is a flat array of RGB values stored as 3 bytes each. Since this is the final fallback format, it accepts any file size, so my converter will actually allow one with less than 256 colors, if this ever occurs.[/quote]
PyMS is a modding file API with GUI programs built on top, so all the programs use the same part for palettes. For normal palettes PyMS supports StarCraft PAL/WPE, RIFF PAL, JASC PAL, 256 color BMP, and paletted ZSoft PCX (not as a special palette) throughout. Everything about determining which format and opening it is the same. If .act is the same format as one of the files above I have no idea why it wouldn't open (i never check the extension) unless there is a bug. So either way .act will be working in the next version.
Edit: Well a quick look online seems to say the .act format is the same as a SC PAL so it should open them. Baja, can you send me one of your .act palettes so I can look at it?

[quote name='bajadulce' post='8046' date='Nov 7 2009, 11:31 AM']
I think I added this feature (compiling .bmps of different dimensions) at least within the first couple versions of the program
Oh. I only just noticed this last week when I combined 2 different sets of .bmps and forgot to resize them to match as I normal have done.


poiuy, I tried to decompile my first .grp with the program last night, but get an error upon hitting the export frames button? I thought maybe it was my unusual .grp, and so tried several other SC default ones. All produced the same result.

Code: Select all

Exception in Tkinter callback
Traceback (most recent call last):
  File "Tkinter.pyc", line 1404, in __call__
  File "PyGRP.pyw", line 702, in exports
  File "PyGRP.pyw", line 18, in grptobmp
TypeError: isstr() takes exactly 1 argument (2 given)

[/quote]
I think I may have added some support for different sized BMP's too but I can't remember (maybe I just started to). Anyway I might also look at that for the next version.

Damn it. That error stems from some people's OS's returning unicode strings and others not. You use the source version right? Just open PyGRP.pyw, to line 18 and change it from:

Code: Select all

if isstr(grp, unicode):

to:

Code: Select all

if isstr(grp):

Thanks again!
User avatar
ShadowFlare
Posts: 15
Joined: Tue Apr 15, 2008 7:23 am

Postby ShadowFlare » Sun Nov 08, 2009 10:56 pm

[quote name='poiuy_qwert' post='8062' date='Nov 8 2009, 09:13 AM']Edit: Well a quick look online seems to say the .act format is the same as a SC PAL so it should open them. Baja, can you send me one of your .act palettes so I can look at it?[/quote]
As mentioned in my post, .act uses 3 bytes per RGB value, where the SC palettes use 4 bytes per RGB value.
User avatar
poiuy_qwert
Posts: 548
Joined: Sun Jan 13, 2008 2:14 am

Postby poiuy_qwert » Mon Nov 09, 2009 5:34 am

[quote name='ShadowFlare' post='8070' date='Nov 8 2009, 05:56 PM'][quote name='poiuy_qwert' post='8062' date='Nov 8 2009, 09:13 AM']Edit: Well a quick look online seems to say the .act format is the same as a SC PAL so it should open them. Baja, can you send me one of your .act palettes so I can look at it?[/quote]
As mentioned in my post, .act uses 3 bytes per RGB value, where the SC palettes use 4 bytes per RGB value.[/quote]
The SC .pal files use 3 bytes per RGB value, its the SC .wpe palettes that use 4 bytes per RGB. Either way, PyMS supports both as stated before, so I'll have to see whats up.

[quote name='bajadulce' post='8073' date='Nov 8 2009, 08:15 PM']@modifying Pygrp.pyw:
Couldn't find it. I only have the GUI version so that explains why I don't see any .pyw files?[/quote]
You mean the EXE version? Then yes thats why.

Edit: baja, it seems both the palettes you supplied work for me, the .act format is supported. Are you sure you put them in the right place, maybe you have a duplicate PyMS folder? Or maybe check PyMS/Libs/stdeo.txt for errors.
User avatar
ShadowFlare
Posts: 15
Joined: Tue Apr 15, 2008 7:23 am

Postby ShadowFlare » Mon Nov 09, 2009 11:19 am

[quote name='poiuy_qwert' post='8076' date='Nov 8 2009, 10:34 PM']The SC .pal files use 3 bytes per RGB value, its the SC .wpe palettes that use 4 bytes per RGB. Either way, PyMS supports both as stated before, so I'll have to see whats up.[/quote]
I don't recall SC ever having any .pal files whatsoever.
User avatar
poiuy_qwert
Posts: 548
Joined: Sun Jan 13, 2008 2:14 am

Postby poiuy_qwert » Mon Nov 09, 2009 3:34 pm

I believe they are in the MPQ but never used, can't check atm though. It's either that or PalEditII called them SC .pal files so I just used the same name for the format.

Return to “PyMS (poiuy_qwert's complete modding suite)”

Who is online

Users browsing this forum: No registered users and 1 guest