[Updater] Change the SMBX2 "generate-build.bat" to generate a 32 bit build of the 64 bit build's version in the adjacent folder
Emral opened this issue · 8 comments
Is your feature request related to a problem? Please describe.
For SMBX2, you once updated the files to include a 64bit build of the editor by default and a script to generate a 32 bit build, using a copy of the update-pge.bat script from the 64bit build's folder.
Now people are using it and unintentionally downloading a newer version of the editor which has new config pack settings that the current version of our config pack does not deal with. As such, fields like the new autoscroll and other 38A or xtech specific fields are visible to these people and may cause confusion, or at the very least an annoying "you are using a legacy config pack" message.
Describe the solution you'd like
Could you please update the 32 bit generator script to download a 32 bit build of the version of the editor that's identical to the 64 bit build in the folder the updater script gets copied from, so that all users use the editor version we configured a release for?
@echo off
echo Copying data...
xcopy /Y /I /E /K /H ..\PGE\configs configs
xcopy /Y /I /E /K /H ..\PGE\tools tools
copy ..\PGE\update-pge* .
echo Patching scripts...
tools\fart update-pge* "bin-w64/_packed/pge-project-master-win64.zip" "bin-w32/_packed/pge-project-dev-win32.zip"
tools\fart update-pge* "bin-w64/_packed/pge-project-master-win64.zip" "bin-w32/_packed/pge-project-master-win32.zip"
tools\fart update-pge* "PGE_IS_COPY=false" "PGE_IS_COPY=true"
call update-pge.cmd %1
Thanks
Hello!
The build of the same version is no longer exists on the server, just because it's a laboratory version that gets always up to date. Speaking about config update, I added the little paragraph here on how to fix post-update errors at SMBX2 configuration package: https://wohlsoft.ru/forum/viewtopic.php?f=11&t=1977
To make your idea work for the next time, yo need:
- Before releasing a new version of SMBX2, make full update of Muubdust Devkit to ensure its latest
- Manually download the archive of 32bit version of Moondust Devkit manually
- Preserve it manually at the day of any future SMBX2 release (also give it the name after the version of the SMBX2 release). Place this copy at the same directory as the SMBX2 package.
- when making a 32bit devkit, for the initial download time, use the same link to the preserved version of the devkit, and after, put the link to laboratory version to keep the future ability of users to pull updates when they really needed.
I'll try to write a bit more once I get my computer.
P.S. The better idea is preserving a config pack copy on every release, and let an update script to download the config pack updates too. So, with a devkit, I'll also keep the config pack being compatible to avoid the future mess like this. (Note: there are should be two different versions of "update_pge.cmd": one will update devkit only, use it for internal development of SMBX2 only, and the second that will also download an update of the config pack (preserve a copy on every SMBX2 release).
Also, speaking about the future cases when a pile of new in-editor options gets added, I'll add the field that will disable all unlisted in a main.ini file fields by default, and you'll need to enable every field explicitly when you want to utilize them in a future). That should simplify the life.
So, about unexpected features introductions, I added the default = hidden into main.ini which should avoid future confusion against new features of Moondust Editor that aren't supported by X2. You don't need to do anything right now, I added that field into the current X2's main.ini, so, once again if you'll update Moondust Devkit, you don't need to worry about the unexpected appearance of new features as that field will just work.
Oh, they pull a version from the server? I thought it did a GET request to the git to zip up a specific commit and download that. That complicates things a bit.
Hiding unknown fields by default is a good move. I still somewhat worry about the "You are using an outdated config pack" message when the config pack version doesn't match the one the editor expects. Maybe that warning can be suppressed? It's not often relevant anyway. Then there shouldn't be an issue with it pulling the newest version.
Please read an article I linked above, the "post-update" fixing paragraph at the bottom of ye post. (I already tired to repeat the same for multiple times) this is the actual way to get rid of the warning. That article I wrote to give it to ordinary users to explain how to update Moondust Devkit at X2 and I explained some of sensitive cases to help users to solve them.
Oh, they pull a version from the server? I thought it did a GET request to the git to zip up a specific commit and download that. That complicates things a bit.
Taking an archive of specific version is suitable for released versions only. X2 for the whole time of its existence had always used one of laboratory states of the Moondust Devkit. That why scripts was never relying on an absolute version. Absolute version is possible to retrieve from repisitory's releases where I always attach pre-built archives with a complete stuff inside. So, if you want the 32-bit downloader to download the same version, you'll have two ways:
- stick on one of stable versions (currently it's my recent beta version, previous release is too old and isn't suitable for anything)
- on a moment of on another X2 release, preserve the currently laboratory state, and use it in the 32-bit downloader script.
P.S. For a long time I changed the compatibility check of config packs using API version instead of the absolute version of Editor and Engine. So, I do change the API version once I introduce any incompatible changes like changing of measure units of some values, renaming without alias keeping, significant behavior changes, etc. For other forward-compatible additions the API version remains the same for a long time.