[Ohrrpgce] Fufluns released! ...

Wed Jul 10 02:47:53 PDT 2019

On Tue, Jul 9, 2019, 10:09 PM Ralph Versteegen <teeemcee at gmail.com> wrote:

> I don't understand how you are using "needed improvement" -- I would think
> that's for things which aren't bugs but still ought to be improved, such as
> a confusing control scheme or the lack of spriteset resizing. I'd consider
> much of the stuff you tagged it with as outright bugs, though.
> I think that the lack of frame group names is actually the biggest blocker
> of all. It makes the sprite editor unusable for new users! I've seen even a
> number of longtime users ask which hero frame is which in the Discord
> channel.
>

I agree the line between "bug" and "needed improvement" is not always
clear, and I may have tagged a few wrongly. It is okay to retag.

I see your point about the missing frame group names. I think I was blinded
to the importance of that one by long habit. I have the names memorized
well enough that I forgot they were so essential. I have retagged that one.

> I had been planning to import the bugzilla bugs to github while preserving
> their original bug ID numbers (github doesn't let you assign, change or
> delete bug IDs), and importing the sourceforge bugs without preserving
> them, (instead putting "sf#2000", etc, in the bug name). I think what I
> will now do instead is to import bugzilla #21 to #1015 with their original
> IDs, #1-#20 without IDs (tag them bz#1, etc). The SF bugs will then get
> renumbered to roughly 1036 up. We could even skip over bugs 2000-2044 if we
> ever get that far, to avoid colliding with sourceforge bug numbers.
> As an example, FreeBasic development is now split across sourceforge and
> github, and they have two active bugtrackers. They simply refer to all bugs
> with a prefix, like sf#803, gh#102
>

I will avoid making any more bugs until you have imported, so as to avoid
interfering with the important.

Also, as soon as the SF bugs are in github, I will add a comment with a
link to each remaining sf bug pointing to the equivalent gh bug.

I will also fix hamsterrepublic.com/ohrrrpgce/buglist.php to redirect to gh
instead.

>>
>>
> On Wed, 10 Jul 2019 at 07:14, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> Yeah, we shouldn't do this in Asana. As much as I like their user
>> interface, nobody else can see it.
>>
>> I have got most of these bugs in github now:
>> https://github.com/ohrrpgce/ohrrpgce/issues/
>>
>> After consideration, only a few of these feel like release blockers. I
>> have labelled them.
>>
>> Everything else is nice-to-have, possibly even important-to-have I just
>> want to limit release blockers to the minimum of stuff that is
>> substantially broken compared to last release. "Would this make people
>> stick with the old release?" is the ultimate test of release-blockyness :)
>>
>> ---
>> James
>>
>> On Mon, Jul 8, 2019, 4:42 AM Ralph Versteegen <teeemcee at gmail.com> wrote:
>>
>>> 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
>>>>
>>> _______________________________________________
>>> 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/20190710/5a118cbb/attachment-0001.html>