Okay, try this: http://puu.sh/kXWFL/3bdf4188ee.zip

The included *.grp has the corruption present, and I produced it from the *.bmp

Thanks, fixed!

Nice to see more progress being made with the tools =)

I tried to to compile one of my iscripts with PyICE command line interface and ran into some problems:
1) turn1cwise is mistakenly named as turnlcwise
2) While IceCC accepts coordinates at least in range [-128 .. 255], PyICE only accepts [-128 .. 127]. Not really a bug, but makes switching iscript compilers more annoying, especially since IceCC defaults to using [0 .. 255] range when decompiling iscript.
3) The iscript compilation fails anyways with the following error:

Agreed

Lol nice catch. Luckily there was support from the beginning for multiple names for commands, so I've added turn1cwise to the name list with higher priority so both names will compile fine but turn1cwise will be the one you get with new decompiles.

Hmm not sure how or if i'm going to handle this case I'll have to think about it

Fixed.


Thanks!

Alright, got PyICE to compile my script
But "engset" is handled incorrectly, emitting 2 bytes of parameters even though it should be only a single byte.

Ouch. Fixed, thanks a lot for the reports!

PyGRP may encode a single 0x0 pixel as part of a larger chunk of non-repeating pixels. Then bw doesn't treat it as transparent pixel, but it draws the 0x0 black/space pixel instead.

Interesting. This is caused by part of an optimization I added which makes PyGRP produce the highest compression. I had no idea that starcraft treated "transparent" pixels different than "index 0" pixels. I wonder how the pixel data is stored in memory if index 0 doesn't inherently mean transparent. Anyway, fixed thansk!

I'm assuming this mistake is what made you think of making https://gfycat.com/TestyDentalCalf ? Thats pretty sweet. I'm assuming you just changed the Transparent Index option to make index 0 stay solid?

Thanks!

Hehe, I actually got the idea of using index 0 color in sprites yesterday night, as there was star.spk discussion in the shoutbox

My plan was to add a new color to bexpl.pcx which remapped always to 0 and use that in the sprite. But as the remap palettes have a lot of these almost-transparent colors, they made the index 0 errors stand out more than they would have otherwise.

It was really strange to understand what was going on, as the converting the grp back to bmp gives a correct image D:
But yeah, turns out that the space trick could also have been done with a modified grp converter instead of remap palettes.

And bw actually just keeps the grps in memory, decoding them directly to the framebuffer every time it needs to draw an image. So it apparently just moves the write position forwards when it encounters transparency and copies to the framebuffer otherwise.

Ah, cool. I still need to make a special palette editor, hmmm...

Lol And you shouldn't need to modify anything, PyGRP has an option in the GUI to change the Transparent Index it uses to process stuff.

Ah of course, that makes sense.

I'll just post these as I go.

You'll know when I am done posting stuff because I'll edit this post to say I am done for the night. If you post questions, either here or in the shoutbox I'll probably just edit this post instead of making a new reply. K? K.

This happens when I just try to run PyMAP. Nothing else.


This happens when I try to open ANY MPQ. Only WinMPQ succeeded in opening them, though, not even mpqviewer could open them.



This happens when I try to import a new star. I might have broken it on purpose, though , I tried to import a really big bmp which wasn't 256 colors.


But still, you need better error handling ;o

EDIT2:
Also seems that whenever you save a file it keeps it... open? It gave me an error while trying to overwrite a previous star.spk file that PySPK had generated. A 0 byte one because it had errored but I cannot overwrite it because it says it's still in use.


EDIT3:

Cool:


Here's the deal though. It's not rendering quite well. It flickers sometimes when you move in the parallax. (move screen) it makes big chunks disappear when you mouse hover and also chunks of it disappear when units pass over it.

Chunk disappeared when I moved screen:


Chunks disappeared when I mouse hover:


Chunks disappeared when units went over it lololol:


Actually don't have that last one, I took the image at the wrong time, only the thruster's overlay affected the rendering.

EDIT4:
LOLOLOL



Trying to save this errored and returned a 0byte, uneditable spk. Couldn't even overwrite or delete until I closed PySPK.

Post has been edited 5 time(s), last time on Nov 24 2015, 4:36 am by Corbo.

based on the overlays and the stars appearing on top of black player colors, I think spk must be drawn last.
And the cursor erasing chunks of the huge one, that must be because it's only redrawing the stars that are behind the cursor which does not include the big one.. I bet if you moved the cursor over the center of the sun it would redraw it and fix the holes. But it should be broken up in to smaller images that are tiled together to prevent it... maybe an image limit is more necessary than I first said.

This is because PyMS doesn't actually support vanilla DAT files, only BroodWar dat files. You probably have your MPQ's in the wrong order so it's loading from StarDat. Also note that PyMAP is in heavy development, I've only been testing it with a few blizzard ums maps. Also I don't really think its feasible to make it performant using this GUI engine, but I would love to hear how it performs on other peoples systems.

This is doubly weird because PyMPQ uses SFmpq just like WinMPQ, and the issue before this seems to indicate PyMAP was loading StarDat just fine. You sure you didn't have the mpq's open in another program when you tried with PyMPQ?

Fixed. That was a bug in the error popup that was going to tell you your file was wrong. I would say that even with a bug in error handling, it was still good error handling, you got a copyable traceback and the program didn't crash, thus not losing any work you may have done

It doesn't seem possible that a save file is kept open since I switched to using atomic writing. I write to a temporary file somewhere in your temp directory then when that "succeeds" I copy the file to where you actually saved it, so I never actually have the final file open. You sure something else didn't have it open?

Also, was there no actual error reported when you got the 0 byte file? What happened? Can I get steps to reproduce it?

Interesting... And disappointing

Post has been edited 1 time(s), last time on Nov 24 2015, 5:09 am by poiuy_qwert.

Sure thing:

Try using the image I am going to be attaching. It's a 256-color bitmap that's 512x512. You said you fixed this error already, but if you hadn't the output of that error would actually be a 0 byte spk file.

And that file won't be able to be editer, overwritten or even deleted via windows explorer. That is, until you completely close PySPK

PySPK doesn't even work for me. Crashes on startup with following message

Having PyMPQ require exclusive access to file is really annoying, making it pretty much unusable for me. I can't use it to extract files from stardat/broodat/patch_rt.mpq while Starcraft or even Scmdraft is running. Winmpq is not ideal either, as editing a mpq fails silently when it can't get exclusive access to a file, but at least it allows reading files without having to close all other programs.

Hmm i'm not 100% what that is, but it seems to be that it can't find the file in the MPQ's (or MPQ folder) and is not handling it properly. Will look into it, but for now you could try adjusting your MPQ settings.

I'm using SFmpq, just like WinMPQ, so not sure why it would be different. I was looking to see if there was a way to open the MPQ with a readonly flag, but I didn't see any at a glance. I'll look into it though.

Right.. I have this hackish setup which causes the tools to not find Bw's mpqs automatically. But PySPK is the only one of them which just closes itself, others let me access the settings and add the .mpqs from there.

Found the flag, should be fixed.

Fixed

http://i.imgur.com/2yEvrdz.png

I have highlighted a division in PyTBL that cannot be adjusted to the left/right. It would be great to have this function.

That's PyTBL?

My god PQ. I'd have thought you had string preview or at least a proper list with color formats and other codes with how they'd look. You're slacking in PyTBL

I'll break that one next.