A new release of your favorite engine HiddenChest has been released today!
Version 1.1.57 now allows you to come up with your own custom solution for changing the current SoundFont during gameplay!  

Step #1 - Create a Custom SoundFont Directory

It should be named Audio/SF2.
Yes, it has to be created in the Audio folder as you might have guessed by now.
It will prepend the SoundFont you defined in the hiddenchest.conf file if there is any at all.  

Step #2 - The Script Call

Just use this script call:


...and it will do all the heavy lifting for you.

I might say I got the inspiration after playing a couple of Ys games a couple of months ago. The latest ports allowed you to change the soundfont on the fly or play an OGG or MP3 instead.

Well, this version only handles SoundFonts.
And nope, I'm not planning to include some special OGG or MP3 support to the engine the way those commercial games did.
 No way.

List All of Your Custom SoundFonts

Use one of the following script calls depending on your RPG Maker version:

I'm a bit at a loss...

On your main page, you have three sets of download links "For HiddenChest", one for Mediafire, one for Box.net and one for Mega. Mega contains no content at all except the folders themselves, and the binaries/exes within the others are no newer than 2020, even for the Linux editions.

And within your HiddenChest Github, specifically shown as hiddenchest_linux when opened, your section for "mkxp 650px Wide Prebuilt Binaries" brings up 404 pages, and the +800px Wide Prebuilts do not appear to have anything 'compiled' newer than kbuntu2004 20200509 dated May 9, 2020 or win64 20200312 dates March 13, 2020.

I don't see the new, at least insofar as compiled work.

Yeah, I can't blame you for not being able to find any recent binaries.

The thing is that back in the days, Ancurio also had binaries for both Linux and Windows. The reasoning behind it was that it all started as a Linux port of RM games only. Then over 2 years ago, the Linux executables compiled back in 2015 and 2018 suddenly disappeared.

Then around a year ago I noticed that the Windows binaries had also vanished.

The other reason for this gap would be a number of rollbacks I had to perform in the past couple of years, including the one regarding the evented cutscenes. RGSS as a separate component, technically called a source library SO for Linux with no port for Windows version of the engine, also ceased to exist.

Right now the only executables available online are those I had compiled BEFORE I lost my desktop PC during a small fire.


As a side note, I want to add that the Mega link is useless now. I hated to see how they did not keep my files intact for over half a year so I simply decided for my files to get wiped out automatically by the Mega devs / bots.

I just forgot to properly update the calls to the Settings module from Graphics module and the Bitmap class. Now both of them are calling the Setup module just as expected.

Yet, this update includes a little surprise: the KSoundFontMenu XP script!

It is a basic RMXP-styled menu where you can select the next soundfont with ease.
Now I gotta warn you that there might be a little delay before the engine can actually apply the new set of MIDI instruments to the current MIDI file.

Time for Kudos.

First, I pointed out to a FEW people that you have a feature whereby soundfonts can be selected, and went so far as to show the menu where they can even be chosen in-game. Lets say... you turned some heads with that one.

Second, I personally appreciate the repository of older binaries within your GitHub. True, not current. Certainly not current for Windows editions. I know you've had difficulties on recovering some content, though there is some promise that you did recover the older Windows Port. Hopefully the references to the Boost Library and OpenAL functions reveal themselves.

Incidentally, I learned that one of the older Windows Ports was relayed as more 'stable' graphic-wise. That not just from me. So perhaps this older port you recovered is likely the graphically stable version. It was brandished as 'hires', and the most recent .dlls it used were x64-msvcrt-ruby310.dll (June 23, 2022) and x64-msvcrt-ruby300.dll (Jan 6, 2021) if that rings a bell. TRUE, it would mean catching up. But also with known hurdles already detected.

Alas, old... it has no full keyboard support.

On a side note, the Graphic class had a 'screen_resize' method included from RPGMaker VX on up. This allowed the game developer to resize the display screen from the (SAD) default 544x416 back up to 640x480. Stupid that even for VXAce that 640x480 was a defined maximum with that code. So here I ask, does HiddenChest include this method? And if so, can the settings be set beyond 640x480?

Sometimes I get bored of some of your remarks or find them quite weird. Usually it happens because they demonstrate that you forgot what I have already told everybody on this thread. Let us assume you did not do it on purpose but you did not care to re-read old posts.

Yes, HiddenChest DOES include pretty much all keys. The main post lists all of them. Does it mean it has full keyboard support? That depends on your definition.

If you mean that it will let you type texts at will, then the answer is no, it does not.

On the other hand, it could let you use WASD keys to move your character if you patch the Game_Player class accordingly. There is no need to alter the Input module at all.

Sincerely, I do NOT remember compiling the Windows port against Ruby 3.0 or 3.1. Believe when I tell you that I never did that. You would notice it right away when you see that I did not include a series of default Ruby scripts in the game engine package. Starting from 3.0 you got to include them because you would miss basic Ruby stuff like Dir.chdir otherwise.

If memory serves me well, I only compiled HC against Ruby 3.0 on Linux. Plus, I think I would still need to check if there is no need to adapt the code to the modern version of CRuby like I had to do it when I dropped support for Ruby 2 5 or 2.6.

HiddenChest supports Ruby 2.7 only as of today.

Graphics.resize_screen has been available for all 3 RGSS versions from the very beginning. The same is valid for Font.default_outline as well. Those features were part of the motivations I had to fork the original mkxp project in the first place.

Can HiddenChest go beyond the 640x480 limit?
Go ask Melana about that!  She has been using a custom resolution based on her own monitor's for quite some time now.

(05-09-2024, 12:00 PM)kyonides Wrote: Yes, HiddenChest DOES include pretty much all keys. The main post lists all of them. Does it mean it has full keyboard support? That depends on your definition.

I was told that the version I had did not have full keyboard support.  I have to acquiesce and say that the information I was given was incorrect.  A simple replacement of an Input::C with Input::KeyP indeed functioned properly.

As to receiving player input from a keyboard to allow them to simply 'type text' such as entering a character name or cheat command would be a wholly different script.

(05-09-2024, 12:00 PM)kyonides Wrote: Can HiddenChest go beyond the 640x480 limit?
Go ask Melana about that!  She has been using a custom resolution based on her own monitor's for quite some time now.

Here is some interesting good news that you may appreciate...



It turns out that having the statement  Graphics.resize_screen(1280, 736)  will actually resize the game window. Not only that, the built-in Tileset class will properly adjust and draw all the requisite tiles. You may have forgotten that since your github states "Expand RGSS1 tilesets to fill the enlarged screen and adapts the Window_Message settings to the increased screen resolutions". And on top of that, the fog class itself properly adjusts.  It is possible that it receives values from the Graphics.width and Graphics.height properties themselves (added from RMVX on up) so the only thing need adjusting is the Spriteset_Map/Battle viewport settings and adjust values in the Game_Player class to control centering and scrolling options.

Ah, but the Weather system does NOT adjust by itself. Yes, the above screenshot shows weather covering the entire window, but this after I applied a simple 'edit' to the Weather class to cover the defined area:


Once you put this script, it reads the Graphics.width and Graphics.height values from the Graphics class itself, you're set.

I will say that the first time you use Alt+Enter to switch the game from a windowed resolution into a fullscreen resolution, there may be a momentary 2-second pause for the game engine to properly display the screen. But only the first couple of times performed.  Subsequent use of Alt+Enter to switch between windowed and fullscreen suffers no delay.

All this at least with the HIRES edition I have mentioned.  And it appears that I need inform Melana that no resolution script appears to be needed for her HiddenChest project. Just readjust the Spriteset_ classes, menus and a few methods to adapt.

---

(11-22-2018, 06:33 AM)kyonides Wrote: Audio.bgm_pos and Audio.bgs_pos
useful for setting up a new song or background sound at a different position.

Why did I not see this? *sigh* Unfortunately, it only says the second/millisecond position of the audio as it plays and does not allow one to set or advance the playback position of the audio. If you could have Audio.bgm_pos= (and optionally Audio.bgs_pos=), one could make a system to set custom start/end loop points for audio in a a music track.

If an Audio.bgm_loop(loop_return, loop_end) could be crafted.... that'd be awesome. Not sure how fluent you are in DirectSound or what language is used for MKXP/HiddenChest's audio playback routines.

My engine has included the MapCustomResFixes XP and VX scripts for about 5 years now. It already handles the Spriteset_Map, Window_Message, Game_Screen, Game_Map & Game_Player classes. After reading your comments, I suspected one of my rollbacks eliminated the automatic RPG::Weather adjustment for RMXP games. The latest release intends to reinstall that improvement once for all.

It also includes some new RPG::Sprite instance variables (RGSS1 Exclusive):

• hp_dmg_font_name
  
• hp_dmg_font_size
  
• hp_dmg_plus_color
  
• hp_dmg_minus_color
  
• hp_dmg_default_color
  
• sp_dmg_font_name
  
• sp_dmg_font_size
  
• hp_dmg_plus_color
  
• hp_dmg_minus_color
  
• sp_dmg_default_color
  
• sp_damage method
  

These new variables can be modified during gameplay. RMXP's default scripts will NOT call sp_damage at all. Thus, you got to find a way to make them call that method. This normally means that you will need to craft a custom script of your own.

Setup Module Script Calls

• soundfont - The current soundfont if available. The default value is the same as System::SOUNDFONT.
  
• soundfonts - The list of available soundfonts, it is an automated process.
  
• soundfont_index - Current index of the current soundfont, useful for KSoundFontMenu-inspired scripts.
  
• choose_soundfont(Index) - Choose a soundfont based on its actual index.
  

KSoundFontMenu XP also includes the Game_System#soundfont_index variable as a way to let you store that value in your save games automatically. It also includes some embedded comments that will inform you about some caveats in the use of these script calls that you should be aware of as a game developer.

I will ignore any of Wulfo's remarks for the time being. I will be busy dealing with real life issues tomorrow anyway...

Oh my, kind of forgot I asked.

(05-02-2024, 07:46 PM)kyonides Wrote: Most of the details can be found in the Readme.md file. The most recent ones are listed here only.

Depending on what your goal is with your fork, I'd definitely keep them updated and in one place (Readme or Github repo) as it helps to get an overview for the user.

(05-02-2024, 07:46 PM)kyonides Wrote: I do have binaries for Linux for sure, but they will only work on Ubuntu related distros, 22.04 and 24.04 release exclusive.

Thanks. As I'm running Fedora, I'll have a look and test it on my system in the next days and report back.
Like DerVVulfman, I was or still am confused about the different links you provide to the built binaries.
So, for Windows, am I right to say that the one under

https://app.box.com/s/uibg5p52sykl7u0y1gga6vl20m24or1u

in the Windows directory, March 2020, is your current build for Windows and it is on par with your recent Linux build?
Or does the Windows build lack noteworthy features and one is advised to make a build for Windows with your latest Github repo?

Don't report back!  Really.

I know you wanna use it on another distro but it's obvious that the shared library naming conventions are slightly different. I haven't provided any recent so files so I would expect it to fail on Fedora.

It'll take some time to deal with some issues I'm having with the Windows port. This means that any updates on its progress would only be available on a still very distant future.

By the way, thanks to some nosy Wulfo's complains and reports, I had to rollback the implementation of a few features so the version number on those later builds won't make any sense to you. The Ubuntu port has already undergone this process while the Windows one hasn't. I no longer have any Fedora distro so I won't be compiling HC for that OS in the feature. Feel free to blame a couple of games I've purchased for the lack of free space.

If I left any questions unanswered, I did it on purpose.