MAKOINFUSED'S PROFILE

I see... then I guess I found another bug :p. I don't know if I should confine my bug reports to the release blogs; but this relevant to the conversation.

Bug 1:
I tried to set the parent of a player, seemingly this worked fine. However, when I edited some stuff in the child and clicked "OK" the program hangs (no crash occurs). I tested all of the other database pages and they all work when parenting, the problem is specific to the player tab.

Bug 2:
When setting up a parent that has a higher id than the child (ie: parent is element 7, while child is id 6) and then changing the maximum to remove the parent is problematic. At first it will probably behave as intended, informing the user that the database value cannot be retrieved, but if you simply ignore the problem by clicking away, and then back again-- it will crash. I would imagine that resetting the parent to "empty" would fix this issue.

Suggestions
There is some "ease of use" stuff that I would like to see. The first being a "reset to parent" button, removing any changes on the child node. Another one is "reset to default", which would set each field to it's default value, essentially removing all changes.

Nice, looks like you got everything then!

One small note though: when using the editor the workflow is interrupted at certain points due to the "OK" and "Cancel" buttons being in reverse order. For example: in the derived stat edit box it's: [Cancel}, while in the script editor it's . Not a big deal, but flipping those will make editing much more efficient.

Keep up the great work!

Yeah, it'll complain about maxhp and maxmp missing and the like since your old project doesn't have any derived defined.

I figured that, so I tried to fix it up as best as I could.

I can't get that to happen. Did you type something funky in the labels and force a line break?

Noooooooooo.

You probably ran out of memory.

Oh hmmm, maybe I wasn't specific enough. I meant when I opened the main menu in the game (during testplay) not the actual dialog box in the editor. The editor handles the large numbers just fine...well sort of. The numbers seemed to overflow because although the script editor shows 1000000000, when I attempt to edit the value it's a negative number.

I also found one other bug: hit the testplay button, then try to go up on the title screen: you'll get the awesome "Arraylist out of bounds" error.

It will be easier to use, for another. Since it will require no text-based scripting language, but should potentially be equally (or similarly) as powerful. Also it would be easier to port, since it's open source, to other systems.

The list goes on but that's some of the main highlights.

If you need something more specific or detailed beyond the page triggers, add if statements at the beginning of the page that Return if conditions are not met. For really complex conditions, you can write a common event that modifies one variable or better yet, with the new quest system that will be added.

It will be most easy to have events page trigger themselves upon quest stages (with an added bonus of the event page reminding you what quest and quest stage its supposed to be for).

I get that, variables are pretty versatile. However, I was just thinking in terms of making it more friendly to use (and readable). To me that's one thing that made 2k3 pretty awesome, it was the ease of use, this concept would expand upon that. Having to assign a variable just for the purpose of keeping track of other switches and variables is a hassle; not to mention that it makes it harder to follow the chain of events. Using if statements inside of the events actions, however, wouldn't prevent the event from displaying on screen.

The quest system sounds intriguing though, I look forward to seeing how that will work!

The lower layer is actually an automatic two layer (see the terrain setting in the tileset editor). It was a deliberate decision to make it still feel like only two layers yet to actually have three. This was done to make the editor much simpler to use and more RPG Maker 2003 like. One of the (many) reasons I never moved to XP was too many layers, but the autotile terrains going on top of stuff was something I thought was really needed in 2003.

Oh, you mean since the autotiles can have a transparent background? Yeah, that definitely does add some versatility. Simplicity is definitely a great thing, I'll keep that in mind with any future suggestions I have.

Thanks for looking. Try to find things that crash the editor and could potentially ruin projects. The worst thing RPG20XX could do is get something like a map-tree-break.. I can remind people to back their stuff up all the time but it would be nice if the editor has a very high stability rate.

You're most welcome. I'll be on guard for any major problems. High stability would be nice, the map-tree-break has happened to me before. One way to combat that (in addition to avoiding bugs) is to have an auto-backup option.

Here is a report for you:

Minor Issues:
1. I created an event and assigned it a "Full Sprite" graphic. After going back in to "Update" it, the "Full Sprite" radio button was selected; however, the "Parts" and "Composite" list box weren't behaving as expected. I had to click on the "Full Sprite" radio button for it update the dialog box.

2. Attempting to change the maximum of the "Tileset" tab in the database from 1 to certain numbers (2/3) just gives me a "That new maximum limit is too large or small, it will be adjusted". However, nothing is adjusted and the operation is just canceled.

Major Issues:

1. If I create a new tileset and leave it blank, then apply it to the map I get a "could not draw GDI" error. Which is fine, however, trying to change the tileset back to one that works, will crash the editor.

That's it for now!