[Ohrrpgce] Almost time for etheldreme stable release!

Sat Nov 11 17:53:13 PST 2017

On 12 November 2017 at 14:28, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Fri, Nov 10, 2017 at 6:20 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>> Ah, I see I was mistakenly counting the 3 months from Dwimmercrafty+1
>> rather than Dwimmercrafty!
>>
>> What counts as something that "can't wait" for F? Only things to fix bugs
>> or backcompat problems? Or does it include changes that other work depends
>> on, and would result in too much being done in a branch?
>>
>
> I would say any of the above. Basically is there anything you think is
> better to merge now rather than to wait to merge until after etheldreme?
>

Feature-wise, anything that will make a major difference to users. But I
don't have anything like that not already mentioned.

>>
>> For how long before a release do we want to avoid major changes? Sitting
>> around in nightlies is no substitute for testing with release candidates.
>> People only download new nightlies rarely. I'd say how long to wait depends
>> on how significant the change is rather than a hard cut-off.
>> Also, we can keep things out of the release either by not checking them
>> into wip (eg by using git branches) or by branching etheldreme early in
>> svn. I think it's easier not to branch stable releases long ahead.
>>
>
> How about if we aim for a RC around the 18th and a release around the 25th
> if all goes well?
>
> I know that is a short RC testing range, but I don't think a longer range
> will actually result in a lot more testing
>

Sounds fine. I think a week is the right length of time.

>
> I also agree that it is better not to branch the stable release long
> ahead. I think I didn't branch the dwimmercrafty release until the day of
> the release, and that worked fine for me.
>
>
>>
>> I keep jumping between working on so many different things that I can't
>> decide what to do next.
>>
>> The biggest things I had been planning to work on in the next weeks was
>> changing the graphics file format, replacing the spriteset browser, and to
>> convert battles to slices.
>> That would allow raising the sprite size limits, and possibly the
>> 16-color limit (with additional work in the sprite editor) without
>> depending on the new animation system.
>> However it looks like I'll have little time to work on the OHR for the
>> next 10 days anyway, so it's all moot.
>>
>
> That sounds like a lot of work for just 10 days, even if you had nothing
> else to do in the world! :)
>
Converting battles to slices will probably hit into some painful edge cases
in the animation system, but is largely about replacing Frame with Slice,
not new features.
I don't think a new spriteset browser is going to be that big a project,
since it doesn't do terribly much (until animations are added.).
The new rgfx file format isn't finalised, but I've pretty much decided
which changes I'm going to make to it. Saving, loading and upgrading to
rgfx is largely implemented.

Anyway, once I have a free week and pull myself away from other OHR
distractions, I'm going to spend a week just on animations. I think that's
enough time to get them in place :)

>
>>
>> More realistically, I've been doing lots of work on slices recently, most
>> of which isn't exposed yet. I'll think about whether it's ready to expose.
>> And I wanted to work on equip slots.
>>
>> A general summary of stuff I'm actively working on but haven't merged yet:
>> -line slices
>> -template slices (hidden slices which are ignored for all purposes)
>> -refactoring embed_text_codes, so that you can use embed codes in text
>> slices
>> -map editor improvements
>>
>> And some stale stuff that's close to mergeable:
>> -nicer looking minimaps either using scale_surface (which require 32 bit
>> color) or an alternative (which doesn't)
>> -joystick rewrite, to fix our utterly broken joystick handling (so little
>> risk of breaking anything by merging it)
>> -a color replacement tool for backdrops, which REPLACES the 'disable
>> palette colors for import' menu.
>>
>
> Those last two especially sound like great things to sneak in before
> etheldreme. :)
>

I was a little be worried about removing the 'disable colors' menu (I
modified it into the remap tool). I was thinking that a color remapper
(which is just a 'replace color' tool with undo) can't do everything color
disabling does. If two colors in the original get mapped to black, then the
remapper can't separate them again. But if you disabled black, they might
get mapped to dark blue and dark red. Which is a crappy solution too!
And this is only a problem for 32 bit bmps; 8 bit bmps are fine, because
you can remap colors during import, before the information gets lost.
And it would be possible to improve the remapper for 32 bit import too, by
first converting them to 8-bit with an optimal palette.
So I'll merge it.

>
>> BTW, don't forget to update this out-of-date whatsnew line:
>>     * You can now browse for items rather than typing in their ID
>>       numbers [James]
>>
>
> I'm not sure what I need to change there... Maybe I phrased it badly?
>

It's out of date because it only mentions items, but you can browse for
other stuff too.

>
> ----
> James
>
>
>>
>> On 11 November 2017 at 12:43, James Paige <Bob at hamsterrepublic.com>
>> wrote:
>>
>>> It is almost time for the Etheldreme stable release!
>>>
>>> If possible, I hope to release it by the end of this month (Last week of
>>> November, ideally)
>>>
>>> My general impression of the current nightly wip builds is that they are
>>> pretty stable, not to crashy, and have a respectable amount of nifty new
>>> stuff.
>>>
>>> I don't have any pending critical stuff that I need to finish. TMC, do
>>> you have anything that needs to be checked in that can't wait for the f*
>>> release?
>>>
>>> The only halfway ambitious thing I might attempt before then (only if I
>>> have time) would be to try and do a little more work on ThingBrowser to
>>> enable editing while browsing (which currently only makes sense for
>>> ItemBrowser, but will be important for AttackBrowser, HeroBrowser,
>>> EnemyBrowser, etc...)
>>>
>>
>>> ---
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20171112/bdd1ec12/attachment-0001.html>