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!


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

-Foxley pointed out it's no longer possible to go from the enemy attacks
menu to the attacks editor. (Confirmed)

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

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

-make sure James documents "current vehicle id" and "current vehicle npc"
and adds them to whatsnew

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

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


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

Reply via email to