Mark Wedel wrote: > This should probably be taken to the next step, with the client providing > some > nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client > would then present list of possible items (based on client type attribute) > and > list of spells, and player chooses. > > Of course, the client still has to send the actual request to the server, > and > the server would still have to validate if it works. Thinking about this, > the > logic for this on the server side could actually do most of the work with > very > little changes. Eg, client does something like: > > C->S: inscribe <scroll tag> <spell name/identifier> > > The server side command for that could find the object of scroll tag, save > away current marked object, mark the scroll object, store away current ready > spell, ready new spell, call inscribe code, and then put back the marked > object > and ready spell. > > OTOH, would probably be better for the inscribe code to take the inscribe > to > object and spell object and just go from that, as that would be cleaner. > > I am really thinking, however, that having the client handle most of the > presentation of this is the better way to go. > Actually, I'd be inclined to do something such as a more general skill-usage protocol. Something like:
C->S: client_use_skill <skill name/identifier> [ob1:<object tag>] [ob2:<object tag>] [spell:<spell name/identifier>] [message:<text length><text>] Which could be used to make clientside menus for other skills and such things. Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
