[Ohrrpgce] Almost time for etheldreme stable release!

Mon Nov 20 17:07:39 PST 2017

On 12 November 2017 at 14:53, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> 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.
>

Despite being a RC, we still didn't update whatsnew for that or the
highlights.

The amount of unmerged stuff I have is only increasing!
Although I finished Line slices (after finally deciding that they should
draw from x,y to x+w,y+h, not to x+w-1,y+h-1, and that using negative width
and height is most natural, both of those things are necessary for lines
properly connecting together when you parent one to another), I didn't
merge them because I hadn't written the script commands... hmm, should do
so anyway, and the commands are pretty easy to add anyway

The other thing was that I meant to expose the option to change the game
resolution. Even though it's a RC, exposing it doesn't actually change
anything, and it's been in testing for years. I'm sick of telling people
that the option is still hidden.

>
>>
>> ----
>> 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/20171121/dba9c41c/attachment.html>