Re: Local hacks and projects...

[Rupert G. Goldie <rgg@aaii.oz.au>]

> From: Rickard Eneqvist  <eneq@Minsk.DoCS.UU.SE>

> Vick:	Small fix : Monsters with dam=0 doesn't do any damage any more.
>

 This is fine. 

> Vick:	When a character dies, all items with positive magic value
> 	are removed. (Ie good armor, artefacts etc.) This used to
> 	cause people with character backup:s (*necessary when considering
> 	all the coredumps..*) having lots of money from selling
> 	their multiple Stormbringers etc. Not so any more :)
>

 I've already commented on this, but I would make this a compile time option.
I prefer that people can't copy their save's or don't pick their stuff
up again if they do save (but then I'm a player-integrity weeny, so your mileage
may vary)

> Eneq:	Fixed pickup so it can be used by other objects (new field in arche-
> 	types PICK_UP <mode>. See global.h for more description. All objects
> 	that are carried by the monster will enter the map when it is killed.
> 

 This sort of thing is useful for getting us towards smarter monsters, but I
fear that if monsters are going to be picking up and even using (as described
later) objects, players aren't going to be finding anything in the maps
because monsters will be picking everything up. 

[stuff about having your own fonts and title bar deleted]

> 	Added a new field to the archetype definitions (I have done a lot
> 	of those lately :-) anim_speed <no> determines how fast the object
> 	switches face. I added this because I wanted a generator to animate
> 	rather swiftly but only generate monster slowly and therefore couldn't
> 	use speed. The <no> determines how many ticks should pass before 
> 	swapping faces.
> 

 This is good.

> Eneq:	Fixed pick_up so that objects are added LAST in an inventory unless
> 	there is other objects of the same type in which case they are
> 	added in a cluster. To do this I altered insert_ob_in_ob but I also
> 	had to alter drop.
>
 I would have to try it to make a proper judgement, but it sounds reasonable.
 	
> 	Added archetype-fields;
> 		no_drop		Can't be dropped.
> 		no_pretext	No "That is"... is added to the output at an
> 				examine.
> 		container <no>	Object is a container and can hold max no kg.
> 		bonus		Variable for diverse uses.
> 
> 	no_drop and no_pretext is pure, that is code has been added to handle
> 	them. container and routines to handle containers will be added 
> 	tomorrow the idea is that the characters inv is replaced by the
> 	container and then one can drop things on the ground close the 
> 	container and pick it up. 	
> 	The closing of a container is triggered by (1) A move. (2) The close
> 	container gadget is selected (This has no_drop and no_pretext defined)
> 	this resides always at the top of the containers inventory and is added
> 	when one applies the container and removed when one closes it. 
> 
 Containers sound good, but again I would want to try this one out. I'm not
entirely sure I grok it totally from your description.

> Vick:	Added two archetype flags: <will_apply> and <random_movement>
> 	'will_apply' contains information about which objects the
> 	monster will try to apply. Added a monster, the gnome, to use
> 	these features. It currently pulls all handles, opens doors and
> 	tears down earthwalls. In due time, this will be expanded to allow
> 	monster control of scrolls and wands.
> 	It also features 'random_movement' which is a semi-random movement 
> 	type. When set to 1 the monster will move in the vincinity of a 
> 	player, but not in a determinstic manner. (Ie harder to hit)
> 
 This is good and bad. It adds new variety into the behaviour of monsters,
but the player now suddenly loses control of the map. If you are using
handles to control puzzles you really only want the player to be choosing
which handles to use. What is the opinion of your local players of having
a gnome in a map ? I would be really careful about adding such a monster to
any map, as it changes the map quite considerably. 
 I am planning to write a move_friendly_monster() routine, and once I have
a little more free time a move_smart_monster(). pick_up and will_apply will 
be really good for making smart monsters.

> Mol:    Added a new archetype can_apply <number>.
> 	At the moment it behaves just like Eneq's pick_up, i.e. it will 
> 	immediately apply objects it has picked up.  I will modify it to make 
> 	conditional applicaton of objects possible (i.e. monster reads scroll 
> 	of large fireball when a player approaches).

 Again, monsters applying things change the game dramatically. I would be
really pissed if a monster grabbed and used up all the scrolls, potions,
amulets, etc before I got to them. (Of course that's enough justification 
to have carefully placed monsters which do that 8)

> If there is some things here that violates any personal beliefs I don't mind
> getting comments.
> 
> /Eneq

  Well, there's tons of comments from me,

Rupert

--
Rupert G. Goldie, rgg@aaii.oz.au