Re: [crossfire] New crossfire todo list
Mark Wedel wrote: - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) Yes. When inscribing spell scrolls, one needs to do something along the lines of mark scroll-to-inscribe-over; cast meteor swarm; use_skill inscription. The change suggested there would make it so one would use something like mark scroll-to-inscribe-over; use_skill inscription meteor swarm instead. - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) Personally I don't think we want to go that route, however the suggested code re-orgs such as what I proposed a while back in the mailing list, would as a side affect make splitting the 'rules' and 'engine' easier, if at any point we decided we wanted to. IMHO we should do the code re-orgs and decide if we want to split the 'rules' and 'engine' after. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New crossfire todo list
Alex Schultz wrote: Mark Wedel wrote: - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) Yes. When inscribing spell scrolls, one needs to do something along the lines of mark scroll-to-inscribe-over; cast meteor swarm; use_skill inscription. The change suggested there would make it so one would use something like mark scroll-to-inscribe-over; use_skill inscription meteor swarm instead. 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. - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) Personally I don't think we want to go that route, however the suggested code re-orgs such as what I proposed a while back in the mailing list, would as a side affect make splitting the 'rules' and 'engine' easier, if at any point we decided we wanted to. IMHO we should do the code re-orgs and decide if we want to split the 'rules' and 'engine' after. And I'm not sure how much reason there is to split the rules and engine in any case. But if it is easy to do that, that could help in the testing actions perhaps. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New crossfire todo list
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 lengthtext] Which could be used to make clientside menus for other skills and such things. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
