Re: [crossfire] IRC traffic for Sunday Oct 22
Hi all, my 2 cents to improve crossfire. On Tuesday 24 October 2006 15:39 Alex Schultz wrote: Gridarta Ideas: (Note: in Gridarta context, daimonin means Gridarta 4 daimonin, crossfire means Gridarta 4 crossfire, gridarta means code that's already unified and shared) -Better 'connection' (i.e. buttons and gates) interface. Perhaps even give the server new object types for boolean logic, and give Gridarta a flow-chart-like interface to that. Already on the way. Daimonin already has a connection view for that purpose. -NPC dialog editor -Understand @match syntax and the subset of regexp syntax Ay. -Warn users when they are doing 'the wrong thing', as in putting object on the map or in inventories that should never go there. -Daiminion already does this. Code just need to merge this code and make crossfire-specific rules for it. Yep. We will move this from daimonin to gridarta once the code used by this feature is similar enough. -Perhaps warn about connected object in inventories, because that doesn't work and could confuse map-makers. Dito. -but I think more importantly, it should be possible to create a crappy 'my first map' in 10 minutes or less - Cavehippo At least for daimonin that's possible, and I'd say so it is for crossfire. If you think it's not, please let me know what we can improve. Overall on Gridarta: I haven't read new ideas here. This shows some things: * I'm not communicating ideas good enough. Gotta publish more parts of my todo list, also keep information that's already in Daimonin's Mantis in sync with such todo lists. * We're on the right way. I/we see the same issues as the more professional (crossfire) gridarta users. * There still are some basic pressing things to get done (connection ui, npc dialog editor) before moving to more sophisticated features. * I now know which issues are most pressing for crossfire. I've added a todo list to the gridarta website: http://gridarta.sourceforge.net/dev/todo Cher :) -- Christian Hujer Free software developer mailto:[EMAIL PROTECTED] http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB pgpRmqjOYNTtX.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Gridarta concerns [was: IRC traffic for Sunday Oct 22]
(crossposting to the gridarta mailing list) Christian Hujer wrote: On Tuesday 24 October 2006 15:39 Alex Schultz wrote: snip -but I think more importantly, it should be possible to create a crappy 'my first map' in 10 minutes or less - Cavehippo At least for daimonin that's possible, and I'd say so it is for crossfire. If you think it's not, please let me know what we can improve. I haven't looked at gridarta4daimonin yet, however at least in gridarta4crossfire, there are few interface issue which I feel affect this. The current system of, left click to select, right click to insert and middle to delete, is IMHO not the greatest. It *is* a very fast interface to use, however I personally find it too error prone and also could be easier for new users. I personally would advocate an interface more like this: -Have a 'tool palette', and allow right, middle and left mouse buttons to have separate palette modes assigned to each at once. -By default, have left click as select and middle click as insert, and right as a new context menu. -Make an easy thing for resetting the tool selections to those defaults, possibly a lock option. -The context menu contains actions that can be done to the whole stack (i.e. cut, copy, paste, delete, select, insert) and also having submenus for each object inside it, for doing similar actions (i.e. cut, copy, delete, select) to that object alone. -Key bindings with the following defaults: -Delete key deletes objects (something I wish for regardless of if this interface is done or not) -Space bar inserts the selected object on the selected tile -Arrow keys move selection This system could be configured to be the same as the existing system, or more like what I suggest as a default. IMHO it would make gridarta much nicer to use to have such a context menu and to allow mouse button configuration and keyboard bindings. I'm not sure how many would agree with me on that, but that's my view on what would be a nicer interface. snip * I'm not communicating ideas good enough. Gotta publish more parts of my todo list, also keep information that's already in Daimonin's Mantis in sync with such todo lists. Speaking of Daimonin's Mantis, is it still in use for gridarta? I was under the impression that sf's tracker was considered the primary location for new gridarta bugs/etc. I'm not a gridarta developer (currently), but I do look at the sf tracker sometimes, and IMHO having both in use at once is a pain due to looking at two different places. Also, I personally wouldn't exactly be in favor of moving from mixed usage to Daimonin's Mantis either for the long term, because when viewing it's mixed around all these Daimonin bugs in many views. That's just my opinion though :) Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote: Another thought, perhaps instead of the else though, we could use the BASECLASS via another ob_methods structure as mentioned in a different mail, to implement the falling back to the old function. Not only is it well suited to falling back to the old function, it IMHO might prove a useful system to have in place for after the conversion is complete, particularly once getting into per-arch and per-object ones with plugin support. I personally wouldn't be overly concerned about neatness while in the transition. After all, it is a transition, and will eventually go away, so being too concerned about how it work doesn't make tons of sense. per arch/per object I think gets into some other issues. Registering them isn't hard - the more serious question is if those callbacks are in addition to the ones normally for that object, or are instead (or does something control that?). But that is a future discussion. I'd think for generic callbacks, it depends on its purpose. For the transition purpose, I think it'd have to fallback to a single function for all object types. I'd personally rather just see a call like 'apply_fallback()' type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 function for each type, it is easier to follow the code if you see exactly what the function is, and don't have to go look at BASECLASS to see what it is doing, etc. snip The previous example I had was about applying unpaid objects. I can't think of any case where that should be allowed, and if there was some specific reason, I think a flag on the object should control that, and not object type (as presumably, that object would have some behavior like existing objects). I think it is cleaner to have it like: snip (another different case here is dropping of damned/cursed objects - regardless of type, that shouldn't be allowed save for something special (DM)) Well, IMHO those dropping and unpaid restrictions should either be in the command code, or give the callback an 'override' parameter, because of the save for something special cases. Either works for me, but I am inclined against the 'override' parameter as it IMHO creates unnecessary complexity. I was thinking overrride would be determined by the object (or person) using the objects themselves. In the curse example, you could check the person unapplying it, and if the WIZ, let them do so. Sure, you could pass in parameters for that, but I doubt that is necessary In all these cases, that code will be someplace - it is just a question of where. For some things, doing it in the command code isn't ideal, because there are several ways for the command to be issued (some are processed by the client and sent as lower level protocol commands in addition to having text commands the player an use, etc) - in those cases, you want the check code in the function all of those call so it is in one place, not 3. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Protocol extension: exp table
For the client to do things like display scrollbars for exp totals (how close to next level, etc), the client needs to know the exp table the server uses. The following is my proposed addition to requestinfo/replyinfo protocol command. I can't think of anything more to add, but figure it is still a good idea to post it our here in case others have thoughts. exp_table (no parameters) This requests the experience table (what exp is needed for each level) from the server. With this data, the client can easily display how much experience is needed for the different skills or total exp value for next level. Data format: num_levels: uint16 - max level/how many exp values follow. level1 ... level num_levels: uint64 - amount of exp needed for the level. Note that num_levels and the actual exp values are transmitted as binary values. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
