Re: [crossfire] GTK V2 client default layout and map size
Quick thoughts/past notes: I expect that the preferences will be driven a lot by what actual hardware folks are running on. If you only have a display that does 1024x768, then the Oroboros is the likely winner. But if you have a higher res display, that probably isn't a first choice, as you have a lot more display area than it uses. I'm not bothered by that, and it actually is in the spirit of making the game more accessible anyway. I'd consider setting it as the default without even taking a vote. Why should not the majority get their choice anyway - even if it isn't your or my favorite? Now it may be that the client should try and be smart and choose a best default layout based on various factors, like screen resolution. Same could be said for things like map size. A better approach may be to have a basic configuration program (or window) that is used first time client is run by user (no .crossfire file). A fair number of commercial games use that approach - configure the display resolution/quality you want to use, configure sound, etc. That, however, is a fair amount of work, and ideally, the configuration dialogs used within the client match those initial configuration ones (don't duplicate code, but also easier for an end user perspective - if you see one set of configuration dialog the first time you run it that doesn't match the one you see later, may be harder to know what config options you used before, etc) If a user supplies a layout, it could get really hard to have all the necessary information where it would all work just right. It does make sense to pick Oroboros automatically on desktops at 1024x768 or lower. 1280x1024 and higher have always been supported on this client, so auto-picking once in that range seems not to buy much advantage, and none of them default to sizes that won't fit at all on that resolution. On IRC, people seem to be saying that 800x600 is still alive and kicking too. I figured I'd hammer a bit on Oroboros to get one option at that size, so having one of those to pull out of the hat if someone launches it on a small desktop might be good. As for a configuration program, what I can see is showing thumbnails of clients and let people browse them, along with the text descriptions, possibly calling out the default size of the layout separately. Doing something like that, you could advise against certain layouts based on the desktop size, but could allow them to be selected anyway if they want to try to deal with the resizing. That said, I think it needs to stay simple, but even so, presently there are better ways to spend a lot of development time. People still complain too much about what isn't there, and a configuration program won't address what gets complained about the most. Then... there is the whole thing about making the map size coincide with a selected layout... Right now it is difficult to know what to set the map size too. A first effort to address that is probably due quite high priority. You can totally hose a layout by using 25x25, which is the current default. I think the default map size should be a low common denominator unless new features are added to hint map size settings. Note that one reason I put the map window in the upper left corner is that to some extent it made using different map sizes easier. But I do have to say I don't find it ideal either (but I'm not sure what I find ideal). There are two options in the screen shots. Some that put the map on one side, and others. I'm also not wild about the way the stats are displayed in all the layouts (which really isn't changed) - that is to say being in a single row: Str 5 Dex 6 Con 10, etc as that never seems really easy to find for me, and I can't think of any other game that displays them - doing them as a column, with column to the right (or maybe several) may be more readable and more effective use of space, eg: Str 6 Speed 0.50 Dex 10Weapon Speed0.80 Con 18Damage 15 Int 14WC 6 Hmm. Three layouts already do something like this. The first layout on Leaf's listing is very different, and not unlike what you describe. http://krayvin.home.att.net/caelestis_790x600.png Further, all the layout screenshots do not expose the stats, so unless one opened them, it would be difficult to say they hadn't changed. Chthonic, Oroboros do use columns as well. The GTK V1 variants do not for more obvious reasons, but for the others, I'll be most happy to do something different as it would free up more screen area. Remember too, I copied the legacy GTK V2, and differentiation occurs somewhat over time as I play with ideas. Keep suggestions coming. Oddly, when I mentioned stats and the homogenous mode before, the gtk-v2 format was argued for, possibly giving some exception to allowing numbers to cuddle the label. I imagine that
Re: [crossfire] Map logical linking
Hello. Looks good to me. It may be worthwhile to define how that information is used, and thus perhaps other fields. As I see it, information is only used for mapper, to generate map information. No ingame link - at least, none that I plan to do, maybe others? :) The idea to split quests from maps could be interesting, though, someday (so you could distribute map packs containing a quest). As for the format of the field, I'd suggest: HTML, without anything fancy, and no h1/h2 headers (so they can be used for other things on the page). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Mapper tool
Hello. I'd like some opinions/suggestions on the mapper tool for Crossfire (found in server/utils/mapper.c). Current aim of the tool: * provide a map reference for map makers, to know what exists, show links between maps, point to areas where there aren't many maps, ... * spoiler for players wishing to learn how maps are connected or browsing maps online * help find inconsistencies in maps (same slaying between maps, invalid tiling, unreachable maps, invalid exits ...) * make nice pics we can use for background or whatever :) Here are the tool features for now (note: the pages on ailesse are not generated with the latest version, so I may refer to things you can't yet see unless you use the tool locally): * for each map, a page with exits from / to this map ; quest(s) the map is part of ; region of the map ; map lore (without quest info) and level ; map picture (real size and reduced size) - http://crossfire.ailesse.com/maps/scorn/misc/church.html * for each region, a page with the maps part of said region ; the region description - http://crossfire.ailesse.com/maps/scorn.html * a global world map with region information - http://crossfire.ailesse.com/maps/world.png * a map of roads, blocked things and exits (both used and unused ones) - http://crossfire.ailesse.com/maps/world_info.png * a global map index - http://crossfire.ailesse.com/maps/maps.html * list of slaying values used for keys / doors / various mechanism * uses a template system to customize the output (basic templates in SVN, ailesse uses custom ones) * warning for exits to non existing maps * list of maps that exist but are not reachable from the HallOfSelection Features not (yet) on ailesse: * uses real map and region names for display, instead of the filename * tiled maps support, grouping all maps linked through tile_path_ as one map - with the exception of the world maps themselves * list of maps sorted by level * .dot file generation with links between regions Features I'm thinking about and could implement: * nicer world map navigation, maybe using javascript to scroll maps * max small pic width/height to avoid things too big on page * use a scripting language for even more page customisation - may be overkill, but well ^_- Known issues: * Titan (and probably other) pics are shifted bottom/right - this is quite certainly due to the head being on non (0, 0) * platinum coins are weirdly displayed, as well as the pentagon in the HallOfSelection * does not take into account race-specific HallOfSelection Code wise: * no memory leak, even if the tool does not free its memory - all could be freed if needed, but as it isn't intended to run all the time, not required IMO * file too big, I'm thinking of splitting it for easier maintenance * not part of the build process nor installed - could be included (would then need to define a correct generation path, for now it spits into './html') * shouldn't use too much memory when running * could use more documentation, maybe (processing logic and such) So, what would you, as a developer, map-maker or player, like to see? I'm not saying I will implement everything, but you never know ;) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK V2 client default layout and map size
Kevin R. Bulgrien wrote: Quick thoughts/past notes: I expect that the preferences will be driven a lot by what actual hardware folks are running on. If you only have a display that does 1024x768, then the Oroboros is the likely winner. But if you have a higher res display, that probably isn't a first choice, as you have a lot more display area than it uses. I'm not bothered by that, and it actually is in the spirit of making the game more accessible anyway. I'd consider setting it as the default without even taking a vote. Why should not the majority get their choice anyway - even if it isn't your or my favorite? I have no problem with the majority not deciding the default layout. My point is that the majority is more likely to vote on what works best for them. If the majority chooses a layout that doesn't work good at low resolutions, is that the final word, or should we try to do work that makes things work better for low resolutions? Hard to say what the right answer is (at one time, a fullscreen mode was suggested, but with the wildly varying screen resolutions, that would be really hard) Then... there is the whole thing about making the map size coincide with a selected layout... Right now it is difficult to know what to set the map size too. A first effort to address that is probably due quite high priority. You can totally hose a layout by using 25x25, which is the current default. I think the default map size should be a low common denominator unless new features are added to hint map size settings. That should really get improved - arguably that is a bug going all the way back to the original X11 client. What should really determine the mapsize is the size of the window pane provided for it, not what is set elsewhere. That is also just a lot more user friendly. Start with a small map size and resize? You get a larger map display. Resize smaller? It should reduce the map size. I need to look and see how hard it is to do that. One issue with that plan is there could be folks that want a relatively little map data (11x11) sent from the server, but still have a larger viewable area for fog of war. For folks on highly constrained bandwidth situations (dialup modem), this may be relevant. OTOH, we may also have to ask ourselves how much effort should go into trying to cover old requirements. If easy to do so, we should do so, but at the same time, we shouldn't spend a lot of time trying to make things work in marginal situations at best. and so on. As an aside, since exp now has its own statbar, there really isn't much reason for there also to be a display in the stat area. I've noted that, and think removing it might require a code change to avoid error messages as missing widgets do generate them, though I have not checked to be sure. It's a good reminder though. I have thought it odd for some time. At minimum, the lookup_widget routine generates an error whenever you try to find a widget that doesn't exist. If it gets removed from all the layouts, then removing the code that updates the labels makes sense. If some layouts have it, and others don't, I think this can still get managed by checking for null values or the like. An alternative may be to put those labels in some hidden widget that is never displayed, so the widgets are still there, just out of sight. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
