- fixed program window from being upscaled by Windows 10/11
- fixed animation of BD style rocket
- fixed animation when collecting BD style clock
- fixed animation when releasing BD diamond from wall with BD jackhammer
- changed pause button to behave like pause key for tape recorder
Rocks'n'Diamonds 4.4.2.1 released!
Moderators: Flumminator, Zomis
Rocks'n'Diamonds 4.4.2.1 released!
This patch release fixes a few bugs:
Re: Rocks'n'Diamonds 4.4.2.1 released!
Hi Holger, the new sub-release has inspired me to ask about practices for upgrading.
I confess to not following proper practice and deleting the old files and writing out all the new files,
or running a program to mirror the new set-up onto the old structure.
Too much risk of me accidentally deleting my own precious files, levels or conf files.
(I only use the portable version, so I can keep most of my levels etc with the EXE.)
Sometimes I do a 'huck copy' - just copy the EXE and any other files I have identified as having changed, eg DLLs, graphics files.
That is when I think the changes look small/localised enough to do this.
I appreciate that it could go very bad - if I fail to update a graphics strip file, I could get seeming bugs that are my own fault - for that reason, I avoid reporting graphics issues.
Might it be possible, when releasing a new version, to indicate which files have changed meaningfully?
eg the content of a post like the 'news' one below could indicate changed files, either individually or in total:
- the exe, every time, obviously
- DLLs, very rarely
- graphics files
- sound files
- music files {I actually don't care about these, as long as RnD can run happily without these]
- help/documentation files
- conf files will obviously change every time, unless it is a release that changes only say graphics files, which would be very rare.
So, conf files wouldn't need to be mentioned.
* * *
Note I am not talking about date-time stamps, which are always updated for every file. Actually may I ask, is there any possibility of NOT updating the date-time stamps for files the contents of which have not been changed? Then a synchronisation program could automate updating, and could do clever stuff like avoid overwriting built-in files which I have amended - these would be 'Rocks' graphics files - yes I know that is a bad idea and I have decided to stop doing that, as of 4.2.2.0.
But still, it seems that there must be a very good reason for you to date-time stamp every file in a new release, even those which haven't changed. Are you confident the benefit outweighs the benefits that come from NOT date-time stamping files that do not change?
John
I confess to not following proper practice and deleting the old files and writing out all the new files,
or running a program to mirror the new set-up onto the old structure.
Too much risk of me accidentally deleting my own precious files, levels or conf files.
(I only use the portable version, so I can keep most of my levels etc with the EXE.)
Sometimes I do a 'huck copy' - just copy the EXE and any other files I have identified as having changed, eg DLLs, graphics files.
That is when I think the changes look small/localised enough to do this.
I appreciate that it could go very bad - if I fail to update a graphics strip file, I could get seeming bugs that are my own fault - for that reason, I avoid reporting graphics issues.
Might it be possible, when releasing a new version, to indicate which files have changed meaningfully?
eg the content of a post like the 'news' one below could indicate changed files, either individually or in total:
- the exe, every time, obviously
- DLLs, very rarely
- graphics files
- sound files
- music files {I actually don't care about these, as long as RnD can run happily without these]
- help/documentation files
- conf files will obviously change every time, unless it is a release that changes only say graphics files, which would be very rare.
So, conf files wouldn't need to be mentioned.
* * *
Note I am not talking about date-time stamps, which are always updated for every file. Actually may I ask, is there any possibility of NOT updating the date-time stamps for files the contents of which have not been changed? Then a synchronisation program could automate updating, and could do clever stuff like avoid overwriting built-in files which I have amended - these would be 'Rocks' graphics files - yes I know that is a bad idea and I have decided to stop doing that, as of 4.2.2.0.
But still, it seems that there must be a very good reason for you to date-time stamp every file in a new release, even those which haven't changed. Are you confident the benefit outweighs the benefits that come from NOT date-time stamping files that do not change?
John
Re: Rocks'n'Diamonds 4.4.2.1 released!
As your personal data files (like levels, tapes or config files) are separated from the program files, this is not a problem: Just install the new program version over the old one (that is, remove or rename the old program directory and replace it with the new one, or, if you are using Windows, just use the latest "setup.exe" and install the new version over the old one).Too much risk of me accidentally deleting my own precious files, levels or conf files.
Your personal files will not be touched this way.
Regarding date/time stamps, I am also not totally happy with old files having new date/time stamps -- I think it would be better to be able to easily and clearly distinct old from new files in new program versions.
However, as R'n'D uses Git to manage not only its code base, but also its core assets, old files will regularly get current date/time stamps, as Git unfortunately does not store the original date/time stamp in the repository (which makes sense for source code files, as it helps for clean builds, but is sometimes not that ideal for asset files, even though it does not hurt in most cases).
So if you really want to know when certain asset file were originally created or last modified, using the Git history of the R'n'D repository is probably the best solution...