Looking at MonsterData, it looks like cap and floor are the maximum and minimum values that attack, defense, hp, and experience can take. If we want to have 10000 be the default cap and 10 be the default floor, then we do this:
New monster #321 found in Manuel with name 'Striking Stocking-Stuffer Elf' image 'crimboelf.gif' attributes ='Atk: 0 Def: 0 HP: 0 Init: -10000 P: elf'
That seems perfectly reasonable.I'm sort of tempted just to support a Scale: ? notation to show this. Maybe we add new scaling monsters as Scale: ?, Cap: ? Floor: ? and consider the ? to be 0, 10000, 10 in code, with an unspaded note in Area Combat Data and monster stats, til the figures are firmed up.
I've thought about this. Here is what I think would do this for you:I'm sort of tempted just to support a Scale: ? notation to show this. Maybe we add new scaling monsters as Scale: ?, Cap: ? Floor: ? and consider the ? to be 0, 10000, 10 in code, with an unspaded note in Area Combat Data and monster stats, til the figures are firmed up.
Absolutely, I was by that time talking about the Location Details that come from AreaCombatData, and the monster stats that show in the relay browser. Definitely doesn't need them in monsters.txt.- Near as I can tell, if you are looking for Unspaded scaling monsters, that's all the info you need; why would you need an "UNSPADED" keyword in the monster stats, when the "?" means the same thing?
Revision 16185In revision 16184:
Code:Duplicate monster ID 632 : (warty pirate,golden ring)
Revision 16186I've thought about this. Here is what I think would do this for you:
- In monsters.txt, allow Scale: ? Cap: ? and Floor: ?
- When we read that, it remains as part of the Attributes string (visible in the .attributes proxy field of the $monster object) but is translated to the DEFAULT values when registering the monster
- When we see a monster in Manuel, If Attack is ?, then generate Scale: ?, Cap: ?, and Floor: ? in the attributes string which we use to register the monster. That will be handled as above.
beebee gunners 1077 beebeegunner.gif WANDERER HP: [ceil((max(min(MUS,10000)+ML,10))*15/28)] Def: [ceil((max(min(MUS,10000)+ML,10))*5/7)] Atk: [ceil((max(min(MOX,10000)+ML,10))*5/7)] Exp: [ceil(5/7*(max(min(STAT,10000),10)/4+ML/3))] Init: -10000 P: bug handful of honey (0)
moneybee 1076 moneybee.gif WANDERER HP: [ceil((max(min(MUS,10000)+ML,10))*.625)] Def: [ceil((max(min(MUS,10000)+ML,10))*5/6)] Atk: [ceil((max(min(MOX,10000)+ML,10))*5/6)] Exp: [ceil(5/6*(max(min(STAT,10000),10)/4+ML/3))] Init: -10000 P: bug handful of honey (0)
mumblebee 1075 mumblebee.gif WANDERER HP: [ceil((max(min(MUS,10000)+ML,10))*15/28)] Def: [ceil((max(min(MUS,10000)+ML,10))*5/7)] Atk: [ceil((max(min(MOX,10000)+ML,10))*5/7)] Exp: [ceil(5/7*(max(min(STAT,10000),10)/4+ML/3))] Init: -10000 P: bug handful of honey (0)
beebee queue 1080 beebeequeue.gif WANDERER HP: [ceil((max(min(MUS+20,10000)+ML,10))*15/28)] Def: [ceil((max(min(MUS+20,10000)+ML,10))*5/7)] Atk: [ceil((max(min(MOX+20,10000)+ML,10))*5/7)] Exp: [ceil(5/7*(max(min(STAT+20,10000),10)/4+ML/3))] Init: -10000 P: bug handful of honey (0) handful of honey (0)
bee swarm 1079 beeswarm.gif WANDERER HP: [ceil((max(min(MUS+20,10000)+ML,10))*.625)] Def: [ceil((max(min(MUS+20,10000)+ML,10))*5/6)] Atk: [ceil((max(min(MOX+20,10000)+ML,10))*5/6)] Exp: [ceil(5/6*(max(min(STAT+20,10000),10)/4+ML/3))] Init: -10000 P: bug handful of honey (0) handful of honey (0)
buzzerker 1078 buzzerker.gif WANDERER HP: [ceil((max(min(MUS+20,10000)+ML,10))*.625)] Def: [ceil((max(min(MUS+20,10000)+ML,10))*5/6)] Atk: [ceil((max(min(MOX+20,10000)+ML,10))*5/6)] Exp: [ceil(5/6*(max(min(STAT+20,10000),10)/4+ML/3))] Init: -10000 P: bug handful of honey (0) handful of honey (0)
Beebee King 1082 beebeeking.gif WANDERER HP: [ceil((max(min(MUS+40,10000)+ML,10))*15/28)] Def: [ceil((max(min(MUS+40,10000)+ML,10))*5/7)] Atk: [ceil((max(min(MOX+40,10000)+ML,10))*5/7)] Exp: [ceil(5/7*(max(min(STAT+40,10000),10)/4+ML/3))] Init: -10000 Phys: 50 P: bug handful of honey (0) handful of honey (0) handful of honey (0)
bee thoven 1081 beethoven.gif WANDERER HP: [ceil((max(min(MUS+40,10000)+ML,10))*.625)] Def: [ceil((max(min(MUS+40,10000)+ML,10))*5/6)] Atk: [ceil((max(min(MOS+40,10000)+ML,10))*5/6)] Exp: [ceil(5/6*(max(min(STAT+40,10000),10)/4+ML/3))] Init: -10000 Phys: 50 P: bug handful of honey (0) handful of honey (0) handful of honey (0)
Queen Bee 1083 beequeen.gif WANDERER HP: [ceil((max(min(MUS+40,10000)+ML,10))*.625)] Def: [ceil((max(min(MUS+40,10000)+ML,10))*5/6)] Atk: [ceil((max(min(MOX+40,10000)+ML,10))*5/6)] Exp: [ceil(5/6*(max(min(STAT+40,10000),10)/4+ML/3))] Init: -10000 Phys: 50 P: bug handful of honey (0) handful of honey (0) handful of honey (0)
That worked fine except for the wandering bees. None of those are listed as "scaling" - but all of them have formulas that look sort of like scaling formulas, but with weird multipliers.
Where did these come from? They clearly scale, but why do these, of all scaling monsters in the game, have to be expressed in non-standard formulae?
Since Manuel shows them as "?" monsters - i.e., "modern" scaling monsters - I'd prefer if we listed them as "Scale: 10" (or whatever), and did not apply the B adjustment to those monsters in particular. The B adjustment is already special hardcoding for us for this path only. I assume we could add a keyword - NOBEE, say - which would say "don't do it for this monster".They could be made into standard scaling monsters if we hard code skipping the 20% B adjustment for the stats/experience for them.
I'd like it if KoL would go and retrofit all the hardcoded monsters to use their standard "scaling" variables.