On 8 March 2018 at 15:57, Ralph Versteegen <teeem...@gmail.com> wrote:
> > > On 8 March 2018 at 08:08, James Paige <b...@hamsterrepublic.com> wrote: > >> >> >> 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 >> > > 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 <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-motherh >>>>>> amster.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 >> >> >
_______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
