Contest: Name my upcoming combat script!

[zarqon]

Oh. Taking damage in "<element>form" is already handled, but you're right that it doesn't convert all damage you deal into the appropriate type. I've added that locally, will test it and then upload the current fixes here.

 

[heeheehee]

I only brought up the critical thingy because it's an auto-hit, sorta like how a fumble is an auto-miss -- if you're factoring fumbles into the chance-to-hit formula, might as well do the same with criticals.

 

[Winterbay]

The last few days I've been receiveing an interesting error while using fight.ash as reported here.

I've looked at the code but can't seem to find anything that would generate that sort of +-3 weight error. The error goes away if I rename the script (called it fight.ash.inactive) so it seems to be the source of the problem.

 

[xKiv]

dmg_throwables -> goodfella contract uses both 3*weight and -3*weight ; should probably by 3*fweight and -3*fweight, as fweight is what's used in dmg_familiars
there are probably other invalid modifier expressions in those dmg_* files

 

[zarqon]

@xKiv: Thanks for debugging that. You're halfway there... now upload a fixed dmg_throwables.txt to the Map Manager, and problem solved! Cases like this are the reason those files are now publicly editable.

 

[xKiv]

Cases like this are the reason those files are now publicly editable.

I didn't know that.
But it looks like somebody uploaded a fix already?

 

[slyz]

Just a quick question:

sort opts by monster_kill_rounds(dmg_dealt(value.dmg))*max(1,-value.meat);

Sometimes, cheap plinking methods won't kill the monster before the round limit (or before you die). Were you planning on filtering out or re-arranging the options to take this into account?

I know that, apart from trying a lot of combinations, getting the cheapest sequence of options to use for the whole fight isn't going to happen, but I guess you had that in mind at some point. Any thoughts on how to take into account the number of rounds left? Simply spam the cheapest method that will kill the mob (sorry, monster...) before it kills you or before the rounds run out? And eventually update that each round so that some optimization can happen?

 

[zarqon]

Yeah, that's just placeholder sorting to impose some sort of order on the options. The actual eventual sorting algorithm will be far smarter, involving actual action trees.

 

[slyz]

I wish I knew more about complexity theory. Isn't this a NP complete problem or something? Will you be able to cut off branches of said tree?

 

[zarqon]

Sure, at each node, if the cost becomes greater than the current best set of actions, it won't pursue any further branches off that node. If it reaches the end (monster dies, you're beaten up, or round is 30) and the profit is greater than the current best option, that path will replace the current best option.

I've realized I'll have to add a kind of combat simulator to the code, to build semi-accurate action trees. Which is actually surprisingly easy now to do. This also means that I'll have a "macro" option in the code, which will submit the entire action tree as a macro.

 

[Bale]

Sure, at each node, if the cost becomes greater than the current best set of actions, it won't pursue any further branches off that node. If it reaches the end (monster dies, you're beaten up, or round is 30) and the profit is greater than the current best option, that path will replace the current best option.

I've realized I'll have to add a kind of combat simulator to the code, to build semi-accurate action trees. Which is actually surprisingly easy now to do. This also means that I'll have a "macro" option in the code, which will submit the entire action tree as a macro.

You got my underwear wet.

 

[xKiv]

I am still getting "modifier syntax error" sometimes, upping debug verboseness shows that eval is sometimes called for an empty string. I have no idea from where that happens though (which call to eval), I didn't have enough time to actually debug it properly.
(Anyway, is there some way to make mafia print ash "stack trace", prefferably without halting the script altogether? That might be useful.)

 

[fronobulax]

(Anyway, is there some way to make mafia print ash "stack trace", prefferably without halting the script altogether? That might be useful.)

You might find this post helpful...

 

[xKiv]

You might find this post helpful...

That's something, but I would rather have explicit function/command to print the current stack, without enabling debug in the preferences (and the iirc-necessary restart of mafia; I don't want to restart mafia in the middle of my daily adventuring just because I decided to debug something .. and I don't yet want to have debug on preventively for all my mafiaing)

ETA: or maybe I am mistaken and debug can now be toggled at runtime?

debug [on] | off start or stop logging of debugging data.

 

[slyz]

Nope, no need to restart.

 

[xKiv]

OK, I think I found one problem ... dmg_throwables.txt, rock band flyers - no data. What should be there? 0 none none?

 

[zarqon]

Flyers should actually be removed from the throwables file, since FTF handles them before BatMan needs to make any decisions.

 

[xKiv]

OK, removed.

 

[Sputnik1]

So what's going on with the script, Zarqon? I was just wondering since its been almost a year since the beginning of this script.

 

[Banana Lord]

Aside from being curious about how far away this is from release, I haven't seen any mention of free runaways. Will BatMan be able to flee in terror and complete safety?