[Ohrrpgce] Fufluns stabilization?

Ralph Versteegen teeemcee at gmail.com
Thu Mar 8 07:18:06 PST 2018


He's selecting an attack in the attack browser (using keyboard keys), but
it keeps opening a different attack than the one he selected. On Windows.

4:12 AM*] **tmc**: *do you see thate very time you enter the attack editor?
what if you open another game, like Vikings?
*[*4:13 AM*] **Feenick**: *Let's see
*[*4:14 AM*] **Feenick**: *Yeah Except it's attack 10 there
*[*4:15 AM*] **tmc**: *when you hit New, you mean
*[*4:15 AM*] **Feenick**: *Still 10


On 9 March 2018 at 04:14, James Paige <Bob at hamsterrepublic.com> wrote:

> 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/42
>> 1290083124117504/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-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/20180309/6616bdad/attachment-0001.html>


More information about the Ohrrpgce mailing list