Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Jengamon

58
Posts
2
Topics
14
Followers
32
Following
A member registered May 18, 2015 · View creator page →

Creator of

Recent community posts

If I remember, how palette shifted colors are figured out is using 255/(width - 1) as the number of valid greyscale values for each shifted color (it doesn't shift the first color, which is always mapped to 0). That would give us 255/15 = 17. This bug would happen because  FF is hitting the max value and wraps around, and #111111, which is decimal 17 in grayscale, is still with the bound [1, 18] for the first mapped color. 

To solve, I would use greys in the middle of the target, so like #090909 and #F7F7F7 instead of #111111 and #FFFFFF respectively, if my logic is correct. (tbh it's been years since I wrote/looked at the code)

(5 edits)

Video of it happening:

https://jengamon.neocities.org/altitude_click.html <- EDIT: Video link that actually should work (EDIT now with video embedded on page)

Input that triggered it (in Bitwig 5b3):




Ok, found it in the patch notes:

  • The voices control on the top bar now flashes when a voice is stolen.

But if I'm in mono legato, why is it stealing voices for adjacent notes?

Right now, I'm in the process of rewriting this plugin for MZ, so it'll work very differently, but I'll take this usecase into consideration!

Put all the layers under one array, same with configurations. The script only supports 1 top level layers key and configuration key

Can you open the console, and get me a look at the output?

Oh, true. Didn't think of that. Will do in hopefully a week.

Thanks for asking. The original project this is based off of is licensed under MIT, so I'll license it under MIT too.

You specify an index where to the left of it, all colors are static iirc. I can't remember the name of the keys off the top of my head, so I'll pull up the source and document it once I'm done being buried in work.

Can I see your plugins list?

Ok. Will do~

You'd add the configuration to the configuration file, then you'd use either a script call, or plugin command and call 'setConfiguration'

as a script call (for a theoretical configuration named "cruise"):

JM_EBB.setConfiguration("cruise")

as a plugin command:

EarthboundBackgrounds setConfiguration cruise

I should have been clearer but I generally use <> in the documentation as a placeholder, the literal syntax looks more like:

EarthboundBackgrounds setConfiguration myConfigName

or:

JM_EBB.setConfiguration("myConfigName")

depending on whether it is a plugin command or a script call, respectively.

Creating a configuration is much trickier than using one, where the README describes exactly what goes where and the necessary formats to creating a background. Creating a guide would be wonderful and I might eventually do it, but it's pretty low on my priorities because of RL things.

(2 edits)

Yeah the backgrounds that come with the plugin in a separate zip are all ripped from the EB ROM afaik, so try not to use those if publishing.

Feel free to keep me in the loop of any game you develop, whether free or commercial.

Try this build: https://www.dropbox.com/s/06iaa12eqvo3odi/dist_20210303.zip?dl=0

updateZCoordinates now only calls the line this._battleField.children.sort(this.battleFieldDepthCompare); without the battleBack stuff, so this might work.

Do you know where 

Spriteset_Battle.prototype.battleFieldDepthCompare

is called in the other plugin? Yeah, my plugin specifically doesn't like being included before Battle Core because of the whole updateZCoordinates thing.

Sidenote: The reason the plugin overwrites 

Spriteset_Battle.prototype.updateZCoordinates

is something about compatibility with Yanfly Battle Core. I might experiment later to see what exactly is going on, but it was replaced by a no-op...maybe it was messing with _back*Sprite which this plugin coerces. 

(1 edit)

Where do you call 

Spriteset_Battle.prototype.battleFieldDepthCompare

because it's not a default RMMV parameter, and that might be causing the error. My plugin overwrites

Spriteset_Battle.prototype.adjustSprite
Spriteset_Battle.prototype.updateZCoordinates

Now that I think about it, if that plugin overwrites updateZCoordinates, it would be wiped clean by my plugin, so try including that plugin after EarthboundBackgrounds and see what happens.


Basically: Flip the order of the 2 plugins and see if that fixes things.

What's the exact error you get?

The original file's structures is it, you have to follow it. By copy pasting you are trying to have 2 JSON roots, and JSON doesn't like that. This is described in the README, but the root object must be 1 *object* with entries called "layers" and "configurations". So inidividually your files would work, but you have to put them into 1 JSON object.

If you want Javascript to do it, there are resources only that explain how to do it, but the Javascript to run would kinda look like.

let object1 = JSON.load("foo.json");
let object2 = JSON.load("bar.json");
let olen = object1.layers.length;
object1.layers += object2.layers;
// You have to adjust configurations, which can be non trivial
// If config is simply an array
object2.configurations += object2.configurations.map((config) => config.map((x) => x + olen));
// Configs can be objects too. Look at the README.

I will lock this topic, as this seems to be a basic misunderstanding of how JSON works, which is beyond the scope of help that I'm honestly willing to give for a free plugin. Please open another topic if you still have trouble with things that are specifically about the plugin, and not documented (quite a bit better than mine tbh) stuff.

put the additional layers into the first "layers" array, then reference those players in the configurations that u will put under the original "configurations" object.

No, you have to merge those into 1 JSON tree, it's quite a bit more involved than copy pasting.

multip[e in 1

Welp, I finally figured out how to do it: https://jengamon.itch.io/jms-earthbound-backgrounds-for-rpg-maker-mv/devlog/2076....

This should work properly. Post here if it doesn't. I'll unsticky this now.

Look at the README for more details on the configuration format and details, but basically they are simply greyscale images.

If it only affects the background, use the upper layer (as backgrounds consist of 2 layers that are mixed together). If it also affects character images, the menu, etc. that's outside the scope of this plugin.

I didnt think about that. Let me see what I can do.

Here you would use `JM_EBB.setConfiguration("soup")` unless you literally named the configuration "<soup>".

(1 edit)

Just one config file. If you have a confiuguration in the file named "doomguy", you would use [EBB: doomguy], no angle braces. You can name them with any valid JSON string.

You have to create a new configuration inside the configuration file. README should describe the format.

Changing the background in a battle (or for the next battle) is a script call (or plugin command). Adding new backgrounds and adjust existing backgrounds is a configuration change, yes.

Yes, the only valid configurations that can be used are those specified in the configuration file.

Also, you should be able to freely encrypt the files, but since I don't know how to control RMMV's exclude mechanism, you might wanna avoid it...

This should fix it: https://jengamon.itch.io/jms-earthbound-backgrounds-for-rpg-maker-mv/devlog/1722...

Is "normal" the name of a valid configuration in ebb/jm_ebb_normalbattle.hjson?

@Kireus you can change the colors of the pattern. Just change the palette file.

Nope. It's written with JS and uses a custom shader. That would be *difficult* to say the least to port to VXA. MZ? Possible, and probably, but VX/A is probably a no-go for lack of shaders.

Posted! https://jengamon.itch.io/jms-earthbound-backgrounds-for-rpg-maker-mv/devlog/166938/fix-script-defaults

Have all your questions been answered?