[Ohrrpgce] Fufluns stabilization?

Thu Mar 8 07:14:11 PST 2018

I can't tell what is going on from the gif

Could this be a platform specific bug? What platform is Feenick using?

On Thursday, March 8, 2018, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 8 March 2018 at 15:57, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>>
>>
>> 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
>>
>
> It gets worse!
>
> https://cdn.discordapp.com/attachments/275093196852166667/
> 421290083124117504/beyondthedoor0008.gif
>
> *[*3:18 AM*] **tmc**: *does it still happen fi you quit and reenter the
> menu
> *[*3:18 AM*] **tmc**: *or quit and reenter the program?
> *[*3:21 AM*] **Feenick**: *let's see
> *[*3:22 AM*] **Feenick**: *Still being wonky
> *[*3:23 AM*] **Feenick**: *Lemme download the newest nightly and see if
> it's still an issue
> *[*3:26 AM*] **Feenick**: *Still having the issue...
>
>
>>
>>
>>
>>>
>>>
>>>
>>>> -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-motherh
>>>>>>> amster.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/aff589a0/attachment-0001.html>