Re: [crossfire] Things to fix
Le jeudi 29 mai 2008, Nicolas Weeger a écrit : Hello. Here are some things that need fixing IMO. I intend to start some, but I can't do everything alone :) The game is missing lore. Some is on the wiki, but not much is integrated in the game itself. Also, many many maps are missing hints relative to their location or purpose (warrior tower, ...). So we need people to first incorporate the existing lore, then add missing one, into a coherent thing, then add hints to various places or things. Ideally, *all* houses and maps could have a whole story (ok, not a whole quest maybe, but some background). I'd answer yes, but with comments on this one. A lot of places do not really need a story - places like pubs, inns or shops often don't require such background for themselves. OTOH, what they always require is a taste of truth. A shop is technically nothing more than a place where you can buy objects; but in-game-wise, it is a place where people work and try to make it so customers are attracted. To achieve such a result, utility maps, or maps that are too small should get details that make them more believable: customers passing by in shops; drunk lads causing trouble at night in the pub; and so on. Another small idea: most places are probably not open all the time, or offer different things based on the time of the day - that wouldn't be very hard to implement either, but would make the place more alive. I'd like to expand towns to let's say 5 times their current size. This would enable even more things, and make the scale better IMO. Ideally, the world itself could be much expanded. I'm not sure of that. If you mean scenaristic expansion (more active NPCs, clues - true or false - or dynamic effects that have an impact on the story), then I agree. But if you are speaking of geographic expansion, I'd disagree: IMHO, the main issue is not how small cities are, but how (in)efficiently the available space is used. Or to say it in another way: it is not the number of pages that makes a book good. Besides that, I believe it is easier to not start with huge projects, but rather work with smaller scenaristic chunks and maps, and expand places only step by step, as the need arises. I'm not sure of the best way to put lore ingame. Currently we have books (random things), NPCs. I added some professors in Navar university, one can tell you a long story about Lorkas if you ask. Things to take into account, IMO, are: one NPC shouldn't know everything of the world, or maybe even all the details of one thing. On the other hand, it can be weird to have exactly all the people you need to learn things... Opinions on how to present lore or on those issues? Two main paths for information diffusion: - Random diffusion, from automatically generated books, artifacts, or NPCs; - Human-implemented, by map-makers. Random lore bits should be managed just like any other item: the rarer they are, the higher the chance for them to be meaningful/important/accurate. With a few dead-end ones, to trap the player, of course: not every legend known has to be true, or lead to a quest. Just because Karis Imaden told you there was a huge treasure hidden in one room of the Scorn's Inn doesn't make it true :). Human-implemented lore should follow the classical rules of scenario writing: enough clues to allow the player to be able to progress through the story, but with a layer of uncertainty/inaccuracy, whose importance depends on the average difficulty level of the quest. The principle of key objects one must own to trigger a new clue, or the right action to take at the right moment, should be much more extensively used. Most current NPCs are only working on a keyword/answer paradygm, simply because nothing else was possible; this is no longer the case, and we should thus make full use of the available possibilities. The combat rebalance needs to be finished. Mark, how can we help you on that? Also, do people have comments about the current hand to hand combat rebalance? Can be seen on the Ailesse servers (one permadeath, the other non permadeath). What about general item/monster fixing/balance? No opinion on this. IMO, the best way to progress is game experience-driven development: develop things because they add stuff to the general ingame atmosphere, not for the sake of it because it's cool. In the same way, we should avoid the not invented here syndrom and try to use existing libraries when they exist. Again, I'd agree - with caveats. Adding things because they are cool is perfectly fine - as long as they allow cool in-game results, and just not because it is technically esthetical. I'd prefer seeing development being driven by the what kind of game do we want ? reflexion; the game experience-driven development is part of it, but there is more than that - mainly the need for a coherent idea of the game. Else, you end up with a lot of small mechanisms that may be
Re: [crossfire] Project: Slow down combat
Some short comments about all this... I'm concerned no one replied already, but well... My brain is slow, and needs time to formalize thoughts :) Shortly summarized (so that those who do not like to read a lot don't need to): I am not convinced at all that you can isolate the combat system from the rest of the gaming system. I'm also not convinced that tweaking the current system a bit can provide a very good answer to the current issues perceived by players. Now, for the less impatient ones, I'll provide a little more details on why I think so. First, there is a problem of content. All the current maps were designed with the base idea that combats are fast and furious in mind. It means large rooms full of monsters in which the player runs and harvest. Slowing down combat would dramatically change this, and involve the complete redesign of most - if not all - maps in which combat happens. This is probably the most important issue in making combat pace changes, especially given that there are not a lot of map-makers out there. Second, there is the problem of other combat skills - basically, spells. Those were too designed with the idea of large-scale battles, with a single players fighting lots of monsters at the same time. Cone spells, as well as the explosive spells (like fireball) were obviously made with the idea of damaging a lot of opponents in a single cast. If the combat pace is slowed down, then it means the player will, on average, face less monsters at a given time, and thus this will reduce the effectiveness of those combat spells. The result will be that magic will get harder to use - and given that it *already* is hard (try to play a spellcaster in the context of a permadeath server if you don't believe it ! :) ), it would ultimately mean changes in the magic system as well. Third, archetypes will need massive changes - if the combat pace changes, so does the game balance; and thus, the monsters and weapons characteristics. Although some of such adaptations can be performed automatically by scripts, I believe that handwriting will also be required to balance the result in an appropriate way. Finally, the whole mechanism of combat needs to be rethought, and not only its pace, IMHO. Currently, melee combat is nothing more than run into a monster. There is no combat visuals, little tactics, and no real variations between melee techniques - whatever the weapon or the melee skill used, it is just a matter of running into monsters. As a fighter, I'd like to have to choose between various techniques, to have special hits, or simply to enjoy seeing my character swinging its poleaxe all around orcs :). Overall, I tend to agree with Kevin R. Bulgrien's point of view: I don't think designing things piece by piece is a good idea. But given that the boss already expressed lack of interest on that point, I'll not extend furthermore on this. Just my 2 eurocents. (Now, Ryo, you have one more reply - and before the rewrite was finished. :) ) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Metaserver2 / schmorp
Le Saturday 15 September 2007 13:55:51 Marc Lehmann, vous avez écrit : Yann, you are a liar, and you know it. There is no excuse for the amount of FUD you spread, as what you say can easily be verified. The fact that you didn't even try to verify your claims and sitll do them has no excuse. I don't like answering personal attacks, because most of the time, there is so much hatred behind them that it is pointless to attempt to conduct a reasonable debate. I'll do anyway, not because of the answer you could provide, or the exchange of ideas we may have (none of this being possible, I think), but so that all other readers may make their own opinion by knowing both points of view. I'll try to keep this short, as I don't think spending hours on this is very useful. 1. On the issue of reporting absolutely accurate information The metaserver2 is, in case people forgot, The Crossfire Metaserver List. This means that the reference implementation is the original Crossfire server, mapset, and archetypes. To distinguish between it and other variants without having to use complex version strings as in the metaserver1, the arch/maps/codebase fields were introduced. This is clearly the only way one can distinguish a CF and a CF-TRT. It is true that the project name should not be used in the version field - there are the arch/maps/codebase fields for that purpose. This was clear from the start; AFAIK, none of the TRT developers asked for any clarification on their meaning on the Mailing List; the metaserver webpage (crossfire.real-time.com/metaserver2/meta_html.php) makes quite obvious that outside those three fields and the version one, there is no way for the client to guess the variant. 2. On the various code improvements and code quality I never questioned the code quality of the TRT project in this debate - this never was the issue discussed, and it has little to do with protocol-level interoperability. Neither did I discuss about the server stability in a comparative or particular way. Bringing those points on the table only helps derivating from the central point. 3. About forgetting the CF servers in the TRT clients lists Schmorp used the following arguments to explain that they didn't forget anything at all: a) they didn't have time to create their own metaserver compatible with gcfclient; b) they were removed first from the metaserver; c) his server was blocked from accessing metaserver information. I find point a) rather strange, actually. There was already a working metaserver; metaserver2 is now also available. Both provide the infos required to connect to a game server, and are completely independent of the particular implementation of the server notifying its presence. Both metaserver implementations are freely available and can be deployed to provide an alternate metaserver in a matter of minutes. Both are also obviously recognized by the TRT servers, and they actually used them. It seems quite odd that TRT developers weren't able to make their client interoperable with any of those, to display the whole list of available servers, and not only the TRT ones. Point b) is simply not true. The TRT servers were removed from the CF metaservers only a few days ago; original CF servers were already missing before that date. Point c) could have easily been solved by discussing the blocking issue with the metaservers administrator. Note that this is somewhat irrelevant, as the TRT client could simply have read the infos from the CF metaservers directly (see point a) above). Whatever the reasons, the result was the same: TRT servers used the CF infrastructure to advertise their presence, but TRT clients didn't bother listing the CF servers. 4. On being blocked without any notice First, the discussion was conducted on the public mailing list. One that some of the TRT developers are subscribers of. They (or you) had the opportunity to participate in the discussion, and formulate objections. If you chose not to take part on the debate and expose your own position, it was up to you. Second, *I* didn't block TRT from both metaservers without any notice; I just exposed my point of view that they should be. I never prevented the metaserver maintainer to ask the TRT team complementary information if they deemed it necessary - they have a brain and can decide by themselves if my proposal is grounded or not. As a side note, the original discussion that led to the exclusion of TRT servers, was about the metaserver2, and not the metaserver1. Note that my original proposal was to use metaserver1 for 1.xx compatible servers (TRT is one of them), and metaserver2 for 2.xx only (this means that I'd have banned CF 1.xx servers from metaserver2 as well as TRT ones). 5. About criminal behavior On this, I'd just like to point out that calling somebody a criminal on a public discussion when no crime has been committed is, in most countries, condemnable by law.
Re: [crossfire] Schmorp back on metalist
Le Friday 14 September 2007 19:27:37 Jonas Stein, vous avez écrit : Dear opensource community, i was very disappointed, when Schmorp disappeared from the metalist. I had no problems with any client on Schmorp in the last weeks. Although this is no evidence, that there are no bugs or problems. It would be the correct and fair way to include this server in the metalist as it would be comletly against the idea of opensource to constrain inventions and forks. I think it is a good solution to inform the user about what he can expect from the server. As long there are bugs reported someone can include a MOTD message wich informs the user. Indeed we all do not want to force the user to select a particular software or user. He should have the chance to select free between a new testing environment or an old stable system. It would be a shame for the nice community on schmorp, when user will no more login because its invisible in the list. Many people have high level characters there and have a lot of fun to play there in their leisure time. So we should not annoy them. Thanks for reading so far, Dear user, Just as a side note, I'm writing in my own name, and not of the whole project - keep that in mind when reading. I can understand that you are disappointed. Especially after you have (I guess) read the latest news entry on Schmorp's Crossfire TRT website, where he explains that Both our servers have silently been removed from the Crossfire metaservers. While this was expected to happen at one point due to the friction between the projects, its unexpectedly harsh to do this without giving us any advance notice or explanation. But thats the ways of the Crossfire developers: if you can't convince with quality, try to shut them down with other means... Which indeed made you wonder something like why are those Crossfire jerks blocking those servers ? That's mean ! Maybe they are jealous ! And if I were you, I'd ask myself that as well, and would probably write the same kind of letter as you did. Now, given that you wrote that letter, I guess you deserve an explanation - from the point of view of a Crossfire (non TRT) developer. First, let's make this clear: this is not a question of being jealous. Schmorp chose to explore new ways of developing the game. This, in return, gave ideas for the next development path of Crossfire itself. There is nothing wrong about a derivative of our original code to be successful, or to invent new things to improve the gaming experience. I don't care who is the project leader - what does are things like does this change make the game better ? or What issues players get into ? How can we solve them ? You are speaking about the absence of technical problems between the stock CF client and the TRT servers. I'd like to mitigate this by underlining two important points: - First, the old network protocol commands used to transmit map data, still used in the 1.10 client, has been removed from the trunk code (that is, the code for the 2.x version of Crossfire). This means that, for all those people using the trunk code for the client, they are unable to connect to a TRT server. They'll wonder why, of course, since those are labeled as versions 2.x, and may conclude that the whole game is crap. I doubt this is a goal either the CF team or the TRT one seeks; - Second, there are obviously some annoying compatibility irks noted on Schmorp's side - else, why are they bothering to print all those compatibility notes in red letters when you use the gcfclient to connect ? Given that they themselves have to use workarounds to make both interoperable, this is probably not a good idea to continue that way on the long run, forcing them to support other clients than their own one. Then, you are underlining the fact that it is correct and fair to include their server in our metaserver lists, because it is how opensource spirit works. Sure - I just wonder why they forgot that spirit and forgot to display all the other CF servers in their own client's server list. Exchanges of ideas and freedom of choice can only properly work when all involved sides agree to play the game. You point out that it is good to inform the user what he can expect about a server. Definitely - and that's all what the metaserver2 was about: providing more accurate informations about what a server offers. This is why metaserver2 includes a field about the map set used, for example. Now, again, this can only work if each server follows the rules and provide proper informations about its content. TRT clearly isn't using a standard content (this is one of its major differences with the original Crossfire), yet was saying otherwise to the metaserver2. Same with the version number. Or for the code base used. Or for the archetypes set. Why didn't they play nice and provide accurate information is a question you'd want to ask them, not us. The fact is that I
Re: [crossfire] Metaserver2 / schmorp
Le mardi 11 septembre 2007, Mark Wedel a écrit : Nicolas Weeger wrote: Hello. Schmorp server appears on metaserver2. But the officiel client (latest) SVN does *not* work with this server. This server shouldn't be on metaserver2 until it supports the official Crossfire client, since metaserver2 is the future 2.0 version. snip As such, it would seem banning servers from metaserver2 because they do not support latest trunk would be wrong, because that would likely result in us banning 1.x servers also. I don't see this as a problem: keep the metaserver version 1 for 1.xx servers, and the metaserver2 for 2.xx versions. It seems rather logical to me that two series of servers that are not using interoperable communication protocols with their respective clients appear in different lists. If schmorp was not playable with either the 1.x client or trunk client, then it seems reasonable it shouldn't be listed. If we let incompatible servers in either of the metaserver lists, then what will new players think of the game when they attempt to connect with the wrong version of the client to a given server ? This could be excused if one connects with a client marked 2.x, to a server marked 1.x - the difference would give him a clue about the problem. But what when he connects to a 2.x-trt with a trunk client, and sees it fail ? Do we want to damage the reputation of Crossfire just because we don't have the guts to ban a not fully compliant fork from our public server lists ? Looking what is there right now, it does seem that schmorp is reporting some incorrect information, which would be grounds for blacklisting - in particular, it clearly isn't running off a standard code base (and I'm not sure about maps or arches), so that should get fixed. It also doesn't seem to be reporting bytecounts, but I don't think we have an actual official policy that it has to do that. You are the boss. Why does it take so long dodging around the problem ? Is the 2.x-trt server fully compliant with 2.x (trunk) clients ? No. Hence its marking is not proper, its presence in metaserver 2 isn't either, so scrap it from it - problem solved. 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] Metaserver2 / schmorp
That is certainly an option, although I did backport the metaserver2 support to the 1.x branches. One thought behind that was for the metaserver1 to go away. Another was for clients to filter out incompatible servers, so for example, if I connect with a 2.x client and because of protocol changes it is not compatible with 1.x servers, it wouldn't even show them in the selection list (and vice versa for 1.x clients on 2.x servers) Then, I wonder why the TRT servers are not filtered out, given that they're clearly not compatible with the trunk client. That is why I think the client should be modified to not show/drop entries from servers that are not compatible with the client. Thus, the player would never see a 2.x-trt server if in fact the client they have won't be able to play on it. Indeed. The problem is when the server itself is not honest, and does not report accurate information. - Should I remind you that TRT is reporting Standard for the arch, map, and code base ? - Should I remind you that TRT is reporting 2.2 as its version string, increasing the confusion furthermore ? - Should I also underline that TRT reports 1026/1023 as the protocol version, despite the fact it uses elements that were never included in the original Crossfire 1026/1023 protocol ? I agree that the filtering is the solution to sort out between the various versions of servers reporting accurate information. But I do think it isn't an option for servers who don't play nice with the metaserver2, reporting false informations just to increase their visibility - for those, blacklisting (until the issues can be solved with the server administrator) seems to be the only option. signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] CFDialog Documentation (was Re: Vote: Next major project)
Le Tuesday 21 August 2007 10:42:03 Kevin R. Bulgrien, vous avez écrit : L) NPC chat right now really isn't very good. *sigh* From the header of maps/python/CFDialog.py: snip See also http://wiki.metalforge.net/doku.php/cfdialog It is always refreshing to see how one's work is appreciated :). From the documentation indicated, I would not easily know how to make a map that uses this since I do not know squat about using python scripts in maps. Documentation reference: - How do I hook a script to an object, from server/doc/Developers/python - Same title, from http://wiki.metalforge.net/doku.php/cfpython Of course the CFDialog does not explain how to write Python scripts, since this is already documented elsewhere. And no, the CFDialog document doesn't explain what an NPC is, or why they are answering using speech; for what matters, all this is supposed known from the rest of the documentation. The code documentation and wiki documentation is too light, and could show an example of an NPC definition that uses the script example. See above. For practical examples of NPCs using scripts to manage say events, see for example maps/scorn/shops/IPO_scorn. Various scripted map examples have been in existence since 2001 in the maps. It would be nice not to have to go digging through other documents to find out how to do python scripting in general just to get started. There is no digging needed. If you had done your homework, you'd have found that it is clearly explained in a single document, which can hardly get a more explicit name (doc/Developers/python and cfpython on the Wiki; it is also the first entry found when searching for python on the Wiki search engine.). Now, if typing python in the Wiki search textbox is digging through documents, then maybe we should just trash the whole content of the doc/ directory and from the wiki, since it is probably too difficult to find anything useful in it. If that were the case, I'd probably make use of what I did know (even if that is only a lazy slob's excuse). It would be better to show a complete example, and reference the docs that discuss python scripting as it relates to map editing as a way of encouraging the reader to broaden their understanding of the available tool set. The example given in the wiki is a *complete* script. It is expected that the reader will be clever enough to read the related Python page (which is *also* linked from the CFDialog wiki page) if he/she has trouble for hooking scripts. There is a complete example, there are several scripted NPCs in the maps, and there is a rather detailed description of what CFDialog does. What the heck was I supposed to add ? A youtube video of clay characters visually explaining how to type P.Y.T.H.O.N using the keyboard ? Presently I think it is difficult for a map developer to know how to use the facility. For a map-maker that doesn't even bother to read the provided docs, yes, it is. With some mention, cross-linking, and a better example, more than likely the author's work _will_ be far better appreciated, and maybe even used. A *better* example ? Fido Damn It(tm), the example is a two-level-deep hello world style dialog ! What by the gods am I supposed to find as a better example for a class used to provide scripted *dialogs* ? For reference, the example provided in the Wiki contains 20 lines of code (the rest of the content being comments). 6 of those are either required imports or variable definitions. This leaves 14 lines that are specific to the use of CFDialog. Should I conclude that 14 lines is already too complex for a two-level dialog with three different answer branches ? Was I expected to make one-liner examples only ? Cross-linking ? More mention ? Do you realize that a search on dialog on the Wiki returns the CFDialog documentation as the *first* result ? Same for speech ? That it is the 5th result on npc script ? The only one on npc answer ? The first one on npc answer ? Or maybe CFDialog is not an explicit enough name ? Maybe I should have named doc/Developers/python this-is-the-doc-related-to-scripting-stuff-using-python-use-a-text-editor-to-open ? I'm sorry if I'm feeling my temper on this, but that's really BS. Any 2-minutes search on the Wiki would have told you what you needed to know about the extension alongside with an example script (heck, I didn't even know which keywords would have worked to find the cfdialog page - I just tried the first words coming into my mind on that topic !). Now, if even a search in the Wiki is asking too much to a map-maker, then maybe we should plainly ask the question of the pertinence of maintaining a documentation wiki in the first place. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client proposal: redo inventory/look widgets
Le samedi 4 août 2007, Lalo Martins a écrit : On the quest to ungeekify the client... ;-) Based on recent discussions and a comment from Mwedel, I'd like to propose a revision of the inventory and look areas, and the introduction of three new things. (Of course I'm volunteering to write the code for this.) See also http://wiki.metalforge.net/doku.php/ui_proposals , whose purpose was to serve as a central point to UI design-related discussions. The shortcut area is really Mwedel's idea. It would be a 10x2 or 10x3 (or even 10x4) table, and you drag either equippable items or spells to that area. Each slot essentially manages one keybinding; so if I put my axe on 1,1 and small fireball in 2,1, then pressing 1 does apply axe (well not really, but you get the point), and shift 1 does cast small fireball. The rows correspond to no mod, shift, ctrl, and alt. *hrem* Just as a side note, that's a design idea that has already been suggested and discussed several times (The JXClient fastbelt, the technolous's quickbar proposal, or the fastbelt in the UI Proposal #1 on the link above). You may want to ask IRC log archives for discussions about UI proposals (and also to give proper ideas credit were due :P). See in particular http://www.ailesse.be/irclog_client_ui_1.txt , which contains a couple of interesting comments over one of such proposals. Then the stuff notebook; I imagine it has a control (checkbox or toggle button) that chooses between details and icons mode, regardless of tab (I think the choice applies to all tabs). First tab is look; the objects on the floor near you. Second is the plain, unfiltered inventory. Yes, the filters are occasionally useful, but IMO, not often enough to justify polluting the UI. Fourth tab is the spell list; this is an awesome addition to the game, IMO it's about time it gets a more permanent space in the UI (and it's somewhat necessary in order for the shortcut area to be useful for mages). The problem with tabs is that you cannot have the content of two different tabs on screen at the same time. This was the reason why the original JXClient design didn't use them - having both spells *and* equipment items directly accessible is quite important, IMHO. The third tab deserves its own paragraph :-) what I'm proposing here is a body diagram similar to what many computer adventure games have. Yes, it would require some tinkering, since we have IIRC 3 or 4 different combinations of body parts... but I have an idea how to do it and I'm willing to write the code. Here, you'd have a rough outline of a body, and for each body slot your character has, there would be a space where an icon can be drawn; if you equip an item on that slot, the corresponding icon appears there. Clicking a slot (with or without an equipped item) would bring up a menu with the items that can be equipped there. Since it's a notebook widget, it would be hard to drag items from the inventory to the body diagram; but then again, I have no idea why you'd want to do that, since you can double-click it on the inventory :-) Because drag-n-dropping an item from one location to another to equip/unequip them is somewhat more intuitive than double-clicking. I think hovering an icon on any of those widgets, if you are on icon view, would display the rest of the information (what you would have on detail view) on a tooltip. Thoughts? I think you should add your proposal to the wiki page mentioned above. I'm also not sure revising the inventory part separately from the reste is the way to go. I tend to believe that rethinking the UI should be done in a more global way, as every element relates in a way or another to the others. Just my 2 €-cents. 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] GTK2-v2 Client new layout defined (gtk-v1)
Le samedi 4 août 2007, Kevin R. Bulgrien a écrit : Hmm... So then the mumbler was really just detracting from my feeble attempts to work on fixing what I felt like moaning about. Ok... I get it. Just as a side note, my original comment was about underlining the (IMO) terrible layout of the GTK1 client, one that the GTK2 adaptation didn't make any better. Or, to speak using other terms: - no, it wasn't a free ad for jxclient; - yes, it meant that regardless of the toolkit used, I found the UI cluttered and unfriendly. Does that mean it shouldn't be fixed ? Of course not. It simply meant that IMHO mimicking the GTK1 client UI didn't fix anything. Nope, that make huge assumptions. All I get is an exception when I do that. On the other client, it has ./configure that has a chance of showing me maybe I don't have all the requirements installed, which I suppose has something to do with ant croaking when I try to start it. If you had spent two minutes googling about it, you'd have found that this message was caused by a badly installed/configured ant, and not by a problem in jxfire's building process. Reference (amongst several others): http://ant.apache.org/faq.html#NoClassDefFoundError With a badly installed/configured C toolchain, you'd just get the same kind of failure with ./configure. Don't blame the SVN content for a problem in your own building chain. Just my two €-cents. 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] GTK2-v2 Client new layout defined (gtk-v1)
Le vendredi 3 août 2007, Kevin R. Bulgrien a écrit : Here's a layout that is pretty close to the gtk-v1 client. snip http://krayvin.home.att.net/gtk2_gtk-v1_layout.png Am I the only one finding this interface rather scary and cluttered by tons of stuff ? 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] map design guideline (was: Summary)
So, no one has any opinion on what was said on the thread? Ok, if you insist... My opinion is that regardless of the design guidelines, Crossfire maps will stay at best average, because the fighting/damage system used forces fast and brutal combat. This is perfectly suitable with the original concept of a hack'n'slash game - but I do not think it fits the role of a more RPG-oriented game. Neither does it with the idea of multiplayer gaming. There is also the content problem, of course: too few content written, and fewer actually used in maps. No one cares? I stopped caring after it was obvious that better content was not map-making's top priority. No one has any idea? Write content. Use what's already written. Change the pace of combat to give a meaning to multiplaying. Then, maybe it would be time to set some design rules for maps. No one agrees? No one rejects? What do you people on the list expect of Crossfire? I expect it to focus less on code, and more on everything else. It doesn't seem to be the case. Are you ready to help? For teamwork ? Sure. For single-handed development, no. Or is the project so dead no one contributes in any way? A better question would be to ask why people don't contribute more. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
Le Thursday 10 May 2007 08:34:07 Mark Wedel, vous avez écrit : Lalo Martins wrote: One thing that has been bothering me recently, is that increasingly, most scripts are tied to arches, yet they reside inside maps, which means an admin needs to keep arches and maps strictly in sync. I don't think keeping both in sync is a problem - if I create a new map and use a new archetype in it, I'll have to sync both regardless is scripts are involved or not. Now, it could be more convenient for the archetype-maker to have the scripts in the arch package itself; the collect script could copy those into the appropriate places in the maps/python subdirectory (or elsewhere) when needed. I'd like to propose the tiniest addition to the complexity of the python plugin, so that we'd have a structure like this on a server: lib/ python/ (arch scripts) maps/ (maps) python/ (map scripts) So we can introduce a notation to mark a script as an arch script, eg: mmm... I don't understand what the advantage of this would be - I think it makes things rather complex for map-makers, with no obvious benefit. Is it possible to run scripts from text that is in memory? If so, then an approach similar to the treasures - collect them into a file, read them into memory, and when needed, run the script from that information in memory. Yes, it is possible - the problem in that case is that as the number of scripts increases, this may become a noticeable waste of memory. Also, not that the current system allows one to test scripts on the fly, without having to restart the server each time - memory loading would not provide the same possibility. If this idea isn't feasible, the next approach would be to have a 'scripts' directory, and the collect process just takes the scripts and copies them over there, and then install copies all the scripts elsewhere. I tend to think this is a better approach. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] scripts
Le Thursday 10 May 2007 13:41:08 Lalo Martins, vous avez écrit : mmm... I don't understand what the advantage of this would be - I think it makes things rather complex for map-makers, with no obvious benefit. You missed the point here. It couldn't possibly make things complex for map-makers, since this would never be visible to them :-) map scripts stay exactly as they are. What I'm talking about is introducing a distinction between them and arch scripts. So it would make things complex for arch writers... which, IMO, it wouldn't, it would make things a bit simpler for them. I consider arch-makers to be the same kind of people as map-makers :). Granted, I should have used arch-maker there, which is what I really meant. What I don't like is that @ syntax - it is cryptic and not required, provided that archetype scripts get installed at the proper place upon archetype collection. I don't think introducing another specific notation would make things a bit simpler. As for the idea of shipping scripts in the arch package, instead of having to put them into the map package, my position is why not ?. I doubt that compiling scripts in a single archive would be a great idea, though. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting more artists
Unless you start to allow fractional coordinates, such as (2.5, 8.3). I am unsure if a move away from 100% tile-based would be a good thing at this time though. Moving to fractional coordinates would be somewhat more complex to implement; enlarging objects so they occupy more tiles requires no changes in the code (except, maybe, to manage multitiled players). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver
Obviously (all of) you are not confused about it at all, so who is, and how? We asked our players, and they do not seem to be confused by that. We (as in the CF devs) are not all the players by far. I think the most confused ones will be the newcomers, of course - and those hardly express themselves on the ML or on the IRC channel about that. I'll not comment about your player base - I have not enough knowledge about them to estimate the value of that answer they gave you. Then wouldn't it make to keep it as it is? Looking at all servers on a most interesting feature basis clearly makes the 2.x servers more interesting, both for internal features as well as player-visible ones. That's your opinion, which is subjective. I myself don't state one project is better than another - and thus, I don't think it is appropriate to label one as superior to the other (as the + suggested), or newer (which the 2.x numbering implies). Even if I accept the hypothesis that CF+ is better than CF, CF is not a dead project, and CF+ is in no way its successor. The current version numbering system leads to think exactly that. So if you want to make a discussion about technical merrit, No. It is not the point, and I'll go no further in that direction, which involves lots of subjective views and personal bias on both sides. If you think version numbers should reflect most interesting features, then the current situation is your goal, and no confusion could come from it. You misunderstood what I meant: it should reflect the most interesting/advanced features *for the given application*. It seems logical that Crossfire 1.10 is an improved iteration of 1.9, which in turn is an improvement of 1.8, and so on. Now, CF+ is *not* the same project. It is a fork, and is now developed in parallel. Hence, Crossfire+ 2.0 is *not* the next improved iteration of Crossfire 1.10, but the start of a new branch. And as time passes, both projects will diverge more and more. That is an empty claim. People did not get the impression that C++ is the next version of C, either, similar for other cases. People will think it might be an enhanced version, or a new generation of something, which is actually what is the case. Except that C and C++ are languages made for developers, not a game for a wide audience. Moreover, when C++ initially came out, it wasn't called C++, but C with classes, which clearly removed the possible confusion. And, as Stroustrup itself expressed, C++ is an extension of C. CF+ is not an extension of CF, but a diverging branch. Unless you can guarantee that CF+ will forever stay compatible with CF, and keep all the features CF has; that, I guess, would be a rather bold assumption. Thats your opinion, but there is no evidence for that so far. I find it interesting to get that claim repeated without any evidence, and when challenged for evidence, we never get any reply. And what do you want us to do ? Get ten testing people at random, show them the game, and ask them the question ? And when the 2.x series of CF are out, how will we distinguish both ? Or maybe Crossfire should use odd version numbers (3.x, 5.x, etc), while CF+ would be using even ones (2.x, 4.x, etc) ? Honestly, I am a bit annoyed at crossfire 1.x. We wanted to use the +, and we constantly being told that the + should go from the version number. Now that we did we are asked (or some cases commanded) to add it again. Where was that asked ? I do remember that it was asked to use something else, as 2.0+ was not clearly enough different - it looked like a regular 2.0 version with some add-ins. I doubt anybody ever asked you to remove the + and simply use 2.x - and if somebody did, I'd be curious to see the log of that conversation. Before shoving perceived or made-up problems into our direction, couldn't all of you first agree on what you really want and then ask us? Obviously we are happy to comply, but it is no fun if you make a full 180 every few months. Could it be that the reason you are annoyed at us is actually of your own making? I think it is unfair to call us arrogant when all we do is try to play nice but only earn arbitrariness in return? The request is pretty easy to understand, though: change the version number displayed and the project name so that it cannot be perceived as a newer version of Crossfire. We never asked anything else than that, and there was no 180° turn. Make your project name clearly distinguishable from ours was always the only request we ever made. I guess that if your only goal is to play nice, then you'll happily change the version number displayed to something clearly distinguishable - a change that has no impact on the game itself, and that requires less than 5 minutes to achieve. ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver
My quick thougths on this: Crossfire+/crossfire2/schmorp should really come up with its own unique name for the project, just as daimonin did when it split off. The difference between Crossfire+ and Daimonin is that we currently still are protocol compatible. Aside from that only some of our maps differ and the overall gamebalance was changed (from the users view). (If gamebalance and maps are significant, then I wonder whether cat2 is Crossfire). Correct me if I'm wrong, but the code has changed as well, including switching parts to C++ and integrating Perl as a scripting language. That, more than the content, makes the project different IMHO. AFAIK, cat2 is still Crossfire: although some of the game content is different, the server code is basically the same. Thus, yes, that's the same application for me. Calling it most anything with crossfire in its name is confusing. I don't really understand that, who finds it confusing and why? Are you joking ? Crossfire2 presents your project as the 'next version' of Crossfire (which is still in the 1.x series). Are you so naive to believe that using the same name for both projects does not create confusion between both ? ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver
4) Any servers should be free and open, that is to say, not pay for use/play. I am not sure 4) is fair. If people have hardware and time they can donate to run a server that is one thing, but if a CF derivative ever becomes very popular and needs a farm to run on, it is likely a fee would have to be introduced to cover hardware costs, and possibly even hire full time admins/dms/mapmakers/artists. As long as the source code is released under GPL and anyone is free to set up their own server I would still consider that server free and open, I see no problems there. The subscribers would be paying for services that accompany the game, not the game itself. When/if pay for play servers are introduced they could send pay for play information to the metaserver, thus avoiding confusion. Then again someone could also make a new tileset and their own maps, and say do not redistribute whilst running them on their own server, for which they could charge money. I am not sure there is anything GPL can do about that. I agree that it would be fair to still put servers that require a fee to play in the metaserver - it is indeed true that somebody may want to pay the server costs in that way. However, I think that any new content material (maps, graphics) should be freely redistributable as part of the Crossfire project. A server that refuses to share its content with the rest of the community should not be allowed to stay in the metaserver listing, IMHO, because it goes against the spirit of freedom that drives the project. ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver
But to the _user_ there isn't a big change. I mean, if the current crossfire server is rewritten in for example scheme and speaks the same protocol and has the same or similar rules, would it be crossfire? No, unless the rewritten version is made by the people of the original crossfire project as a new version of it, superceding the C code. That case would be a replacement/new version, and not a fork. The project is indeed different, but why shouldn't it have 'crossfire' somewhere in it's name when it's inheritance is still so much visible? Because it is confusing. So the difference that makes us Un-Crossfire is something that can't be noticed by players/users!? Yes. If I code a clone of vi, even if it perfectly mimicks the original, it would still not be the original, and I would still have no right to call it vi - it would still be a clone/rewrite, regardless on how users perceive it. Telling them it is vi would be dishonest, but also a bit dangerous: can I really guarantee that the behavior is absolutely identical in all cases ? I doubt so. Could you re-read my question? I'm not asking about 'Crossfire2', I was asking about the confusion that is created when we have 'Crossfire' in our name. Eg. 'Crossfire+' or 'Blabla-Crossfire-BlubbBlubb'. No need to re-read your question, I understood it pretty well. But Crossfire-whatever definitely seems confusing to me, whatever is that -whatever. I understand that 'Crossfire2' might cause confusion. But the question is: who is really confused? Is a user/player who just runs cfplus or gcfclient and connect to cf.schmorp.de confused because the server software that runs there has a similar name to the server software that runs on metalforge? - I guess not. Actually, such a user is fooled. If I'm a new CF player, I'll not pick a server randomly, but will probably select the latest one, because it probably got the most interesting features. Hence, of course, if I have the choice between an 1.10 and a 2.1, I'll definitely select the 2.1 one, and label the 1.10 one as outdated server. a name like 'Crossfire+' or 'Crossfire-ng' is pretty different from 'Crossfire' and shouldn't cause confusion. Except that with those both examples, one gets the idea that the project is the next version of an older software. Similar as 'syslogng' isn't confused with 'syslog' or 'quake' with 'quake2'. syslog-ng is a tool for system administrators, not lambda players. I think there is a rather important difference between both publics. And AFAIK, quake2 is the second version of quake; so this is similar as if we decided to name crossfire crossfire2 for our next major release. In the jabber community there is jabberd14 and jabberd2. snip But again, those are software that already require some understanding of the computer world - installing a Jabber server is not something very common. Even so, it already created confusion. I'm not convinced that players will not be confused when server administrators sometimes were. We don't object to change the project name to 'Crossfire+' again. But some rationale or explanation why that still is confusing would be nice. Note that the confusion is not limited to the name of the project - the discussion started because of the displayed version number (remember that the project name appears nowhere in the metaserver infos). Even if you estimate that Crossfire-xxx is not confusing, having a 2.1 number without anything else definitely is. ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting more artists
About the tiles size: I do believe that having the feeling of game objects being bigger on the screen makes the whole gaming experience more immersive. I've made tests with 32x32 tiles enlarged to 64x64 on the fly, and the feeling was really different, not looking anymore like a stamp-sized game. Now, I would not suggest using 64x64 as a new size for tiles. Instead, keep the base tile as 32x32, and enlarge various objects, so that they take more than a single tile. Why ? Because having a base tile (32x32) that is smaller than the default tile (64x64) allows you to make more complex shapes - for example, L-shaped tiles. I guess that at some point, the way graphics are transmitted and displayed should also be revised, to allow proper pictures overlapping. Just my 2 (Euro)cents :) ___ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] House sizes
Maybe it being absolute is a bit too much. But having a general rule of thumb could be a good thing Yes, I agree with that. At some level, it has to be assumed that the outside scale isn't completely uniform - a player isn't as high as the town walls, etc. Instead, I think we need to recognize that there are different scales about. What annoys me with such scaling - for buildings, I'm not speaking of objects the size of a bottle or a sword - is that it prevents abstracting the visual representation of the game from its logical one. So, although generating a 3D view (or a 2D isometric one, or any other view than the top-down 2D view) from the data grid sent by the server would technically be not too hard, those scaling issues make the result rather ridiculous :). I'm also worried by the risk of wasted work: who can tell we wouldn't need to change scales again in the future ? If we wanted to fix all the scales, we could probably do that, but would probably be a major undertaking, (...) But that also starts to get into another discussion - one which we could have, but something I think we'd probably be looking at more for the 3.0 timeframe. I tend to think that it is better to handle the whole scaling issue at once, instead of taking the transitional route - rescaling buildings alone would already mean a lot of work, both graphically and 'mapically'. Fixing all the scales later would probably mean fixing buildings again, and thus difficult work on the GFX would have been wasted (it isn't as if we had a lot of graphists... :)). I suppose that is true for everything 'the sooner the better', but there is the issue of finding time to do so. OTOH, this is one of those things that doesn't require programming experience to fix. Yeah - maybe that's the biggest problem - it is easier to code a monster than to draw it :). I guess that we could proceed by not changing any of the current maps, but building a parallel set of renewed ones (maybe linked to the old ones in a way or another, so that they can be tested by players ?). So that could be a change not arbitrarily fixed for a given release, but something that could replace the old maps once it is ready. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Release of 1.10 soon.
I'd like to make a 1.10 release of crossfire sometime soon. So if you have bugs you're currently fixing, getting those fixes in now would be good. Hrem, I don't think people keep fixes for ages in their local hard disks before submitting them :). If you are aware of any unreported bugs, please report them now. If you need time to fix some bugs, please also let me know. I do. I'd like to have enough time to solve at least the following bugs before the next release: - #1612838 : Problem with item_power code; - #1539120 : Talisman of Evocation grants wrong skill; - #1528525 : Sometimes bad initial items are created. I think it would also be nice to wait until #1522796, #1551398, #1556723 and #1605033, which are all marked as probably fixed, are verified and closed. Given that a significant amount of bugs can be adressed in a relatively short time, and that the GTK2 client as only 5 priority 5 bugs pending, none of which being overly difficult to solve, I think it is best to wait until those are pushed into the Pit of Oblivion before making a release. After all, there is no deadline to follow, no need to rush something out - so trading one week or two for a cleaner result would definitely be a good choice, IMHO. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] blasphemy, vulgarities etc.
As long as there is no request for maps rated other than (at most) PG13, I think this is not worth the efford. And I doubt this demand will ever arise (unless CF becomes much more graphical) I agree with this - and given the tone Crossfire has kept until now, I doubt the problem is worth a code patch now. My main concern was however the language use of NPC's. I don't remember which NPC's this concerns, but some use expressions that are forbidden on Metalforge. I disagree. If the NPC represents somebody that uses rude language, so be it. As long as the usage doesn't become excessive, I see no reason to change that *if that fits the character depicted*. I'd easily understand that an upset NPC or a gruesome pirate to use rude words; OTOH, for most NPCs, that would be inappropriate. Another issue is the naming of certain maps monsters. I guess angels - and especially arch angels - might upset some people, not to mention the appearance of 'holy ghosts' in Valriel's church. Huh, what ? I strongly disagree with this. Angels are a concept found in just about all mythologies (including the judeo-christian one); they are present in the collective cultural background of many players. Why the heck representing angels should ever be a concern ? Who exactly would be offended, outside of a couple of fundamentalists ? Let's make my point clear on this: just because some symbols are used in real-world mythos and religions doesn't mean it is forbidden or offending to use them in another context. Religions depicted in Crossfire are fictional ones, and claim no relationship with real-world ones. Making that position clear in the user's guide (maybe it is already ?) seems good; OTOH, I'm opposed to start removing/changing creatures on the sole pretext a couple of fundamentalists could consider their religion has a monopoly on them. About holy ghosts - if anybody creates problems with that name (hey ! that's something that belongs to christians, remove that, it is insulting !), I suggest reading them the following explanation from the notorious Compendium Khelentika, written by nobody else than the famous wizard Dhelyy Olyy himself: Shadow-like creatures, born from the spirit of deceased priests of Valriel, that defended the Temple of Valriel of Kaïrudan when it was attacked by the Arch-Demon Zurnad, during the Dark War impressed Valriel so much by their bravery and their devotion that the god blessed them and their descendants, protecting them by a part of its holy aura. Since that time, they are called 'holy ghosts' for obvious reasons. It is considered an honor by monks of Valriel to be reincarnated in a holy ghost. Also fighting devils or demons could be too much for some, especially when it comes to Demon Lords ;-) Again, I think it is excessive. Just about every mythos has demons and devils, which are basically nothing more than the embodiement of bad principles. In most mythos, there's a hierarchy of evil, just as there's one on the good side, hence the idea of Demon lords - those are leaders in the ranks of the demons. If we start that way, then why not banning dwarves (they're an insulting joke to players affected by nanism) or elves (they are an insulting caricature of ecologists, and, besides that, we may displease fans of Tolkien) ? I agree that we shouldn't offend existing religious groups, but this seems to go way too far IMHO. And the entry to '/euthville/devil.church1' - a building filled with devils - is for some reason not manifest to me called 'jesus weeping' (see as well the name of /eutville/devil.church3). Does this game bring the gospel? ;-) Well, the game initially used God and Satan for the two Gods named now Valriel and Gorokh. The Jesus Weeping map dates back in the early days of Crossfire, when that still was true, and the CF mythos wasn't really defined. I think it would be a good idea to rename it to something like Valriel Weeping or anything else more in sync with the current CF mythos. Further, IMO things that are usually regarded as 'morally bad' (such as slavery) could be no problem as long as this is not propagated. A society with much less woman rights as is common to us might be proper content as long as 1) it does make sense and 2) there is no attempt to justify this. I agree. As long as we don't promote such concepts (like by winning a girl slave for example), I think it is perfectly acceptable to depict them, as they were rather common in a lot of past civilizations. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. You must be joking, I suppose ? Although Debian Sarge - the stable branch of the Debian distribution - is indeed out of date (which is somewhat logical), Debian testing and unstable both have Crossfire 1.9.1, which is the latest release of it. Answer to the initial question: The lack of plugins in the Debian package of Crossfire is documented as bug #379348, and has been solved by the package manager (just give it a couple of days for the new package to spread and become available in the repositories). Unless you are (1) using Debian Stable or (2) cannot wait a couple days more, you wouldn't need to worry about compiling stuff yourself. In case you really want to compile it yourself anyway, note that building the Python plugin will require the python-dev package to be installed before you use the configure script shipped with the Crossfire sources. To get the sources, you can do an apt-get source crossfire-server, then cd into the directory created and do a ./configure; make; make install. I also suggest first removing the installed Debian package, to avoid clashes between both. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit : Yann Chachkoff wrote: The biggest danger is that given there are only a handful of servers, if the first release of 2.0 (or whatever major version) has serious problems, it might be hard convincing people to try 2.1, etc Well, at least for the code side of things, it seems to me that a software that shows serious problems should not get released. Now, you could say that there is no way to be sure that the server works before trying it; I'd answer to this that (1) we developers are supposed to do at least some rough beta testing and (2) nothing prevents us to set a single beta-testing server clearly flagged as such to get player's feedback and spot what could have been missed during development. I'd also like to underline that other games suffered serious problems at times, but it wasn't hard to convince people to try the next step, provided that they initially found the game promising/fun/interesting enough. If we are not sure of this, then we may have a content problem that needs to be put on the table. And if the changes break compatibility, that makes it even less likely for servers to switch over. As long as an old version will only get bugfixes, servers will switch over anyway, to have access to the new cool and shiny features. But again, the interest of the new stuff should be strong enough and, if we believe it may not, then we have a problem regarding the content of the game and our relationship towards the player side of the community: it would basically mean that we work without understanding what players need/want/await for. I suppose it depends on how often we plan to do major releases. If only every couple years, this can lead to other problems: 1) To players/users, the project may appear dead (nothing new in the past 12 months) Sorry if I sound rude by saying this, but that's ridiculous. Since when a project that mostly releases revisions of a given version is considered 'dead' ? To take a simple example, PHP 4.0 was released in 2000, and PHP 5.0 'only' in 2004 - did people consider it a 'dead project' in the meantime ? Again, I am not saying we should provide nothing new - but simply not include major changes. And I think there are plenty of smaller-scale stuff to keep us busy to provide minor releases anyway. 2) To developers, less satisfaction making changes if no one (outside perhaps a very limited set of developers) will see it for 12 months First, there are changes that can be introduced by each minor release. Second, major changes worth an upgrade of the major version number are likely to take a long time to complete, maybe months, so the waiting time is unlikely to be a problem - you cannot be upset that your code isn't used if you haven't even got enough time to finish it. This can be solved by doing major releases every 6 months (or a year at max) - but that then limits number of changes that can be done in each for each major release. Which may not be a bad thing, but just a note. Why would we ever need to base major releases on arbitrary dates ? That's a terrible idea, IMHO. Such changes should be based on the features first, and *then* on some kind of deadline to complete the work, not the reverse. But last point is scope of changes - if major changes break compatibility, you probably don't want to do them too often - players (and server admins) probably don't want to have to start from scratch every 6 months. Sure. I was more thinking about a rather long cycle for majors - one every two years or so, possibly even longer. That more or less matches what I said for the CVS branch. I guess if we're not really concerned about stability of major releases, doing pre-releases isn't necessary. But given that major releases will have much larger scale changes, I'd see that number of severity of bugs to potentially be larger. Likewise, if the code isn't being used very much until it is released, it means that a bug for a big change may not be discovered until a year after that change is made. I know from my own developing perspective, I'd much rather find bugs for code I do relatively shortly after I do the code, because the code will be fresher in my mind than if I have to look back at something I did 6 months ago. Then simply open a public beta server using the last usable CVS code. There's no need to play with pre-xxx labels of any kind for that. I suppose in short what I'm saying is it is really nice to have all code actually exercised/used somewhat shortly after the code is written. Yes, indeed. But that would also include some testing made by the developer(s) it(them)selves. Often, changes made in the CVS currently result in an unusable code because of gross errors that could have been avoided if the coder had spent ten more minutes to build, install and test his/her new addition. At the same time, the number
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le vendredi 21 juillet 2006 20:15, Andrew Fuchs a écrit : What I'm inferring, and my op pinions: Summary: While 2.0 should be a significant release, the majority opinion is that it should not take years. This makes it difficult to implement what everyone wants, etc. True. I think 2.0 should be the point at which most issues that we have known about, but haven't fixed, should be fixed. I'd get furthermore by saying that the last 1.x should be the point where most issues should be solved. And then, we can start making massive changes leading to the 2.0 version. Additionally, the game should be made easier to use (more graphical interfaces on the client side instead of typing in commands constantly), Yep - some proposals for the ergonomy of the client would be more than welcome. Gaining developers: snip Agree on all this, although gathering more devs is probably not the most important point ATM. Strengthening the community: On the community side, we need to encourage player interaction, both in and out of the game. One way to boost in game interaction would be bolstering the player economy. I think that, before entering into such details, we should ask ourselves what is fun in the game and what isn't. And more important, as players what they find fun, and what they don't. I am also doubtful that changing game mechanisms is the top issue for a stronger community - rather, that's making the game attractive and fun, by proposing events in and around them. Many MMORPGs feature special events around their games (contests, one-time special quests, etc). I think that should be investigated for Crossfire. However, that will probably not be done in time for cf2.0. Indeed. But that's probably a good time to start thinking about that part, and try to produce a list of what should be done. For the community out of game, make it easier to find resources like the forums, and the wiki. Additionally, make it easier to join irc channels, possibly by putting a java applet somewhere. Good idea. Probably make the Forum and Wiki more visible on the front page would also help. Another thing that could be done to aid the community, both in-game and outside of the game, would be to setup a method to connect to servers, just for the purpose of chatting with people who are playing (oldsocketmode uses food iirc). Agree. Another topic of communication between players, would be the inter-server chat discussed a while ago. Yep, although that's a little more complex issue to solve. Maybe bridges with the IRC could solve the issue. My opinion on release numbers: Once we have more developers and enough are willing to volunteer, it may be a good idea to appoint some people to maintain the stable branches. Maybe. Note that I don't think we should maintain several stable branches concurrently - only the last release made. I doubt we'd really need specific maintainers in such a scheme. Micro releases: bug fixes, and addition of small features Minor releases: Features involving significant changes Major releases: Huge changes in game play, major overhauls, milestones in development I mostly agree with this. Just for the record, I think micro releases probably wont require any CVS branching. I'd put small features as minor release ones, though - else, we're taking the risk of a slide where most changes become considered as micro release ones to make them happen faster. Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. Quite probably. I think we should first fix all the remaining problems, release that as 1.10, and then work on that strong code basis to get a 2.0. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
(I fear I'll be overly long again, so fasten your seatbelts :)) Le jeudi 20 juillet 2006 07:29, Mark Wedel a écrit : Although I do agree that delaying 2.0 too far away would be a bad thing, I also think that releasing a 2.0 that would basically be a 1.9 with some fixes would make little sense. At some level, all version numbers are arbitrary and can mean whatever. Sure - yet there are some commonly admitted values behind version numbers. Basically, an increase in the major number means a noticeable, significant break from the previous series; a minor usually indicates a natural evolution of a given codebase. In my thinking, the differences of any major release should be seen from the previous major release (1.0 - 2.0, 2.0 - 3.0), not the previous minor release. In which case a lot has changed from 1.0. That's a rather strange way of seeing things. The last iteration of the 1.x codebase is 1.9.1, not 1.0. There is no reason to evaluate a new release with one that was made several years ago, and long outdated by an extended evolution process. To put it in another way, do you think players will compare 2.0 against the last known stable version (currently 1.9) or with the 1.0 that's five years old ? Maybe that isn't great, but as I think was discussed elsewhere, I wasn't aware of this. if there is a separate branch for 2.0 (or 3.0 thinking after that), it probably won't get used much, and before you can really release it to the general public, you have to make sure it is in fact used. Sounds a somewhat flawed way of thinking. If you develop a new version of a software - whatever the software is - you cannot expect it to be widely used before it is released. So this means that a lot of those features have to put in to the previous version. No, I don't think so. You can backport *some* features if the new version takes too long to develop, but why would you want to do the work twice ? I see little interest in this. I have the feeling that you consider that leaving the 1.x server for a possibly long period of time without adding more than bugfixes to it is not acceptable - but I personally don't get why this would be a problem; that's a common development cycle and, unless 2.x takes years to be finished, it is hardly an issue for players. Maybe going forward, there should be a pre-2.0 (or pre-3.0) branch, and all significant changes have to be put in that branch, so that current branch only contains bug fixes. But this still goes back to what do the numbers really need - if most people are running pre 2.0 (pre-2.0-1.9?), then there are not lots of changes when that is decided to stop calling it pre 2.0 and make it as a real release. I don't get why you would need to play with pre-x labels - that only adds useless complexity. Let's not forget that the CVS is essentially a developer's tool. Its content is by definition unreleased code. So I'd suggest to branch whenever we make a new stable release, whatever its version number. The main CVS should contain the latest, work-in-progress stuff. The various branches (1.9, 1.10, 2.0) get only bugfixes and can be used to create package revisions (1.9.1, 1.9.2, etc). I think the confusion comes from that currently, a lot of people are using the CVS directly and don't care about the file releases. I don't think it is the best way to ensure a smooth transition process between version, and pertly explains why some important projects get delayed or lack coordination (because the current general assumption is that the CVS must always work). That is a reasonable model - the official version is bug fix only, and all new features go into what will become the next major version. But as said above, snap shots/pre releases of the next major version still need to be done at some point, and what do we call those? No, I don't think they need to. But if the goal of such snapshots is to provide some food to the beta-testers, then that's simple: whenever an important development step is done, create an archive of the CVS content, name it with a -bXX suffix and continue to code afterwards. I don't get where this would be a problem. Sort of goes back to whatever arbitrary numbering scheme we choose. Yes, but the scheme would be a logical one, and not one that would be based on a rather vague I think it is time to change the number feeling. Problem is that then we will never make another major release, as the list of things to do will continue to grow. No, because you can impose a time limit to submit new ideas that needs to be incorporated to the 2.x line. Say for example that we end discussion on August 31th, have a debate during the first week of September about the submitted ideas, who will do what and what can be dropped because of being too ambitious/irrealistic/whatever else. Currently, there is no such team planning - it is basically free for all; it has its
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le mercredi 19 juillet 2006 06:50, Mark Wedel a écrit : To me, the issue for targetting this for a 2.0 release is timing. We can come up with a huge list of things that should be done before a 2.0 list. And we could attempt to do them all, but then 2.0 probably won't be released for 5 years or the like. Although I do agree that delaying 2.0 too far away would be a bad thing, I also think that releasing a 2.0 that would basically be a 1.9 with some fixes would make little sense. The discussion for a 2.0 release probably needs to be done. Several questions need to be asked answered: 1) What is the target date for a 2.0 release? It can't be 'when all the cool stuff is done', as then it never happens - always something new to add, etc - some general date has to targeted. I had previously mentioned shooting for end of this calendar year. That's a question that can only be answered once goals to reach for 2.0 are cleared. 2) What are the 'must have', 'nice to have', and 'not really important' features to target for that release? The wiki - http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by high/medium/low priorities. Does code restructuring fall into high category? There is a code cleanup which is high, but I had envisioned that to be a bit more modest than what is being talked about now. I'd say that there are basically two types of changes to be done: (a) Fixes to problems currently encountered in the 1.9.x version of Crossfire. Typically, this is the case for Game balance or Fix weather. Those do not involve creating new systems, but rather work so that the current stuff does its job as expected; (b) Additions to the existing functionality. Two subtypes here: (1)minor changes, that are relatively easy to code, or that are mostly not necessary and (2)major changes, that will require some time to complete, or that change the game experience in a significant way. I'd say that everything that is (a) should be done and integrated as a release of the 1.x series - there is no reason to change the major version number for bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - major changes is what one expects to have when the major version number itself changes. Finally, for stuff belonging to (b.1), I'd say that it depends on the priority we put on it: if it is desperately wanted, then integrate into the 1.x series; if that's just a nice idea but not really top-priority, then push to 2.x. Depending on the timeframe would determine how many can really be done in the targeted time. I think that's a bit backward-thinking: the number of tasks should define the timeframe, not the opposite. Bugs, both new and current, also need to be similarly prioritized - fixing bugs is great to do, but can also be a big time sink. That's true, but I don't think it is realistic to start working on 2.0 when 1.x isn't even mostly bug-free. 3) Who commits to working on these changes? The wiki above has lots of things to do, but very people signed up to do them. If there are only a few people actively working on making code changes, that certainly limits number of changes that can be done for a release. So all that said, if we think end of the year is a reasonable target date, I think that limits us to trying to take on somewhere between 2-4 decent sized projects. If we look at the wiki, taking things currently marked as high, that would be: Character creation - new character creation method Sounds good for inclusion in 2.0 - new feature that's radically different from what we have. Game balance - fix various balance issues Looks like a bugfix to me rather than a new feature - so that's 1.x work, IMHO. improve client ui Depends on the level of improvements. If that's just fixing/completing the current client, mark that 1.x (that's basically nothing more than minor tweaks); if that involves rethinking the client UI, then mark that 2.0. code cleanup (but have to be careful this doesn't lead to rewriting huge sections of code) If that's only cleanup without any fundamental change in the way it works, then that's definitely an 1.x task. change password command Agree, although it looks like a rather minor point to me compared to others. Of which, none of those currently has anyone signed up to do them (I was personally planning to look at the character creation sometime soon) I'm not even sure there is a clear document for each of those tasks describing what we are supposed to add/do/design. I mean, everybody understands what new character creation method; but there is nothing documenting what has been decided about it, what it should/shouldn't contain, etc. That's basically a free for all: the first one that assigns itself to the task and submit it to the CVS will get its concept becoming the de-facto choice. I think that before starting to blindly code, we need to clearly define how
Re: [crossfire] Code restructuring
. Or for that matter if two different script register different callbacks for the same type, problems occur. The one plus side of using a table is it can be easier to detect these duplicate entries. I don't like the idea of using a numerical type identification - this is running the risk of type id clash. I think such a restructure should wait until post 2.0 (I suppose work could start now in a branch). Given that this is obviously an important change, I don't see why it should wait post-2.0. Quite the contrary, I think that an improved code structure is a primary goal that the next major CF version should take into account. This endeavor may make sense to do in a branch, simply because multiple people could be working on it. The issue always with branches is how many people will use it, if not many, the benefit of branches go down. I'd almost say it is better to do an approach piece by piece in the main branch, simply because such a major reorganization is such that merging isn't a simple issue. Eg, I fix a bug in apply.c, but in the branch, it is types/weapon.c - the merge isn't going to catch it (it will catch that apply.c is different, but you'll have to manually move that change to types/weapon.c). The drawback being that this is a rather important change of the code; I think that doing it in the main branch is a bad idea, as it will probably make other changes harder to achieve. If this is going to be done, I'd suggest to make a stable branch, which can be maintained for the duration of the transition as a bugfixes-only code base (so basically, the main branch would be Crossfire 2.0 code, while the stable one would be 1.9.x, and would get deprecated once the goals defined for 2.0 are met. -- Yann Chachkoff --- GPG Key 2006: http://keyserver.veridis.com:11371/export?id=-43113965597490782 Fingerprint : C224 F1F9 9025 4FC7 987D 05BB FF66 D413 A3B4 01A2 --- Reality is a nice place, but I wouldn't want to live there. pgp3joW1Ape7p.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
Given (IIRC) that the client does not currently register itself with gnome of KDE, I'd expect most people to actually run from the command line. Any my experience is that very few programs will dump out all that information by default. And one problem in doing so is that it can be harder to see real error messages. It sounds like backward thinking to me. That most people have to run the game from the command line (and thus, see all what the client can spit out) seems to be the point to solve, and not the messages provided. Moreover, if the error messages are hard to spot, then make them more obvious (add stars around them, write a couple of !!!, shift them, add blank lines before and after them, etc). I'd also underline that the error messages targetted at the player shouldn't only go to the console, but also be clearly visible from the GUI itself in the first place whenever possible. In such a case, the player would logically first report the short error message he/she saw in a dialog box. Then, if details are needed, he/she can sends the whole content of the console messages. Sounds a much better way to make at least common errors easier to spot for the player than completely hiding what's basically useful information. Probably the correct solution is to add a -V or --version option to the clients which dump out that information - that is what most all other applications do. It hides the information people don't need by default, but still provides a way to get that information in case of bug reports, etc. The question is: which informations are needed by default ? I think the Info should have an obvious meaning: provide a couple of informations that *may* be useful in several cases, debugging being one of them. If some informations are judged superlfluous at the default level of log (typically, what's required only for debugging/post-mortem analysis) then those should be put back in the Debug log level, which would appear only when the verbosity is explicitely increased. Finally, I don't get why this change was done in the first place - I've so far never heard anybody bothered by the amount of log messages provided in the console; besides that, there are relatively few messages displayed, even at the Info level. So not only does the change of the default verbosity level in the client sound detrimental to me, but it solves a problem that didn't even exist in the first place. Crossfire CVS repository messages. a écrit : Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 UTC 2006 Modified Files: client: ChangeLog client/common: misc.c Log Message: common/misc.c: Make default log level 2 when not in debug mode. Normal users probably don't want all the INFO log messages, and it never makes a good impression about stability/quality if a program spews out lots of errors or other messages. MSW 2006-07-01 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky wxfJo+dw4uAaI3ySSS6aYYI= =fnnG -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff --- GPG Key 2006: http://keyserver.veridis.com:11371/export?id=-43113965597490782 Fingerprint : C224 F1F9 9025 4FC7 987D 05BB FF66 D413 A3B4 01A2 --- They misunderestimated me. - George W. Bush pgphImGpG7EyP.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Yet another crossfire fork. Recruiting.
Sir, I'd be interested to get more practical informations about your proposal, which may sound as an interesting way to make my professional path a little more interesting. Please provide me with additional informations on the following email address: yann dot chachkoff at gmx dot net. Given that a meeting between us was scheduled on this afternoon, it would also be a good opportunity to bring a copy of the Non-Disclosure Agreement you require, so that I can sign it and get to examine your offer furthermore. I also take the opportunity to remind you the existence of some scenaristic material related to the Crossfire in French project. I'd like to know: 1. If that material conflicts with any material that is to be published in the commercial game; 2. Depending on the answer to point 1, if that material is still of any relevance; 3. If I should take your email as an official Haltbefehl to any writing work related to Ailesse. A clarification on those points would be somewhat worthwile, especially given that since it appears that that material is now completely useless, it could probably be reused for Crossfire itself. Yours, Y.E.J Chachkoff. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
Briefly discussed on irc, but also related to other discussions, is perhaps what client(s) to use going forward. To me, at some level, keeping the gtk(v1) client about may not make a lot of sense. I'm not sure about that, at least not on the short term. The gtkv2 is far from complete IMHO. On the longer term, it is probably correct that the gtkv1 would get superceded at some point, though. Especially if we start going down the path of new character creation and other widgets - I don't look forward to trying to write those for the gtkv1 client. I know a lot of people still use the gtkv1 client. Well, I think it is actually more accurate to say that it is the most used one :). So my basic question is, for those of you that do, what needs to be changed/added/fixed in the gtkv2 client so you would use it. My most important complain is already well known: gtkv2 requires a 1280x1024 screen resolution, which is not available (or comfortable) on many screens. The resolution currently considered as standard is 1024x768 (a lot of laptops are limited to it, while a lot of 17''CRT monitors can only display 1280x1024 at rather low frequencies). Although I understand that people that got bigger screens would want a client best suited for them, let's not forget all those who cannot properly display such a big client: they'll have no other choice but quit playing, or deal with ugly things like virtual scrolling. I think that the problem comes down to the impossibility to reconfigure the client interface to suit your needs - not everybody needs/wants a 25x25 map display, for example; others may want to get bigger tiles instead of getting more. Before scrapping gtkv1, I think that the v2 must provide the same level of display configuration. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
But relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. Apart from the code cleanup idea, here's what I see as important: - Better visual appearance. On the coding side, it means adding things like support for smooth moves (continuous move of characters and monsters between squares, instead of the current direct jump to the next square visual effect), or support for action animations (when I attack a monster, I expect my character to swing its weapon. When I wear a shield, I expect the shield to appear on the character displayed). - Better scenaristic background. Currently, a lot of the maps are very bash-n-slash without little to no story behind. I think that more than software code additions, solid, interesting stories will keep people playing. Offering different starting points for each race, providing more interactions with NPCs, chaining quests, etc. would require no new code and would also help filling the Bigworld map. - Friendlier client. The currently available clients are intimidating for newcomers: the cfclient looks rather primitive while gcfclient is crowded with options bars, icons and menus and leaves only a small patch in the middle to display the game playfield itself. I think that a friendlier design here that leaves more space for the game would make the game somewhat more immersive and enjoyable to play. Those are the things that I see as top-priority. Apart from the first, I don't think they require massive code changes. I tend to think that - once cleaned - the current game engine of Crossfire is very good and includes a lot of interesting features, on par with many commercial RPG and that it mostly requires to offer better content to get much more attractive. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). How about not removing things from the game, a novel idea, no? How about proposing an alternative to let's keep everything unchanged forever - a novel idea for you, wouldn't it ? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, not completely, but at least back to what is actually used. I do agree with that. I think that fixing all the current bugs should be the first priority, so that a solid 1.9 release can be achieved. Note that after 1.9 could come 1.10, though :) (and maybe include some metaserver filter to stop servers older than this being included too). If protocol compatibility is to get broken, it is probably better to change the metaserver URL, so that versions 1.x and 2.x don't overlap. If this were to occur there would be an awful lot on the server side that could be dispensed with the map command and map1 commands (map1a could be used exclusively) Probably a good time to get the map2 command idea back on track. the item1 command (the C clients have long since used item2) spell conversion from the old spell system support for the old skill system. support for oldsocket mode (pippijn recently made a textmode parser using the modern packet structure, oldsocketmode is a hack that could be retired completely) doubtless there are more that I haven't thought of. Remove all that compatibility cruft first, and then, when the server is made leaner as a result, look at what, if anything needs simplifying. Yes, I agree with that completely. Not having to deal with old piece of code would make the work a little easier for sure. (note also, I would suggest taking the same approach with the C clients, which have a similar problem (though less acutely)) Probably, although I'd say that clients are lower-priority, as their code complexity is somewhat lower. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, I never suggested to make a complex API to enforce such separation. Quite the contrary, I think that the API should be kept simple, organized and rather straightforward. If the resulting API is complex (either in structure or to maintain), then it is indeed a failure, as one of the goal is to make the code easier to interface, not harder. a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. Such a layout is indeed one of the points to achieve, and is the first step to do (one cannot expect to define a solid API without a clear and global view over the existing code). On the other hand, let's not forget that cleaner code is *one* point a modularized system with a generic API for objects is meant to address. A modular system would allow easier interfacing with other libraries, languages or software, would make possible integration of new classes of objects alongside the maps themselves; if properly done, it could allow upgrades and fixes in the modules code to be integrated in a running server without having to stop it; on-demand loading/unloading of code, with the possibility of creating auto-downloadable chunks, etc. It would basically make Crossfire a game framework that could effectively be used as a workbasis for all kinds of square-based multiplayer RPGs, something a monolithic code will *never* be able to achieve. Of course, you may object that this is pure conjecture, that would get only results on the long-term, if they ever get any. Sure - this is an important change. I think that it all comes down to asking the question: do we want to polish the current infrastructure, keeping adding details to it, or do we want it to evolve into something more ambitious ? I think that we should, at some point, clearly put on the table the future direction we want Crossfire to go to, goals we want it to achieve not today or the next month, but on a long-term perspective. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] the marvels of miscommunication :)
You shouldn't GFDL it if deb considers it non free. I never considered using the GFDL, since it was meant to be used for text or documentation material, not artistic pictures. The Debian sees it as non-free point was never considered, since the GFDL obviously didn't fit well artwork. Stick with the GPL that crossfire uses. At the risk of sounding repetitive, the GPL is *not* suited for artistic pictures ! It uses definitions that *cannot* be applied in a clear, unambiguous way to that kind of work. So no, I'll *never* use it for anything else than code (and other similar works). Note that it doesn't mean that I want to create a special case that would make the picture not compatible with the GPL - quite the contrary, I think my proposal protects correctly the work done, while allowing free redistribution and compatibility with GPL-based softwares. I make alot of art for crossfire and I don't insist on a new license... you can do the same. No. The GPL wouldn't correctly protect that work in most countries. Simply because you accepted such a situation doesn't make a clunky solution more efficient or appliable. Otherwise... why do we need a new welcome screen? Because the current one is not very nice ? Because it depicts monsters whose design completely changed ? Because a change or two is often refreshing ? Besides that, I posted the license proposal so that if a GPL-incompatibility had slipped in, others may spot it, allowing to solve the issue. The decision of not using the GNU-GPLv2 or the GFDL has already been taken, and there is no point of reopening that debate, especially when nothing but sentimental feelings can justify the rediscussion. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] the marvels of miscommunication :)
Le Lundi 23 Janvier 2006 00:12, Miguel Ghobangieno a écrit : I've heard people complaining about the GFDL, what is the controversy over it? If I am correct, there is a controversy about the GFDL in Debian: the GFDL seems to be considered non-free according to the Debian Social Contract, which would force Debian to put all the GFDL'd docs into its non-free repository. It seems that the Debian legal experts themselves are not sure if the GFDL conflicts with the DFSG or not. Given that Crossfire is not related in any way to Debian, the GFDL is not a problem that we'd need to worry about, though. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgpEq3pSwvNml.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: Re: [crossfire] Moving server towards a modularized system?
Indeed. Just because the server can be modularized thus blocking any other new development whilst that takes place doesn't mean it's a good idea. There is no reason to block any other development. I suppose you know that the C in CVS means Concurrent ? I for one frown on the idea of making the server slower There is no reason that it would be slower than it is now. There are no reason for a modularized system to be slower than the current version. The only overhead would be when connecting callbacks to objects - and that's hardly something you'd notice, unless if you're running Crossfire on a [EMAIL PROTECTED] and blocking other development. I think I already said it, but there is no reason to block other developments. Everybody who has already worked in large-scale software projects knows that parallel development on different parts of the code is a rather common practice. That you believe that only a single task can be performed at once on something like the Crossfire code shows that you urgently need to get better informed on software development/engineering techniques and more generally on modern teamwork methods. For what is worth, I could already be working on a code prototype on my personal workstation - would you ever notice it before I submit a patch ? Would it prevent somebody else to add something in the code in the meantime ? The answer to both of those questions would appear obvious, I think, to every reasonable person. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 02:56, Miguel Ghobangieno a écrit : It is not half broken as far as I can tell. Yes it's not running on MF, that doesn't mean it's broken. So having trees growing on sea squares isn't broken ? It gives few problems on Cat2. This whole thing is about slowly dumping whatever MF doesn't use. It is not about moving code out of Crossfire, but about re-organizing it so it is easier to manage. Which, as a side note, should help debugging chunks like the weather system and provide fixes without even having to rebuild and restart the whole server. If you read what I typed earlier, you'd note that I think random maps should get modularized as well - and AFAIK, it is used extensively on MF. Let's repeat it again: modularizing code is *not* about removing functionalities; it is *not* about scrapping code out of the main CVS tree. It is mostly a structural change to make an easier maintenance for those wanting to work on such pieces of code - so it is in fact a way to make them *better* supported. Open your eyes, the 2nd biggest server runs weather code at it's most extreme, in terms of players that's not a few. That there are many players on Cat2 doesn't make the weather system less broken. I suggest you not implement a huge worthless code change that is nothing but busy work. That's indeed an opinion based on emotion rather than facts, unfortunately. I reject your assertion that cave's analogy is flawed as it is not. Tell me how it isn't, then, or stop the nah, nah, nah song. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. Breaking the server always occur when a new functionality that is larger than a few lines of code is implemented (everybody makes mistakes, even skilled coders). And given that I see it as useful, I would have no problem breaking it. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. I don't see why. Moving existing parts of the code into modules doesn't mean development on other parts of the code would suddenly be halted for months. And I could return you the argument: the completely optional get drunk when drinking functionality you suggested would block the more important restructuration of the code, probably for a couple of weeks - where's the difference ? You could of course object that players want to get drunk, but don't give a damn about an obscure change in the code. Presented like that, sure. But wouldn't a server that is easier to maintain, debug, and extend have a more in-depth impact on the players in particular, and the game interest in general ? I think it does, even if it means that the priority is set on changes that are not immediately visible to players. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgpEc5eUt2t9I.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
Try not to dismiss things solely because they disagree with your opinion. I dismissed a flawed analogy, based on wrong technical assumptions. It is not an opinion point, but rather the rebuttal of an out-of-topic flambait. Modularizing the server would create a ton of problems, Tons ? Name them, then, and we'll have something to debate. breakage, Just as there is with *each* code change. Are you suggesting that we stop changing the code ? and solve nothing As I (and others) argumented, it eases a couple of development issues. It could be a flawed view - but then, demonstrate it, and suggest other solutions. Note that those points weren't based on air, but on significant experience in other projects, not on taste or other egocentric or sentimental feelings. and add even less: it is busy work. If you must be busy be busy on some new feature Given that you are not a coder, you have no right to decide for me what I should work on (Note that I usually don't follow such a philosophy - but since you expressed the exact same reasoning not so long ago, I find it appropriate to provide the same kind of answer now). rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Why ? I see a rant based on a pure sentimental feeling from somebody who has little knowledge of the Crossfire code, or of C coding in general. Provide technical arguments, and we'll have a serious discussion. If you cannot, then stop spamming the list. Just as a side note, scrapping the whole code has never been the intend. Next time, try to understand the emails you read before flaming their content. Things you can help add: Out-of-topic - we're discussing the pros/cons of modularization, not about your personal wishes about the code. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Moving server towards a modularized system?
Sorry, in the initial post I presumed it would be python, but a C plugin seems like a reasonable idea. Yep, I easily understand the confusion, given that for the most part, the Python plugin was the only one widely used (Actually, it is the Crossfire-Python bridge itself that is the plugin, not the scripts it allows to run). For one thing, I can't imagine a C plugin ever not being able to be installed (unlike python where people could be lacking the libraries) Well, it really depends on what the C code requires as dependencies - the Python plugin has one with the python libs for example. But stuff that was initially in the server code would have no such external dependencies indeed. That said, trying to figure out what is optional or not is difficult. I'd venture to say a lot of people would say the random maps really are not optional (or if those are optional, what else is optional, like shops, monsters, etc) Well, I don't think we should actually draw a line between what is optional or not in gaming terms, because basically nearly everything actually in the server code could be considered as core in that respect. On the other hand, I think splitting the code in logical entities, more or less independent of the others, would be a path of thinking to try. As such, random maps would appear as a good target for modularization, since it doesn't really depend on anything else, apart from very basical operations, and is called only at a few places. Alchemy would be another good candidate - both are very important in the game, yet are working very much like black boxes - complex code with relatively limited interactions with the rest of the code. I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob-dam? Theorically, yes: there's nothing preventing such a thing. Wrapping such access behind functions was basically to allow checking that the values passed were in the correct range, and to provide encapsulation of the data (so that a plugin wouldn't get tempted to directly change fields it wasn't supposed to change without a high risk) That said, the plugin itself won't fix all the ills. That's true. It is a way to make some things easier, but it is definitely not a magical answer to all problems. My opinion is that it would make the code cleaning/maintenance easier, but it will certainly not do that maintenance by itself. To do that, more radical changes are needed in the basic functions as is, and that will break things. Sure ! But I think such changes would be easier to make if the code was, in a way or another, split into smaller entities, so that they affect only a limited part of it. And indeed, a lot of functions would benefit from some in-depth rebuilding. Also, part of the problems of code debugging/maintenance come to how things are distributed all around the code - finding where to add/change things is a rather complex task. Making small changes to make the code more readable and editable would thus be another important point to achieve, IMHO. all that said, I do think it is fair to discuss other work to be done - if you have limited resources, it makes sense to discuss where those resources go. Indeed, it does - as long as it stays a reasoned discussion attempting to find the best solution, and not a collection of ignorant rants and ridiculous analogies. I'm tired of having to read such useless things, which (un)surprizingly always come from the same person. Yet at the same time, given this is a volunteer project, one can't really force anyone to do anything. Yes, although I understand the urge that many people have to see some funny/interesting ideas implemented. Simply, there is a civilized way to ask for those, a way that unfortunately not everybody seems to have understood. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] (Python) script distribution
I think the webpage idea isn't very good - most people will simply ignore/dismiss them. I'd rather see harmless scripts get directly into the python subdirectory of the map repository, while the more controversial ones could get into an optional package, available at the same download location as the maps or the server. Controversed scripts could also get into /maps/python-optional - even if it means people will download some files they'll never use, I think that the space overhead is really negligible. As long as the added functionalities don't disturb the play balance (and are not too bugged :)), I think they should get into the maps CVS repository. That's exactly what we do when we add new functionalities coded in C, so there's no reason to handle this differently. -Original Message- From: Nicolas Weeger [EMAIL PROTECTED] To: Crossfire Discussion Mailing List crossfire@metalforge.org Date: Sun, 15 Jan 2006 14:45:42 +0100 Subject: [crossfire] (Python) script distribution Hello. There are a few (Python) scripts i'd like to write, to extend Crossfire. Merely thinking something like a visit card system (to let other players know your level or skill), or something to autorejoin party at login time. So I'm wondering where to put those scripts. Should I put them in the python subdirectory in maps, and assume everyone will want them? Should we create a new subdirectory with optional scripts? Should I put'em on some web page and let interested people download? Note that this can in some ways apply to existing scripts (occidental stuff scripts, for instance). I'd say either put in python subdir, or create a new subdirectory - it's the simplest way to distribute things imo. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] requestable spell lists.
One thing that was suggested by gros on IRC earlier was almost a hybrid approach, instead of having a stats value that says what type of change has occurred, you have a stats value that contains a number for the spell object, these would be assigned sequentially, and be unique for any one player on each run of the server. (everyone would have their spells numbered 1,2,3,4, etc.) Then, if ever a spell was added or removed (by moving the attunement into a seperate stat, and sending only the base cost, this can be the only time an update is needed), the stats command can send the number of the spell that was changed, and the client could then requestinfo # and get back only that spell. (this was my understanding of gros' suggestion, I hope he will clarify if I misunderstood some detail) Well, not quite. My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached. My vision of the communication scheme would be: C-S: spell id[fields] Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player. The optional fields argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose. S-C: spell nrspellsid 1information 1id 2information 2... This is either an answer to an explicit C-S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells. The information field would be something like this: - typeofchange (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=). - name (string): The internal name of the spell, as used in cast or invoke commands (burning hands); - caption (string): The visible name of the spell, as displayed by the client (Small Firestorm of Lhangwival). The client is free to do whatever it wants with its value. - cost (16bit): The base casting cost. ... and so on. The information content would depend on the content of the C-S spell flags/setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent. The S-C spell message is sent as soon as its trigger (reception of the C-S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process). Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK. I'd also like to underline that IMHO the client should never ever have to compute any value from a base value sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server. Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things. I also used a generic spell name for the command names - for what matters, it could in fact be requestinfo spell/replyinfo spell, or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] requestable spell lists.
One thing that was suggested by gros on IRC earlier was almost a hybrid approach, instead of having a stats value that says what type of change has occurred, you have a stats value that contains a number for the spell object, these would be assigned sequentially, and be unique for any one player on each run of the server. (everyone would have their spells numbered 1,2,3,4, etc.) Then, if ever a spell was added or removed (by moving the attunement into a seperate stat, and sending only the base cost, this can be the only time an update is needed), the stats command can send the number of the spell that was changed, and the client could then requestinfo # and get back only that spell. (this was my understanding of gros' suggestion, I hope he will clarify if I misunderstood some detail) Well, not quite. My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached. My vision of the communication scheme would be: C-S: spell id[fields] Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player. The optional fields argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose. S-C: spell nrspellsid 1information 1id 2information 2... This is either an answer to an explicit C-S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells. The information field would be something like this: - typeofchange (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=). - name (string): The internal name of the spell, as used in cast or invoke commands (burning hands); - caption (string): The visible name of the spell, as displayed by the client (Small Firestorm of Lhangwival). The client is free to do whatever it wants with its value. - cost (16bit): The base casting cost. ... and so on. The information content would depend on the content of the C-S spell flags/setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent. The S-C spell message is sent as soon as its trigger (reception of the C-S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process). Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK. I'd also like to underline that IMHO the client should never ever have to compute any value from a base value sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server. Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things. I also used a generic spell name for the command names - for what matters, it could in fact be requestinfo spell/replyinfo spell, or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Idea for skills
There should be NO redistribution of the quests IMHO. If you want more quests in an area do what I'm doing and make more (I'm working on a navar quest). If you don't make more quests you don't have a right to complain about a lack of quests in an area IMHO. First, I have the right to complain to whatever pleases me - who are you to dictate what I should think ? Second, notice that I was actually not speaking about a lack in *quantity*, but about a lack of proper *geographical distribution*. My idea was simply that each area would only contain quests of a given difficulty range (for example, Scorn would have level 1-15 ones, Brest level 15-30, Navar 30-45, etc), so that the player would be practically forced to travel at some point. Note that I am not considering this as a rigid system - Scorn could contain high-level quests for example, but access to them should then be dependent on the previous completion of a quest located in another area. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Idea for skills
I don't really like that idea. Sure, the intend - force people to explore the world furthermore - is good. But I see little justification of forcing them to make a given quest to increase their level. Arbitrarily capping the levels looks very artificial to me. On the other hand, I think that a similar principle (make some quests a must do to go further) could be used to unlock other quests and areas. Such a system would be easy to justify scenaristically-wise and would achieve the same result without artificially bending the skills/levels system, or requiring changes to the code. It would mean that a geographical redistribution of the quests would have to be done at some point, and/or that locks would have to be put to prevent access to higher-level quests. But all this sounds like map-making job, which I see as a better (or cleaner ?) way to go than creating another special-case to rules in the code. I tend to think that the whole problem of people not exploring the world all comes down to the quests structure and locations: people don't explore because they have no reasons to do it, and because travelling without encountering anything is just plain boring. I'm far from being convinced that we'd solve that problem with another piece of code - I think that improving *maps* would lead to more satisfying solutions. So, my opinion: - No to artificial capping of levels; - Yes to capping of quests and areas access, unlocking them by finishing some key quests. Le Samedi 26 Novembre 2005 15:47, Nicolas Weeger a écrit : Hello. Here's an idea concerning skills: add a cap level without doing a quest. For instance (levels are random numbers): a player could level up to 15 in one handed weapons. Then he'd need to complete a quest to be able to get to 25, then another for 40, and so on. The aim would be to force players to explore the world, to find those quests to reach higher levels. Of course the quests should be designed to be do-able with level ~15 / 25 / 40 one-handed weapon. Ryo ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgpRVNpvyZmJf.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Introducing item fatigue
annoying to be forced to wait before casting again. Fatigue allows them to cast multiple times in a row - if they are ready to handle the risks involved. Now, what about the Alchemist's Fatigue I'd say that it should basically work as the temporary fatigue I wrote about just before. It slowly recharges over time when doing nothing tiresome. Every complex action (casting a spell, or slashing monsters) should create fatigue. Caster's fatigue shouldn't increase the dangerousity level of the alchemical attempt, but instead its randomness: the more tired you are, the higher the chances of making an error in the process and thus the bigger the randomization of the results. Caster's fatigue helps fighting the case of scripters using several cauldrons alternatively to let them cool down - the caster him/herself will have to cool down as well if he wants to still be able to make useful work. This system has a kind of drawback, though: no longer you can safely play with alchemy whenever you want and especially after having emptied a couple of dungeons full of monsters. It forces you to planify your future actions. I'm not sure all players would easily agree with that. As the Cauldron Fatigue, I think the value of this stat shouldn't be clearly visible to the player - at most, he/she should get an evaluation of it, possibly false under some circumstances (drinking alcohol, for example). Some items could help fighting fatigue (like the coffee cup), too. So now, I ask to seasoned players their opinion about the fatigue idea: - Do you think it is an acceptable solution ? - If not, what are the possible issues you see ? - If not, what is your own proposal to solve the problem ? If players agree to spend a couple of minutes of their time to answer those, then the future system will probably be satisfying for most of them. It is up to you now, as I've written enough for today Smile -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgpEaRy0NIE5j.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] jcrossclient lives.
You missed my point. I wasn't suggesting that the JCrossclient should have been part of the CF client subtree (as the X11, GTK and GTK2 are), but siomply why the JCrossclient wasn't part of the main Crossfire tree, alongside the (C) client, the Java Editor, the server, or the map sets. Given that all other CF-related subprojects so far have all been integrated in a unique CVS root tree, I didn't get (and still don't) why it was different for JCrossclient. It would have allowed all CF developers to contribute to the Java client, instead of having to register a second time. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] chat-embeddable in webpage
Le Vendredi 21 Octobre 2005 00:14, Lord Youkai a écrit : I've been wondering if there was a way to embed a read-only view of chat into a server's webpage. For example, DeviantArt has a readonly view of the shoutbox in a sidebar, when your not logged in. It updates only when you refresh (unless your in the shoutbox itself) the page. The old Logger basically did this. Note that it is currently being rewritten, because it stayed in the cold for so long that it wasn't working anymore (and nobody obviously cared about it). Perhaps a neat feature to add along with inter-server chat could be an ability to embed a view of the current chats on a server. Server - web page communication has been done, as Mikee has proved with his Most richest players list.. *hum* again, the logger code for that kind of thing appeared in 2001 (it went to use on MiDS's server) - it used the logger alongside PHP pages and a postgresql database to do the job. There weren't really inter-server facilities, since those simply didn't exist at the time in the server. The problem was that it wasn't easy to set up. Furthermore, when the skill system changed, the plugin didn't get updated and became partly broken. Since it was in such a bad shape, I scrapped it during the plugin v2.0 transition a couple of days ago and am in the process of rewriting it. If you want to have a look at the old logger capabilities, just download one of the current stable server packages and have a look at the content of plugin_logger/. http://mids.student.utwente.nl/~crossfire should also still hold records of the logger, although the server seems down ATM. Expect the rewrite to have about the same functionalities as the old version, but hopefully with a cleaner, better implementation :). Just wondering. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgp3hXr4csCAJ.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Smooth movement
Basically, it consists on accepting input (whether it's actual input from the user, or a decision from the monster AI code) at a point in time half a tick before when the object actually gets its tick. Think of that as neural impulse delay. Does that make sense? It does. But I think that's just the first issue of the whole problem, and not the most complex one to solve, unfortunately. The first issue is with the protocol itself. Currently, the server basically sends the client a gird of objects that are strictly square-positioned. What about the transitioning objects (those who are in the middle of a move, at a position like (X+0.3;Y)) ? Two solutions: - Either you do not strictly synchronize the client with the server. You just send the same messages that are currently sent (thus no transitioning marker of any sort), let the client compute the supposed position of the character and backtrack if necessary when the server sends the next map update. You'll have to face synchronization problems at some point, obviously. - Or you include synchronization messages in the protocol - but then, you'll have to make drastic changes to it, which will require a complete redo on the redrawing side of the client. The second issue that's not really adressed is about what I call the square conflict problem. Suppose that your character attempts to move on a square S, but that a monster attempts exactly the same thing. With the current square-by-square gaming system, there's no problem: the faster one is moved on the square. Now, with a smooth move system, it means that you'll see one character being suddenly stopped at the edge of S, while the other is moving into it. It could lead to the rather strange situation of a character being hit by a monster that's not even right against you. I think that the question of knowing where the character is on the map while transitioning is a rather simple one; I see the major issues more in the client/server sync and with the current communication protocol, which doesn't seem to be easily adaptable to handle a smooth moves situation. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire Plugin System v2.0
The small rewrite of the Crossfire Plugin subsystem is nearing completion - finally. I think that a couple of explanations are necessary. Why ? - The main reason to answer the why a rewrite is that the older way of managing plugins was simply too complex and obscure. Using the CFParm structure to pass arguments between the server and the plugins initially seemed a good idea - but it came at the price of an heavy-to-write, heavy-to-use system. Having to fill in a table of CFParms and to ready a return CFParm structure is counterintuitive to what most C programmers usually do. What will change and how ? -- 1. Code Internals. The rewrite somewhat simplifies the code writing. Basically, most server functions are now exposed with the following prototype: void* cfapi_funct(int* type, ...) type indicates the type of the return value, as defined by constants in include/plugins.h. The arguments are now transmitted using the more conventional va_args mechanism. There is obviously a drawback in that the server now assumes that the correct parameter values are passed by the plugin - but expecting that the plugin developper passes a correct parameter type isn't too much asking IMHO. Moreover, a group of common server function wrappers has been written. When a new plugin is being developed, the coder should include those common wrappers in its compilation process. Those ensure that (1) the plugin coder doesn't need to directly call the server callback function pointers and (2) limits the possibility of passing wrong argument types. So for example, instead of having to use the void* cfapi_map_create_path(int* type, ...) callback and taking the risk of passing wrong argument types and having to manually manage typecasts and callback bindings, the plugin coder can call the common wrapper char* cf_get_maps_directory(char* str) and use it without worrying on how the plugin-server communication works. On the server-side, the code is also somewhat simpler, because the CFParm wrapping doesn't exist anymore - calling a plugin event now takes one or two lines, to compare with the dozen (or more) before. 2. Event hooks The second important change is how the events are bound to objects. Previously, plugins used various event_xxx fields in the object to bind. It has a rather annoying drawback: you couldn't bind more than one action to one event (chains of events weren't possible). The new system uses a new archetype type EVENT; the map-maker now wraps the binding in an event_xxx *object* that is stored in the inventory of the bound object. It allows to bind several plugins to a single event in a single object. It also removes the need for supplementary fields and makes the event subsystem more consistent with the everything is an object motto. 3. Compatibility with v1.0 of the plugin system The v1.0 plugins (there are currently 3) are *not* compatible, even at source level, with the v2.0 interface. There is also no effort made to ensure compatibility with objects bound with the 1.0 event_xxx tags, so map-makers will have to adapt them accordingly. Note that it isn't a lot of work - it isn't as if there were thousands of objects to convert. I could have assured compatibility, but it the work and code complexity it introduced seemed much greater than the work needed to convert the few objects that were using the old system. A potential problem may arise with players owning scripted objects, as those will cease to work. But unless there are *lots* of such cases (which is doubtful), simple manual exchange with newer versions of the objects from the DMs should suffice. What about the current plugins ? 1. CFPython The CFPython plugin has been rewritten to match the new interface. The occasion to rewrite it has been used to make the CFPython interface cleaner and (hopefully) easier from a Python-coder point-of-view. The most important change is the introduction of Python object types wrapping Crossfire entities (Crossfire Objects, Maps, and Players). Available functions are mostly the same (only those rendered obsolete by the new plugin infrastructure were removed), but they are now properties and methods of Python objects. Examples CFPython.AcquireSpell(target, spell) now becomes target.AcquireSpell(spell). CFPython.GetStrength(who) now becomes who.Str. CFPython.SetStrength(who,val) now becomes who.str = val. The conversion process is rather straightforward and shouldn't cause trouble - it took me an afternoon to convert all scripts supplied in maps-bigworld/python and I'm no Python specialist. 2. The Animator The Animator is currently being rewritten to work with the new plugin interface. Apart from the event-binding procedure, there should be no other change in the way it works. Work on it isn't finished, but shouldn't take years to complete, unlike CFPython :). 3. The Logger The Logger is outdated
Re: [crossfire] Unban me
Le Mardi 11 Octobre 2005 17:00, Mitch Obrian a écrit : I was banned from the debain lists because the debian people are pro-women's rights for the most part. The ban had no effect, I post to those lists at will (check out debian women's list for confirmation). Point is that if you follow the proper netiquette of good behavior, you'd never get banned from anywhere. Crossfire is a clique based project, it does not matter how much one contributes, if you don't obey the clique then it's felt that it's better that you leave. Keeping anarchy from crippling a project that exists for so many years, involving people with so many different habits is a difficult task. That's why there are some basical rules to follow - and it is already hard enough sometimes to coordinate everything. Being part of a community and participating to a project starts by accepting its rules. If you don't want to comply, provide good reasons to show in which way those rules are harmful for your work and should be changed. Apart from that, I agree with the clique: if you don't obey the rules, it is indeed better to leave. We wonder why there are few CF developers... There are more than enough developers for a project of that scale. well men usually don't take kindly to do as I say because you have to obey! mentality, which is the current CF mentality. Again, if you have good reasons not to comply to rules that were edicted for the goodness of everybody contributing, then expose them. Else, either comply or leave. Simple as that. Death To women's Rights. Keep your political rants outside of this list, which is devoted to Crossfire, not to your personal opinion about topics that aren't related to it. That's *also* part of common courtesy. Have a nice day. -- Yann Chachkoff --- Garden Dwarf's Best Friend --- GPG Key: http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 pgpxXWp22Yx9o.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
