[hmsong]

@Queue

Could you also add a sub-option to make King Truffle to not wander around? (similar to what you did for Karon)  I prefer him to not wander around when I'm trying to talk to him to lift me out of the explosive death.

What is this "Flight_Waits_For_Events (should prevent the Mana Fortress barrier skip)" you're talking about?  I don't mind doing the testing, but I don't even know how to activate the bug thing.

[Queue]

I can probably add a sub option for Truffle's wandering, it's just so harmless I hadn't considered it would be wanted. It's not like there's a time limit there or anything, and he's adorable as he staggers around (and is potentially less confusing for a new player, since if you're to the left, and see the message about him, but don't walk far enough right to actually see him, if he wanders he can randomly come into view).

For testing Flight_Waits_For_Events, I just need people to play the game and make sure it doesn't break something I didn't think of to test (I tested cannon travel, sunken continent rising and sinking, event controlled flight and player controlled flight).

What it actually fixes, is... let's see how to explain the steps:
- be at the part of the game where if you land on the Mana Fortress it ejects you
- go somewhere with outdoor whip posts where you can also call Flammie (e.g. Lofty Mountains)
- activate a second player
- have player 2 start to melee a whip post (use any weapon, I generally just punched them) and just after the attack starts, open the ring menu with player 1 (so player 2 shouldn't have hit the whip post yet)
- have player 1 use the Flammie Drum
- you should see player 2 hit the post and maybe start walking in an arbitrary direction
- once flying, go to the Mana Fortress
- without Flight_Waits_For_Events, it should let you land because the whip post event paused for flight, then continued after landing and ended up blocking the auto event for the Mana Fortress
- with Flight_Waits_For_Events, you should get ejected as expected

[hmsong]

@Queue

Okay, I tried the Flight Waits Events bug (w/o the patch, then with).  It works, but you can still move around. the initial screen, as long as the dialog box is open (you can even kill Dark Stalker/Dark Ninja and Captain Duck, and maybe more).  Something I noticed though.  Why is P2 controlling Flammie? (this happens for vanilla too).  Weird.

Also, I don't see any errors when using Cannon Travel (not sure how Flight Waits Events would affect that).  If you want me to specifically test for something in particular way, let me know.

Boy, I'm having fun with switching orbs.  Thanks a lot for that.  One question.  I tried to change an enemy into an orb chest (in Moon Palace), but the chest RUNS AWAY.  Sure, I can still catch it, and the chest contains what I intended, but how do I get it to stay still?

Hmm.  For whatever reason, I sometimes see Mech Rider 3 reflecting his own Lunar Boost (originally Speed Up), despite me making Lunar Boost bypass Wall.  Sometimes, it reflects, other times, it doesn't.  I'm not sure what's going on.  Can you check?

[Queue]

Moving while the dialog box is open is effectively just a mistake in the event that shows that message that I should be able to improve. A vanilla issue as far as I recall.

I noticed the player 2 controlling Flammie thing too; not sure why it happens, clearly a vanilla bug, but not game-breaking, just annoying, so haven't looked into it.

If it interfered with cannon travel, the current event would break, or the game would hang, so if everything has seemed normal and nothing was obviously wrong, that's good.

I don't think any vanilla pre-placed chest runs, so I can only guess that it's due to some flag being set, like maybe the "this NPC is stationary" flag which is... the high bit of the Y coordinate? So, add 0x80 to the Y coordinate and see if that makes it stop running. There's also a flag that prevents it from being pushable. Which should be the high bit of the chest's event value.

I'll look into Mech Rider III. Grr, I didn't hit any snags when testing bypassing Wall and it's such simple code, I can't think of what could make it fail off the top of my head.

[hmsong]

@Queue

Wow, what you suggested about running chest solved the problem.  Just added 0x80 to Y, and boom.  Done.  Thank you.

It seems that sometimes, my Dispel Magic fails to dispel Walls.  My Dispel Magic was Lv7, and I casted it on Metal Crawler's Wall (single target).  And sometimes, it fails.  Probably due to the same reason Mech Rider 3 reflecting his own buff spells.

[Queue]

Found the issue with Mech Rider III; bosses don't use normal spell targeting code (that's part of how they can cast Saber buffs on the players regardless of a Saber's normal targeting restrictions), so whether his spells bypass Wall or not is based on the last spell a player cast. Figuring out a solution.

Haven't looked into Dispel yet.

[hmsong]

Hmm.  I consistently see Mech Rider reflecting his own buff, but I don't see my Dispel Magic (or my own buffs) being reflected by my Wall.  Maybe it was a coincidence.  Hmm.  Testing some more.

[Queue]

Version 2019-11-20:
https://ufile.io/1ir0gcd9

Changes:
- Fixed Data_Driven_Wall_Bypass to work correctly for bosses (probably, will detail new version after testing)
- Replaced Balance\Weapon_Affinity_Damage and Balance\Saber_Elemental_Damage with Balance\Bonus_Weapon_Damage; affinity and elemental damage now fit cleanly into the damage formula, and it fixes a bug where level 0 saber buffs don't get the expected 10% damage bonus
- Added _Wandering_Truffle as a sub-feature to Remove_Empire_Castle_Gate; defaults to On

Technical Changes:
- Started ground work to import Stardust Herb then table-flipped when I saw all the unrelated changes bundled in with it, so, I'll come back to this later

Note that I will likely be unavailable Friday through Sunday; just a heads up if I don't respond then.

[hmsong]

- Started ground work to import Stardust Herb then table-flipped when I saw all the unrelated changes bundled in with it, so, I'll come back to this later

Haha.  If you're inclined to do so, then feel free to take out the tweaks I did with with the unrelated monster drops (there were lots of unrelated changes -- if you want, I can post something to hash out the unrelated monster drops).  It may be wise to leave the shop parts alone though, since I changed lots of orders -- increased the consumables (including Stardust Herb), and changed a bit of available armors (they're very minor though).

Btw, I can't help but notice that ninjas (Dark Ninja, Dark Stalker, Ninja Master) cast sabers, but as soon as they throw boomerang, they lose their saber status and have to cast saber magic again.  And I'm betting it's not just them (I've seen that happen with Shellblast/Turtlance).  Every enemy has two weapon slots, so I'm guessing they "switch" weapons when they do different attacks.  So... is it possible to make them NOT lose their saber magic when they switch weapons?  At least for the monsters?  Player characters can also keep their saber magic when they switch using the L button, but I have a feeling that's gonna be tough to program.

[Queue]

I suspect Stardust Herb will be a fair bit of work for me whatever approach I take. Lots of compatibility fixups and planning for everything involving shops and enemy drops.

You're probably not going to like hearing this, but quick weapon swapping not stripping the Saber buff is an oversight that I need to fix. Even though the result is dumb, it's definitely intentional behavior: there's separate code to remove the Saber buff when a player or an enemy switches weapons (and the version for players is oddly complicated). I'm also fairly certain the reason is because they didn't have a reasonable way to apply the Saber buff's palette change to the new weapon, because nothing keeps track of the colors the Saber buff applies (it's just part of the Saber buff's animation that overwrites the weapon's colors), so if I'm going to properly change the behavior, I'll need to figure out a good way to preserve the colors when swapping weapons.

But yes, you're correct on the cause, it's due to enemy AI scripts that change their weapon for different attacks. Not every enemy makes use of both weapon slots, but I think it's more common than not.

[hmsong]

I suspect Stardust Herb will be a fair bit of work for me whatever approach I take. Lots of compatibility fixups and planning for everything involving shops and enemy drops.

Well, in the worst case scenario, you can just say, "not compatible with Faerie Coconut or Magical Herb".  I don't know if there's any other patches that involve enemy drops and shops.

You're probably not going to like hearing this, but quick weapon swapping not stripping the Saber buff is an oversight that I need to fix. Even though the result is dumb, it's definitely intentional behavior: there's separate code to remove the Saber buff when a player or an enemy switches weapons (and the version for players is oddly complicated). I'm also fairly certain the reason is because they didn't have a reasonable way to apply the Saber buff's palette change to the new weapon, because nothing keeps track of the colors the Saber buff applies (it's just part of the Saber buff's animation that overwrites the weapon's colors), so if I'm going to properly change the behavior, I'll need to figure out a good way to preserve the colors when swapping weapons.

But yes, you're correct on the cause, it's due to enemy AI scripts that change their weapon for different attacks. Not every enemy makes use of both weapon slots, but I think it's more common than not.

Oh, I thought switching with X button stripped the saber buff.  The color changed, so I assumed.  Upon testing, it doesn't strip the saber buff (but switching through menu strips it, which is what we want).  Interesting.  I'm actually glad players get to keep the saber buff (hopefully, you can make the color change).  I hope that can be applied to the enemies, so they don't waste anymore time casting Sabers after their initial saber magic (this ought to make the ninjas and turtles a bit more difficult).

Hmm.  The recent Saber buff modify (Bonus_Weapon_Damage) strips the Sabers from giving the extra def stat to the target.  Was this intentional?  Is there any way you keep that Def buff, as well as get the new Atk buff effect?

Here's my test result.

PC Atk test.  I'm using Randi (Lv7 Sword, Lv99) against Shellblast, and I'm using Lv7 Thunder Saber:
1. Default (no saber): ~185
2. v1118 (saber): ~230
3. v1120 (saber): ~235?

Shellblast Def test:
1. All versions (no Ice Saber): ~185
2. Default (w/ Ice Saber buff): ~112
3. v1118 (w/ Ice Saber buff): ~112
4. v1118 (w/ Ice Saber buff + Randi's Tunder Saber): ~135
4. v1120 (w/ Ice Saber buff): ~185

Based on these tests, I feel like not getting the extra Def from Saber magic is a bit of loss, since Lv0 saber magic is something all players will get over rather quickly.  Perhaps I should test with Popoi, since she has weaker Pwr.

Btw, does the Saber magic level affect the damage output?  I thought the saber magic level only decided the duration of how many hits it can do before auto-dispelling, not the damage output.

[Queue]

Version 2019-11-21:
https://ufile.io/zjd9b51a

Changes:
- Added _Element_Match_Defense sub-feature to Bonus_Weapon_Damage
- Added _Doubled_Bonus_Damage sub-feature to Bonus_Weapon_Damage
- Modified Equip_2nd_Weapon to (mostly) remove saber buffs like vanilla weapon changing behavior

Surprisingly complicated code (due to space constraints) to re-add Element_Match_Defense and to make sure Doubled_Bonus_Damage can't cause more than -100% damage, so hopefully no bugs.


I was in a hurry to get 191120 released to fix Data_Driven_Wall_Bypass, so I didn't take the time to explain Bonus_Weapon_Damage (or work on it more than I did before release).

I finally figured out where the enemy Saber element matching to their element's defense bonus was coming from, and so can definitely say it is a bug. Additionally, if an enemy got a Saber element on them that was an element they were weak to they'd take double damage (maybe Wall yourself and bounce Saber spells onto them?). The same part of code that was broken so that Saber element and enemy type affinity on player weapons didn't affect damage was causing the enemy Saber element match defense behavior.

I intend to re-implement the enemy Saber element match defense bonus as intentional behavior, because it is neat, but with better control over its function and strength (in vanilla it halves damage for the calculation step it occurs during, which is kinda nuts; the only reason the total damage isn't halved is because further stuff happens in the damage formula).

A Saber buff's level adds a damage bonus based on what level it is (and its effective level is reduced if multi-target cast). It's Damage/(10-SaberLevel), so Damage/9 (+11%) for SaberLevel 1, and Damage/2 (+50%) for SaberLevel 8. It should've also been +10% at level 0 but the logic that checked if a Saber buff was on wasn't very good, so it skipped the bonus if 0. I also am pretty sure there are ways to keep this damage bonus even if the buff fades in certain ways (like by switching weapons).

The point of Bonus_Weapon_Damage wasn't to fix the missing 10%, that was just an extra benefit. The purpose was to rewrite the affinity and elemental damage features into better code and with a better damage formula. This necessitated fixing the enemy Saber element match defense bonus because it interfered with correct implementation of affinity and elemental damage.


Edit: Added new version to this post.

[hmsong]

Nice.  I shall test.

EDIT:  Hmm.  At 25%, Saber doesn't grant as much Def as vanilla.  But I don't want to give 50%, since that'll boost the Atk way too much.  Having said that, I'm okay with this too.  So thank you.

Do you think you can make it so that monsters don't lose Saber status when they switch weapons?  Saber magic makes them much stronger, but they lose that buff when they switch weapons (ex: Ninjas and Turtles).
November 22, 2019, 04:09:18 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Okay, here's the new list of Stardust Herb monster drop (I got rid of some, because there were way too many enemies with Stardust Herb) (I replaced Dark Knight's Gauntlet with Stardust Herb, and instead gave Gauntlet to Gremlin for better balance):

Code: [Select]

'[Rabite]
@OFF $D03A53
RAW 40 1E
'[Buzz Bee]
@OFF $D03A58
RAW 40 32
'[Mushboom]
@OFF $D03A5D
RAW 1E 40
'[Chobin Hood]
@OFF $D03A62
RAW 3C 40
'[Iffish]
@OFF $D03A69
RAW 04 00 78 4B 43
'[Kid Goblin]
@OFF $D03A71
RAW 32 04
'[Specter]
@OFF $D03A80
RAW 45 43
'[Polter Chair]
@OFF $D03A94
RAW 3C 4A
'[Ma Goblin]
@OFF $D03A99
RAW 50 4B
'[Dark Funk]
@OFF $D03A9E
RAW 4B 43
'[Zombie]
@OFF $D03AAC
RAW 78 44 4B
'[Nemesis Owl]
@OFF $D03ABC
RAW 44 4B
'[Steamed Crab]
@OFF $D03ACB
RAW 41 43
'[Howler]
@OFF $D03ADA
RAW 4B 44
'[LA Funk]
@OFF $D03AE4
RAW 45 43
'[Bomb Bee]
@OFF $D03B20
RAW 4B 42
'[Mushgloom]
@OFF $D03B25
RAW 4B 4A
'[Trap Flower]
@OFF $D03B2A
RAW 44 42
'[Dinofish]
@OFF $D03B2C
RAW 84 00 78 4B 43
'[Mimic Box]
@OFF $D03B34
RAW 43 4A
'[Spider Legs]
@OFF $D03B4D
RAW 41 4B
'[Weepy Eye]
@OFF $D03B52
RAW 44 4B
'[Marmablue]
@OFF $D03B70
RAW 4B 43
'[Gremlin]
@OFF $D03BB1
RAW 4B 38
'[Dark Knight]
@OFF $D03BD9
RAW 4B 22
'[Doom Sword]
@OFF $D03BE8
RAW 44 37

And if you don't want to put the unrelated-to-Stardust-Herb monster drops, here it is:

Code: [Select]

'[Iffish]
@OFF $D03A69
RAW 04 00 78 4B 43
'[Ma Goblin]
@OFF $D03A99
RAW 50 4B
'[Dark Funk]
@OFF $D03A9E
RAW 4B 43
'[Zombie]
@OFF $D03AAC
RAW 78 44 4B
'[Nemesis Owl]
@OFF $D03ABC
RAW 44 4B
'[Howler]
@OFF $D03ADA
RAW 4B 44
'[Bomb Bee]
@OFF $D03B20
RAW 4B 42
'[Mushgloom]
@OFF $D03B25
RAW 4B 4A
'[Dinofish]
@OFF $D03B2C
RAW 84 00 78 4B 43
'[Spider Legs]
@OFF $D03B4D
RAW 41 4B
'[Weepy Eye]
@OFF $D03B52
RAW 44 4B
'[Marmablue]
@OFF $D03B70
RAW 4B 43
'[Gremlin]
@OFF $D03BB1
RAW 4B 38
'[Dark Knight]
@OFF $D03BD9
RAW 4B 22

And here's an addition to the shop (added Dwarf Village shop):

Code: [Select]

' Dwarf Village (D8FC73)
@OFF $D8FC73 '
RAW BA
@OFF $D8FC74 '
RAW BE
@OFF $D8FC75 ' Stardust Herb
RAW C5
@OFF $D8FC76 ' Cup of Wishes
RAW BF
@OFF $D8FC77 ' Rabite Cap
RAW 7E
@OFF $D8FC78 ' Head Gear
RAW 7F
@OFF $D8FC79 ' Midge Robe
RAW 93
@OFF $D8FC7A ' Chain Vest
RAW 94
@OFF $D8FC7B ' Spikey Suit
RAW 95
@OFF $D8FC7C '
RAW A7
@OFF $D8FC7D '
RAW A8

I'll send kethinov to update to this list (I'll need to send him the IPS).

[Queue]

If I can figure out how to maintain the Saber weapon colors, yes, I'll add the capability for Saber buffs to persist across a weapon change. In addition to maintaining the colors, maintaining the weapon status effect proc is the other non-trivial part (it has to be re-added when the weapon changes, since weapons have their own innate procs). The Saber's element (which is separate from the proc), level and remaining hit/use count are the easy parts.

It's easy to say what's necessary, but tricky to do, and made more complex since there are at least 3 different systems that can change an equipped weapon (e.g. AI script function, player ring menu, weapon forging, etc.). I wouldn't be surprised if it's a different system for bosses than for normal enemies.

Thank you for doing some of the leg work for Stardust Herb.

Have you had a chance to see if the changes I made to the Wall bypass code resolved the issues you were seeing?

Like I mentioned a few posts ago, I won't be available this weekend, so this post is probably it for me until Monday.

[hmsong]

@Queue

I see.  I look forward to it.  But I don't think any bosses uses Saber magic on themselves (and I have no plan on giving them saber magic either, since you can't even "see" their saber color).

Yes, I tested it.  Your Wall Bypass works great.  So far, no issue.  Thank you.

Enjoy your weekend.  I may re-edit the Stardust Herb drop list (above), but I'll finalize before you get back.

[Queue]

Version 2019-11-25:
https://ufile.io/ssacjw8f

Changes:
- Rewrote most of Turbo_Mode to fix some long-standing issues:
-- the HUD should update correctly (e.g. the weapon charge gauge at the bottom of the screen should look better when doing back-to-back charge attacks)
-- enemies where their AI checks their stamina will now randomly use their "tired" AI 25% of the time (instead of never) to resolve AI behavior where an enemy needs to occasionally be tired to act correctly
-- ally AI should be able to use more than one charge attack per fight and should no longer stop attacking after performing a charge attack

[hmsong]

Whoa.  Turbo mode do all that?  I usually don't use Turbo mode, because it made the game way too easy (I can just spam melee to curbstomp any enemy).  Also, what are some of the "enemies where their AI checks their stamina will now randomly use their "tired" AI 25% of the time (instead of never) to resolve AI behavior where an enemy needs to occasionally be tired to act correctly" examples?

Is there anything that needs to be changed from Enemy Behavior Change?

[Queue]

Version 2019-11-27:
https://ufile.io/mnhblpwv

Changes:
- Dust Flare high level animation colors now match its lower level variations
- Fixed a bug in Magic_Recharging where spell recast timers didn't work correctly with weird or atypical party compositions (e.g. girl and sprite without boy, boy and sprite without girl)


First off, the "randomly tired" AI thing only matters for Turbo Mode. Turbo Mode removes the "stamina" system, simply by changing any code that would set the value to anything besides 0 (it's actually an exhaustion system, where after an action like attacking or running, a non-zero value is set that then counts down towards 0; the player's UI shows it counting up to 100%, but 100% means the exhaustion / tiredness value has reached 0). Anyway, this means any AI that checks if that value is zero will always succeed, and some AI has stuff that will only happen when that value isn't 0, so for Turbo Mode checking that value now gets a random true / false result of 75% true (not tired) and 25% false. If not using Turbo Mode, this isn't necessary.

You're likely reading too much into the changes description; Turbo Mode is still fundamentally really simple, I just had to fix some weird behaviors that only happen when the "stamina" value never changes.

As for examples, there really aren't many, and most don't matter (usually a tiny change to movement logic). I was hoping to make the bats less pathetic, but it didn't help. I'm really at a loss to why kethinov thinks the Grave Bats are a troll-y enemy for nighttime Great Forest; they may be high level but they're so bad at combat I just don't see them as dangerous. I can only imagine there's something I'm forgetting or not seeing when testing.

No, there are no changes to Enemy Behavior Changes that'd be relevant.

I've made this argument several times before, but I see this game as so fundamentally easy that Turbo Mode doesn't make a meaningful difference in difficulty; I'd rather just be able to pound on the B button and enjoy the combat rather than stare at a little number filling up to 100% and beeping at me between B button presses. The upshot is enemies don't have to wait between attacks either so sometimes they can catch you off guard and mess you up a little before you get them stun-locked like usual. I still intend to find some way to boost difficulty that feels fun, I just haven't found it.

A Turbo Mode specific bug that that update fixed that I didn't mention was where an AI-controlled hero using a ranged weapon would play the wrong walking animation after doing an attack (basically they'd get stuck on the charging weapon shuffle walk).

I don't recall if AI-controlled heroes have issues with charge attacks without Turbo Mode (I pretty much always play with it On), but the listed fix to their charge attack behavior is Turbo Mode specific.


Edit: Added new version to this post.

hmsong, I'm hoping you'll check that there aren't visual side effects to the Dust Flare high level spell color, for example, that it doesn't cause other fire spells to have the wrong colors. I did some quick checks and it should be okay, but I ran out of time today to be thorough.

[hmsong]

@Queue

I just tried them (including all other Salamando and Gnome spells).  They work great.  Thank you.  Truly awesome.  It's a beautiful work, thanks to you.

The high level animations were in bank 1C?  Dayamn.  That's way off from where I thought it was going to be.

Btw, which color of Dust Flare do you like better?  Brown, or Yellow+Black?

[Mr X]

There is this weird thing that sometimes I trigger where when I check the status menu for the hero it turns permanently blank and his name vanishes except the first letter, for the rest of the game from the moment that gets triggered.

 Basically except the first letter of his name and the stats on the right, you cannot view the orbs, exp, gold and all that, but it is shown just fine when it comes to the Girl and Sprite.
November 28, 2019, 10:19:06 am - (Auto Merged - Double Posts are not allowed before 7 days.)Another thing regarding the Boomerang even tho I used a charge attack it was doing the same damage as the regular attacks.