[crossfire] TODO list items.

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:
> I won't comment on the priority, just other things :)
> 
>> Better NPC logic				1.x?		1
> 
> Can be scripted. I'm no mapmaker, but if someone gives me the flow of the 
> dialog I can write the script.
> I could look at adding utility functions to help write such dialogs, too.
> (Daimonin does that, I think)

  I think for NPC logic, it should be termed monster logic really.  I think that 
is what it is talking about.

  So what I'd see if monsters being smarter on what attacks they choose, finding 
a path to the player (right now, I think they just pretty much do a straight 
path logic, so easy to duck around a wall and never have them get to you), 
sensibly use healing spells, etc.

  OTOH, some of these depends on other issues - as long as monsters have 10x the 
number of HP as players, most healing spells will be pretty pointless for them.

> 
>> Newspaper (script based)			1.x?		3?
> 
> Can already be done, but no one actually did it...
> (may require scripts to access timeofday stuff, but not that hard)

  Probably also needs more detail in terms of what information it will actually 
present.  As it is now, it is relatively vague in terms of what it would do.

> 
>> Player clothing (image change based on clothing) 3.0		3?
> 
> Would require many graphics artists, though, and already many things to redo 
> first :)

  Which is why I put it as 3.0.  And at some level, given the relatively small 
image sizes, might be really hard to distinguish (most if the images for actual 
equipment uses the full 32x32 pixels, and thus just can't be overlayed on top of 
the image for the characters.

  A perhaps easier thing would be using different color channels (or whatever) 
so that the color of clothing could be changed - eg, you get a new color key to 
use.  So you don't need seperate images for a red mage vs a blue mage, just a 
different color key.

  The problem is that has to get communicated down to the client, which means 
revising the protocol.  And, unlike animations and smoothing, which are 
basically image/archetype attributes and only need to be sent once, color keys 
(or clothing changes) is an object attribute - could have bunch of different 
mages currently in the game with different colored garb.

> 
>> Time of day based events			2.0		2
> 
> See newspaper :)

  Depends on the level and commonality of the events.

  The most basic use of this I would see would be exits (shops) closing at night 
and opening during the day.  Could be certain places (taverns) that only open at 
night.  Scripts could be used for that, but sort of back to some previous 
things, if we are looking to use that a lot, may make sense to have an easier 
hook (or need common scripts, so that you don't need need to write a custom one 
for each shop).

  Secondarily would be NPCs saying different things.  I think scripts may be 
needed for that.

  Also, having the different connected values based on time.  It would make 
sense that the scorn gate is open during daylight hours, but closing during the 
night.

  But like a lot of these, exactly how it is done isn't as important.  If these 
can be easily done with scripts, thats great, but those scripts still need to be 
written, tested, etc.

  Saying it can be done with scripts isn't that much different than saying 'it 
can be written in C code' - that code still needs to be written :)

> 
>> Make slaying more consistent			2.0		2
> 
> What do you mean by that?

  From the TODO list:
Slaying is sloppy in that it uses strstr.  This, an item that has 'slaying
giant' (like holyword of mostrai) will kill ants.  strstr matching was most
likely added to support comma seperated slaying lists (slaying demon,undead).
However, the code should really insist on exact matching, and if necessary
break apart the comma seperated list.  Probably best to make something like a
'does_slay()' function which can be used all over the place (consistent
behaviour is a good thing).  If performance for this becomes an issue, making
a slaying a set of pointers could be done (char **slaying), and it gets filled
in at load time, and at save time, gets filled in the opposite direction.
However, from a simple basis, a check in does_slay() can be done to see if
slaying does contain a comma, and if not, just do simple strcmp, and only if
it does does extra work need to be done. MSW 2003-03-28

> 
>> discrete attack damage (dam_fire, dam_cold.)	2.0		3
> 
> Hu?

  Right now, if you have a weapon that has attacktype physical & fire, and dam 
40, it will do dam 40 of whatever attack works best against the creature.

  It is fairly common in most games that extra attacktypes do some extra damage. 
  Eg, this weapon does 20 physical damage and 10 fire damage.  There isn't any 
way to do that right now (ok, maybe with scripts :), but that isn't really the 
point here).

  The effect of the unified damage in crossfire has some bad effects - for 
attacktypes which are really affects (paralyze, slow), the duration of the 
effect is determined by the damage.  The problem this gets is if you have a 
weapon that does physical + paralyze, it is hard to balance the damage (the 
paralyze effect could be too strong in order for the weapon to do a reasonable 
amount of physical damage, etc).

  If those are separated out, it allows much finer tuning of objects.  It would 
actually lower the power, as a weapon that currently has physical + fire with 
dam 30 should be changed so that it's dam_phys + dam_fire = ~30.  For sake of 
argument, lets say it is an even split of 15/15.

  If your using that weapon fighting fire resistant creatures, you'll still do 
15 physical, but much less fire.  So I think it would make it less clear what 
the best weapon to use would be - right now, the more attacktypes a weapon has, 
the better basically.