PyTILE:

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.


-Bug?
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?

-Feature requests
Double-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.
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.

Thanks again for all your hard work, on this and many other programs!

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.
Edit2: Slight edit to make things more readable

Attachments:

Post has been edited 2 time(s), last time on Jul 23 2017, 1:36 pm by Nekron.

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 issue

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 issue

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.

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.

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 issue

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.

Hmm, I can look into it. https://github.com/poiuyqwert/PyMS/issues/26Github issue[url]

Glad to do it!

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!

Eh, this could get annoying if it happens more often since I'd have to paste some 100 scripts in everytime, but nonetheless thanks for the explanation

There shouldn't be many commands that have incorrect parameters that are being used in scripts, so it shouldn't happen often. Also once all commands have been verified it will never happen again. Also, if you need to import many scripts, use the batch importer from the main window (Ctrl+L).

I remember it crashing before but now it works fine (with MPQ functionality disabled) if the programs fail to load SFmpq.

Actually the registry crash I reported few pages back was related another 64-bit thing, as BW's installation directory is located at 'HKEY_LOCAL_MACHINE\Software\Wow6432Node\Blizzard Entertainment\Starcraft' when viewed from a 64-bit executable, so it failed to find my installation

The lack of error message when accidentally using Python 3 is something that's difficult to figure out. But I guess it would be pretty difficult to make the program fail with a emssage when the Python 3 interpreter rejects it before any code gets run?

Internal error - https://pastebin.com/raw/ETbdkPq5 on trying to either test code or save (don't remember which exactly) this https://i.imgur.com/02Wp6A4.png script(yeah I know that the ending loop should go to 0001, missed it when writing the 1st time around). Crashed after clicking OK afterwards

K, I have a github issue to double check dependency stuff anyway.

Interesting, I didn't know the registry did that. I have updated this github ticket to include this issue. I already have the branch sfmpq_64bit_dll where I have added the 64bit SFmpq.dll and updated the registry reading to always look for the 32bit SC keys. If you could test it out for me that would be awesome, otherwise I'll probably wait to merge it into master until I can get access to a windows PC to test.

Yeah I'm not sure I can do anything about running with the wrong python versions, but i'll investigate (github issue). I am working on an updated README with installation instructions (github issue) and have plans to update the docs in general (github issue), I'm hoping that will help with installation issues.

Was a typo, sorry Fixed.

Yep, I've been doing this. It's a lot easier to be able to fill with a click or two though.

Right, that's what I thought.

Gotcha. I mentioned it some time before but the only super-ideal thing to add to the previewer (besides what I mentioned in my last post) would be an SCMDraft-style preview of pathing, like so:

K, will do.

Yeah, I have created a github issue to remember it. There are a few problems with making this:
1) I can't do alpha blending with this UI toolkit, so I will have to code a new drawing method to be able to darken patches for the preview
2) It may be hard to create a performant drawing system
3) I will essentially have to create a basic terrain editor to be able to preview it. Your tiles are laid out in groups in such a way they could be previewed in the group palette fine, but I would want to make this previewer work for any arbitrary terrain. Maybe I can investigate using the SCMDraft brush format for the previewer as well.
Also I created a github issue for adding color cycle preview and possibly support for Color Cycle Edit's .ccc files.

What's the difference between the height field that applies to the entire group and the height painter that applies on a minitile basis?

Bug: when in the height painter, the save UI on the bottom of the program disappears.



Also, it would be nice to be able to resize the program.

You could use the alpha tables. tileset\*\trans50.pcx is probably ideal, since you can just blend over whatever colors from SC's palette.

Post has been edited 1 time(s), last time on Jul 24 2017, 6:13 am by FaRTy1billion.

PyTILE:
-There is no 'remove group' function that I can see.
-Support to read an updated stat_txt.tbl for better sorting of the doodad group field would be appreciated.
-Got doodad placeability working and everything seems to be set. Option to copy fields from other doodad groups would be nice so I don't have to hunt for the right string in the group field, or have doodads default to the first doodad category string instead of Terran Marine.

I don't actually know how a lot of the stuff works in game. It looks like you got some clarification from FaRTy in the shoutbox though. We should definitely keep track of any new info FaRTy finds about the formats so I can put them into the programs.

Yeah there seems to be a lot of cross platform issues with windows that can't be resized, but making some of them resizable doesn't make sense in terms of their UI. For example, what should the current PyTILE UI do if its resized? Nothing makes sense to grow bigger, so you would just get a whole bunch of blank space, which would just make it look odd/broken (though I guess thats still better then losing UI). I have created a github issue to look into this more. Also, have had some more ideas on how to revamp the PyTILE UI which would probably resolve your issue: update main UI, split doodad groups

Yeah, I would want to have support for using special palettes and stuff to the system, but would also want it to be able to do stuff outside of the palette. Still have a lot of investigating to do though.

Yeah, removing stuff is more complicated then it seems. I have created a github issue to look into it.

Will do. github issue

There are probably a bunch of things that could be improved for doodad editing, I can look into this.


Thanks!

It wouldn't be difficult at all to support 24-bit color, other than that makes it hard to use the special palettes (or do what I think CHKD does or did where it's 32-bit color, but the alpha is the original palette index)

This issue should be resolved now, along with other issues related to it. Thanks for finding this!

I just mean that I have to do all this in Python using Tkinter and PIL, so I need to investigate if/how I can do this with enough performance for it to not be 1fps

Post has been edited 2 time(s), last time on Jul 25 2017, 3:36 am by poiuy_qwert.

Doodads are not displaying correctly for me, in PyTILE's placeability section or in SCMDraft. Maybe you can shed some light as to whatever I'm doing wrong?

My doodad looks like this:


And its flags look like this:


But its placeability and in-editor state look like this:


I can still place them tile-by-tile like all other doodads since the tiles exist in the tileset but the idea was to simplify that process

I will also be messing around with setting doodads to have specific overlays for some of my assets. If all goes well I'll probably wind up updating a few existing ones that could use them (extractor/refinery come to mind). If not, I'll post my troubles here.

Also, an option to turn off the warning for expanded tilesets upon file load would be nice.

I'm still relearning how this works myself So this part is definitely not very intuitive, and its something I want to update (github issue). The issue is you have chosen a Doodad # that is already in use. You should find the highest Doodad # in use (should be the last doodad in the palette) and pick the next number. Whats happening is when looking up the Doodad # (Placeability, Editor), it starts at group 1024 and goes up looking for the first groups with that Doodad #, so your new ones never get reached because the already existing doodad (the one that shows up) is found. Also, it looks like there is an issue with the placeability editor where you can only double click the first row of tiles (github issue). Until its fixed you can find the right group by double clicking one of the top tiles and then use the text boxes to change the ID's.

Looking forward to it

Makes sense, i'll look into it (github issue). For now you can delete these two lines in PyTILE.pyw

Thanks!

That's... bizarre. I assumed the number was tiletype-dependent; 38 is the last vanilla high dirt doodad, so I chose 39 to sort it afterwards. I should be choosing a number higher than the highest dirt doodad, then?

edit: The placeability dialog does not update with the correct megatiles for setting placeability until after restart. this is me fucking up, nvm

edit 2: yep, got it working! Now for overlays...

edit 3: Ok, here goes.

I tried hooking the overlay to the doodad in PyTILE, using a jungle doodad as reference:



I use the same overlay flag, set it to ID 5, and replace the appropriate graphic in the mpq.



However, it doesn't place a sprite anywhere when I place the doodad in SCMDraft. I'm able to manually place it using the pure sprites feature, and it looks as desired:



...until you put a unit where it should be obscured, and it isn't. Also pictured are units underneath other sprites that behave as appropriately, with their sprites/selection circles/health bars hidden underneath the doodad's overlay.



Any ideas on how to fix either of these issues?

Post has been edited 3 time(s), last time on Jul 26 2017, 5:17 am by Pr0nogo.

Has the hard freeze whenever using PyTBL's search function still not been fixed?