Dec 31, 2013

Daily Life Project (part 1 - time and lighting)

It feels a bit strange that, after all this time, I finally get to repost the script that started this blog, a long while ago, long before I had made myself a name - that is, long before the ACMS. :p The loop is getting looped, and it feels like a nice parting gift with all of my faithful RMXP followers.

The Daily Life project initially is my own attempt as a day/night system. If you would like a day/night system and...
  • you think most of those look ugly or otherwise unrealistic
  • you would like to control the flow of time
  • you would like to make variations on events based on the time of the day or day of the week
OR
  • if you would like a realistic, dynamic lights system
Then it is exactly what you need.




Features



Event-controlled time.

  • time does not advance automatically - unless you command it to with a parallel event. You get to control how time changes with game variables, down to the second.


  • a wide range of variables and switches allows you to set event to appear/occur only at specific times - specific hours and/or days in the week and/or months and/or years...


Natural-looking day and night.
  • progressive transition between dawn, day, dusk and night
Progressive change in daylight on a summer solstice
  • progressive change of daytime duration according to the season (daytime lasts longer in summer)
Progressive change in daylight on a winter solstice
  • fading overlay effects according to time of the day (sunbeams at noon and haze at night)
  • events named "Shadow" automatically fade out as night gets closer
  • day/night can be disabled when inside closed spaces, and luminosity set manually
Closing the curtains forces the luminosity to zero despite the fact it is noon

Realistic, dynamic lights
  • any number of light sources can be set and blend naturally into each others
  • real-time calculation allows light sources to flicker and even move around
  • adjustable radius and strength
  • lights tear through darkness but do not overlay ambient light




Known issues



  • This script is known to make the interpreter lag, depending on the user's machine. It is not the script's fault. RPG Maker's graphic engine has such poor performances, that how the script works will necessarily confront it to its limits sooner or later. It is pointless to ask me for an optimization, since there's absolutely nothing more I can do to address this issue. However, here are a few guidelines to avoid lagging:
  1. More light sources mean more calculations - do not make too many of them
  2. Map scrolling requires recalculation at each frame - avoid making maps that exceed the screen size
  3. Having light sources flicker or move around also requires frequent reclaculation - do not overuse those effects
  4. The darkening overlay which gives the illusion of night is arranged in small blocks. The DARKNESS_PRECISION constant in the Constants - Custom entry controls the size of said blocks - the smaller they are, the better the quality and the worse the lagging. It is set to 2 by default, which I found to be the best quality/performance ratio. Setting it to 1 will make the overlay appear blocky but will cut the load in quarter.
  5. The DARKNESS_FRAME_SKIP constant in the Constants - Custom entry allows to force the calculations to wait for a set amount of frames, thus effectively cutting the load. It is set to 0 by default (no skipping) but you can set it to small numbers (like 4 or 5) so that the overlay does not appear too jumpy, and you gain a little performance boost.



Download



The following link provides a script bundle meant to be used along with the Script Manager. Terms of use and instructions are provided within. Please credit me if you use it in your own project. A nice comment is always appreciated.


The following link provides a demo for said script.

Dec 29, 2013

The Variables Binder or How I Made Something Easy Even Easier

Faithful users of my works know that I like event-controlled system, when appliable. For example, my Balloon Messages System relies not on clumsy commands input in messages or stuff like that, but rather on regular switches and variables, which are easier to handle. Those switches and variables are then read by the scripts which in turn do their job. To achieve this, the scripts have to know which switches/variables were appointed to this or that purpose, because from one project to another, a same switch/variable may very well have a different ID - like, if I use switches #2 and #3 in my demo, they might already be allocated, and you'd like to use other ones instead.

Up to now, you had to manually set up constants for that purpose. You had to choose free switches/variables in your project editor, then you had to open the script where the constants were set and replace each of them with the ID you'd chosen, and then it was all cool and easy. That was, until I decided I was too lazy to do the manual part anymore. I decided it was not that hard for the scripts to find the matching switches/variables after all and they could very well do it on their own. From that decision, a new script was born. Behold... here's the Variables Binder!



So what does it do?

Basically, automate the process of binding switches/variables as set in the project editor with the scripts. Say you install the Balloon Messages System to your project, you run it just after, then return to your project editor and poof! a couple of variables and switches which control this system have installed themselves in free slots, saving you the trouble of naming them manually. From then on, those switches/variables will automatically be recognised by the script you've just installed and you don't need to worry about that anymore. So, in short, it's simple as 1-2-3.



Any recommendations?

The Variables Binder will never ever mess with switches/variables which already have a name so it's absolutely safe to use on a project you have already started a while ago - however, it decides whether a switch/variable is free based on whether its name is empty or not, so make sure all of the switches/variables you're using at this time have a name, otherwise you could get surprises.

You can see that your newly named switches/variables have got a tag before their name. This makes it easier to see which variables group together, but it also works as an identification code. That is, you're free to rename the switch/variable as long as you keep its tag intact.

If you were already using one of my event-controlled scripts prior to the arrival of the Variables Binder, please make sure the variables you've set manually have the exact same name (without the tags) as in the original demo, since when the tag is absent, the Variables Binder will identify them based on their name, and automatically add the matching tag - so you end up with the exact same settings as if starting a fresh new project with the scripts' latest version.

If the switches/variables have not been installed prior to the Variables Binder's first launch, it will claim the first free slots it can find, so you might want to have several of them in a row so that they don't get scattered. Also, make sure you have set the maximum number of items so that there's enough room for the newcomers in the first place!



What if I still want to set the variables manually?

If you're not satisfied with the Binder's automated setup for whatever reason, there's nor problem at all. Just cut/paste the name of the variable you want to move to another slot. Since the setup is dynamic, the script will recognize the newly named variable as if it had set itself up on the next time you run the game.



Where can it be found?

The Variables Binder is part of the latest version of my Common pack. You should re-download it to ensure compatibility with my future scripts.

Aug 25, 2013

Surprise on the Moon!

Hello folks,

Recently I was announcing I'd lost some significant contents that was supposed to help me complete the oh-so-awaited update to the Script Manager. This led me to question some choices I had made at the time, since I was to remake them anyways. And so, I'm pleased to announce that I've AT LAST succeeded at making the Script Manager as versatile and powerful as I wished it to be. Though it's not quite the all-in-one utility I had in mind at first, I think it's all better as it is now.

From now on projects are going to be hybrid, meaning you can run them as regular projects using their featured copy of the scripts they use, or run them using the Script Manager, with no modification whatsoever. For example, when I release a new script, you can try it out downloading it as a plugin and launching your project with the Script Manager - this will read the newer version you've downloaded instead of the older one from your script editor, without replacing it, so your game still runs the same as before. Additionally I've made a tool to export scripts from your projects (read scripts from the script editor and export them as .rb files, so that they can easily be used along with the Script Manager), as well as another one aimed at importing the .rb files used by the Script Manager into your script editor, all of this automated of course.

I will not be going more into detail tonight, I was merely to excited about this new achievement to wait any longer to let you know. I will be replacing all of my Script Manager-dependant demos with hybrid demos you can run as they are in the following days. As of right now only the newer version of the Ballon Messages Demo is available for download. You can try it out, check that it does actually run on its own, and have a look at the scripts inside its script editor, all of them imported automatically from external .rb files. :)

Have fun!

Aug 20, 2013

Even More News From The Moon

Hey guys,

Today I wanted to complete the update I'd promised a loooong time ago on the Script Manager, but I realized I had failed to update my backup copy with the latest version of my works. Fortunately not everything was lost, but I have a lot of catching up to do and I must confess this sad event has killed the little courage I was able to gather. So probably still no update before a while.

Regarding OpenRGSS, a friend of mine helped me through the process of writing the C code I need, but now we're stuck at the compilation step, which really seems to be a pain with Ruby in a general manner. Also, I'm considering dropping SDL as OpenRGSS's backbone and replacing it with SFML at the suggestion of a community mate, but I still need to investigate its features and of course, to install it succesfully before making a decision. This would mean rewriting the low-level engine, but hey, life is an eternal starting over.

So, lately, I feel the urge to create something, but nothing seems to go right. Anything for me to do, anybody?

Jul 10, 2013

More News From The Moon

Hey guys,

I know many of you await news from the OpenRGSS project. Sadly I haven't been any further than what you have seen already. The main reason for this is that I'm stuck with technical issues. Simply put, there are things I will not be able to implement in Ruby, not because I cannot do it, but because Ruby is very slow and even with optimal programming, some processing-heavy functions slow down the engine too much. So, I would need to implement some of it in C++, which is Ruby's "parent" language. The problem is that I don't know the first thing about C++. So, if anyone who is knowledgeable about C++ happens to pass by, your help would be very much appreciated on those issues, it's mostly about investigating the Ruby/SDL gem's source code and helping me with syntax and stuff - nothing too time-consuming, really. Also, if you know someone who might be able to help me, please do spread the word. As soon as I get past those lil' setbacks, I can resume OpenRGSS's development.

While I'm there, I would like to share my feelings regarding something which has been bugging me. I know the Script Manager has rendered the installation of my scripts less intuitive, especially since I have still not released the update like I had promised a while ago. Still, as open to criticism as I might be, I do not accept comments like "I don't understand the first thing about your site, make another tutorial". I can understand your frustration and I'm honored you absolutely want my scripts in your games, but I am not a company, I am not making business out of scripting, I have not sold anything to you and I am not an after-sales service either. I have made those scripts for the sake of making them, and nothing forces me to share them in the first place. I might as well shut this blog down tomorrow and close my MediaFire account just because I feel like it, and keep my own scripts to my own self, and there would be nothing to lose as far as I'm concerned. Because I share my creations does not mean I have pledged to have them work perfect in each and every one's games. If you address me without the slightest "please" or are implying that I did a poor job, you're welcome to look for scripts elsewhere and I will definitely not mind you not using mine, really. People who have no respect for others' works do not make games I like to play, anyways,

So, basically, if you have no consideration for me, don't expect me to have consideration for you and your game, either. And don't come bragging about how you will never use my scripts to punish my arrogance, because frankly I don't care. People who have addressed me in a friendly, respectful manner, can testify I sympathize with others' issues and often do my best to help them while there's nothing for me to gain in return. The others can keep on asking and complaining as long as they like.

Sorry about this little digression, nothing has changed towards my faithful readers, and I'll make sure to let you know it as soon as I have solved my C++ issues.

Take care in the meantime.

May 20, 2013

OpenRGSS Progress Report - Sound & Music

I'm still doing a lot of behind the scenes work, so nothing really new since last time except for the addition of sound and music, which was kinda piece of cake as compared to the graphics engine. So this time you get to watch a small video to see how all this blends together (please watch in HD).



Comments in the video say it all I guess. If you listen carefully, however, you might notice that the music sounds a bit different than what you are used to. So you might wonder what I did to those music files to improve their quality. Well, nothing actually, and that leads me to a very interesting fact I'd like to point out.

You have surely noticed that MIDI files (.MID) tend to have poor quality. On the other hand, they are tiny in size, but then many people wrongly assume that there's a link between the two. This is true for sound files, like .WAV of .MP3 files, because the bigger they are, the more information they have, and thus the better the quality. Well then, a MIDI files does not contain sound. It's merely like a sheet music, it just stores what note it's supposed to play at what time using what instrument, and that's the reason why it takes so little space. This is also why you can easily tweak pitch, tempo, volume, instruments... track by track, using the proper editor, while sound files are somewhat "merged", raw sound, with no concept of notes or instruments in the first place.

So you're probably going to wonder, how do I get to hear a MIDI file then? Well, you just need to have a synthetizer to read the sheet music and play it back. It will do so using a sound bank, in which samples for each instrument are stored - meaning, if you followed me, that if you use another sound bank, your MIDI file will start and sound differently all of a sudden. This is very much like using a character font for text - the text data remain the same, but it's rendered differently according to which font you pick. What I previously called sound bank is sometimes referred to as soundfont, by the way.

So the reason why your MIDI files sound bad is because the default synth featured with your system has a crappy sound bank. Get a good synth and they will sound better just like magic, with no addition or tranformation whatsoever to the files themselves. The good news is that it is possible to replace Windows's default synth with another one that supports soundfonts, then you get to choose the soudfont most fitted to your taste and computer performances. The bad news is that MIDI files will still sound crappy in RPG Maker. This is because RPG Maker does call the system synth, but rather uses its own, internal synth, which sticks to the crappy sound bank, and there's nothing you can do about it. But then again, another good news is that, of course, OpenRGSS does call for the system synth to play back MIDI files, which means it does support soundfonts as long as you have a software synth installed, which supports them itself.

For this video, that's exactly what I did - downloaded a software synth (namely Coolsoft VirtualMidiSynth), downloaded a soundfont (Merlin Gold v4.10), set the synth to use the soundfont and use it as default synth for MIDI playback. Now all MIDI music that will play on my system, wherever it might come from (except for RPG Maker of course) will use the soundfont and sound nice. Note that this applies only to MIDI files, though, and that it depends on the user's system - meaning if you install the synth and soundfont to get your MIDI to play nicely, it will still sound as bad as always on the computer of someone who hasn't.

I couldn't resist recording a few pieces using either the RPG Maker playback, or the synth/soundfont combo, so that you can hear the difference. I'd like to insist that those renderings were obtained using the exact same MIDI file with no adds or modifications whatsoever.

RMXP playbackOpenRGSS playback
using VirtulMIDISynth & GeneralUser GS FluidSynth v1.44 soundfont
001-Battle01.mid
RMXP
012-Theme01.mid
RMXP
026-Town04.mid
RMXP
034-Heaven01.mid
RMXP
039-Dungeon05.mid
RMXP
044-Positive02.mid
RMXP
062-Slow05.mid
RMXP
GRABBAG.mid
Duke Nukem 3D
STALKER.mid
Duke Nukem 3D
ALIENZ.mid
Duke Nukem 3D
EXRUM.mid
Monkey Island 2
LARGSTAB.mid
Monkey Island 2
HITGM.mid
War Wind

So, I hope this post shed some light on the MIDI format and gave you a better opinion of it. More progress to be shared soon, so stay tuned and have a nice listening-to-better-MIDI experience in the meantime.

May 4, 2013

OpenRGSS Progress Report - Graphics Engine & Windows

Hey guys,

Not so long ago I made an announcement regarding my upcoming project, OpenRGSS, and told you what it was all about. Since then I've made a lot of progress, and because a picture is worth a thousand words, I'm going to share some screens with you today.


Ring any bells? Yep, this is RMXP's default title screen, except that it is run not from its featured Game.exe, but from the OpenRGSS launcher. Not impressed, are you? Want something a lil' more ground-breaking?


So, how about getting the same screen to a 800x600 resolution instead? We can do so through the built-in options menu OpenRGSS projects can access anytime pressing the F1 button.



This menu will replace the Game.exe options menu and will eventually feature control changes and stuff like that. Also, since it is part of the Ruby scripts, it means that you will be able to tweak it, and even script your own options.

Note that windows and background sprites can be set up to automatically adapt to the new resolution.

Also, you might wonder what that troublesome lil' arrow is doing in the middle of the screen. Well, that, my friends, is the mouse cursor. Of course you will be able to customize its appearance and disable/re-enable it at will.


But the interesting part about it is that windows can now be browsed using the mouse. It's as simple as what you'd expect it to be - just point & click to select an option. This is featured by default only in standard selectable windows, as shown above, but the OpenRGSS functions allow you to easily give mouse support to other window types with minimal code.


This last screenshot sums up about everything I've added to the OpenRGSS engine so far, including windows and text management, and it's all pretty self-explanatory. I should give a word about the composite windowskin feature (bottom-right window), though. The thing is I've grown tired of being always required to make edits to windowskins pictures because I liked this background and that bordersand wanted them together. So since I'm scripting my own engine, I thought it was about time I did something to improve this aspect. So what OpenRGSS does is that you can have a variety of backgrounds, borders, cursor graphics, and so on... to choose from and the engine will render windows from your choice. It is still possible to select a single windowskin picture, as you are used to, but then what OpenRGSS does is that it extracts each component from the picture and add them to its library of windowskin parts. So what I did there was to select the custom windowskin for the bottom-right window, then tell it to pick the default windowskin's borders. Also, note that windowskin components can have an arbitrary size, for example it doesn't matter if your custom background has a size that differs from 128x128, which is RMXP's standard. Though it's not implemented yet, it is planned to add support for RMVX windowskins as well.

Oh, and regarding the cut-out text in both bottom windows, it's not a glitch - it's merely that the chosen height for this screen (600) isn't divisible by 32. It's an issue with the screen size, not an engine malfunction.

Hope you liked what you saw and see you next for more updates!

Apr 27, 2013

Progress Report - OpenRGSS

Hi folks,

So, some time ago I said I would keep in touch regarding what I'm doing at the moment. So here I am. :D I also said I had my mind off RPG Maker, and today I'm going to tell you why. Actually, as a programmer, I like to do things my way. I mean, it's just like a spriter lookingfor graphical resources and unable to find anything satisfaying, you're just gonna say "let me do the whole stuff on my own anyways, since I can do it". Same goes for me as far as scripting is concerned. I can't refrain from seeing flaws and limitations everywhere, and just think "I absolutely need to reprogram that from scratch someday". For instance, you might think the reason why I made the Animated Custom Menu System in the first place was because I felt some artistic urge arousing in me and I couldn't resist it - but actually it's just that I was fed up with all existing custom menus, either for being so ugly or for offering so few customization options (or for both). Not to sound self-important or anything, I'm merely sharing some insight as to what motivates me. And mediocrity is a powerful motivation catalyst to me.

The reason why I'm telling you all this is because RPG Maker itself is quite mediocre in my opinion. You might be surprised to hear me say so, and then wonder why I've bothered to write scripts for it in that case - and I suppose it's for that very reason, since I felt there was so much to improve in it. Then you might wonder why I don't move on to another maker/language. Well, the fact is, I'm not the hard-working type for one, and it's not like game-making earns me anything but personal satisfaction (and nice comments from time to time, too) anyways. I'm not ready to spend a lot of time and energy learning how to use new tools - besides, it so happens that I have grown to like Ruby a lot and it fits my style of thinking prefectly. In other words, I can't decide between sticking to RPG Maker and its stupid limitations, and trying my hands at something new.

So, the "doing things my style" reasoning led me to the following conclusion - since I can program in Ruby, why not reprogram RPG Maker itself? I mean, not the maker in itself, but rather the game engine. Since I'm aware this concept might sound a little foggy to my everyday reader, let me come up with a cool diagram to illustrate my point.



The important part of it is that, while scripts featured in the script editor do power your RPG Maker project, they are in turn powered by something called RGSS, of which contents is not directly accessible because it's compiled (that is, already transformed to machine-understandable code). This is what I called the game engine, that is the stuff that makes it possible for Ruby scripts to run a video game in the first place. Scripters may have noticed there are limitations you can't override, unless you use some dirty, heavy workaround when it's even possible. For example, it's the game engine's fault if we can't have a window larger than 640x480. Or if we can't have the game run at more than 40 FPS. Or if the game tends to lag with big maps. It's all because it was programmed by Enterbrain in a certain way - and there's nothing we can do about it, since the code responsible for it is already compiled in the .DLL and Game.exe files.

So my thinking is: if we could replace the game engine parts (RGSS####.dll and Game.exe) with Ruby scripts, then we get ourselves a 100% customizable game engine, since as scripters we can program in Ruby anyways. Eventually, such a game engine should be able to run RPG Maker projects, instead of its own game engine. And this is exactly what I'm trying to do right now - program a suitable replacement for what runs RPG Maker projects. I call this project OpenRGSS since it's still RGSS, technically speaking (RGSS being the name for the programming language on top of Ruby rather than the game engine) and its main purpose is to be open-source, somewhat like OpenOffice is to Micro$oft Office.


Okay, great! But why go through the trouble again?
  • Natively bypass RGSS's limitations (screen resolution, FPS limit, inability to use the mouse or the entire keyboard, lack of support for some file formats...)
  • Offer better performances than RGSS
  • Pure Ruby, thus entirely customizable and reprogrammable as long as you can script in Ruby
  • Ideally entirely compatible with any versions of RGSS-using RPG Maker, past, present and future, and all custom scripts available on communities
  • Uses a more recent version of Ruby (2.0.0 as of 4/2013 against 1.8.1 for RMXP) and thus benefits of all the improvements made to it - and can be rebuilt with any future versions of Ruby as well to keep up-to-date)

So, more about the progress report itself. I'm currently dealing with the engine's most basic functions, that is loading images and displaying them on-screen. There's nothing very exciting to be seen so far as it essentially involves a lot of work behind the stages. However I decided to make an interesting experiment to compare the performances of OpenRGSS with RPG Maker XP's built-in RGSS. This also served to show that the exact same piece of code can run in both environments with no difference in the output.

The following tests were run on a ASUS EEEPC 1005HA laptop (Intel Atom N280 @ 1.66GHz, 1.00 Go DDR2 @ 271MHz, Mobile Intel 945 Express Chipset Family), which is far from the cutting edge of technology, but I thought that was the best condition to try since it would show how easily both engines could run out of reliability on slower machines. All tests were run in the same conditions, save the running environment, in a 640x480 window, using the exact same script. Mean FPS ratings were recorded and rounded-up each time. Since the original RGSS has a FPS limit of 40, the >40 mention denotes a perfect 40 FPS all along the running process, with no slowdown, while ~40 means that the program oscillated around 40 FPS but slowed down from time to time. Also, scripts were run on OpenRGSS with either a 40 FPS limit, or no limit at all, to see how fast it was able to go. All screenshots were taken from the OpenRGSS application using its built-in screenshot function. :)



Moving sprites

In this test, a number of 32x32 sprites were randomly placed on the screen and moved in any of the four directions, vertically or horizontally, at each frame. We can see a neat improvement in OpenRGSS as compared to RGSS - when the latter's performances start to waver and drop under 40 FPS, it's still running at 92 FPS, and it's still playable, though not smooth, at 4000 sprites, while RGSS is already unbearable at 2000 sprites.

FPS in game engines according to number of sprites
Sprites250500100020004000
RGSS>40~40~17~7~3
OpenRGSS (40 FPS limit)>40>40>40~28~15
OpenRGSS (unrestrained)~155~92~52~28~15




Rotating sprites

In this test, a number of 32x32 sprites were randomly placed on the screen and rotated at various speeds. The rotating process is very costly, hence the loss of performances for both engines compared to the moving sprites condition, however once again OpenRGSS fares pretty well against its counterpart.

FPS in game engines according to number of sprites
Sprites2505001000
RGSS~10~5~3
OpenRGSS~35~20~10




Scaling sprites

In this test, a number of 32x32 sprites were randomly placed on the screen and scaled up and down at various speeds. This time, RGSS wins over OpenRGSS, but this is because OpenRGSS uses the same method for scaling and rotating - thus, its performances are just the same as in the rotating condition.

FPS in game engines according to number of sprites
Sprites2505001000
RGSS~35~35~20
OpenRGSS~35~20~10




Scaling & rotating sprites

A combination of the two previous conditions, in which sprites were rotated and scaled-up/down at the same time. As stated above, since OpenRGSS uses the same method for both transformations, it sticks to the same performances whether just one is applied, or both. RGSS's performances, however, drop dramatically, as the very costly rotation process stacks with the scaling.

FPS in game engines according to number of sprites
Sprites2505001000
RGSS~6~4>2
OpenRGSS~35~20~10



There might still be room for optimization, but so far things are going pretty well, so I'm satisfied with my work. Also, since I'm going quite fast, I think there might be additional progress reports very soon to keep you informed of my advancement with this project. Don't hesitate to let me know what you think. Cheers and stay safe in the meantime.

Apr 14, 2013

News From the Moon

Hey guys,

I know I haven't been around for quite a while. I know there are some posts I still need to reply to, shame on me. Well I have no real excuse, except that I've somewhat lost my commitment to RPG Maker in particular, and the thrill for video game development in general. I think it's temporary and should come back anytime soon; but let's not get ahead of myself - I've not come here to announce anything definitive, just to let you know I'm still alive and I still think of you.

Also, while browsing other people's blogs, I was surprised to see how often they give news, even when they don't have new works to share, and I thought maybe I could do it too. I guess that's how I'm used to have people expect results of me that leads me to believe my readers wouldn't be interested in progress reports. I'm determined to give more news in the future, that is for as long as I'm into game-making at all. Anyways don't hesitate to share your feelings about this issue.

Maybe just one "useful" pieve of information - I've taken note of the many negative reports regarding my Script Manager. I must admit it's more of a developer's tool and I understand that it's not necessarily useful to my next door game-maker. That's why I've decided to change the way I distribute scripts, to make it easier for the casual user to fetch them and get them to work, without getting rid of the Script Manager itself, which I use a lot myself. Of course this requires a lot of re-thinking and re-programming, which I've actually started long ago, but I kinda lost my motivation about it right in the middle. I wish I can complete this update, at least, so that people can benefit of everything I've written so far - but then again, no promise I'm not sure I can keep. I'm merely sharing my state of mind but I'm sure some encouragement could do wonders as it has done in the past.

So here we are for now, and my apologies once again for being away for so long.

Take care.