On Thu, Jul 01, 2010 at 02:26:15PM +1200, Ralph Versteegen wrote: > On 01/07/2010, James Paige <[email protected]> wrote: > > On Wed, Jun 30, 2010 at 01:58:44PM +1200, Ralph Versteegen wrote: > >> I was recently helping Jeremy with a script which walks NPCs through a > >> step-on NPC. which required tags to temporarily remove that NPC. > >> > >> It seems obvious that we need a simple way to allow NPCs to walk over > >> step-on activated NPCs. A simple "does not obstruct other NPCs" bit > >> would be easy. But then I wondered whether this bit could be > >> generalised. What if you want any NPC to be able to walk over NPC ID > >> 1, but only NPC ID 4 to be able to walk through NPC ID 2? Or perhaps > >> you want to limit an NPC's movement by boxing it in with step ons, but > >> allowing other NPCs to wander through. > >> > >> We could come up with something similar to vehicle passability options > >> (except actually working, of course :). Does anyone have any ideas for > >> a good balance between flexibility and simplicity? > > > > I think I would prefer a simple "does not obstruct other NPCs" bit. That > > will be intuitive, and it will cover the most common use cases. > > Hmm, Jeremy wasn't keen on anything more complex either... > > OK, new suggestion, give each NPC 3 bits: > -does not obstruct, and not obstructed by other NPCs or heroes > -not obstructed by walls > > I wanted to add commands to suspend an individual NPC, and to suspend > obstruction or walls for that NPC, so this would just add bits to NPC > definitions to correspond to bits on NPC instances.
Cool! I like that plan. > (Notice we could add a "does not obstruct heroes" bit, and > automatically set it if the activation type is step-on, but I can't > think of any use for it) Hmmm. The advantage of that would be the ability to make an NPC the hero can walk over but that is still activated in the normal "use" way. Could be interesting, but certainly not essential. > > If we want more detailed NPC collision control than that, then we might > > want to have an if-npc-collides plotscript trigger, that would return > > true if the collision should obstruct, and false if it should not. > > Oh! I totally forgot about these kinds of scripts, which will not be > allowed to wait. Seems the Multitasking Plan is still incomplete... A wait would be a bad idea here, although I am not sure it should be strictly forbidden. You are probably also thinking about damage calculation scripts, or accuracy scripts, or level-up formula calculation scripts. None of those should normally contain waits, but there would be situations where it should be okay. For example, when level-up calculation is based on your success in a slot-machine mini-game, or when attack damage is modified by whether or not you accurately type a word. Although in the case of NPC collision checks, it is pretty hard to imagine a game that would want an interruption every time that happened. --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
