PyTILE: Allow a 4th minitile elevation level

[joankaradimov]

I've mentioned in the SEN discord that I managed to implement 4 ground elevation levels.

Here's the EXE patch that made it possible: joankaradimov/Magnetar@dafa524
Here it is in action: https://www.youtube.com/watch?v=osrQW417MTI

In a non-patched game this will always behave as if it's the third elevation level (high). So it will not break/crash the game; it will just not behave as higher ground.

This PR exposes the new elevation level in PyTILE. I'm not sure it should be always available, though. Is there a way to switch "extended" options off?

[poiuyqwert]

Hey @joankaradimov,

Thanks for the PR, this is great! I have two main concerns:

1. Usually features like this that require customization of the StarCraft EXE to function are for plugins that anyone can add to their mod. I'm not sure if these changes are available for anyone to add to their mod as a plugin? I don't usually add these types of features to the public release of PyMS unless anyone would be able to use them in their mods.

2. For features that are not standard in StarCraft and require a plugin to function, there needs to be a way of indicating that to the user in the app. Usually that includes:

   • Marking the feature with an indicator in the UI. So the dropdown option might say something like "Higher (Green) [SomePlugin]"
   • Warn the user when they go to use a non-standard setting in a file that is still standard (A popup dialog telling the user the feature requires a plugin, and ask if they want to continue)
   • Present a warning to a user when they open a non-standard file, just letting them know it is non-standard and requires a plugin
   • Display an indication that the file is non-standard in the status bar

   You can see an example of how this works in PyTILE for expanded vx4 (vx4ex) support (if you add enough tiles to go over the limit of the standard file), or in the unreleased version of PyDAT that supports expanded entries (in the expanded_dat_files branch).

If you could clarify item 1 for me, I would love to include support in PyMS for this. Then if you would be willing to make the updates described in item 2, I can merge the PR, and if not I can look to add support myself in a future release (though I don't know when I would be able to do it).

Thanks for your interest and contributions!!

[joankaradimov]

Usually features like this that require customization of the StarCraft EXE to function are for plugins that anyone can add to their mod

This is not available as an MpqDraft plugin. I do have a branch of my mod that can load MpqDraft plugins. So in principle it's possible for someone to inject their qdp files and mix their plugins into my mod without writing code.

But TBH I dislike MpqDraft plugins and I'll probably not merge it into master. And I'm not excited about porting the code to GPTP either.

I'll check if anyone on SEN is willing to port it to GPTP and get back to you.

For features that are not standard in StarCraft and require a plugin to function, there needs to be a way of indicating that to the user in the app

Sure, that sounds reasonable. Let me see if I can address (1.) and then I can move on to fixing these.

[poiuyqwert]

Hey,

Alright great, I would really like to see this being made available! I'm sure someone from SEN would be willing to create an MpqDraft plugin to support this. Once that happens, and you are looking to make the updates for item 2, I can provide some high level pointers on the implementation if you would like.

Also as a side note: MagnetarCraft does look really cool, and I have had fun looking through the code. Are there any high level details on the project somewhere?

Thanks!

[joankaradimov]

Also as a side note: MagnetarCraft does look really cool, and I have had fun looking through the code. Are there any high level details on the project somewhere?

Thanks!

I've updated a bunch of README files today. You can check the main one. Or this and that for details on specific components.