Re: [crossfire] Food consumption
Kevin R. Bulgrien wrote: Mark Wedel wrote: Kevin R. Bulgrien wrote: I am running an x86_64 test server with an Opteron processor. Food consumption seems unreal... I never played Gaea before... That's what's doing it. Regeneration +2... Man, I need to carry a refrigerator around with me... :-) A separate discussion could perhaps be change food consumption rate. High food consumption just means you carry around lots of food - not much other affect. Hmmm... Well, food beep seems to not be working again... Lately I have been working on maps with my client up and running, and have died quite a few times due to starvation because the warning seems to not work anymore. It has been patched ages ago, but I guess something has broken it again. Looking at the code, I don't see anything odd with the foodbeep code. Also, the poor halfling cannot carry very much weight, so has to resort o eating carcasses... blech... in a dungeon crawl. He is not nearly high enough level to have create food, town portal, and the like. Not complaining here so much as saying its not quite as simple as carrying lots of food. IIRC, carrying capacity is directly related to strength. Of course, halflings have a strength penalty, so that doesn't help. I don't think that is true. The 3-1 rates mentioned in the original post were standing around doing nothing. That's what limits you. Now, is it more real? Probably, but it isn't scaled well with the other characters. Which is maybe a decent question - the regen rate for Gaea is seen as an advantage. I don't know if the high food consumption rate was factored in as a disadvantage, or is an unintended side effect. And in some sense, having it as a granted ability from Gaea is a disadvantage, in that you can't turn it off. For other character, you can just take off the ring of regeneration and be back to normal food consumption. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Alex Schultz wrote: -If you try to make a keybinding over a key that is already bound something, it shouldn't just append to the list, it should warn you and if you choose to continue, remove the old binding first. Yes - that is a valid point - overbinding a key doesn't make sense. But it gets a little odd with modifiers. -One idea that might be good, is while it is waiting for you to press a key to bind to, it should come up with a graphical display of the keys on the keyboard, and with color coding showing which keys are already bound. Tooltips when hovering over a key show what is bound there and clicking a key counts as if you pressed that key. I don't know if there is a widget for that or not. That is not something I'd want to have to write ourselves. We just can have a universal looking keyboard - after all, laptops, different keyboards, etc, can have different layouts. Inventory control via keyboard: I'd be interested in how people think that should work - I really can't envision much any reasonable way to control the inventory only by keyboard, whether we use gtk2 widget or write our own. I'd personally consider this to be a pretty low thing to do. Personally I think this would make a big improvement if it could be pulled off in a reasonable manner. The best I've seen for keyboard inventory control in large inventories, would be how nethack does it even in it's gtk interface. That keyboard interface might work well if we used popups, however see the popup issues above. One could do something though with giving focus the inventory list and allowing keyboard scrolling of it and pressing keys to apply from it or drop etc. however one would need to make it VERY obvious to the player when they have focus on that, and also would have to make it very difficult to accidentally trigger while easy to trigger manually (and for fairly obvious reason I don't think focus on click would work well for it...) A valid question may be whether the inventory interface should be completely redone. The mouse buttons I believe kept what was used in the old X11 client. I don't think the current button presses conform to what people would expect from a GTK application. I'd say that a single button press being the expected behavior is not standard. What comes to mind could be something like this: Left click selects an item. A double click applies the item (most common operation). Double middle click drops item (second most common operation?) Right clicking on a selected item brings up a little pop up menu on additional item actions (drop, lock, apply, examine, mark, etc). I think that is better than having these odd shift and control combos. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
A nice thing would be to have a generic client, with an interface layer. This way we could apply different interfaces while retaining a common layer. Think something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest to use that language for the interface). Maybe with a widget system? Let users write (in Python? LUA?) their own displaying widget to display game information? The problem/complication is that at some level, the UI becomes a pretty major portion of the code. And it probably makes more sense to spend our time to just get a good, thorough working client with (for lack of better term) hardcoded toolkits and not have some scripting writing language that no one really uses. Now an intersting side point to this is that the gtk2 client uses glade for all the layout. In theory, someone could write a new glade file/description, and as long as all the widgets remain the same, could just be dropped in place. This in fact may be the thing to do relative to high and low resolution clients - rather than trying to have layout to cover everything, having two glade files might not be that unreasonable. Now I do think the current code may need some additional work. In such a model, I could certainly see some versions not implementing all the widgets (for space reasons, whatever else). That can easily enough be handled I think in the code to make sure the widget isn't null, but that checking isn't there right now. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
