WOLFCODER'S PROFILE

Oh, return your DPI/scale size to normal, but then under the window theme settings, make the font all big. There should be a way to make the title bar and controls all big by doing this.

Luckily, the end user product game engine itself is completely unaffected by this DPI madness.

Nevermind, I found the issue.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd464659%28v=vs.85%29.aspx

Windows Vista and above, if you increase the DPI setting, a virtual DPI manager fucks with my program without its knowledge and makes everything glitch out. It looks like there might be a way for my program to disable it for itself. This might make the program revert to its original size ignoring your scaling but at least it would stop glitching and you wouldn't have to change your global scale just to run RPG20XX at all.

Beats me, he just talks to me whenever he feels like it.

Some of the windows in the UI are very busy at the current moment.

It's actually pretty barren from what I had in mind.

but I imagined that maybe down the road you would want to streamline it further to improve ease of navigation.

Yes, mostly in the script editor (support of keyboard accelerators, etc.). Once RPG20XX enters BETA, that's really the time to polish everything possible.

If you set up a Patreon or something once the program hits beta I am sure I could throw more than a few extra dollars toward a good cause...

Patreon was designed for people who released videos and things, but I might consider it. It does have a normal donation button and link. The biggest thing I need however are bug fixes. Those are the only things even a single-person-army can't do by themselves.

In the top menu of the editor, some icons are unclear. Why is Import a checkered square, and Database a rounded blue square?

"Database" and "Resource" are somewhat abstract concepts. I'm open to icon designs that convey? these better, though.

with the radio buttons becoming tabs located on top, and enlarging the window so that the edit menu can be integrated into the database menu.

That method makes everything incredibly messy in both code and UI design, although I agree with the feeling. It works the way it does at the moment to make things as simple and bug free as possible, but I have plans for the database editor dialog.

Previews exist for material resources, but not for database entries. An important ability for an author would be to flip through a database list and view all the information about each entry in the preview.

Double-click to edit exists as a shortcut in other dialogs (setting autotiles for a tileset, as an example). It'll be used here later when I can confirm the database editor is solid enough.

The separation between Player and Enemy is getting annoying. It is almost the rule (with few exceptions) that for each enemy Player there is only one matching Enemy entry. I'm considering merging the fields. This would make it so there are only Player with the option for "Is Enemy". If "Is Enemy" is checked, it lets you click a button to edit the enemy properties for AI, drop lists, and the like. This also eliminates the possibility the author forgets to check "Is Enemy" for each player that is being used to define an enemy. I can recycle the Enemy data type into something else more useful.

Probably an entire data type dedicated to weapon handling.

Authors will also need the ability to EDIT another database entry mentioned by the current one they are editing. Say the author is giving a Player default equipment. They need to both PREVIEW each equipment from the selection dialog, and maybe they will want to EDIT it real quick without having to close out of the Player editor. Caution has to be exercised that the author doesn't accidentally create specific chains of editor dialog boxes that may cause catastrophic damage to the database.

On top of all this, don't forget I gave you inheritance. This makes every field of each child database entry you didn't edit match the parent. If you later edit the parent, all children are also updated. Use this well to shave 80% of your time spent editing database items.


I have a lot of plans to polish, accelerate and make more robust the editor once BETA is reached. Right now its very explicit in everything you do. It has a lot of accelerators and automata already, but those are just to make testing less tedious.

Holy shit you've been unbanned!

And I already gathered that after looking into it further. I've begun converting REFMAP tilesets, but there's all this extra room because RPG20XX gives you 2 additional autotiles per tileset (oceanic tiles converted into animated autotiles take up a few spaces), 5 additional animated tiles per tileset, and a lot of single tiles. I'll have to figure out how to merge similar tilesets.

I still won't bundle these with the engine, but I'll have an archive download for you to import out of. Because it will be annoying to manually set full body sprites (since all the existing character sprites are normal single image sprites), I'll add a manifest directive inside the archive that instructs RPG20XX to automatically add imported characters to your list of composite parts as full bodies (if an entry for it doesn't already exist).