Thanks GAFMEDIA it worked!

Now, is 101 still to edit the menubar background? I've tried making it a little transparent but it doesn't seem to change after I've logged back in?
Heeeat wrote:Now, is 101 still to edit the menubar background?

Menubar background is now 48 and 107 :thumbsup:
I've updated the sartFileTool on GitHub for a full rewrite using Cocoa classes and making it more readable. I've also posted an entire file format specification in the readme on the repo. It is not fully tested yet so I'm not going to post a built executable but you can try it at your own risk by building yourself:

https://github.com/alexzielenski/sartFileTool

By the way, it works on 10.8
Last edited by alexzielenski on May 21st, 2012, 8:07 pm, edited 1 time in total.
jivhg wrote:By the way, it works on 10.8

CONFIRMED !!! :thumbsup:

Image

Encoding/Decoding works on 10.8 ...

( ... does NOT work on Lion 10.7.x ... )
mindlessmissy wrote:( ... does NOT work on Lion 10.7.x ... )

Yes it does…?
jivhg wrote:
mindlessmissy wrote:( ... does NOT work on Lion 10.7.x ... )

Yes it does…?

You know what ? YES IT DOES !! :thumbsup:

Sorry about that ...

I was trying to encode/decode a 10.8 SArtFile on Lion(10.7) ... ( now THAT, is a no go )

Thanks for the tools :cool:
To encode/decode a 10.8 SArtFile on Lion you must specify the -os option (./sartFileTool -os 10.8.0 SArtFile.bin sartFiles)
Thanks for the update, it's working very nicely on the latest build of 10.8, aside one one issue I've noticed with the little magnification icon (294-1.pdf). It seems to have transparent pixels rendered in the foreground colour, and this is just with decoding and encoding without changing anything. The PDF itself doesn't look broken after extracting it but renders strangely for some reason.

Image

Either way thanks again for putting in the time to get this working with 10.8.
This is an issue i noticed earliet and thought i fixed. Make sure you have a really up to date version of the tool and that it has buffer1 in the receipt
Ah, this is the latest version as of now from your repo I compiled earlier today, buffer1 in the receipt.
They decoding with the -pdf option and then re encode it after making your changes again.
Same issue with the -pdf option, with or without it the bin comes to the same checksum (8a39ec48d642d0bb7d4ec1b4bae4ce1d). I haven't looked around throughly but it only seems to be that single resource that's having this issue.
Okay Joe, I'm seeing this issue now. I'll get back to you…
Joe: I pushed some changes to the git repo, try it out…
Thanks, though you seem to have some issues with your args processing when encoding the file, it takes the default path of the SArtFile.bin as the decoded resources directory.
Ah, I see what you mean. I've just fixed that. How goes it on your end?
Didn't see a push on your repo so I fixed the args thing (break instead of continue) and it seems to be returning exact binaries when decoded with the -pdf option, though I haven't yet tested any modifications to the resources.

Also a little confused about the PDF rendering option, is this how the PDF representations are stored inside the binary itself, and should I be editing these rather than the actual PDF file?
Last edited by Joe on May 22nd, 2012, 10:28 pm, edited 1 time in total.
PDF files and two pre-interpolated representations are stored inside of SArtFile.bin, when you use the -pdf (i recently just pushed so its now --pdf) it will write these pdfs out and won't interpolate them for you. If you are using the -pdf option then you should be editing all representations of the pdf but to make it render them for you, do not use that option.
Interesting, so the OS doesn't render the PDF but the raster representations stored inside the binary? It seems that without rendering them out that transparency bug remains though.
I think it'll use the rasters when the size is the same but it'll render the PDF if necessary. I see now that the problem is that when i render the PDF, Cocoa is turning the transparent values into FF FF FF 00 rather than 00 00 00 FF.
Last edited by alexzielenski on May 22nd, 2012, 11:26 pm, edited 1 time in total.
Weird, I wonder why it was only visible in that single resource, other PDFs with transparency didn't seem to have that issue at least as far as I could tell.
Because I'm guessing that was the only place we could find where the rendered PDF was used since it was the same size. Anyway, I've pushed a change to the repo that should fix this issue.
Last edited by alexzielenski on May 23rd, 2012, 1:15 am, edited 1 time in total.
Oky, what's wrong?
Image
You need to build the tool.
Oky, I'm stupid. Thank you very much! This work is very pleasing to me.