Fixed dungeon generation (by retrying), fixable sumo house (thru DevCons cmd), etc.

[AquariusPower]

Fixed dungeon generation about "invalid config sought" that would ABORT; Added a dev cmd to fix the over crowded sumo house; Added some command line commands, environment variables and a --help command, mainly for developers; The environment variable can be used to test the dungeon generation many times, default is 250 times. Fixed crafting a item that breaks and has no BROKEN config; Fixed developer console to use festring and more reliable MACROS; Added many new commands to developer console;

all copied from https://github.com/Attnam/ivan/pull/587

[ryfactor]

@AquariusPower these DevCons commands are quite cool. I've been playing around with generating the dungeons, and they seem to generate normally. Do you have a savefile with bad dungeon generation I can test? I still need to get around to testing the Sumo House fix.

[AquariusPower]

@AquariusPower these DevCons commands are quite cool. I've been playing around with generating the dungeons, and they seem to generate normally. Do you have a savefile with bad dungeon generation I can test? I still need to get around to testing the Sumo House fix.

I think I may not have documented this well, the below steps should be in the developer documentation!

To test "retry dungeon creation" run this: IVAN_DebugGenDungeonLevelLoopID=43 IVAN_DebugGenDungeonLevelLoopMax=500 ./ivan

• start a new game
• enter the first dungeon cave
• enter wizard mode
• teleport to crystal caves (type "|" "4")

It will start to recreate that dungeon 500 times in a loop, to let help it crash randomly. It will exit the game as soon the test ends To see how many times it retried already run this tail -F ~/.ivan/.ivan.dbgmsg.log| grep "fsGenLoopDL" (TODO: these retries could be shown on the terminal tho with printf) Beware, the 500 loop test will require 1.6GB free RAM because of the memory leak bug when deleting/de-allocating a dungeon from RAM memory.

Obs.: that dungeon level was created 500 times w/o a problem right now! what is good news!

[ryfactor]

When testing FixSumoHouse with the situation depicted in the accompanying image, it doesn't fix. Might need to get the algo to teleport any BG standing in the doorway as well. To get bananagrower to stand in the doorway, I got the player character to stand in the doorway first, eat pineapples up to bloated, wait for bananagrower to come, eat some more pineapple, then rUn to the downstairs and challenge Sumo when BG is standing in doorway about to deliver banana. Then win fight, come back and everybody stuck in Sumo house.

I wonder if it would be easier to drop all the spectators and combatants outside Sumo house and then the whole thing might be moot. Or maybe only allow the sumo fighting if there are no bananagrowers in the sumo house including the doorway.

[ryfactor]

I think setting FeedingSumo = false; for all bananagrowers on the level immediately after a Sumo wrestling match might cause them to drop their bananas in the bananadroparea. See: https://github.com/Attnam/ivan/blob/e91cdad23a0a7de069f7048bbc1d03a531e14d26/Main/Source/human.cpp#L3457

[AquariusPower]

I think setting FeedingSumo = false; for all bananagrowers on the level immediately after a Sumo wrestling match might cause them to drop their bananas in the bananadroparea. See:

https://github.com/Attnam/ivan/blob/e91cdad23a0a7de069f7048bbc1d03a531e14d26/Main/Source/human.cpp#L3457

If i remember it well, I think the workaround teleports the workers near the player, may be increasing the range could improve it also, another way would be to just teleport all workers everywhere. But the proper fix you suggest is much better overall :)

[AquariusPower]

btw, I generated the glowing caves about 3000 times w/o a problem. If I am not wrong, I think I found (or someone else did) the place the bug happens and fixed or workarounded the code there to prevent the "crash" (ABORT), that's why the generation in loop test shows no problems. Anyway, as I remember, there is a small retry limit in case it ever happens again, I think it is 5 or 10 retries, in a normal gameplay.

[ryfactor]

@AquariusPower I made a PR here on your branch: https://github.com/AquariusPower/ivan/pull/68 for the bananagrower fix

btw, I generated the glowing caves about 3000 times w/o a problem. If I am not wrong, I think I found (or someone else did) the place the bug happens and fixed or workarounded the code there to prevent the "crash" (ABORT), that's why the generation in loop test shows no problems. Anyway, as I remember, there is a small retry limit in case it ever happens again, I think it is 5 or 10 retries, in a normal gameplay.

Cool, I tried out your crystal cavern generation method as well and it works good. I'm happy with how it behaves.

[AquariusPower]

Might need to get the algo to teleport any BG standing in the doorway as well.

Yes, looks good too, in case your proper fix doesnt suffice. Not only where the player is, but also at the sumo house door location, it could look for, not only workers, but also for spectators as there are more than the ones on screenshot, despite I think the land lord (I forgot his name, with 2 red whips) should be skipped. Let me check the code, it is as I remember, a loop in all directions centered on player. I could just be an extra loop centered on sumo house door. And it would cover all problematic spots against workers and spectators/tourists overcrowding.

[AquariusPower]

https://github.com/Attnam/ivan/pull/597/files#diff-e5b9350766723578f4cecfd649c49124103519367bdf419f76f5541c35957d5cR5382 at FixSumoWrestlerHouse() now I see the check is centered on sumowrestler (SM, the old champion) and not the player... loops at SM->GetNeighbourSquares() I think we can use ->GetNeighbourSquares() centered on the door spot (may be that spot->GetNeighbourSquares()) and then teleport bananagrower and the tourists. Or just loop on all neighboursquares collected for each of the SM->GetNeighbourSquares() loop (overkill), but it is just a temporary workaround. Anyway, all that just in case the fix you proposed doesnt work for some specific case (like the screenshot that never happened to me :))