Loading any (1.16) .bin file with crashes PyBIN:

And once PyBIN works for 1.16 bin files, would be neat to have support for 1.20 ones as well. They have had some format changes, not sure about all of them. Some flags seem to have changed and there are new 2 bytes (padding? not sure) around offset 0x20 for all controls, so anything after that is offset by 2 bytes from the 1.16 format.

Should be fixed (was an issue trying to preview without the background being loaded). I also updated the main UI to be fully resizable and fixed some other issues. Does double-click to edit work for you in the widget list or the canvas?

I don't really have any plans to support the new file types, but if you document all the changes and people keep pestering me for it I might do it. Though I also wouldn't be able to fully support the new HTML widget or video files.

I had another fatal error occur in PyMPQ after trying to add files to an mpq while SCMDraft was reading data from it. Didn't grab a dump this time though, and there's nothing in Libs -> Logs. If I can replicate it later I'll post more details, but I figured you should know.

PyAI: Longstanding issue on windows where after saving a script, pressing `Yes` on the confirmation, and closing the entry, the main window resets to the very top of the script list instead of remaining where you were. I kept forgetting to report this, but hopefully it's an easy fix.

PyICE Bug: The undo bug reported several pages back for PyAI seems to be present in PyICE as well.

PyTBL: Any chance we can get an entry previewer to see what it will look like in-game? Something below what we type, maybe similar to the preview seen in FireGraft.
Bug: after using save as, the file path at the top of the program is inaccurate (still shows the original file loaded before saving as).

Could you try going into Libs\SFmpq.py and changing DEBUG to equal True at line 298. If it doesn't introduce any lag, you could leave that enabled until you get the crash again, then hopefully there will be some extra info in the logs that will help me debug it.

Noted.

Hmmm, the fixes I made before should have applied to all code editors. You will need to provide me with detailed steps to reproduce the issue like before, or just confirmation that the same steps from before will reproduce it.

There is already a previewer, its the checkmark button, or Ctrl+T. PyTBL is one of the oldest UI's, so it is very basic compared to the newer apps. I already have plans to revamp PyTBL, but any additional ideas are welcome.

Noted.


Thanks!

Ok, will do.

Yeah, looks like a false alarm. After a few copy pastes and such, pressing ctrl+z a bunch of times will occasionally just wipe the entire script window, but pressing ctrl+z again restores it (as far as I can tell).

Building the previewer into the main window a la firegraft would be super ideal. Otherwise I have no specific suggestions as of right now.

PyAI: The script will be corrupted if you use create_unit with a coordinate outside the maximum map bounds. ~8192 is the highest coordinate for both width and height, so maybe don't allow users to save if a coordinate goes over that number.

PyMPQ: Here's the crashlog I mentioned earlier. Happens when SCMDraft is holding onto the mpq that is being edited in PyMPQ.

What do you mean "the script will be corrupted"? I assume you mean the script compiles/decompiles fine (not corrupted), but starcraft crashes when it tries to create the unit? For me to be able to add checks for this I will need someone to be able to figure out some things:
What is the exact valid range of coordinates? Does the map size matter? Like can you spawn a unit at 4096,4096 on a 256x256 map but it crashes on a 64x64 map?
Maybe we can get Neiv to look at the actual implementation?

Yeah its the same crash. Was DEBUG enabled in SFmpq when that log was created? If so it doesn't look like the debug info is coming through, so I still don't really know what is going on If you are able to reproduce the crash, maybe you can edit Libs\trace.py so STDOUT_FSYNC = True on line 11. It will make the programs lag while writing the debug info to the log, but it should ensure the SFmpq DEBUG logs are written during your test. Then you can disable it once you are done the test.

The actual ramifications of the corruption are incredibly bizarre. Specifically, the script was called to `create_unit(Mineral Field Type 1)` at invalid coordinates. I used a modified unitdef.txt, and using `create_unit(Mineral Field #)` worked fine in other instances. After saving the script, I noticed "an unable to create unit" error in the map, so I fixed this and saved. However, a mineral field failed to spawn regardless of the coordinates (or even if there were any `create_unit(Mineral Field #)` calls in the script - and no other scripts or triggers existed that would be spawning them; I checked several times). The fix was to paste an old copy of the script and write in the `create_unit` calls with accurate coordinates.

No, I forgot that, but since it's 100% reproduceable I was able to turn it on and then make it crash again. Crashlog

Let me know if you need me to do that extra step.

I'm still not really sure what you mean, or what the specific issue is. Is the issue that the mineral field isn't created, or that it was giving the "unable to create unit" error even after you had deleted the `create_unit" command from your script? Can you give me step by step instructions to reproduce the issue, with expected result and actual result on whichever steps they diverge?

I think I've fixed it! I've also updated the logging a little, so if you get the crash again, please give an updated log with SFmpq DEBUG on.

Thanks!

Yes.

1. Use a unitdef with mineral fields listed (should work for any unit/structure though)
2. Call `create_unit` at invalid coordinates
3. Save changes, add it to a mod, call it in a map. Expected results: 'unable to create unit' error.
4. Remove `create_unit` call in script. Save changes, add to mod. Expected results: same as above.

Can't test these currently, but that's what happened to me.

Ok, will do. Thanks!

Why is this happening? Trying to extract any file using PyMPQ does this. Is it related to what I changed for debugging a while back?

When attempting to open glucustm.bin with PyBIN, the program throws this error.

Since I can't check, is there any function in PyBIN that allows for the creation of new dropdown menus, similar to the game mode selection menu (where you choose UMS, melee, etc)?

That is because it can't open the MPQ, it apparently just doesn't have an actually error message to properly be handled.

Its crashing when trying to preview some text, i'll have to investigate. Are you using any custom MPQ's or "Preview Settings" in the settings? Also if you would like to get around the issue temporarily, you could disable text previews.

You can add widgets to BIN's, and one of the widget types is "combobox", but I'm not really sure how it works after that.

No. I had only just opened up the program for the first time. Double-checked and nothing is different from the standard.

PyTILE: Internal error when trying to export multiple groups at once.

PyICE gives me this when decompiling a script

It now shows user friendly error dialogs.

This is fixed.

I can't reproduce this. Can you give me detailed steps to reproduce it? How many groups did you export? Which groups did you export?

That should be fixed. The command lines are definitely lacking in attention. If you find issues, or there is a program that doesn't have command line support, or the command line doesn't have the functionality you want, I would love to hear about it!

Thanks!

I opened this tileset and exported these cliff groups: 52 - 75, 84 - 111

edit: Any way to make SCMDraft read completely new isom groups? Sort of like how you can add doodads to the doodad layer. I'm working on high asphalt atm, and want to include high structure and maybe high mud as well.

Request: make pressing escape close currently-focused subwindow (e.g. group importer, group previewer in PyTILE)

Reminder/please prioritize? -- double-click/right-click to 'fill' minitile painter with the selected property, and hotkeys to semi-automate applying selected megatile's properties to all megatiles in group

Bug -> PyTILE: when scrolling through the main window, it scrolls the last selected drop-down menu as well, but it's only visual - i can still paint walkable/unwalkable flags even though it says 'minitile' or 'ramp' or etc

Bug -> PyTILE: if you've just saved, applying selected megatile's properties to all megatiles in group will not register as a change for the save indicator (it's still greyed out/out of focus)

Checking in: are you any closer to the overlay previewer for doodads in PyTILE? Can't remember if you had started this or not.

Post has been edited 3 time(s), last time on Sep 11 2017, 5:16 pm by Pr0nogo.

FYI just sending the .cv5 is not enough, all the files are required for a tileset to be opened. I was able to reproduce the issue on the default badlands tileset though, since it turned out to just be an issue exporting more then 16 groups at once. I got annoyed very quickly shift clicking all the groups, so I updated the multi-select to do proper shift-click of ranges and cntrl-click for toggling individual rows.

I don't know anything about ISOM, there are very few people that do. The only person I know of who knows how it works is SI, he might be able to tell you how to get it working. Also if we can get SI to somehow document the way ISOM works, I might be able to improve the editing of the ISOM information.

Yeah I'm not sure why the escape key is not enabled by default. I'll need to do a little investigating to make sure there isn't a good reason, but its a simple 1 word change to enable it for all dialogs. You can do it yourself if you want to try it out before I investigate, just open up Libs/utils.py and change line 251 so that 'escape=True'.

Both are now done (Use right click for fill function).

There is a lot of limitations in the UI framework I'm using, one of the biggest is in how event focus works. I don't really know if there is a good way to fix it, you will just have to make sure you pay attention to what has focus.

Looks like Apply All never marked it as edited, fixed!

This is a huge change that requires rewriting a lot of things. I have not started it, and it would probably take a while once I do, so don't hold your breath

Post has been edited 2 time(s), last time on Sep 11 2017, 6:48 pm by poiuy_qwert.

Ok, gotcha.



I've sent him a PM, thanks!

I don't mind waiting for your official fix to come through, seeing as how it's such a minor inconvenience. Just thought I'd bring it up.