Would it be possible to add to PyTILE the ability to scroll with the mouse wheel when watching all tilegroups?

Also, hawt tiles has the ability to export the pallete. This is very much useful so I can export the pallete and apply it to the images I want to be as terrain, otherwise it will be funky colored :C and not-palleted


Also a few errors:



Post has been edited 2 time(s), last time on Mar 20 2015, 3:29 am by Corbo.

Alright added.

You could use PyPAL to open the .wpe file and convert it to another format. I can add a convenience button in PyTILE to export the palette though. Does it just export to a .pal or how does HawtTiles handle that?

I need more context for these errors.

Hawt tiles just lets me export the 256-color pallete for the tileset. Which is useful so I don't have to "guess" and just apply it with Photoshop.

I am still figuring out how to save the images so EITHER of the programs accept them, hawt tiles did this when importing:


Though, pyTile just seems to not like importing anything at all


There is none. One I was just trying to import an image to replace a group and one I was just trying to open a MPQ.

EDIT:

Out of curiosity, I have two questions:
1. What kind of format does PyTILE expect me to shove my image as into it? How would I go about making such format?
2. Do I have to respect Null tiles? farty and I had this conversation, that the bug might have to be because I imported stuff into the null tiles and converted them all to that weird funky looking thing. this sucks, because null tiles might mean extra tiles (I realise I can add groups) and really respecting null tiles is just dumb. Why would they all be the same?

EDIT2:
Also, now that I think about it, selecting flags minitile by minitile is rather innefficient. Could I have something like selecting all minitiles and applying the same flags for all of them? This would ease the process of editing them. Minitile by Minitile should still exist, though.

Post has been edited 2 time(s), last time on Mar 20 2015, 5:26 pm by Corbo.

Yes but what format does it export to? I'm going to assume it just exports to .pal format. Like i said I'll add the convenience button to PyTILE but for now you can use PyPAL.

That is more context. I don't really have any idea what the MPQ issue would be, you might have to send me the mpq to look into it more.

The importing definitely seems to have issues, I'm working on it. Working with the images is just like for GRP's, you need an 8-bit paletted BMP using the tileset's palette.

I have no idea what is going on there.

The MPQ is the original Starcraft 1 MPQ. StarDat. I haven't touched a single thing. Do you really want me to send you that?

Also, no, hawt tiles lets me export to .act, .pal, .ppl and .wpe.
.act is by far the most useful one outside of these programs, for editing. BUT I can live without that. Importing tileset groups really should be what you should be fixing right now



EDIT:

Also, I think it'd be a good idea to update the megatile group pallete once you put something into it. For example, I edited a few tiles (via your program, since it doesn't let me import images) and did this:



But when I view the tile group pallete I get this:


Unchanged images. I'm pretty sure it'd also do that when you fix the importing, so you might as well look into it atm.

Post has been edited 2 time(s), last time on Mar 20 2015, 5:53 pm by Corbo.

Can you open the MPQ's in other programs settings? I don't get this issue on my Mac so I probably wont be able to look into this until I get a windows dual-boot/machine.

Yeah just use PyPAL for now.

I can open it with other programs, such as WinMPQ, and Ladik's. Which is what I am using since PyMPQ didn't seem to like me.

Also, how would I go about breaking said link between minitiles in different tiles? What if I wanted them not to share the same minitiles?

EDIT:

Yes, as I feared. My testings indicate that one must respect null tiles, unless you break this "bond" between the mini tiles. They all seem to share the same minitile, so editing one, edits all of them. As seen here:


EDIT 2:

I might add that editing the MegaTile number or index DOES update in the Tile Group Pallete: So it's a matter of updating their grahical images in the pallete.


Post has been edited 2 time(s), last time on Mar 20 2015, 6:18 pm by Corbo.

No I meant can you open it in other PyMS programs settings dialogs?

There is nothing special about null tiles, this is just the same confusion over MiniTiles vs MiniTile Images. You really need to wrap your head around the difference between a MiniTile and a MiniTile Image. Here is a overview I hope will help:
MegaTile Group: A MegaTile Group has settings and references a bunch of MegaTiles, so if you edit a MegaTile all the MegaTile Groups that reference that MegaTile will have changed
MegaTile: A MegaTile has a bunch of MiniTiles. These are not references to MiniTiles so editing them doesn't effect any other MiniTile or MegaTile
MiniTile: A MiniTile has settings and a reference to a MiniTile Image, so if you edit a MiniTile Image all the MiniTiles that reference that MiniTile Image will have changed
MiniTile Image: Just the pixel data

You would need to find a MiniTile Image that is not used (not sure if there are any in the default tilesets) or create/import a new MiniTile Image in the MiniTile Palette (I'm going to rename this to MiniTile Image Palette for some more clarity). Obviously there are issues with importing so this area is not easy to work with.

Yeah this is due to heavier caching in the palette, I'll have to think about the best solution.

Okay, so I've got a few errors but first,

Thanks, importing... sort of works and the group pallete does show imported images, or modified ones, as shown here:


Thing is that I can't seem to manage to actually replace a megatile or a tilegroup in consequence... Whenever I import it seems to just put them at the end of the tile pallete, like adding a new entry instead of replacing an already made one. Which would be good, or acceptable if I could change the megatile value of an existing one to the newly created one.


Take that image, for example. Those are my imported megatile groups which were created as a new group, instead of replacing one. But you'll notice that it has the megatile ID os 4844.
Now, if I wanted to use them (so they can be placed via ISOM in SCMDraft or something like so) I'd have to replace the existing ones with those megatile ids. Except I can't. Editing them manually just makes them be 4843 (which I assume it's the max ID for that tileset and that's why the program is not letting me write beyond that. Seriously. I can't write 4844



The problem found was this:


I was importing old tilegroups I modified. Exporting again and modifying and then reimporting seems to work. Might have changed the export format so old files can't be read now?

Yeah currently importing only adds them to the end because of collisions of other MegaTiles/MiniTiles referencing the same items in the tiles you want to replace. You had the right idea of updating the megatile id's, but yeah I wasn't updating the acceptable id range on add/import. I've fixed this now. Also just so you know you can double click an item in the Palette window to have it choose it instead of remembering the ID, closing the Palette, and typing the ID in the text box.


Yeah there was a typo in the export. You should find and replace "HasDow" with "HasDown" in any existing files and that should fix them.

So, this happens when selecting an imported/added group:


Actually ALL of them change. Not just the thing that looks like a tbl string

That's a really weird bug, right?

Ah yeah, thats because MegaTile Groups above id 1024 are doodad groups. This is another reason why the current system of importing is flawed. For now you'll have to edit one of the earlier MegaTile Groups to point to the new MegaTiles created.

Figured that much.

So this happens:



Happens when you click to go page up or down but NOT use the bar. As in click in the space in between the bar and the arrows.
Click + dragging the bar does not bug it out.

Awesome. Thanks. bye.

Commit dbcb4c3 broke PyDAT on my pc. It seems to get stuck somewhere as the python process uses a lot of cpu and has to be killed manually. No GUI or any kind of error appears ._.

So, something hit me while facing some more issues with editing the tileset. To understand me you first have to see this picture:


The selected megatile group should look like the one below. Why doesn't it do that? Because some mini tiles use the same mini tile image. But, why?

I mean, the program, at the moment does NOT, replace megatile groups. It just adds new ones, so why doesn't it just export whatever image "as is" and instead it needs to use the old megatile group configuration, thus, creating problems like the one I face.


I'd understand if it was a replacement for the megatile group, in which case, yeah, they'd have to use the same flags (even then I'd still argue if it is completely necesary) But it is now that case... so yeah. I should be able to just import whatever mini tile image information I want without these issues if it's just added at the bottom so I can reference the actual real image I am importing and not something scrambled up.


EDIT:
When editing a minitile image with that particulary small editor, both, OK and Cancel buttons do the same. If I make changes and don't want them applied in the end, Cancel is no option

Post has been edited 1 time(s), last time on Mar 21 2015, 4:44 pm by Corbo.

Nothing in that commit looks like it could cause an infinite loop. Are you on that commit or the latest commit but dbcb4c3 is the earliest commit with this problem? If you are not on the latest commit please update and tell me if its still happening?

I think you are doing something wrong. Here are some detailed instructions on how you would change the graphical portion of an existing MegaTile Group without effecting that groups settings, for the current way the program works (which will hopefully be changing to something better):
1) Click the button with the magnifying glass next to the MegaTile Group at the top to open the Group Palette
2) Select the MegaTile Group you want to change
3) Export the group to its BMP and TXT components
4) Modify or replace the BMP with your own tiles
5) Since all the MiniTile Images in our BMP are not be flipped, but some of the original ones may have been, we need to edit the TXT file to make sure all the FlippedStates are 0 (so like "FlippedStates: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0")
6) Import the BMP and TXT, which will create new entries for everything. You can ignore the new MegaTile Group, we'll just use the MegaTile's that are created
7) Close the Group Palette, the original MegaTile Group you wanted to change should still be selected for editing in the main window
8) Click on the first MegaTile in the group
9) Click the button with the magnifying glass next to the MegaTile field in the middle to open the MegaTile Palette
10) Go to the bottom of the palette and choose the corresponding newly created MegaTile that you just imported. It has the original settings (from the TXT file) and the newly created MiniTile Images (from the BMP)
11) Repeat steps 8-10 with the rest of the MegaTiles in the group

If this does not clear things up you'll need to give me more details on what you are doing, step by step instructions to replicate the issue.


The Cancel button is fixed, and I definitely want to look into making it resizable.

Post has been edited 2 time(s), last time on Mar 21 2015, 7:23 pm by poiuy_qwert. Reason: Added step about flipped states

Okay, the issue was that the commit removed line doing self.deiconize(), so the window was permamently hidden. The cpu usage was just startup taking its usual 15 seconds, sorry for misleading

Also, there are at least following typos in PyDAT: organinc & resource containier in units.dat flags tab and open directiory on the toolbar

Odd that didn't effect me on Mac. Anyway i've fixed it.

Alright fixed.

Thanks for the reports!

At the moment:

• Bringing an element off bounds from the container makes it so PyMS won't display its properties via double-click on the BIN preview. Double clicking on the items list does bring the properties box.
  
• Clicking the "advanced" checkbox should really keep that setting. I personally hate having to recheck it everytime I open an item's properties.
  
• Resizing an element does not change an element's width or height. It just changes its boundary on X-Y coordinates. Should really update the width and height too. (I realise that you did put buttons to help one and "autoset it" when you've changed it but, really, at least when you're editing them in preview it should auto resize everything. Since you're not viewing the properties box.
  
• Kind of similar to the issue above, the Mouse Response box does not update when resizing in preview mode. In my opinion resizing an item in the preview button should change all of the values, if you want them to be different, that why you should edit them manually.
  
• I don't know wether this is just yet not programmed but I am adding it anyway: Changing font settings does nothing in the preview. Neither alignment settings nor size settings. They do change in-game, though.
  
• Neither changing the text works. Which is unusual since reopening the edited .bin file DOES make the program open it with your changes.
  
• Vertical alignment options read TOP, MIDDLE, RIGHT. Should it not be top, middle, bottom? Either way changing them does nothing neither in the preview, neither by re-opening the .bin. They do work in-game, though.
  
• I assume adding new items is not coded yet as it bugs out.
  

• Bringing an element off bounds from the container makes it so PyMS won't display its properties via double-click on the BIN preview. Double clicking on the items list does bring the properties box. Fixed
  
• Clicking the "advanced" checkbox should really keep that setting. I personally hate having to recheck it everytime I open an item's properties. Done
  
• Resizing an element does not change an element's width or height. It just changes its boundary on X-Y coordinates. Should really update the width and height too. Done
  
• Kind of similar to the issue above, the Mouse Response box does not update when resizing in preview mode. Done, but not sure if this is how it will stay though
  
• Changing font settings does nothing in the preview. Neither alignment settings nor size settings. Done
  
• Neither changing the text works. Which is unusual since reopening the edited .bin file DOES make the program open it with your changes. Done
  
• Vertical alignment options read TOP, MIDDLE, RIGHT. Should it not be top, middle, bottom? Either way changing them does nothing neither in the preview, neither by re-opening the .bin. They do work in-game, though. Fixed
  
• I assume adding new items is not coded yet as it bugs out. Fixed
  

Post has been edited 2 time(s), last time on Mar 26 2015, 9:01 pm by poiuy_qwert.