On Wed, Mar 7, 2018 at 6:34 AM, Ralph Versteegen <teeem...@gmail.com> wrote:

>
>
> On 7 March 2018 at 18:32, James Paige <b...@hamsterrepublic.com> wrote:
>
>>
>>
>> On Tuesday, March 6, 2018, Ralph Versteegen <teeem...@gmail.com> wrote:
>>
>>> "Must-merge" is such an emotional phrasing!
>>>
>>>
>> Hehe!
>>
>>
>>
>>> The problems with the spriteset editor are:
>>> -you can't import or export spritesets. This is definitely a blocker. A
>>> number of people are not using nightlies for this reason.
>>> -the cursor keys are super wonky, so I need to check in my plankmenu
>>> arrow keys rewrite
>>> -it's extremely slow due to the way that default palettes are stored and
>>> loaded. Eg. POWERXE.RPG takes about 8 seconds to bring up the walkabouts
>>> menu for me. I have a branch where I replace defpal#.bin with rgfx
>>> -frame names like "hurt", "attack B" etc are missing. I have a branch
>>> for that too
>>> -the obsolete .pt# and .mxs lumps aren't deleted yet
>>>
>>> I also have a large collection of unrelated bug reports, but we could
>>> work on those after feature freeze (I should get back work on migration the
>>> bug trackers too... was having problems installing perl modules)
>>>
>>> But my actual argument against going to feature freeze now is that it
>>> would be sad to delay such game-changing features such as animations by
>>> three months, when they're almost ready and we've already paid most the
>>> instability cost. For example, I can make walktall obsolete just by adding
>>> a simple prompt asking what size spriteset you want to add. (Abitrary enemy
>>> and hero sprite sizes are enabled by a branch where I've done heaps of
>>> battle code cleanup and partially converted battles to slices)
>>> I know this is the same reason we always ended up delaying releases by
>>> months or even years, but in this case I think it's more like days!
>>>
>>
>> Okay! I have rescheduled my alert for a secret time in the near future.
>>
>
> I can't figure out whether it's more or less stressing to have a secret
> deadline!
>


Haha! (wrings hands like an evil supervillian)



>
>> Is there anything I can do to help you with all your pending stuff?
>>
>
> Unfortunately it's hard for me to suggest anything right now; I really
> need to merge in what I have to avoid conflicts, and to provide APIs and
> examples to work with.
>
> Oh, I just remembered: there will be a problem with Test Game once you can
> add more frames to an existing sprite set: updating the sprite cache won't
> work. The solution is to always use Sprite slices in-game instead of Frame
> ptrs. I've converted battle sprites to slices, but I believe there were
> still one or two places not using slices which need converting.
>
> If you wanted to, a completely separate project would be to remove the
> 16-color limit. At this point I'm assuming that we aren't going to delay
> release for it. We have almost no code left that still assumes a Palette16
> has 16 colours. 95% of the remaining work is to replace the .pal lump and
> to update the sprite editor UI. I haven't started on either. (As part of
> finishing off PNG support, I'm already updating the import/export code
> which explicitly asks for 4-bit bmps)
>
>
> We could also start working through all these bugs. Here are some I've
> written down:
>
> -This morning Feenicks wrote: "oh yeah, tmc: I still seem to be getting
> the bug where pressing the 'new' button or pressing the end key to get to
> the end of the list sends me to attack 23"
> I haven't looked into it or asked what he meant. If he said so earlier, I
> forgot.
>
>
I'll see if I can get ahold of him and ask. I haven't seen anything like
that yet



> -Foxley pointed out it's no longer possible to go from the enemy attacks
> menu to the attacks editor. (Confirmed)
>
>
This is already taken care of. When I switched to the AttackBrowser, the
only way to get into attack edit mode was the non-discoverable CTRL+E
keyboard shortcut.

Since then I have made it so you can right click on an attack and go to the
attack editor from the pop-up context menu.



> -Foxley reported a Self-target On-death attack causes the on-death attack
> to trigger again, looping forever (Confirmed)
>

Hmm... that sounds like something I would have done by design... but
perhaps the bad kind of "by design" ;)
I know I wanted to make it possible for an on-death-bequest attack to
trigger a self-targetting attack that heals the enemy and prevents the
death, and I know I did a lot of testing of self-targeting on-death-bequest
attacks that transmogrify the enemy into a different form.

I guess I didn't test on-death-bequest attacks that don't fall into either
of the above categories. I am curious what Foxley's specific use-case was.
I'll ask him.



>
> -Foxley reported that F9 Reimport Scripts while in any part of the tileset
> editor wipes the tileset. (Confirmed) He did some really thorough testing
> showing that whether it permanently wipes it, or it just appears black
> until you reenter the menu, depends on which submenu of the tileset editor
> you're in. But unfortunately I didn't copy it down. Should be an easy fix.
>

Yikes! I can look at that too.


>
> -make sure James documents "current vehicle id" and "current vehicle npc"
> and adds them to whatsnew
>
>
/me pretends he didn't completely forget about those


> -"Reset stored target" happens after "Store Target", so if you set both
> bits on the same attack, Store Target does nothing. But being able to set
> both bits would be very useful, makes Store Target work the way you would
> expect it does. It's not enough to swap the order the bits take effect,
> because inflict() is called multiple times if there are multiple targets.
> Instead Reset stored target needs to happen before the first inflict() call
>

Good point!


>
> Oh, also that bit for capping negative stats Surlaw asked for; I feel bad
> not getting around to that.
>
>

I remember that one! And didn't we decide that one bitset would be good
enough, we didn't need a full low-end-stat-cap feature with equal
complexity to the upper-end stat cap feature, right?


>
>> ---
>> James
>>
>>
>>
>>>
>>>
>>> On 7 March 2018 at 17:11, James Paige <b...@hamsterrepublic.com> wrote:
>>>
>>>> My calendar alerts went off again. How are you feeling about starting
>>>> Fufluns stabilization, tmc? What must-merge branches do you still have for
>>>> it?
>>>>
>>>> ---
>>>> James
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce@lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce@lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to