Sharina's Screen-Saves

[DerVVulfman]

Sharina's Screen-Saves
Version: 1.4

Introduction

This system allows you to alter the save-game window to include a screen-shot of the field map where the player and party are is traversing. Along with that, there are items which may optionally be shown within the save game files.

The system also allows one to take advantage of two classic RPGMaker savegame scripts by RPG Advocate: the Unlimited Saves script which allows the game developer set how many save files may be recorded, and the Save Override script that brings up a prompt warning the player that an older save game would be erased in favor of the new.



Features

• Save screen-shots of your current map into the save game files
• Go beyond the 4 save-file limit
• Either 2 or 3-save window layout (no 4-save window layout)
• Alter the layout of your savegame windows to your specifications (in reason)
• (INCLUDES) an XP port of 'snap_to_bitmap'
• (INCLUDES) A PNG file generating script

Screenshots







Demo

CLICK HERE -- Box.Com link (Note the Download button at the top of the Box.Com window)



Instructions

Plenty... in the script.



Compatibility

Does a fair amount of rewrites to scripts that handle game saves, primarily as the window and scene scripts were based on Phylomortis rewrites. So, will likely not play well with other save-game altering scripts.



Notes

It uses a PNG file creation script not dissimilar to that within the Zlib system, but comparatively smaller and faster. It is used to actively make temporary files within the project's root directory, though they are deleted almost immediately. If the game's root folder is somehow protected from recording data, you would need to redirect the location where these temp .png files are recorded.



Credits and Thanks

Thanks to zeus81 for the snap-to-bitmap for RPGMaker XP script. And to RPG Advocate for the basis of the Unlimited Saves and Overwrite Prompt save scripts. Also thanks to Carlos_Davilla for noting how cloud-based services like DropBox may have issues with the generated .png files.



Terms and Conditions

Free for use in games, even commercial works. Only due credit for myself, RPG Advocate, zeus81 and Carlos_Davilla are required.

[DerVVulfman]

BUMP

to version 1.2

True, only a day has passed, but the Zlib system that creates .png files has been replaced with another.  This replacement is based upon those found within utility systems such as MapMaker.   

However, the replacement code is a hybrid between the Zlib and MapMaker scripts. While MapMaker's code is able to more quickly create .png files, the generated files cannot load through RPGMaker's cache system. This annoyance was part-and-parcel to how the MapMaker code ended the data blocks within the .png files. So corrections based upon the Zlib edition were made.

Also, the hybrid code includes a little tweak courtesy of yours truly.

It is known to some within the RPGMaker XP community that the 'Graphics.update' command must be executed at least once every ten seconds, otherwise the game engine itself thinks an error in scripting may have occurred.  Something like an endless and recurring loop would cause such an issue.  And if one was to execute either Zlib or the PNG creating system for extremely large graphics (imagine a 500x500 map), it could take much longer than 10 seconds depending upon the PC.  Obviously, the system would shut down and exit.

The hybrid which I provide includes a counter of sorts, actually looking at how many iterations have passed during the creation of the .png bitmap, and execute Graphics.update on a fairly regular (but quite spaced apart) basis.  This would avoid the issue with the Game.exe thinking that it has run into an endless loop, and allow it to function even with massive image files.

*  *  *

Due to the ZLib system being replaced, the use of the SYSTEM_MODE variable within the configuration page no longer exists.  This latest edition no longer has this configuration variable.  If you already have defined your configuration page, there is no worry as the elimination of SYSTEM_MODE would not hamper your setup.

* * *

Just for kicks, I added the timed 'screen-saving' feature into Scene_Battle. While using the default [Call Save Screen] built into RPGMaker XP kicks you out of battle and into the Field Map (ugh), someone may be inventive enough to find a way to save their game while in combat. For this, I added screen shot capability.

So no, it does not save your games IN combat. But it will generate the screenies for someone who DOES come up with such a feature.

[DerVVulfman]

Time for one more

BUMP

to version 1.3

One more day has passed, but an important upgrade was required.

It came to my attention that some in the community sync their PCs with cloud services. As they connect their PCs to outside sources, these sources would require access unfettered access. And if a file was somehow protected from the cloud service, or its creation/deletion interfered with the cloud service, an issue would arise that would force a CTD (Crash to Desktop).

In order for Sharina's Screen-Saves to function, it must create .png files in which to work, and then delete them the moment their usefulness has passed. And therein lay the dilemma. It was this that cloud services would have issue. So something had to be done to resolve this issue.

It was learned that filenames that begin with certain prefixes (~$ or .~) are typically looked upon as temporary files, files that are expected to be created and later thrown aside. And these files are ignored by cloud services. And here dawned the solution.

When creating a .png file, Sharina's Screen-Saves now adds one of these prefixes to their filenames. This is an automatic process. While you (the user) may define the general name of the work file, the prefix is itself added by the system.

So now that the generated .png files are flagged as Temporary Files, cloud services will ignore and leave alone Sharina's Screen Saves and let things be.

● ● ●

I should note that the issue uncovered with Temp Files would actively affect scripts that use ZLib during the creation of the Hope.gz and like files unless addressed.

But that's another system.

[Melana]

Oh, sadly this needs win32api so i can't use it in my game. :c
It looks really cool.

[kyonides]

I think I know why, Melana.

Valid For Custom Implementations of RGSS Only

Well, in your case you don't need Sharina's implementation of Graphics#snap_to_bitmap at all, meaning that you can comment it out right away. Actually, I'd dare to say that you can remove the whole Graphics module found in Sharina's.
As a summary, I'd say that you better use a different script for non vanilla RGSS1.

[DerVVulfman]

BUMP

to version 1.4

Alas, one more bump, but with two updates for effect.

First, some replacement engines for RPGMaker may incorporate their own 'snap to bitmap' method. Given that some replacements for RPGMaker XP's game.exe may have that method, Sharina's Screen-Saves now looks to detect the method before adding its own. So engines that already have 'snap to bitmap' will not have their versions overwritten.

Understandably, the script had been designed with RPGMaker XP and for RPGMaker XP. The addition of the snap-to-bitmap' may be seen by some as a patch to include a missing feature. However, one should not as the feature was neither missing nor removed; instead only later conceived for newer engines. Its addition is an enhancement, and that alone.

However, the snap-to-bitmap method will detect if the engine using this system has its own so-named variation, and disable itself if recognized.

Second, it came to my attention that some saves did not properly update and replace the map image. This is because of an innate feature within the cache system. When the cache system sees that a bitmap is re-loading an already existing file of the same name, the system ignores the bitmap in favor of the original. So recording atop the last game save may not have presented the updated map.

For this, the game saves now include the time stamp. When the temporary bitmap is created, the time stamp now becomes part of the filename and thus fixes this issue. For this, the time stamp must actively be created when the game is saved, and not just acquired from the file itself when being read. Recorded now within the saves, this prevents the unlikely chance that the time stamp may change by a mere second between image generation and the game actually being saved.

Insofar as being compatible with other savegame systems, I did state this at the very beginning:

The system also allows one to take advantage of two classic RPGMaker savegame scripts by RPG Advocate: the Unlimited Saves script which allows the game developer set how many save files may be recorded, and the Save Override script that brings up a prompt warning the player that an older save game would be erased in favor of the new.

It is not that the image-saving feature would interfere with other services, but is instead the script base of the RPG Advocate scripts. Both scripts are, in fact, save-game rewrites plain and simple. However, to allow larger space for the map images, indeed some methods did require rewrites for the number appearing and the refresh method of Window_SaveFile to allow the map to appear beneath the texts.