set/get hero picture doesn't work with portraits

[Mogri]

set hero picture(0, 1, spritetype:portrait) sets the hero's walkabout set to 1, and get hero picture(0, spritetype:portrait) returns the hero's walkabout set, at least as of Beelzebufo. Has this been fixed in the nightlies?

[Bob the Hamster]

set hero picture(0, 1, spritetype:portrait) sets the hero's walkabout set to 1, and get hero picture(0, spritetype:portrait) returns the hero's walkabout set, at least as of Beelzebufo. Has this been fixed in the nightlies?

The ability to set portraits with "set hero picture" was not added until July 2014, well after the beelzebufo release.

The spritetype:portrait constant should not have even existed in the beelzebufo plotscr.hsd, which makes me suspect that you might be using a newer nightly plotscr.hsd with your beelzebufo custom

[Mogri]

Oh, that does seem likely, actually.

[Mogri]

Well, I downloaded the nightly, and that made it worse until I noticed that I should be using hero portrait instead of spritetype:portrait. The change in behavior is a little odd. Before, I could set hero portrait(0, X, spritetype:portrait) and get X back from get hero portrait(0, spritetype:portrait). The command now returns 0 regardless of X.

This isn't a complaint per se; keeping the old behavior would have made things really confusing when I tried changing the portrait to something else later.

Unrelated bug: automatic-width menus are sized as if all menu items were visible. Rendering a large-width menu item invisible makes the menu unexpectedly large.

Another unrelated bug: text boxes that chain into shops that only have the Buy option don't disappear while the shop is onscreen. This is really ugly if the text box happens to occupy the lower half of the screen.

[TMC]

Before, I could set hero portrait(0, X, spritetype:portrait) and get X back from get hero portrait(0, spritetype:portrait). The command now returns 0 regardless of X.

This isn't a complaint per se; keeping the old behavior would have made things really confusing when I tried changing the portrait to something else later.

You meant "get hero picture(0, hero portrait)", right? What on Earth do you mean by "the old behaviour"? I wrote testcases for the hero picture/palette commands, and they seem to be fine. Maybe you passed a hero id instead of a party slot?

I actually would prefer that the textbox always disappears when you enter a shop, regardless of whether it has an outer buy/sell/whatever menu... well, maybe it should be optional, I guess some people might want the shop to look like a textbox choice menu.

[Bob the Hamster]

Oh, yeah, the spritetype: constants are for sprite slices! Not compatible with set hero picture at all!

[Mogri]

This is what I mean by the old behavior:

set hero picture(0, 1, spritetype:portrait) sets the hero's walkabout set to 1, and get hero picture(0, spritetype:portrait) returns the hero's walkabout set, at least as of Beelzebufo. Has this been fixed in the nightlies?

The invalid "spritetype:portrait" was treated as if it were 0 (outside battle). Not a behavior that you should need to reproduce.

I can work around the shop/textbox problem by chaining to a script that calls the shop instead. I can't work around the menu width problem as easily. Any chance that could get a quick fix?

[TMC]

Well getheropicture is intended to return the current value, not the default. If you want the default, use resetheropicture. And passing an invalid picture type to getheropicture actually causes it to return 0. We definitely need to improve script error reporting. The current script error level setting just doesn't work: we can't really add additional script errors because they'll start appearing all over the place in existing games, especially since we encouraged people to turn on script errors. Need to switch to "develop with errors shown, release with them hidden".
I'm really looking forward to adding "typed integers" when we get a new script interpreter. Then "inside battle" and "spritetype:hero" will both have a value of 0, but different types, so an error can be shown if you use the wrong one, but we can still hide the error and continue.

It turns out that the menu width thing was actually intentional:

IF .disabled AND .hide_if_disabled THEN CONTINUE FOR 'hidden matter for auto-width but not auto-height

I can see what the intention was, though don't think it's such a good idea, as the min menu width is a better way to avoid changes in the width. Since it's a pretty minor cosmetic thing, it should be OK to change. Done.

[Mogri]

Thanks! I appreciate the fast turnaround.

The current script error level setting just doesn't work: we can't really add additional script errors because they'll start appearing all over the place in existing games, especially since we encouraged people to turn on script errors. Need to switch to "develop with errors shown, release with them hidden".

You could add a "warning" reporting level and make it only appear in g_debug.txt, maybe.