What's up, RMers?

[kyonides]

What I don't like about the official RM forums is that there are times when it becomes like a tiny version of StackOverflow. If you don't know what the latter is like, I can tell you that there you can ask technical questions at will... at the risk of getting excessively toxic replies from so called knowledgeable people.

They allow the question and its replies to be qualified and even get very low scores. Some users will simply tell you that you made no effort and never address your issue at all. Heck, I wonder who else demonstrated that they love to be lazy as well.

So what happened over the former place?

Well, there was a guy that can get under your skin every so often but this time he hasn't been that bothersome. Yet, they keep complaining about him not understanding the Compress Game Data feature. We're talking here about a forumer that used to fiddle with the PS version of the Maker. The rest of the repliers kept telling us that it's just too obvious or he's disregarding the replies that handle it. I felt compelled to explain it to them that for people not used to the series, the PC ports at least, it might actually sound confusing because literally what it means is "let's save some HD space now" instead of something as crystal clear as Deployment or even a mix of both labels.

I seriously wish the official forums don't become another StackOverHell site any time soon.

[DerVVulfman]

I've been wondering about the Compress Game Data feature myself, particularly the "Create Encrypted Project" system... that is how to actually implement that so I could make an rgsaad file from my data without relying upon the editor itself.

BUT... Widgets news!



My work on a scrolling listbox will become the replacement for my initial listbox widget.  It now 'auto-detects' when it needs to scroll or NOT to scroll.  With a noted exception that the window height MUST be at least a certain size lest the scrollbar won't fit.

The listbox can have a decorative single-pixelthick border around the entire widget and of a chosen color, or let it remain at whatever default setting is in use.  And it has all the font, color, and background image capabilities of the original.

Scrolling does work.  But the tab indicator which you would normally be able to move up and down doesn't yet calibrate when you resize the window or add/remove content.  I would figure that would be the next update, and I assume should be the last insofar as the basic listbox widget itself is concerned.

Well, that and migrating the buttons to the widget 'drawn objects' class (giving em actual arrows)...

[DerVVulfman]

  I have a dedicated class for all graphics. And the buttons for the new scrolling listbox does not use what I used in the previous scrollbar.  So I either migrate these new buttons to that class, or see how to adapt the old ones to work.

DONE!    The only arrow buttons that don't share the same code are the resizable buttons for the numberbox widget as they stretch... not fixed to a 16x16 image.  And bonus, you can use the predefined render option or import a set of 16x16 arrows of your own.  Only the TAB indicator and numberbox arrows remain in-system rendered as they must scale to fit the widget/scrollbars.

  And I need to ensure that clicking on the scrollbar doesn't interfere with any currently highlighted/selected data.

Oh, that is SO done.

And when I  (1) change the size of the font, (2) add/remove items from the list or (3) change the height of the list, the scroll bar's increment system needs to be recalculated.

Scrolling does work.  But the tab indicator which you would normally be able to move up and down doesn't yet calibrate when you resize the window or add/remove content.  I would figure that would be the next update, and I assume should be the last insofar as the basic listbox widget itself is concerned.

That is now COMPLETELY fixed.  Scrolling the list and dragging the tab indicator up and down is smooth.

Of course, the number of items listed and the size of the initial window must be accounted for.
   Imagine having a list to 200 items but a window that only shows two at a time!  That'd be a mess.

My work on a scrolling listbox will become the replacement for my initial listbox widget.  It now 'auto-detects' when it needs to scroll or NOT to scroll.  With a noted exception that the window height MUST be at least a certain size lest the scrollbar won't fit.

True that!  And now, my scrolling listbox IS the replacement.   Operating perfectly, I replaced all my initial Listbox commands in the demo with the new one.

  But with what I have accomplished, replacing the combobox (or dropdown list box) may be readily be made in much the same fashion.

And that...     will be NEXT!

[kyonides]

I think I'm out of scripting ideas once again.  This situation is unnerving but  what can I do?

[DerVVulfman]

HiddenChest Win Editions?  

The ComboBox (or Dropdown scrolling list box) has basically been made!  WOOT!



Clicking the bar works!  Clicking the scroll buttons and dragging the tab works!  Clicking a choice works!  Whatever item is selected as the index position displays within the bar just as it should!

It is a ComboBox!

But... for comparison purposes......


The above screenshot is a window-based compiler where you can actively draw widgets on a window (designated a 'form').  And with this, I performed some tests.

If you have a ComboBox open and click outside the widget, the opened ComboBox automatically closes... It thinks you're ignoring it and basically says "Harumph!!!"  As such, all 'other' objects such as checkboxes, buttons, listboxes... they cannot function while the ComboBox is open.

This is a problem which I must tackle. As it stands, I can click and activate the other objects in the windows/forms while my ComboBoxes are open.  In the first window, I do have a checkbox visible... which unfortunately does register its 'click', even if I click an area covered up BY the ComboBox's list.  That's an OOF indeed. And it is something I need to rectify.

Meanwhile, there is another LISTBOX of sorts which I need to fix up... a Checkbox list which can be seen in the second window.  Unlike the traditional ListBox, you can click multiple items in the list for a result while a normal list box opts for just one.

[DerVVulfman]

WOOHOO!!!!


Collapsable ComboBox aka Dropdown scrolling lists work BEAUTIFULLY!!!!

I can click the contents and select a new item!  I can use the scrollbar, both the arrow buttons and the tab indicator, to go through massive lists!  Clicking the list right atop another widget does NOT trigger the other widget, whether the other widget is another combobox or not! And clicking outside an expanded window CLOSES the window!

When clicking in the window, it checks for areas of effect.  It's fun checking the area where the scrolling lists exist, the 'area' always based on its size when expanded/opened.  The fun part was to make sure the un-collapsed comboboxes reacted properly with the expanded ones.  Fun Fun Fun.

But WOOT!  ComboBoxes are a THING!!!!

[DerVVulfman]

Anyone with a native version of RPGMaker that uses Ruby wanna try some code?
* by native, I mean official version that supports the Win32API
* by Ruby, I mean XP, VX or VXAce

Paste this above 'main' as usual, and run it.

Code:

#==============================================================================
# ** Registry
#------------------------------------------------------------------------------
#  This module handles the registry by using Windows 32 API calls.
#==============================================================================

module Registry
  module_function
  # The Master HKeys in the Windows Registry
  HKEYS             = { 'HKEY_CLASSES_ROOT'   => 0x80000000,
                        'HKEY_CURRENT_USER'   => 0x80000001,
                        'HKEY_LOCAL_MACHINE'  => 0x80000002,
                        'HKEY_USERS'          => 0x80000003,
                        'HKEY_CURRENT_CONFIG' => 0x80000005   }
  HEX_TRUE          = 0x00000001
  HEX_FALSE         = 0x00000000
  RegOpenKeyExA     = Win32API.new('advapi32','RegOpenKeyExA',   'LPLLP', 'L')
  RegQueryValueExA  = Win32API.new('advapi32','RegQueryValueExA','LPLPPP','L')
  RegCloseKey       = Win32API.new('advapi32','RegCloseKey',     'L',     'L')
  #-------------------------------------------------------------------------
  # * Read Registry Data Value
  #    key   : The master HKey and pathway to the list of entries
  #    entry : The entry where the data is stored
  #-------------------------------------------------------------------------
  def read_data(key, entry)
    key.sub!(/(.*?)\\/, '')
    return nil if HKEYS[$1].nil?
    hkey = HKEYS[$1]
    opened, type, size = [0].pack('V'), [0].pack('V'), [0].pack('V')
    RegOpenKeyExA.call(hkey, key, 0, 131097, opened)
    opened = (opened + [0].pack('V')).unpack('V')[0]
    RegQueryValueExA.call(opened, entry, 0, type, 0, size)
    data = ' ' * (size + [0].pack('V')).unpack('V')[0]
    RegQueryValueExA.call(opened, entry, 0, type, data, size)
    RegCloseKey.call(opened)
    data = data[0, (size + [0].pack('V')).unpack('V')[0]]
    type = (type += [0].pack('V')).unpack('V')[0]
    case type
    when 1;   data.chop
    when 2;   data.chop.gsub(/%([^%]+)%/) { ENV[$1] || $& }
    when 3;   data
    when 4;   (data += [0].pack('V')).unpack('V')[0]
    when 5;   data.unpack('N')[0]
    when 7;   data.split(/\0/)
    when 11;  (data.unpack('VV')[1] << 32) | data[0]
    else;     nil
    end
  end
end


#==============================================================================
# ** Drive Detector
#------------------------------------------------------------------------------
#  This module merely cycles through all available letters in the alphabet
#  to see if you have any matching drives on the PC, and then determines if
#  they are hard drives, CDs, or whatnot.
#==============================================================================

module Drive_Detector
  #--------------------------------------------------------------------------
  # * Methods/Functions Executable From Outside Call
  #--------------------------------------------------------------------------
  module_function  
  #--------------------------------------------------------------------------
  # * Object Execution
  #--------------------------------------------------------------------------
  def execute
    #
    #
    # Cycle through all letters and put them in the Drive List array
    drive_list = []
    for i in 65..90
      drive_letter = i.chr + ":"
      next unless FileTest.directory?(drive_letter)
      drive_list.push(drive_letter)
    end  
    #
    # Now, cycle through and test all gathered drives for the PC
    drive_list.each {|drive_letter| test_drive(drive_letter) }
    #
    #
  end
  #--------------------------------------------------------------------------
  # * Test each individual drive letter and find its type
  #     drive_letter : drive_letter
  #--------------------------------------------------------------------------
  def test_drive(drive_letter)
    #
    #
    # This is the path to the mounted devices within the registry
    # It holds the signatures of all the drives (HDD/SDD/CD/DVD).
    key   = 'HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices'
    #
    # Define from which Dos Device Drive we are getting data
    # Ex: 'DosDevices\C:'
    entry = '\DosDevices\@'.sub(/[@]/, drive_letter)
    #
    # Obtain the data from the registry with the 'read_data' method
    # It is accessing the registry's mounted devices path for the
    # specific entry for the defined drive.
    drive_data   = Registry.read_data(key, entry)
    #
    # We really just need the first character from the data and have
    # it converted into a Hexadecimal character. For testing sake,
    # we are having the test string itself UpperCase.
    first_char    = drive_data[0]
    hex_sig_test  = sprintf("%.x", first_char).upcase
    #
    # Now... just test the signature
    case hex_sig_test
    when '5C'
      p "Drive " + drive_letter + " is an Optical Drive (CD/DVD/etc)"
    when '5F'
      p "Drive " + drive_letter + " is a Flash drive or related"
    else
      p "Drive " + drive_letter + " is any typical hard drive"
    end
    #
    #
  end
end


# This just runs the module
Drive_Detector.execute

When you execute it, you should receive a series of 'pop-up' notices, one for each drive on your PC. And it should tell you what 'kind' of drive you have for each, whether it is a HDD/SSD, an Optical (CD/DVD), or a flash. The code only suggests one of these three types (floppies not withstanding... assumed HDs). But it should work for original RPGMaker systems that have always supported the Win32API.

... not counting any 'virtual machine for Linux or MacOS'...

PS: Funny... Someone asked at StackOverflow if it were possible to get what kind of drives were on a PC with Ruby without installing/requiring the Win32OLE, and responses said ... Nope!

[kyonides]

Even if you don't like these results, Wine on Linux did find the emulated Windows drives.
Got no floppy drive so that remains a real mystery.

[DerVVulfman]

On the contrary... it's great news. I didn't expect it would acquire the drive signatures with an emulator. But it appears that it does! Oh, and as towards floppy, I had heard that floppies use the same initial signature as hard drives... weird as that sounds.

[KasperKalamity]

i gotta start over. there's no xp resources anymore, and the character maker i have doesn't export properly for some reason.

should i do MV or MZ? I want to be able to send this out on mobile once it's done.