[Ohrrpgce] Fufluns released! ...

Mon Jul 8 01:41:57 PDT 2019

Ah, I fell for the subject line again :)

Wow, I knew I was terrible at time managment, but this is a whole new
level. I've been saying "next month" for well over a year now! I think if
you add up all the OHRRPGCE release delays I'm responsible for it might
come to four years...

I'm sure we will actually release this month, if we attempt it. After this
I want to go back to a three-month release schedule!
There are so many major bugfixes in nightlies that it's crazy to hold up
the release.

I don't think Asana is an ideal place to maintain a list of release
blockers, since that's something that should be public, and part of a bug
tracker. Of course, right now only a tiny minority of our bugs are filed
into a real bug tracker.
(I still want to move the buglist to github or elsewhere -- it hasn't
happened yet, so anyone can still argue for a better host if they know one.
I still don't have any preference for github over, say, bitbucket.)
And even when we do get all our bugs into a bugtracker, we could use Asana
for other organisation. I'm not too sure what that would look like.

I signed up and made changes to the existing bugs in the Asana project but
I've got quite a list here, which I haven't added there:

Here are the things I consider probable blockers (all of these are new in
Fufluns nightlies):
-Frame group names like Up, Left, Attack, Cast need to be added back to the
spriteset browser. Note that the plan was to name frame groups rather than
frames, and there's code for this but it's not finished. For now the frame
group names should be hardcoded so that code doesn't need to be finished,
but when you can freely add new frames they'll be customisable.
-There's a nasty crash in the tag browser autoset tags detail viewer which
I have been criminally lazy about fixing
-(Same as above?) "crash when I tried to assign the same "is equipped by
active hero" tag to more than one item"
-Crash when viewing minimap in Arc Wars on Pride map (Reported by Feenicks,
I haven't looked)
-Sell menu is horribly and painfully broken when max inventory size is less
than one screenful
-A few remaining places in battle were non-standard sized sprites are
mispositioned. I don't want anyone to depend on this. Most importantly
centering of attack animations over a target; secondarily also
attacker-target alignment for Dash In etc.
-Fenrir reported pasting text always crashes Custom, whether text copied
from within OHR or another program. Win 7, OHR wip 20180918 directx/sdl.
Strangely only Fenrir has complained. We have a crash report.
-Crash when changing window zoom using F9 in places which run at 32-bit
colour, such as the browser and map browser (well, the map browser part is
new)
-Look over the other crash reports we have, to see if we can easily fix
any. (e.g. crash when importing .tilemap with multiple layers (crash report
6eaee903) is not new, but should be easy fix.)

Maybe some of the above are not blockers. Also in the
not-blockers-but-ought-be-done-for-release-if-there's-no-deadline-panic
category:
-(Not new in Fufluns) Closely related to above crash: bug causing addition
of \r on Windows when pasting text
-delete .pt# and .mxs
-do something about slow thingbrowsers, spriteset browser, map browser in
big games/slow computers
-Fenrir reported gfx_directx flickers or doesn't display map editor minimap
screen, presumably because it defaults to 32-bit color minimaps. I assume
it happens in-game too, which may be a blocker. He didn't mention that
though.
-Uninitialised attack or enemy record (0% elemental resistances) getting
appended ("loadrecord: record # is off the end of" dt6/attack.bin). Can't
remember whether this is fixed. Likely new in Fufluns
-improvements to variable-resolution sprites support, such as fixing
portrait boxes (currently always 50x50) and fix positioning of NPCs in the
map editor, and finally add ability to resize existing spriteset
-Nathan Karr complained about broken textbox chains when upgrading to a
nightly with the broken textbox chain bug fixed. Sounds like it must be a
coincidental different bug, or maybe just confusion. He gave me an .rpg
from before he upgraded to the nightly which caused the problem, but didn't
have a broken .rpg anymore. I haven't examined the .rpg he sent yet
-Remove useless "import translations" option from in-game debug menu
-Look over this list for bugs new in Fufluns and see if we can easily fix
any: https://rpg.hamsterrepublic.com/ohrrpgce/Bughunters_League_Table

Pretty much all the significant new bugs in Fufluns are on the league table
on the wiki. I have a separate list of unreported bugs I've discovered, but
strangely they're all fairly minor (if someone reported a significant bug I
knew already knew about, I gave them credit by adding it to the league
table.)

In the last month or two I've hardly touched the OHR, but what I did work
on was finishing sprite and map layer alpha transparency (I actually did
most of the work on that months ago - haven't been delaying for this,
honest!). I was thinking about committing it since it's useful even without
32-bit colour depth (which is unfinished but makes it look dramatically
better), but now I reconsider, and for stability it's better that I commit
it afterwards, and everyone can then get it in nightlies.

On Mon, 8 Jul 2019 at 03:29, James Paige <Bob at hamsterrepublic.com> wrote:

> Ahoy, Ralph!
>
> I would love to try and make the Fufluns release happen this month, and I
> think I'll have some time to actually work on it.
>
> Let's come up with a list of the absolute critical blockers.
>
> I would define a blocker as a bug that would leave some important
> functionality in Fufluns significantly broken in comparison with the same
> functionality in Etheldreme.
>
> I sent an invite to join my OHRRPGCE Asana project. Don't feel obligated
> if you don't want to use it, but I have been finding it pretty handy for
> listing to-do-list tasks. We can also just discuss plans here if that works
> better.
>
> ---
> James Paige
>
>
>
> On Fri, Mar 23, 2018 at 6:43 PM Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 24 March 2018 at 11:01, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>> On Fri, Mar 23, 2018 at 2:41 PM, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 24 March 2018 at 03:42, James Paige <Bob at hamsterrepublic.com> wrote:
>>>>
>>>>> I agree that adding a textbox option does sound best. Are you thinking
>>>>> an option to change the anchor/align? or pixel positioning or both? I think
>>>>> I would be inclined towards adding those positioning options in a way that
>>>>> is similar to what is available in a slice, but not going as far as
>>>>> actually saving slice data in the current textbox format.
>>>>>
>>>>
>>>> Both, I suppose. Definitely want pixel position. Alignment isn't
>>>> strictly necessary if you can position, but it's convenient. Don't need
>>>> separate alignment and anchoring, just combined align+anchor.
>>>>
>>>
>>> That sounds reasonable. I can implement that.
>>>
>>>
>>>>
>>>>
>>>>> I am fine with leaving the default positioning top-left
>>>>>
>>>>
>>>> I'm also OK with top-left if it has to be, although it seems suboptimal
>>>> for backdrops smaller than the screen - you're unlikely to want them there.
>>>> If you increase the game resolution (and especially if you used
>>>> backdrops as portraits), the textboxes move to the center but the backdrops
>>>> don't.
>>>>
>>>> But actually on further thought I realised the default position is NOT
>>>> top-left, see below.
>>>>
>>>> Oh! Another thing: if the backdrop isn't as large as the screen and
>>>> isn't transparent, it would be good to have an option to cover the rest of
>>>> the screen with a solid colour.
>>>>
>>>>
>>>>>
>>>>> As for "show backdrop" I could add convenience arguments that would
>>>>> change the anchor/align of the backdrop slice.
>>>>>
>>>>
>>>> Those convenience arguments would be very nice. However I note that
>>>> current behaviour is that "show backdrop" (and also textbox backdrops)
>>>> don't change the position/alignment of the backdrop slice, so for
>>>> backcompat we ought to keep that behaviour... however it's a very strange
>>>> default to have and will cause heaps of annoyance if alignment arguments to
>>>> showbackdrop and textbox backdrops are added. Imagine: you change one
>>>> backdrop to use some other alignment and now you have to make sure that you
>>>> either manually change the alignment back to top-left afterwards, or change
>>>> followup textboxes/showbackdrop calls to explicitly specify top-left. That
>>>> would be dreadfully annoying!
>>>>
>>>> So maybe we need a backcompat bitset to make textboxes and showbackdrop
>>>> reset the backdrop position to top-left 0,0 by default instead of keeping
>>>> the previous position.
>>>>
>>>>
>>> Hmmm... I didn't think of that, but you are right. That would be a
>>> reasonable backcompat bit.
>>>
>>> So both textbox backdrop position and script backdrop position would
>>> default to either same-as-previous with the bit off, or top left corner
>>> with the bit on.
>>>
>>
>> But if we're adding a back-compat bit, we could take the opportunity to
>> make the new default centered rather than top-left.
>>
>>
>>>
>>> I can work on that also.
>>>
>>> Actually though, none of this sounds like a release blocker to me, just
>>> a feature that isn't as complete as we would like it to be, not a bug or a
>>> breakage.
>>>
>>
>> Yes, it's not a blocker.
>>
>>
>>>
>>>
>>>>
>>>>> On Thu, Mar 22, 2018 at 10:13 PM, Ralph Versteegen <teeemcee at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Also, how should non-320x200 backdrops be positioned? Currently,
>>>>>> textbox backdrops and I think "show backdrop" places these backdrops
>>>>>> aligned to the top-left corner of the screen, while the titlescreen and
>>>>>> battle backdrops are centered. Perhaps we should change this. It would be
>>>>>> best to add a textbox option to position the backdrop.
>>>>>>
>>>>>> On 23 March 2018 at 18:11, Ralph Versteegen <teeemcee at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The spriteset editor is unusably slow in large games; I need to get
>>>>>>> rid of the defpal#.bin lumps. (WIP)
>>>>>>>
>>>>>>> .pt# and .mxs lumps need to be deleted.
>>>>>>>
>>>>>>> Cursor keys in the spriteset editor are still very wonky. I rewrote
>>>>>>> the cursor key handling, I just need to clean up the code and commit it.
>>>>>>>
>>>>>>> Also, the Windows 10 bug which breaks gfx_directx fullscreening
>>>>>>> ought to be addressed, I think at least 4 people have complained about that
>>>>>>> problem. The easiest way to solve it would be to switch to gfx_sdl as the
>>>>>>> default for game.exe, but switching backends always causes unexpected
>>>>>>> problems (and gfx_sdl fullscreening is really bad anyway), so I'd rather
>>>>>>> try to figure out how to fix the problem properly.
>>>>>>> (And anyway, Pepsi reported another new problem with gfx_sdl
>>>>>>> fullscreening on Windows:
>>>>>>> https://www.slimesalad.com/forum/viewtopic.php?p=132358#132358)
>>>>>>>
>>>>>>> There was a bug which resulted in broken textbox links; I fixed that
>>>>>>> bug but for some reason didn't merge in the upgrade code to scan a game for
>>>>>>> broken textbox links and show a message.
>>>>>>>
>>>>>>> Although I merged in my branch which reenabled MP3 previewing, when
>>>>>>> I tested it later it didn't actually work for some reason. Should either
>>>>>>> fix it or delete that from whatsnew.
>>>>>>>
>>>>>>> I still need to fix the rest of the bug where copy-pasting text is
>>>>>>> broken on Windows (it appends \r characters to each line).
>>>>>>>
>>>>>>> Audio doesn't work at all on Windows when the codepage (for
>>>>>>> non-unicode applications) is set to Japanese, because in that codepage the
>>>>>>> \ character has a different code point. Not really a blocker, but serious
>>>>>>>
>>>>>>> On 23 March 2018 at 16:09, James Paige <Bob at hamsterrepublic.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hehe! Well, we will release for real soon enough. Other than the
>>>>>>>> Sprite import/export stuff, what else would you consider blockers?
>>>>>>>>
>>>>>>>> ---
>>>>>>>> James
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, March 22, 2018, Ralph Versteegen <teeemcee at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Haha! Surprisingly for that split second before seeing the "Just
>>>>>>>>> kidding" I didn't feel shock or annoyance; more like relief :)
>>>>>>>>> I have been unfortunately too busy, and when I have had time,
>>>>>>>>> failed to work on the important stuff, so this is turning into a bit of a
>>>>>>>>> farce... I am currently working on the missing spriteset import/export now
>>>>>>>>> though, and will follow that up with other important features.
>>>>>>>>>
>>>>>>>>> I don't want to keep delaying forever and have come to think that
>>>>>>>>> we (mainly I) are following the wrong strategy: rather than releasing late
>>>>>>>>> to fit in more features, we should cut early releases when we have
>>>>>>>>> something cool we want to get into people's hands without delay! (However
>>>>>>>>> in this particular case we couldn't, and can't, release on-time because of
>>>>>>>>> blockers)
>>>>>>>>>
>>>>>>>>> On 22 March 2018 at 11:03, James Paige <Bob at hamsterrepublic.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Just kidding! not yet! I like imagining your reaction to that
>>>>>>>>>> subject line, TMC ;)
>>>>>>>>>>
>>>>>>>>>> But seriously, how are you feeling about pending features and
>>>>>>>>>> bugfixes?
>>>>>>>>>>
>>>>>>>>>> Shall we push the stabilization of for another couple weeks?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> James
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>>
>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ohrrpgce mailing list
>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20190708/85cbd3ec/attachment-0001.html>