Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - KK20

Pages: [1] 2 3 ... 153
General Discussion / Re: RPi JavaFx game development framework
« on: June 23, 2018, 08:19:03 AM »
No one here uses Java (we all hate it)

Update to 2.33
Includes update to XPA_Window (v1.31) which addresses assigning them to a Viewport, so they should now behave exactly like XP Windows

It's not fully tested yet, so keeping 2.32 up for now.

Any instance you see this in a Window class
Code: [Select]
cursor_rect.set(x, y, width, height)
You will need to change it's associated parameters in this manner:
  • Add GameGuy::X_OFFSET and GameGuy::Y_OFFSET to the X and Y coordinates respectively.
  • Change the width and height values to 32. No exceptions.
As an example, in RO Job/Skill, there's only one instance of this:
Code: [Select]
self.cursor_rect.set(x, (@index + 1) * 32, @cursor_width, 32)So you would change it to
Code: [Select]
self.cursor_rect.set(x + GameGuy::X_OFFSET, (@index + 1) * 32 + GameGuy::Y_OFFSET, 32, 32)

Script Troubleshooting / Re: Borders and Dumb Dumb Troubles
« on: May 30, 2018, 10:18:18 AM »
It'd be easier to create a new script to handle that instead. But icons behind the battler? Not sure I agree with UI graphics being blocked by non-UI graphics.

Script Troubleshooting / Re: Borders and Dumb Dumb Troubles
« on: May 30, 2018, 03:46:01 AM »
Yes, if you are sub-classing Window_Base (which all the default window scripts--and 99% of custom scripts--does), that bit of code in the update method is what ensures there's only one windowskin being used. As soon as $game_system.windowskin_name changes, all the windows will automatically update to use the new graphic.

Script Troubleshooting / Re: Borders and Dumb Dumb Troubles
« on: May 30, 2018, 12:23:00 AM »
Yeah the problem wasn't shown in the script you posted. You made edits to the default Scene_Battle scripts, e.g.
Code: [Select]
    # Refresh status window
You're missing your @actor3_window variable in all of these instances.

Script Troubleshooting / Re: Borders and Dumb Dumb Troubles
« on: May 29, 2018, 08:46:29 PM »
In Window_Base#update, you just comment out these lines
Code: [Select]
    # Reset if windowskin was changed
    if $game_system.windowskin_name != @windowskin_name
      @windowskin_name = $game_system.windowskin_name
      self.windowskin = RPG::Cache.windowskin(@windowskin_name)
And to change a window's windowskin, it's simply
Code: [Select]
@my_window.windowskin = RPG::Cache.windowskin('graphic_filename')
Just know that you will have to manually handle dynamic changes to the windowskin (e.g. player can go to Options and change the windowskin graphic), if you have anything like that in-game.

For the actor updates, I don't see anything in the code. In fact, it doesn't look like any of your actors should have their values updated at all, not just the 3rd actor.

Script Troubleshooting / Re: Border Refuses to vanish
« on: May 29, 2018, 06:09:09 PM »
Not even VXA has a method for changing window border opacity, so you'll need to edit a custom windows script to allow it.

An alternative would be to edit the default scripts to allow custom windowskins for each window. Then make a copy of your windowskin graphic without the borders.

Script Troubleshooting / Re: [XP]Animated Picture
« on: May 29, 2018, 05:59:26 PM »
Are you using game variables 1 and 2 for anything?

I can tell that you're learning how to script. Good! But I will just tell you that what you're doing isn't super straightforward.

For starters, I'm going to need to see how you're calling your item window on the map. Did you modify Scene_Map to do this?

The check for button B is also doing nothing. Most likely you're going to want to put that in your map scene. Where it is right now, the only time it gets ran is when your game is opened and everything is loading before the title screen appears.
Code: [Select]
# an example...don't put this in your game
def update
    if Input.trigger?(Input::B)
  # other things that update in the scene go here...
Not sure what your plan is with the @item_window attribute either.

We're not really known for VXA support, but I was able to figure what was wrong. Replace your script with this one:
(click to show/hide)
Problem was his use of $game_party.members. When in battle, this returns up to the first 4 actors only. Originally in the script, he did this
Code: [Select]
      if $data_system.opt_extra_exp
         @result_member_max = $game_party.members.size
         @result_member_max = $game_party.battle_members.size
Essentially, @result_member_max would always return up to 4 regardless of "Reserve Party Members' EXP" setting. Changing it to all_members fixes this.
Other change was in the loop where actor EXP was awarded:
Code: [Select]
      for battler_id in @result_member_id..@result_member_max
          actor_result = $game_party.members[@result_member_id]
          actor_result.gain_exp($game_troop.exp_total) rescue nil
Again, $game_party.members would only return the first 4 actors, so simply changing it to all_members here resolves it.

RMXP Script Database / Re: [XP] Blizz ABS Active Action Info
« on: May 21, 2018, 02:11:35 AM »
Seems like, at the time, Drago forgot Arrays are 0-indexed. How this went unnoticed for years is beyond me.
For the sake of keeping the fix easy, find this around line 38 and make sure it looks like this
Code: [Select]
def mpit() @mpit ||= [nil, 0, 0, 1, 1, 0, 0] end
@Drago: Problem lines are
Code: [Select]
# Scene_Map#main
@mpit.visible, @mpit.contents_opacity = true, $game_system.mpit[6]

# Scene_Map#update
@mpit.contents_opacity, @mpit.visible= $game_system.mpit[6], true
$game_system.mpit[6] -= 3
The mpit variable was only an array of 6 elements, hence mpit[6] returned nil.

RMXP Script Database / Re: [XP] Blizz-ABS
« on: May 15, 2018, 07:59:14 PM »
Yeah, explore with events first. You don't want to cheese a HUD script to affect the environment.
Besides, I think the alternative would be a custom tilemap script that allows you to alter individual tiles dynamically.

Welcome! / Re: New Kid In Front Of The Computer
« on: May 15, 2018, 04:05:09 AM »
sup dude

Weird that you think that way with FES. I found it harder to do the easy things in FES than in XP or even 2k3. Something like a push puzzle takes a ton of events when PC versions requires one event and (optionally) a parallel process.

Then again, I'm a scripter so I can basically do whatever I want in XP and not be limited to hard restrictions.  ¯\_(ツ)_/¯

RMXP Script Database / Re: [XP] Blizz-ABS
« on: May 15, 2018, 03:59:42 AM »
1. Considering that the help file states to use an "animated spriteset", I'd assume that would be a character graphic. So make your gold graphic as if it were a character (4x4 spritesheet)
2. Blizzard's scripts were designed to be compatible with each other. I find it hard to believe that his mouse script doesn't work.
3. I know in Tons Of Add-ons there's a script that will display an arrow over the player when hidden behind tiles, so it could be possible to extend that script to apply for all events. I think there was a script that made higher priority tiles transparent when the player moved behind them, but don't know what it was called. You could try Drago's script to draw the name of events. It looks like the name will be displayed above tiles.

Script Troubleshooting / Re: [RMMV] Problem with language on mobile
« on: April 19, 2018, 08:24:00 PM »
Did you contact the author? I feel they would be more helpful than any of us (largely because everyone that's still active here doesn't do MV script support).

Thanks for the QA, I must have been in a drunken stupor last night.
The DLL is fine by the way.

Reverted to 2.31 until I fix it.
EDIT: 2.32 is back up

Quick update to 2.32
  • Forgot to update XPA Tilemap's DLL from version 0.4, whoops :P (thanks tasuku13 for reporting this)
  • Input module's constants are now integers (as they are in XP) instead of symbols (as they are in VXA). You can still use XP's or VXA's way of handling input, like so
Code: [Select]
Input.trigger?(Input::C) # XP
Input.trigger?(:C)       # VXA

It does return something now if you try to access the window's viewport, yes. But the way the viewport is used is not how XP does it. I know that the way you implemented it was more so for convenience in positioning all the window's elements and not having to move all of them when--as an example--Window#x changes (as the top left corner of the window will always be at [0,0]; just only need to move the viewport).

IOW, your rewrite always creates a viewport the same size as the window. As such, the window is always in full view. You also cannot initialize the window to another viewport.
XP doesn't create a viewport unless explicitly initialized with one. And it behaves like any Sprite would (contents being clipped out if not contained fully in the viewport, etc.).

But default XP scripts never initializes any of the window sub-classes with a viewport. Hence, no one should be using the Window's viewport anyways. Only example I have seen so far is that online script whitespirits mentioned, where the author was drawing item description sprites to the Item Window's viewport, which were being clipped using XPA_Window (basically, there was no reason for the author to be initializing these sprites to the window's viewport).

Hidden classes are exactly as they read: hidden. You don't have access to the underlying code-base for these classes. Any rewrites to these classes are the scripter's best interpretation of how the script works (usually) in pure Ruby. The Tilemap class, for example, is most likely largely written in C code since the amount of drawing it does is performance heavy.

btw Selwyn's Window class rewrite is not a perfect copy of Window. Blizzard's is nearly an exact replica where Viewports are not necessarily used correctly, but no one should be accessing a Window's viewport to begin with. Try using this windowskin and compare the two scripts

You should see the difference at the title screen, namely the cursor.

That script you linked from the ARC dev thread just grabs a list of the classes' methods and variables. Again, there's no actual source code because it's hidden. This was used mainly to get an idea of what they needed to implement their own version of the hidden classes.

For getting the fonts, it probably just uses the Windows' environment variables. For example, in Windows Explorer, typing %windir%\Fonts will bring you to the fonts folder. If the font isn't found, then RMXP just doesn't draw anything (I mean, there's nothing wrong with that). There isn't a way to manipulate the underlying code to look elsewhere for font files, so you have to use a script to get that done.

Pages: [1] 2 3 ... 153