Contest: Name my upcoming combat script!

Which is the best name for Zarqon's upcoming combat consult script?


  • Total voters
    60
  • Poll closed .
Changing that to ftf() would be interesting. Perhaps desirable, since all of the actions which FTF handles (olfaction/putty/special items, etc) are deliberately missing from BatMan. I'll give it a go on my end and see how it works out.

EDIT: Oooh. I like it a lot -- it's like a hybrid of consult and relay play. I'm a Sauceror right now and it basically keeps my HP topped off during combat without me ever casting Salve. I wouldn't recommend you make this change though unless you are prepared for some glitches -- FTF was designed to run once at the beginning of combat, not every round -- first things first, then first things second, then first things third, and so on.

Haha, I also had a funny issue where FTF won the fight by using the phylactery, but the first round page was served to the browser anyway. When I tried to use the phylactery, I was redirected to the main map. "???" I thought, until I looked at the CLI. :)
 
Last edited:
I tried playing with the css and ... it looks like the "display: block;" lines in "html>body thead.fixedHeader tr" and "html>body tbody.scrollContent " make each row count as a .. kind of subtable?
So it applies the 20% width that is set for first column ... to all the columns together O_O
Removing those two lines from the CSS fixed the problem for me.

ETA:
Ooooh ...
display:block ... will generate a block box (a line break before and after the element)
display:inline .. will generate an inline box (no line break before or after the element). This is default
display:table-row ... The element will behave like a table row (default for tr)
...

So. Table elements *must* have display set to the correct "table-" value or they behave like non-table elements (div or span). Even display:none stops width from propagating from thead to tbody
(but then, width should be set using <colgroup span="2" width="20%" /><colgroup span="6" width="10%"> here (between <table> and <thead>).

And if you want to have some vertical space between the header and body, you will need to ... do something else, like inserting an extra row with borders set to none ...


ETA2:
.. first things third ...

and finally first things win!
 
Last edited:
I don't actually want to specify width -- I'd prefer that the browser handle it, so that it can be as wide as the user's available space. I merely tried the percentages as a way of preventing the <th>'s from being squished together on the left, and it semi-almost-worked (still all over on the left on a very wide screen).

Removing the "display: block" as you mentioned solved the cells lining up problem but created a new problem: there was no longer any scrollbar. Removing only one of them meant that the entire tbody was lined up under the first <th>. ???
 
Hmm. After some more googling, I must conclude that eighter the W3 guys didn't think this through, or no browsers are css compliant.
The w3 TR I read explicitly states that TBODY elements are there to "allow visual agents to scroll parts of the table separately", yet you can't enable scrolling on the element without also making it block-level element, which makes it non-table element, which means it doesn't work properly in tables (ETA: because, as per the specification, the browser must insert an implicit TABLE element between the offending non-table TBODY and its table-row content).
>_<
Also, all the "scroll only data part of table" examples that I have seen working actually use absolute positioning on both TH in THEAD and TD in TDATA ...
 
Last edited:
Well, looks like the table has to be inflexibly sized then. You'd think after this much development has gone into the web environment, there would be a HTML/CSS method to display a scrollable table without a fixed width! Geez.

Thanks a lot for researching that, xKiv.
 
You *can* have scrollable table, just not scrollable table body.
Or you can do it as two tables, let the data-table render, then use JS to adjust columns in the header-table. I had to resort to that once. Bleah.
 
Been playing around with fight.ash for a while now and it is certainly interesting, though I cannot recommend it to anyone with more than 10 combat skills since the number of options quickly becomes overwhelming. Of course, the optimal strategy is still noodle-butting, most of the time. Kinda makes me wish I hadn't permed all those combat skills. ^_^;;

As a pastamancer it is kinda neat to see the damages for all my skills and know exactly how much it will take to kill a given monster. Then my damage almost always comes in slightly below the expected average and the monster fails to die on cue. Ouch!

At the moment I still have to put together my own combat strategy out of those options. Looking at it, it makes me wish that it could automatically assemble those skills into a combat macro for me. :heh: Have you thought about creating an employ version of this script, or are you only doing a consult version?
 
@xKiv: would JS work for sizing the <th>'s after the <tbody> renders?

@Bale: hehe, yes, the table needs some help. Basically, it's just too dang big, but I'm not sure how to compact it further. I don't want to remove items from the list, even if they do nothing, because a person might think that the script skipped it, or they might want to confirm that a certain item does nothing vs. a particular monster. That's why it's sortable, by a fairly comprehensive range of criteria. It's come in very handy for me when fighting stronger monsters without preparing -- for instance, if I need to restore HP/MP during combat it's ridiculously handy, or when mafia's ML data is missing for a monster and the estimated attack damage is way off, and I need something else that deals damage, or when I want to delevel a monster just a little bit but don't have any deleveling skills.

Of course there will be an employ version (assuming by "employ" you mean "perform"); eventually, clicking the action will perform it. There will also be a button "BatMan's Choice" centered above the table which will always perform the top action in the optimally-sorted list. But your talk of macros starts to give me lots of crazy ideas.

1) in addition to clicking the action to perform it, a "perform indefinitely" button for each action. Anyone want to save me the work of researching the URL to submit for that? I'd assume it's different for skills vs. items vs. attack...?
2) perhaps! an action queue, much like eating/drinking in mafia's Item Manager. You could cue actions and it would keep a running tally of the predicted outcome -- then you could click "execute" and it would submit the macro for the whole combat.

That second one is a lot more JS than I'm willing to tackle for a good while though -- and first I've got to hammer out the sorting algorithm. I've basically got it figured out, but it will be a lot of foreaching and number crunching, especially in aftercore, and especially especially with funkslinging.
 
I think with "employ" what is mean is the new type of mafia-script calls that calls a function that builds into a macro, much as a consult script works today.

Also: The damage calculation does not seem to take into account elemental allignment for the monsters. I am currently fighting "a shaky clown", sleeze aligned, and the text for my PM shurikens still show the same amount of damage for each type of element. Is this intentional?

ETA: Also also, it does not seem to take my ghost summon into account as a possibility. (just throwing out ideas) :)
 
This table displays raw, unresisted damage -- but it should display adjusted damage (resistances/vulnerabilities included, maximum remaining monster HP) right afterwards, where it says "Actual: N".

I've discovered using this script that Lord Spookyraven is not actually spooky aligned? At least, my love song didn't do double damage (as predicted) against him. That seems suspicious. Did I build resistances right?

PHP:
typedef float[element] spread;
spread get_resistance(element which) {
   spread res;
   foreach el in $elements[] res[el] = 0; res[$element[none]] = 0;
   if (which != $element[none]) res[which] = 1;
   switch (which) {
      case $element[hot]: res[$element[spooky]] = -1; res[$element[cold]] = -1; break;
      case $element[cold]: res[$element[sleaze]] = -1; res[$element[stench]] = -1; break;
      case $element[spooky]: res[$element[cold]] = -1; res[$element[sleaze]] = -1; break;
      case $element[sleaze]: res[$element[stench]] = -1; res[$element[hot]] = -1; break;
      case $element[stench]: res[$element[hot]] = -1; res[$element[spooky]] = -1; break;
   }
   return res;
}

And what?? There's a new type of script?? I've not even looked at macros yet -- I'm in another one of those barely-have-time-to-play modes for a while.

Ghost summoning is handled by FTF, so it's left out of BatMan. However, BatMan should include the effects of already-summoned ghosts in its calculations.
 
@xKiv: would JS work for sizing the <th>'s after the <tbody> renders?

That should work, but I can't say anything better right now.


ETA: I just noticed ... this script always divides (in to_spread) expected damage by number of damage types, but doesn't yet handle the possibility of tuned damage (flavour for pasta spells, immaculate for sauce spells, some items that force spell damage type, element-forms for everything, ...)
 
Last edited:
Just a couple of suggestions:

- they will have to be hardcoded apparently, but taking into account spell alignment from cookbooks, Flavour of Magic and Immaculate Seasoning can make a big difference
- I was in BM, where lust left me with a negative Weapon Damage (a simple max(0,numeric_modifier("Weapon Damage")) takes care of that?).

EDIT: oh, and what i think is a bug...
Monster: Possessed Wine Rack (ATT 163.0, DEF 168.0, HP 170.0)
Will hit 94.0% of the time, dealing 43.42 damage (40.82 DPR).
You have a -418.18% chance of hitting for -2.82 damage (0 actual)

the -2.82 must come from my -5 weapon damage, and my buffed muscle is 87 (with the staff of the soupbone equiped).

I think the return value of hitchance() should be:
PHP:
return minmax((6.0 + attack - max(monster_stat("def"),0.0))/10.5,0.0,1.0) * (1.0 - fumble_chance());
 
Last edited:
Shouldn't there also be something to account for criticals?

They're a fairly important part of speed softcore if you have a vivala mask. I've been wondering if this script would make any effort to consider vcrisis. As a starting point, I suppose it would have to know how much meat you're willing to spend for those 4 substats.
 
I believe this was the post. To be fair, it's just an alpha version of the relay script, and so it's not quite perfect yet. Trust Zarqon to have it down after a few edits, though. :)
 
@xKiv: tuned damage for pasta / sauce spells is on my to-add list. The tricky part is that some of the spells can't be tuned. And what did you mean by "element forms for everything"?

@slyz: good catch on those lower bounds checks. I'm not sure why your hitchance was so low... I'll take a look at your proposed edit when I get come from work.

@heeheehee: This script doesn't do anything with criticals other than averaging them into your regular attack damage. And even that needs some fleshing out -- currently the script merely assumes unmodified critchance. I recall not being able to figure that out when I was writing it.

I suppose we could create an oncrit event -- containing special things that happen when you get a critical hit. But do any of those affect combat decisions? (I mean predictively; obviously, after a critical hit, you need to do less damage than previously expected to kill the monster, but BatMan is already aware of that since it recalculates every round).

@ammy55: It was not released anywhere. I'm just asking for some help debugging and making the information more accurate, so I posted an alpha of the relay script. Use it at your own risk/inconvenience.

@lostcalpoly: since BatMan takes a profit-driven approach, it doesn't consider stat gain; stats are very problematic to convert to meat. It's not even a part of the data files. So the script will not consider stat gain -- although the stat gain from monsters can be considered a part of your valueOfAdventure setting, which the script considers part of the cost of losing the combat.
 
@xKiv: tuned damage for pasta / sauce spells is on my to-add list. The tricky part is that some of the spells can't be tuned.

The items and skills that align spells are commented in modifiers.txt, so I guess those would already need to be hardcoded. Immaculate Seasoning and Flavour of Magic only affects sauceror and pastamancer spells respectively, and I can't think of a way to tell if a spell is a sauceror/pastamancer spell other than hardcoding that too. With everything hardcoded, not tuning specific spells is easy =)

@lostcalpoly: since BatMan takes a profit-driven approach, it doesn't consider stat gain; stats are very problematic to convert to meat. It's not even a part of the data files. So the script will not consider stat gain -- although the stat gain from monsters can be considered a part of your valueOfAdventure setting, which the script considers part of the cost of losing the combat.

Let optimizers worry about stat gains for themselves, they know what they loose if they get beaten up. Stats are managed on different scale than resources (not on a per combat basis), and BatMan can concentrate on helping with in-fight resource management only.

V-crisis management would need pre-combat preparation I guess, and could be the focus of another, specialized, script suit.
 
And what did you mean by "element forms for everything"?
The "Hotform", "Spookyform", etc ... effects, which force all damage caused by the character to be of one element type (and damage taken to double/one-i-fy according to element).
 
Back
Top