Hopefully an easier feature to add in PyTILE: keyboard shortcut for applying all flags to group? Would help with having to click twice for each group you're editing.

Something like:
Ctrl+Alt+F - applies flip flags to group
Ctrl+Alt+W - applies walkable flags to group
Ctrl+Alt+H - applies height flags to group
Ctrl+Alt+B - applies block view flags to group
Ctrl+Alt+R - applies ramp flags to group
Ctrl+Alt+A - applies all flags to group
Ctrl+Alt+N - toggle 'exclude null tiles' option

Or you could eschew the Alt component of the shortcut since I don't think Ctrl+F is used in PyTILE, which would make it slightly more simplistic, but that's up to you.

On another note, for the times when you want to make copies of your doodads that are graphically identical but have different height levels, would you just import the group again and apply the flags, or would you have to make some visual change to the tiles for them to not inherit the flags of the identical megas/minis? This is for things like jungle/high jungle or temple/high temple that are aesthetically identical but have different height levels (and if they're doodads, they're placed on different tiletypes).

I can look into this.

There is no obvious straight forward way to do this right now. I have thought of adding a duplicate option or something like that, but have not looked into it yet. It can be accomplished right now with the import system. What you want to do is import the graphics again, and make sure you have the "Reuse minitiles" options enabled, but not the "Reuse megatiles" options. I will look into adding a better way for this, but it will probably be a lower priority for now.

The list of enhancements for PyTILE are starting to pile up

Right on, as long as there's a way to accomplish it (even if it's a roundabout one) I'll be able to make it work. You're right to keep it lower priority given everything else on the list haha.

I don't think these are nearly as high priority now that the 'apply flags to all megatiles in group' function is back online. This is a massive luxury to have - so much so that I'd go out on a limb and say it probably isn't worth the backend work required to make it happen.

New request: field to enter string ID from stat_txt.tbl corresponding to a doodad's `group` field. Would make sorting doodads much less irritating (don't have to scroll for half a minute for each doodad, etc).

Well its on the list, it will probably eventually get in. But yeah, low priority

Yeah that is something I have wanted to add for a while, but it didn't really work for the old UI. That will be part of the UI overhaul i'm doing. Have you tried out the snapshot with the new main window palette?

What do you mean?

I was talking about this:
Though now I realize I haven't added back a way to get to the group palette window yet, so it wont actually be useful to you.

PyAI: when saving the files as new files, is it possible to make the filenames default to aiscript.bin and bwscript.bin instead of having to type them manually?

Good point, I can add that for a few programs. Github issue

This is fixed.

I can't reproduce the issue. When I import that bmp the GRP is created properly. Can you give me detailed steps to reproduce the issue? Are you creating a new grp? What settings are you using to import?


Hey Pr0nogo, can you test a new flow layout I'm hoping to use for the new PyTILE UI? If you download this snapshot (don't replace the PyMS you actually use), you should be able to run "Libs\FlowView.py" to get a test program. If you could mess around with it by resizing, scrolling, tabbing around the text fields, and just make sure it works alright? It doesn't actually do anything, its just to test laying out the views. If you restart it a few times, it randomly generates different view combinations for testing. If everything goes well, I'll probably start updating the PyTILE UI to use it Thanks!


Edit:
This is now fixed.

Post has been edited 1 time(s), last time on Aug 5 2017, 8:13 pm by poiuy_qwert.

Defiler, Queen, Vessel, and High Templar.

Overlord check is hardcoded unit id, workers I'm not 100% sure but BW should be checking the units.dat worker flag.

Ok, it works fine now.

Noted, thanks!

Noted, thanks!

Awesome, I've merged it in. Thanks for testing it!

I had opened an old GRP (the one I sent you) and it happened, I didn't test with a new one because I'm a bit of a dunce. I'll mess around with it more and see what happens.

I messed with it quite a bit, tabbing, resizing, typing, etc and no problems so far.

Will check out the updates to PyTILE soon-ish as well. Thanks!

PyTILE's update seems to work as intended. Thanks for fixing that.

PyTRG: can we open default trg files without extracting them from the MPQs? I didn't see a way but I didn't look very hard.
Is the syntax identical to SCMDraft's text trigger editor, or is there a different way it needs to be written for it to be accepted?
Bug: File path does not update after using save as.

PyMPQ: Internal error when attempting to save an archive (in this case, an exe) while its open. It should just inform you that you forgot to close the file
It would be nice to have PyMPQ default to all files or all supported files instead of mpqs. I mostly edit exes.

Post has been edited 2 time(s), last time on Aug 7 2017, 9:01 am by Pr0nogo.

K

Awesome. Here is a peak at the new interface (which uses the flow layout):

Working on doodads next. Any comments/ideas for the new UI?

Great, np.

I don't think so at the moment. I have plans for better support for MPQ integration in all programs.

It uses its own syntax. There are details in the PyTRG Docs (one of the few programs with at least some docs )

Noted, thanks.

Hmm, I'll have to look into this. It shouldn't error like that...

I don't think I have control over that unfortunately. I can look into it though.

Post has been edited 1 time(s), last time on Aug 7 2017, 4:32 pm by poiuy_qwert.

Honestly that looks incredible. Makes group editing super easy, at least on paper. I'll use it extensively and provide more actionable feedback when it ships, for sure.

For doodads, it'd be nice to be able to make any group a doodad group, and to preview overlays similar to how PyLO's grp previewer works, but I don't know how realistic either of those features are.

Ok, thanks for letting me know. I'll pop it open and see what's going on, since the syntax went through correctly but the changes aren't taking into effect when I start a melee match. I was able to get some stuff done by editing a template file using PyGOT but it doesn't include everything possible via triggers, obviously.

You might be able to remove all specific file associations with the open dialog (so it's forced to look for all files), but idk if that screws with file associations when opening mpq files. Not a big deal ultimately but would knock a few clicks out of the workflow.

PyGRP: On my system it seems to take a while to extract frames. Is this a known issue?

PyDAT: Ability to read external tbl and grp files for text and image previews would be nice. If we could open EXE files like DatEdit, even better.

PyMPQ: Delete hotkey for removing items doesn't work.

Post has been edited 3 time(s), last time on Aug 7 2017, 5:56 pm by Pr0nogo.

Could PyDAT display the exact range in weapons.dat? Both PyDAT and DatEdit display the range as half-tiles, which doesn't really make much sense. BW cares about every pixel of the range, and some melee units have range by default that is not divisible by 16. For example Broodlings and Zerglings both show their range as 0 in PyDAT, but their ranges aren't actually equal (at least before the .dat is saved, I don't know if the range gets rounded on save)

Post has been edited 1 time(s), last time on Aug 7 2017, 10:03 pm by Neiv.

Making any group a doodad group is not possible, that is just how the file format is (groups >= 1024 are doodad groups). I do have plans to split doodad editing into its own tab, which should improve a bunch of things. I also have plans to update the way doodads are edited entirely, including a previewer for overlays.

Did you save them as .got compatible? (button next to save as, or Ctrl+G) The .trg files used for game templates need to be "headerless", which can be accomplished in PyTRG with the mentioned button, and you can use PyGOT to strip/add the header from existing .trg files.

Oh yeah I could have done that no problem, but I didn't want to get rid of the option to filter to specific types. Anyway, this was just a brain fart and I must have misread your suggestion. I just did what you said and added another option for "Any MPQ", so it should be fixed (I didn't increase the version for this because its trivial, so you wont get a "new version" alert, but there is a new version)

This is not a known issue. What is a while? How many frames and of what size are you extracting? What bmp style are you extracting with? Is it only for specific grps, or all?

This is already possible. Just add your mpq/exe to the MPQ Settings at the highest priority and it will load your mods files. You can also load external .tbl files in the TBL Settings if you wanted (you can not with GRP's, they must come from the MPQ's)

Weird, i'll look into it.

Yeah, I'm not really sure why it did that, I guess I just assumed DatEdit had it correct. I have changed this, thanks!

Sounds awesome, looking forward to testing it out.

Doing this solved my issue. Thanks!

Great, that's exactly what I needed. Thanks!

I'll do some more thorough testing tomorrow but I was extracting ~230 frames from a compressed grp and it was taking over 30 seconds. Happened with two grps. Might have been something unrelated, I'll get back to you on it.

Great, I'll play around with this and let you know if there are any pain points.

Last edit: Either one of "reinstall Python, reinstall PyAI, disable additional info saving, copypaste scripts from scratch" resolved all my issues below, HOWEVER please read the post for the feature requests - I bolded the edits with them so that they're easier to spot. I'm leaving the errors so that if they're somehow related to PyAI and not just to my stuff corrupting somewhere along the way, you can correct them

PyAI error, starting with context:

only openable z3 script for reference - https://pastebin.com/raw/Tvk1iyzY

z3e .txt export before it crashes - https://pastebin.com/raw/80cVc1GG

intended z3e - https://pastebin.com/raw/dWp0Wtgc

result on previous saved bwscript: all scripts open up, E is shown correctly, A-D show the same version of E as D does now - I thought it's a minor display error somehow, since it seemed to work fine in-game, though it required rewriting the scripts a little since it wasn't possible to save after changing with the doubled Z3E0000 block

PyAI version used: the newest one for the entire duration of this BWscript's existence

result while opening z3a-e except d - (btw I can't copy this from the error box itself for some ungodly reason - there is no copy button)
for the record, re-saving->opening ZBE3 didn't fix the issue

Feature request edit 1:

As Neiv found out (God bless him), AI towns that have over 100 lines of build + upgrade (upgrade 1, 2, 3 count as 3 separate lines) + tech corrupt other towns (causing a SC crash). PyAI doesn't seem to check for this currently, please make it check. Since it's on a town-by-town basis it has to somehow check according to the scripts flow, and not just adding up all the stuff in the script, since that would invalidate scripts with multiple variations and expansions. B/t/u commands in a loop add up until there's 100+ of them and then corrupt another town: which means PyAI should also warn or just downright prevent b/t/u commands in a loop. I don't know how easy is this for you to implement, but since it's a stability issue I believe that it should be a high priority change. An example of script that caused crashes because of this issue and was not caught by PyAI would be ZB8A in this paste https://pastebin.com/raw/sSUy7xSH (with ZB8D approaching something like 95 b/t/u commands in each variation)

Feature request edit 2:

There is also still no warning for over 20 defensebuild_xy units of a given type (for clarity, you can have 80 max in total, from aa+gg+ag+ga) (going over 20 of a type makes the over-20 ones not count) p_q pleas implement

Edit:
(issue resolved after reinstall etc, as written above)
https://pastebin.com/raw/F9vRCrcg (ctrl+f "block1"), not fixable, writing in this script https://pastebin.com/raw/bQN0r2Ys and translating->saving it still resulted in the block1 invasion after reopening it.

Post has been edited 7 time(s), last time on Aug 9 2017, 11:32 am by Nekron.

If you also send me the GRP you are testing with I can look into it a little more as well.



Yeah I believe this is from the "additional info saving". I have seen some issues before around it. I don't think it is a very useful feature, it was more of an experiment, and I don't think anyone uses it, so I plan to just remove it entirely.

This is not something that is currently feasible, and is very complex to implement. I would also probably have/want to re-write the entire save/load/decompile/interpret code to accomplish this. This also why the "loop missing wait" check is not perfect. I have wanted to implement "simulating" scripts to detect runtime issues like these for a while. I have noted this in a github issue, but I don't have any plans to actually do it at the moment, sorry.

I can do a very basic check across the script, but this has the same issue as the one above. Unless I "simulate" the script, I can't tell if you are adding too many in a loop, or that multiple build orders are used and none of the individual build orders exceed that max.

I have no idea what this means