PyMS and ProTRG developer
When you save a GRP with PyGRP, you lose a pixel.
Garbage'd for visibility.
Hmm, that sucks... I'm going to use this one to finally create a system for unit tests (
github issue, then I'll make a unit test to fix the issue, so hopefully something like this wont happen again. But that means it might take me a little longer to get a fix out.
Github issueI can look into bundling the 64bit .dll, I just wont be able to test it myself. Anyone willing and able to test that out at some point?
Assuming the requirements are 'running a 64-bit windows', I can definitely give it a whirl, but it's worth noting that I don't have any problems starting PyMPQ or opening an mpq file in it (haven't tested it beyond that yet).
You would need to be running a 64bit Python (on a 64bit windows) which wouldn't be able to use the 32bit SFmpq.dll. If you are able to use MPQ's already that means you have a 32bit Python. Though I will need people to confirm that everything still works fine for 32bit as well.
Github issueUsing PyMPQ, I am unable to rename a file. The first time I attempt to do so, the change is just ignored and the name of the file is not changed. The second time I try to rename the same file, I get this error:
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
File "F:\Modding Tools\PyMS-master\Libs\SpecialLists.py", line 293, in <lambda>
e.bind('<Return>', lambda _,i=i,n=n: self.endedit(i,n))
File "F:\Modding Tools\PyMS-master\Libs\SpecialLists.py", line 302, in endedit
if self.checkedit != t and self.report.rcmd and not self.report.rcmd(self.entries.index(int(n[5:])),self.checkedit):
File "F:\Modding Tools\PyMS-master\PyMPQ.pyw", line 829, in do_rename
if MpqRenameAndSetFileLocale(h, l[0], new, int(l[4]), int(l[4])):
File "F:\Modding Tools\PyMS-master\Libs\SFmpq.py", line 441, in MpqRenameAndSetFileLocale
return _SFmpq.MpqRenameAndSetFileLocale(mpq, oldname, newname, oldlocale, newlocale)
WindowsError: exception: access violation reading 0x00000167
The MPQ is not open in anything other than PyMPQ.
Hmm, looks like I can't rename as well (
github issue), but I can't reproduce the crash (
github issue)... I'll look into it and hopefully fixing the rename also fixes the crash.
First of all, thank you so much for implementing the megatile property painter. It's unbelievable how much easier it is to apply pathing and other properties to tiles now. You knocked that out of the park.
Yeah, glad to do it. I have asked people many times to report "pain points" in modding tasks, but noone seems to ever have any, so things like this never get updated. I got fed up with using the old minitile editor in the like 5 minutes of testing it for bugs when you started reporting issues in PyTILE, so I changed it. If you report other "pain points" we can loo into making them better.
The 'Apply to megatiles' button doesn't appear to do anything when you select the 'apply {property} to megatiles' option. Am I doing something wrong? What is the intended function?
Yeah it doesn't seem to be working. Its supposed to apply the minitile settings from the current megatile to all the megatiles in the current group.
Github issueDouble-clicking on any square in the painter fills the entire megatile with the desired property - e.g. when mid (orange) is selected in height, double clicking on any minitile makes the entire megatile mid-height.
I didn't add anything like this because you can click and drag to draw all the tiles pretty quickly. Did you not know of that or you think it would still be convenient to add the double-click to fill feature? I can add it either way.
Right-clicking on any square in the painter resets the megatile to what it was before you started applying properties - for when you mess up and want to go back to basic. This feature isn't as useful as the fill feature but I know I'd use it.
Hmm, I can look into it.
https://github.com/poiuyqwert/PyMS/issues/26Github issue[url]
Thanks again for all your hard work, on this and many other programs!
Glad to do it!
AIscript/BWscript openable on previous version are now impossible to open and PyAI says that they're corrupted. Which is probably a very real possibility, but I would love to be at least able to open them and not save or something since I have some scripts not copied to Notepad++ yet :I. All Zerg 3 scripts, namely. Also I'm kinda scared even if I copy everything manually now it might get fucked over again, so I dunno whether I should try to replicate the old script files yet or no..
Almost all script files I used are now unopenable, here's the ones I saved with PyAI yesterday with updated Z3 stuff as an example.
Edit: I actually had the previous PyMS still saved, so I just replaced new PyAI/Libs with the old ones and retrieved the scripts. I could open all now unopenable files just fine. I have no idea whether that's an actual issue or PyAI just recognizes corrupted files better, since, well, they most certainly can be corrupted - I worked on these exact scripts with SCAI a lot.
Yeah so when I update the parameters that commands use, that will effect loading files that used the commands that changed, essentially making those older files corrupt. What you did is the correct solution, using the version of PyMS that has the same opcode parameters that your files were compiled with. If you run into other corruption issues with any of the tools, I can also take a look and if the corruption is reversible I might be able to fix things for you manually.
Thanks everyone!