Crash with no reason with no hints whats wrong VX Ace

[ddejan90]

Hello. I'm using Galvs Storage script and it works perfect, except, it don't work...
Game crashes randomly without any notes what's gone wrong, it will just freez, show window "check online for solution" and "close program". It happens randomly, don't mater how many you add, but, usually there are above 900 when it starts crashing.

Here is the link for my STEAM game where a person found the issue, I've tried everything I know to fix it, but, I guess it's too little.


I would really appreciate your help.

 

[Trihan]

Does it only happen with the storage script added?

 

[ddejan90]

Does it only happen with the storage script added?

Yeah, I guess so. As far I can see, only when you add items in storage it happens randomly if huge amounts are added. I don't know why and what it triggers. I had a friend test it out, happened to him once around 900 too. He has items 410x99 of each, armors 175x99, weapons 232x99 each, so it's not happening when it's on him (inventory) just in storage.

 

[Trihan]

Have you personally replicated the issue or is it only happening to the guy on Steam who reported it and your friend?

 

[ddejan90]

Have you personally replicated the issue or is it only happening to the guy on Steam who reported it and your friend?

I tried it once really fast, it crashed around 900 too. I duno what is happening

 

[TheoAllen]

It may or may not be because of the script you linked. It can be any script in your game.
I skimmed through Galv's code, and I don't see anything potentially game-breaking.

You can try to debug your game by using this method. Go back and forth around your menu and battle scene after you installed the script. There might be a memory leak somewhere.

 

[Dev_With_Coffee]

Hello!

Edited:

Sorry, what I said before was wrong.
The problem is not the quantity per item but the quantity of item types, regardless of category, I created 10 more equipment items:


I used variable 7 to limit, and I was testing one by one, it worked normally up to 47 types of equipment, when I increased it to 48 the screen froze in the menu:


I did the same test with minimal programs open on my computer, closed browsers that eat RAM and got the same result.
As the problem happens as soon as it opens, it must be in reading.

That's why the monetary system doesn't freeze even with a very large amount.

I believe that only Galv will be able to know what happened, for some time I believed it was a limitation of RGSS3 itself, but now I'm not sure anymore.

The last test I can do is use the RMVXA's own ruby console to find out when it stops. It could be right at the beginning of "Window_StoreList_Bank".

(I'm not a programmer, so I'm sorry if I'm saying something wrong)

Good luck

 

[KK20]

Problem to me looks like when Window_BankItems is initialized and calls draw_stored. It's not initially given an item (@item = nil) but attempts to draw the "stored_amount" anyways. $game_party.multi_storage(nil) returns the entire hash, and then the window's draw_text attempts to stringify the entire hash, which can eventually hit some arbitrary limit and crash.

So how about we don't make this needless draw...

class Window_BankItems < Window_Base
  def initialize(x, y, width, height)
    super(x, y, width, height)
    @item = nil
    @page_index = 0
    refresh
  end
  def refresh
    contents.clear
    return unless @item #<=============== add this line here
    draw_possession(4, 0)
    draw_stored(4, line_height)
    draw_equip_info(4, line_height * 2) if @item.is_a?(RPG::EquipItem)
  end
#.... rest of the class methods redacted for brevity

 

[ddejan90]

Thanks all for feedback.

I will try KK20's suggestion later on when I'm more awake. Will post update

 

[Andar]

regardless of the other attempts, it might help if you install a backtracer script to get better console output on the crash.
Follow the link in my signature about "How to use a script" to the bughunting section, I linked and explained a backtracer there. Unfortunately past forum updates messed up the formatting on that tutorial, but it should still be readable in that section.

 

[ddejan90]

regardless of the other attempts, it might help if you install a backtracer script to get better console output on the crash.
Follow the link in my signature about "How to use a script" to the bughunting section, I linked and explained a backtracer there. Unfortunately past forum updates messed up the formatting on that tutorial, but it should still be readable in that section.

Thanks for info, I will be trying that next if the above one didn't work.

Also, update:

I've used KK20 tweek and tested it out. I've placed 120x99 items, armors and weapons combined and some of 150+ just in case, tested it out for 10 min nothing crashed. I've asked the person on steam to test it out too if he can and sent him link to the scripts to download and paste. Will post update if he tried it. Again, thanks all for helping me.

 

[ddejan90]

Update:
So, I placed return unless @ItEm as KK20 said and it didn't crash once since then. The guy also said he didn't got a single crash also. So, I'm hoping it will stay that way. If anything changes I will be back. Thanks all

 

[ddejan90]

Update:
So, I placed return unless @ItEm as KK20 said and it didn't crash once since then. The guy also said he didn't got a single crash also. So, I'm hoping it will stay that way. If anything changes I will be back. Thanks all

 

[Shaz]

@ddejan90 , please avoid double posting, as it is against the forum rules. You can use the "Edit" function on your posts to add additional information you've forgotten or respond to multiple people. You can review our forum rules here. Thank you.

 

[Dev_With_Coffee]

@KK20
Working perfectly, include 100 types of equipment and 100 types of armor:

 

[KK20]

regardless of the other attempts, it might help if you install a backtracer script to get better console output on the crash.

Yes, a backtrace script is always a good idea, but it wouldn't be of much use for this case. The error is a hard crash on Bitmap#draw_text, as in the EXE immediately closes with no error message.

Perhaps someone knows more about the intricacies with how that method works. It's definitely some kind of overflow that the RGSS3 library can't handle. You can easily test it yourself with some kind of script like this above Main.

s = Sprite.new
b = Bitmap.new(216, 272)
b.fill_rect(0,0,216,272,Color.new(230,50,50))
s.bitmap = b
r = Rect.new(4,24,208,24)

loop do
  Graphics.update
  Input.update
  s.update
  
  if Input.trigger?(:C)
    b.draw_text(r, 'a' * 960)
  end
end

So with this example, if I change the 960 to 961, my game crashes. Alternatively, changing the character to 'A' will also crash.

Meanwhile, Mithran's Text Cache avoids this issue entirely.

 

[gstv87]

from the help files:

draw_text(rect, str[, align])
Draws the string str in the bitmap box (x, y, width, height) or rect (Rect).
If str is not a character string object, it will be converted to a character string using the to_s method before processing is performed.
If the text length exceeds the box's width, the text width will automatically be reduced by up to 60 percent.
Horizontal text is left-aligned by default. Set align to 1 to center the text and to 2 to right-align it. Vertical text is always centered.
As this process is time-consuming, redrawing the text with every frame is not recommended.

from MV's files:

Bitmap.prototype.drawText = function(text, x, y, maxWidth, lineHeight, align) {
// Note: Firefox has a bug with textBaseline: Bug 737852
// So we use 'alphabetic' here.
if (text !== undefined) {
var tx = x;
var ty = y + lineHeight - (lineHeight - this.fontSize * 0.7) / 2;
var context = this._context;
var alpha = context.globalAlpha;
maxWidth = maxWidth || 0xffffffff;
if (align === 'center') {
tx += maxWidth / 2;
}
if (align === 'right') {
tx += maxWidth;
}
context.save();
context.font = this._makeFontNameText();
context.textAlign = align;
context.textBaseline = 'alphabetic';
context.globalAlpha = 1;
this._drawTextOutline(text, tx, ty, maxWidth);
context.globalAlpha = alpha;
this._drawTextBody(text, tx, ty, maxWidth);
context.restore();
this._setDirty();
}
};

if ['a' * 960] doesn't crash, but ['a' * 961] does, then the error is somewhere down the line of that comparison taking place.
there's no way of knowing what Ace is doing there, but MV retains much of the original code of Ace, just ported to JS.
if this is also what Ace is doing, then maxWidth is not being *compared*, it's *operated upon*
not the same thing, and it could lead to an error depending on the situation.

maxWidth = maxWidth || 0xffffffff; <- if 0
if (align === 'center') {
tx += maxWidth / 2; <- 0
}
if (align === 'right') {
tx += maxWidth;
}
...
this._drawTextOutline(text, 0, ty, 0);
...
this._drawTextBody(text, 0, ty, 0);

0 down the line.

IDK, just my attempt at programming CSI here.