Page 47 of 55

Posted: Mon Apr 26, 2021 5:30 pm
by Andrusi
TMC wrote:
Andrusi wrote:I sometimes see a similar effect trying to navigate menus in GAME.
You definitely should not see that problem anywhere in the menus in Game or Custom! Keyrepeat doesn't start until a key is held for 500ms, which is more than long enough to prevent it. However people often script menus in a way that suffers that problem (use "keypress", not "key is pressed".) Is there some specific place you saw it?
I actually can't find anywhere this happens now. It might be that I was thinking of something else in CUSTOM, or an older build, or something.

Posted: Fri May 14, 2021 10:29 pm
by Hedera
Could there be an option added so that, for a given item, only n numbers of it can be in the inventory at a time? ie: so you can only have one stack of 99, or one stack of 9 (a la The 7th Saga), or two and a half stacks of 99, and so forth?

Posted: Fri May 14, 2021 11:26 pm
by kylekrack
I feel like I'll get flack for asking this, but is there any plan to have the option to lift the 16-color limitation on sprite palettes? Is that even a possibility? Backdrops can be in 8-bit color, but they aren't very organized. Now that we can resize sprites arbitrarily, the color limitation conflicts with making large non-backdrop sprites (if not only because larger sprites tend to use more colors).

As an example, I wanted to import the Katja's Abyss title as a sprite with frames of animation, to give it some more flair. However, it had too many colors and I had to import it as a backdrop. I still could have made more frames and uploaded them as sequential backdrops, but that gets pretty messy pretty quickly, as I learned in Digital Soul Data. The special attack animation in that game is a cycle of I think 24 backdrop sprites. It gets pretty hard to navigate the backdrop editor at that point.

I'm not saying the 16-palette constraint should be done away with. It's one of the most unique things about the ohr. But being able to turn it off on a per-spriteset basis would be another rocket leap into new heights for the engine.

Posted: Wed May 19, 2021 8:44 pm
by Andrusi
kylekrack wrote:I feel like I'll get flack for asking this, but is there any plan to have the option to lift the 16-color limitation on sprite palettes? Is that even a possibility? Backdrops can be in 8-bit color, but they aren't very organized. Now that we can resize sprites arbitrarily, the color limitation conflicts with making large non-backdrop sprites (if not only because larger sprites tend to use more colors).

As an example, I wanted to import the Katja's Abyss title as a sprite with frames of animation, to give it some more flair. However, it had too many colors and I had to import it as a backdrop. I still could have made more frames and uploaded them as sequential backdrops, but that gets pretty messy pretty quickly, as I learned in Digital Soul Data. The special attack animation in that game is a cycle of I think 24 backdrop sprites. It gets pretty hard to navigate the backdrop editor at that point.

I'm not saying the 16-palette constraint should be done away with. It's one of the most unique things about the ohr. But being able to turn it off on a per-spriteset basis would be another rocket leap into new heights for the engine.
One possible workaround for this would be to layer multiple sprites that have different palettes, getting you an extra 15 colors for every layer. If you need a bajillion colors that could get impractical and/or annoying, but 30 or 45 seems like it would be pretty doable.

Posted: Wed May 19, 2021 10:36 pm
by Bob the Hamster
Oh! I meant to comment on this, and got distracted.

Yes! We definitely do want to support larger palettes than 16 colors.

Adding more colors will be optional, people won't have to use it if they don't want to.

Any image with 17 or more colors in its palette becomes 8 bit instead of 4 bit, but that doesn't mean you'll always have to see a whole 256 colors in the sprite editors. I think we can figure out a way to make the sprite editors only show you the part of the pallete you actually want to use.

Posted: Sun May 23, 2021 1:53 pm
by TMC
I expect and intend Icecream to lift the 16-colour limitation. Two further things I think we should add:

-Backdrops with more than one frame, for animations
-Drawing sprites using the master palette directly without an intermediate (16/limited-color) palette. Palette -1 means the default palette, so I guess palette -2 would have to mean master palette. You could still switch palette to an intermediate one.
Hedera Helix wrote:Could there be an option added so that, for a given item, only n numbers of it can be in the inventory at a time? ie: so you can only have one stack of 99, or one stack of 9 (a la The 7th Saga), or two and a half stacks of 99, and so forth?
I've seen quite a few requests for limits on item counts (typically you'd want each item type to have its own limit). I can think of three different types of limits:
-limit the number of stacks you can have of an item
-limit the stack size of an item (which you can combine with limited inventory space). Already implemented.
-limit the total number you can have of an item

There are reasons for preferring any of these, so I'm thinking that we should just implement all three. Then you can even use them in combination, e.g. if you want to let the player have one and a half stacks, or three stacks of up to 9 bombs each.

Re: OHRRPGCE feature requests/suggestions

Posted: Mon Jun 14, 2021 9:19 am
by Ravancloak
Script command to change sound effect volume, like the built in menu item. See the set/get music volume scripts. I looked through source code and it looks like it's almost there if not there. I keep getting disappointed it's not a thing :gonk:

(edit: worth mentioning... I could really use this for the summer slam)

Re: OHRRPGCE feature requests/suggestions

Posted: Tue Jul 27, 2021 12:11 pm
by TMC
Oh, right! A few people wanted that command. I've added "get/set global sound volume". Sorry for the unreasonable delay.
However, the nightly build machine seems to be down, not that it would have made a difference...

Re: OHRRPGCE feature requests/suggestions

Posted: Tue Jul 27, 2021 3:43 pm
by Bob the Hamster
Oops! Yep, the nightly build box lost its wifi connection. I nudged it.

Re: OHRRPGCE feature requests/suggestions

Posted: Thu Sep 09, 2021 7:03 pm
by The Wobbler
Request: A "dash in" animation type for enemy Appear Animation, where they slide in from off screen to their assigned space.

Re: OHRRPGCE feature requests/suggestions

Posted: Sat Sep 11, 2021 8:28 pm
by SwordPlay
about "move slice with wallchecking" command(s)
this seems to only work when the slice is moving.
is there a command to check whether a slice is colliding with wallmap when stationary?

Re: OHRRPGCE feature requests/suggestions

Posted: Sun Sep 12, 2021 1:43 am
by TMC
A dash-in appear animation is noticeable lacking. I was hoping that could be added at the same time as overhauling battle animations.
SwordPlay wrote: Sat Sep 11, 2021 8:28 pm about "move slice with wallchecking" command(s)
this seems to only work when the slice is moving.
is there a command to check whether a slice is colliding with wallmap when stationary?
I'm not sure I understand the question. You want to know whether a slice (or rectangle) is currently intersecting the wallmap? There's no command to check that. The wallchecking commands ignore any walls intersecting the slice/rectangle, and it would be an entirely new command to do so. I don't feel like such a command would be useful enough to bother adding, so would be better scripted. What do you want to do with it?

Re: OHRRPGCE feature requests/suggestions

Posted: Sun Sep 12, 2021 6:06 am
by kylekrack
What about this?

Code: Select all

script, check slice colliding with wall, sl, begin
    variable(x, y)
    
    for(x, 0, sliceWidth(sl), sliceWidth(sl)) do(
        for(y, 0, sliceHeight(sl), sliceHeight(sl)) do(
            if(readPassBlock(x / 20, y / 20)) then(
                exitReturning(true)
            )
        )
    )
    
    exitReturning(false)
end
EDIT: Wait, this doesn't account for one-way walls at all, even if it does work the way I meant it to
EDIT AGAIN: I don't mean one-way walls, I mean wall bits that aren't (north wall + east wall + west wall + south wall)

Re: OHRRPGCE feature requests/suggestions

Posted: Mon Sep 13, 2021 12:00 am
by TMC
Your for loop bounds are broken.

I think the correct script is this:

Code: Select all

script, check slice colliding with wall, sl, begin
    variable(x, y)

    # Check horizontal wall pieces
    # y iterates over all tiles where the slice crosses the bottom edge of the tile
    for(x, sliceX(sl) / 20, (sliceX(sl) + sliceWidth(sl) -- 1) / 20) do(
        for(y, sliceY(sl) / 20, (sliceY(sl) + sliceHeight(sl) -- 21) / 20) do(
            if((readPassBlock(x, y), and, southwall) ||
               (readPassBlock(x, y+1), and, northhwall)) then(
                exitReturning(true)
            )
        )
    )

    # Check vertical wall pieces
    # x iterates over all tiles where the slice crosses the right edge of the tile
    for(x, sliceX(sl) / 20, (sliceX(sl) + sliceWidth(sl) -- 21) / 20) do(
        for(y, sliceY(sl) / 20, (sliceY(sl) + sliceHeight(sl) -- 1) / 20) do(
            if((readPassBlock(x, y), and, eastwall) ||
               (readPassBlock(x+1, y), and, westwall)) then(
                exitReturning(true)
            )
        )
    )
    
    exitReturning(false)
end

Re: OHRRPGCE feature requests/suggestions

Posted: Mon Sep 13, 2021 7:30 am
by SwordPlay
about these scripts.
it assumes the parentage of the slice, right? as well as its align/anchor?

in general i'm rather sick of converting between the different formats based on camera,map, and slice x/y/align/anchor its so confusing!

i tend to make a clone of the slice, attach it to the map somewhere, set its position to match the original, and use this clones x/y