[Ohrrpgce] Fufluns stabilization?

Wed Mar 7 18:57:00 PST 2018

On 8 March 2018 at 08:08, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Wed, Mar 7, 2018 at 6:34 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 7 March 2018 at 18:32, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>>
>>> On Tuesday, March 6, 2018, Ralph Versteegen <teeemcee at 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
>

I asked him some questions and tried to reproduce it in various games and
builds, and can't. I looked at the code and those symptoms seem impossible,
which I guess means the only possible explanation is memory corruption (or
a miscompile). Pressing the New button should go to gen(genMaxAttack), I
don't see any other possibility unless the slice pointers are mixed up.

*Feenick**: *Currently have 178 attacks. Still going to attack 23 when I
try making a new attack
*tmc**: *so you don't get the "new blank attack/copy of X" menu?
*tmc**: *or do you get that, but afterwards it opens attack 23?
*Feenick**: *nah, just goes straight to attack 23

https://media.discordapp.net/attachments/275093413152555018/421096093137240074/beyondthedoor0006.gif

*Feenick**: *Had the same issue with delinquent.rpg, just with another
attack slot
*tmc**: *what version are you using?
*Feenick**: *2018-02-25

*tmc**: *and this always happens regardly of how you enter the attack
browser (eg from another menu), and the End key likewise always does the
same?
*Feenick**: *The end key just goes to the end of the menu
*tmc**: *oooh
*tmc**: *"3:42 AM] Feenick: 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"
*tmc**: *so that was wrong?
*Feenick**: *Maybe?
*Feenick**: *Using the home key to get up to the top menu doesn't result in
anything wrong.
*tmc**: *can you still select attacks above 23 in places like the enemy
attacks menu?
*tmc**: *without entering the attack browser, I mean(edited)
*Feenick**: *It's pressing left on the attack menu while on the left
column, then going over to the new attack button, that causes the problem
*tmc**: *oh!
*tmc**: *but that works for me

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

Right, I was going to amend my email to say I forgot about that.
Unfortunately right-clicking is also hard to discover, because nothing else
in the engine uses it.

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

When testing it, it felt like a really blatant bug. It's actually quite a
natural thing to want to do, to show an on-death message or perform other
effects like setting a tag.

Also, I think we really need three new attack bitsets: "Never triggers
counter attacks", "Don't trigger counter attacks on miss/fail". We only
have a bit to not trigger elemental counterattacks.

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

That's right.

>
>
>>
>>> ---
>>> James
>>>
>>>
>>>
>>>>
>>>>
>>>> On 7 March 2018 at 17:11, James Paige <Bob at 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 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/20180308/13c3179e/attachment-0001.html>