From eracclists at bellsouth.net Tue Mar 1 02:51:59 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Mar 1 03:03:43 2005 Subject: [crossfire] A Bigworld map needs to be altered (quest area unreachable otherwise) In-Reply-To: <20050301015421.72773.qmail@web61006.mail.yahoo.com> References: <20050301015421.72773.qmail@web61006.mail.yahoo.com> Message-ID: <200503010251.59240.eracclists@bellsouth.net> On Monday 28 February 2005 07:54 pm Mitch Obrian wrote: > --- ERACC wrote: > > > On Sunday 27 February 2005 11:51 pm > > Mitch Obrian wrote: > > > > > The titan stronghold stronghold at world_125_124 is unreachable > > > because the area it is on is a big island. That area needs to > > > be attached to the main land. There are some places where it > > > almost makes it but not quite. > > [...] > > > > That is intentional because it is not a newbie quest. It requires > > a certain higher level spell to be used to get there. Figure it > > out. > > Dimention door, I know I use the same trick in some of my maps. > Unfortunatly it failed. That is a problem. > > It did not work over the water. Works fine here and on crossfire.metalforge.net to go over that tiny gap of water. No one else (I know about) has ever complained of the spell failing to get to that quest. Perhaps your maps are hosed or your version of the server is dinked up. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 02:47:05 up 47 days, 9:54, 7 users, load average: 0.05, 0.07, 0.08 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers From mikeeusaaa at yahoo.com Tue Mar 1 08:17:15 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Mar 1 08:23:46 2005 Subject: [crossfire] A Bigworld map needs to be altered (quest area unreachable otherwise) In-Reply-To: <200503010251.59240.eracclists@bellsouth.net> Message-ID: <20050301141715.21372.qmail@web61002.mail.yahoo.com> The maps and the server are last week's cvs... --- ERACC wrote: > On Monday 28 February 2005 07:54 pm > Mitch Obrian wrote: > > > --- ERACC wrote: > > > > > On Sunday 27 February 2005 11:51 pm > > > Mitch Obrian wrote: > > > > > > > The titan stronghold stronghold at > world_125_124 is unreachable > > > > because the area it is on is a big island. > That area needs to > > > > be attached to the main land. There are some > places where it > > > > almost makes it but not quite. > > > [...] > > > > > > That is intentional because it is not a newbie > quest. It requires > > > a certain higher level spell to be used to get > there. Figure it > > > out. > > > > Dimention door, I know I use the same trick in > some of my maps. > > Unfortunatly it failed. That is a problem. > > > > It did not work over the water. > > Works fine here and on crossfire.metalforge.net to > go over that tiny > gap of water. No one else (I know about) has ever > complained of the > spell failing to get to that quest. Perhaps your > maps are hosed or > your version of the server is dinked up. > > Gene > -- > Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 > 02:47:05 up 47 days, 9:54, 7 users, load > average: 0.05, 0.07, 0.08 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare > resellers > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Tue Mar 1 09:33:11 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Mar 1 09:38:46 2005 Subject: [crossfire] New maps almost ready for inital commit Message-ID: <20050301153311.40966.qmail@web61006.mail.yahoo.com> I am working on a bigworld area. https://cat2.dynu.ca/cat2/worldpatch.tar.gz This time I made the correct directory structure from the beginning and aptly named the folder. I will be working on it all week. Todd can we set aside our diff POVs as I now agree with you more. Also in the mlab set (which in CVS is up to you and other devs what to call it) I have included the relinking script which will put all the various maps of diffrent areas into diff subdirectories under the mlab-top directory (perhapse call it mdream? or maby name the dir dreamstate in a diff language?) the newest released version is R15 at https://cat2.dynu.ca/cat2/crossfiremaps-mlab-R15.tar.gz Note that after the char completes the inital tower quest (the story is told as he ascends the 40+ story tower) he finds a bed, sleeps on it, and then wakes up... or does he. From there the story contiues if he dares to seek out other quests in the land of the clouds... he happens to meet the wizard again in an even larger and more epic battle at the castle of the dark elves (who have ben devoured by the cult of death). A link is made between the widespread cult of the devourers and the actions of the wizard... he seems to be promoting that perticular cult as it moves those of the populus into a state that is benificial to him. Then there is the castle of the marquis. This area is even higher level then the castle of the dark elves.. it seems the marquis has succomed to the cult aswell... Now also in mlab I am working on a nice big hell quest including puzzles to solve on the road to hell. A link is made with the cult of the devourers and the pit of hell itself (which is being semi-modled after dante's discription: vestibule and limbo are true to form). The cult of the devours is popular on the road to hell ... and then it gives way to the evil behind all the madness. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From mwedel at sonic.net Wed Mar 2 02:25:16 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Mar 2 02:32:38 2005 Subject: [crossfire] GTKv2 client checked in Message-ID: <4225786C.1020501@sonic.net> For those of you that don't get the CVS log messages, I just checked in my gtk-version2 client. Below is a copy of the README file - if please read it before trying out the client (if you choose to do so). One thing that should be noted that after doing a cvs update -dP to get the new directory, you must run configure for it to even attempt to compile the client. If it finds the necessary libraries, it will compile it, if it doesn't, it won't try. But if you don't re-run configure, your makefile and other bits won't even know about the new client. This is an implementation of the crossfire client for gtk v2. At current time, this should be considered somewhere between alpha and beta quality code. I consider it complete enough that you should be able to play the game using this client. However, all the feature certainly are not implemented. It is just at the point of development where I consider it useful enough to make available and get feedback (as well as hopefully some others to help finish some things up). The client was designed largely to my tastes - this, what is implemented reflects the options I tend to use and the display I like. Please note some of the mechanics are a little different now. Containers are now displayed inline with inventory/look windows using tree widgets. The gtk-v2 client should be built automatically if you have the requisite libraries on your system (configure will detect them, add gtk-v2 to the list of directories to build). Note that the defaults file that this client uses for loading defaults is ~/.crossfire/gdefaults2. It uses the same keybinding and other files as the other clients. The following limitations/issues are known: 1) Many of the config options available in the gtk client are not available. It is likely some number of these will never re-appear (IMO, the GTK client had a problem of more and more options, which makes the code messier and messier). 2) The layout was designed for screens at 1280x1024 resolution or higher. Resizing the images and moving the panes around _may_ work on lower resolutions, but that wasn't my design goal. 3) SDL support is not yet implemented. 4) At least on my system, it overall seems slower than the gtk client - especially the inventory drawing area. I think this is a gtkv2 issue. 5) Map drawing is probably slower - rather than trying to redraw just changed spaces, it redraws the entire map - this should fix up some of the erroneous drawing as related to big images, but can be slower. If you find bugs, please report them on the sourceforge tracker: http://sourceforge.net/tracker/?group_id=13833&atid=113833 Please use the category gtk2-client. If you plan to work on code for the client, please browse the TODO file as well as the README-dev file. Mark Wedel March 1, 2005 From mikeeusaaa at yahoo.com Wed Mar 2 12:16:12 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 2 12:24:59 2005 Subject: [crossfire] Why does no one commit MLAB? Do you reject my maps? Is it personal?! Message-ID: <20050302181612.33570.qmail@web61004.mail.yahoo.com> Look. There is a script that will relink the mlab maps as you see fint into directoties, you can have the mlab maps in a TLDir of your choice of names and run the script which is included with the map pack. Why WHY! Won't anyone commit my maps? IS it personal?? This is insanely frusturating to work on maps that everyone consideres great (sans some woman... but I'm not surprised because I don't like her either and, ofcourse (she being a woman) would never fail to denergrate a man's work if it would suffice to cause him harm in some abstract way... which it doesn't: you fail woman) for a opensource game on my own time... ... to have scripts inclueded to put the maps into the dirs the devs insist on... to finally cave to their demands that the top level dir not have any recognition of it's author.. and apparenly that still isn't good enough. What More Do You Want? Why Won't You Upload The Maps? I have come to the point after about 2.5 or so years of working on crossfire that I NEED to have my work apriciated if I am to contiune with this project (I need to have my maps put in). Is that so hard or is there such anomosity twoards me that it is believed to be a good thing to see mikeeusa fail finally? WHY WONT YOU EVER UPLOAD MY MAPS I MADE THESE FOR YOUR PROJECT. Remeber you wouldn't have bronze items, ores, bars, or even the new mid-east style arches if it wasn't for me. I had the drive to make those contributions. And you won't upload my maps. WTF Why not. I HAVE CONTIRIBUTED YOU CAN'T ASK FOR MORE. I HAVE DONE ALL YOU HAVE ASKED. Upload them to CVS please so I can see that I matter to this project... or would you be happy at my departure. Is there an anti-progress air in here? https://cat2.dynu.ca/cat2/media.html is where the newest Mlab release can be found. Just put them in. It's easy enough to choose a dir name that you are not offended by. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From mikeeusaaa at yahoo.com Wed Mar 2 16:39:09 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 2 16:43:58 2005 Subject: [crossfire] I hear it's midterm week(s) Message-ID: <20050302223910.81740.qmail@web61010.mail.yahoo.com> Explains the drop in list use this week :P. I'm progressing on the whaling villages areas. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From b.t.lally at warwick.ac.uk Wed Mar 2 18:26:51 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Mar 2 18:13:58 2005 Subject: [crossfire] proposal: quest tracking Message-ID: <200503030026.52176.b.t.lally@warwick.ac.uk> Following on from a discussion on IRC and after prompting from Lauwenmark, I hereby submit a design proposal that might simplify questing (for a player) within the game. Quest fields a new header for maps be permitted, questmsg a new value for items also called questmsg be permitted. a new item type quest_tracker would exist. that on entering a map, if a quest is defined for the map, then that quest is deemed to have started. A simple example, terry's farm in scorn. This is the simplest quest map that I know off-hand, there is a farmhouse with a small troll in, a key opens a door, where the troll is found, and the head of the troll is used to open the treasure chamber. (map is scorn/houses/farmhouse if anyone wants to see it for themselves) map header would be adjusted to have the lines questmsg guuhs_head You come across a peaceful looking farmhouse, but something seems to be amiss, perhaps you should investigate.... endquestmsg added. when a player enters the map, they will be considered to have started the guuh's head quest. Information about which quests the player has undertaken would be stored with the player as a separate invisible quest item for each quest. If there is no item existing corresponding to that quest, then it has been only just started, if there is an item corresponding to the quest then increment its level and add the new message to the msg field of the item If they talk to the farmer, he would have questmsg guuhs_head The farmer tells you about the raiders who have occupied his farm, and begs you to help, telling you to take the key in his kitchen and free them from the bandits. endquestmsg the key would have a similar entry questmsg guuhs_head You have acquired the key you need to unlock the door to the barn where the bandits who have been plaguing the bandits lurk.... end questmsg the head itself would hold questmsg guuhs_head You have killed the leader of the brigands, and will doubtless be rewarded handsomely for your valour end questmsg and then when the door to the treasure chamber is opened questmsg guuhs_head You have saved the farmers etc etc terminate_quest terminate_quest (or something similar) would mark a quest as done. (would set a field in the quest item?) to use this then, one new command is needed, quests. typing quests would list completed quests knight_of_scorn baronet_of_scorn scorn_gate_password memeber_of_guild_of_freedom ... ongoing quests guuhs_head assasinate_gothwalte ... then the command quests guuhs_head would display all information (inside the questmsg) about that quest. potential objections: It involves potentially many invisible items, although there are already many of them, and any quests have them already anyway, and there is no real consistency with how they are treated. By having a quest item for each quest, and a standard check for the completion of the quest then it is easier to check for them. It involves lots of changes to the maps to add all the quest information, however this can be done slowly over time, and an empty questmsg-endquestmsg block would simply not give any detailed information for the quests command, whilst still being enough to track start and end of quests. OTOH It would make it far easier to have quests not be ignored, and will mean that it is easier to mark when something significant has been said. The parsing is quite simple, since it can just be a simple change to the way that the msg block is parsed, make it call an external function and multiple quest blocks could be attached to each item. Possible extension to this idea, allow quests to be specified as; questmsg foo+n endquestmsg where +n is the increase to the level of the quest tracker item, progress through a quest then can be measured by comparing level against what it should be to keep track of what a player knows for them. From temitchell at sympatico.ca Wed Mar 2 20:39:55 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Wed Mar 2 20:43:59 2005 Subject: [crossfire] Why does no one commit MLAB? Do you reject my maps? Is it personal?! In-Reply-To: <20050302181612.33570.qmail@web61004.mail.yahoo.com> References: <20050302181612.33570.qmail@web61004.mail.yahoo.com> Message-ID: <1109817595.4495.28.camel@oberon.kameria> Basically it's easier to deal with smaller things than great big things. To commit maps to CVS they have to be tested, any arches they use have to be in the arch CVS and tested before that, and any maps they touch on have to be checked as well (within reason). Also if there are scritps or widgets or other things that need to be used to generate or massage the sources - well we have to take time to deal with that stuff before we can even start. Add this to the amount of time we can spend on crossfire (many folks have spouses, jobs, kids, other projects and down time) and you can easily see why a small change like the Navar maps can be done (that small change still took a few hours out of a busy Sunday) while something like the mlab maps is just off the scale. Other developers were taking on the chore of this mapset so I have not even looked at it for some time. If I commit something I have to take responsibility for it and if I screw up and Metalforge is in chaos or down because of something I did and I don't want to have to go without sleep on a work night to fix it. So this is why we have: "bronze items, ores, bars, [and] even the new mid-east style arches" They were managable pieces. Lots of things I have been waiting for for a long time. I have projects on the go as well (smuggler quest has been a looong time in the making) I keep picking away at what I can commit and keep the works in progress in progress. The thing is you either wait or you do it yourself. If you don't have CVS access (and likely even if you do) you have to make your submissions as easy as possible to test and submit them. If you have a bug fix request you make it as easy as possible for someone to locate and fix it, an enhancement request, as easy as possible for someone to implement it, if you have new graphics you make them as easy as possible for people to get and test... You get the picture. Besides I thought Salathar or Ryo were working on the maps. From mikeeusaaa at yahoo.com Wed Mar 2 21:18:45 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 2 21:24:00 2005 Subject: [crossfire] Why does no one commit MLAB? Do you reject my maps? Is it personal?! In-Reply-To: <1109817595.4495.28.camel@oberon.kameria> Message-ID: <20050303031845.52301.qmail@web61009.mail.yahoo.com> Salathar has been off the chart for a bit. I made a new release with the dir structure cleaned up abit (the maps are still in the one dir but the other stuff is in their own dirs). https://cat2.dynu.ca/cat2/crossfiremaps-mlab-R16.tar.gz all the arches that are in mlab are in https://cat2.dynu.ca/crossfirearch (Sans navarian, I didnt use any in mlab, so the proper name change dosn't affect it :) ) --- Todd Mitchell wrote: > Basically it's easier to deal with smaller things > than great big things. > > To commit maps to CVS they have to be tested, any > arches they use have > to be in the arch CVS and tested before that, and > any maps they touch on > have to be checked as well (within reason). Also if > there are scritps > or widgets or other things that need to be used to > generate or massage > the sources - well we have to take time to deal with > that stuff before > we can even start. > > Add this to the amount of time we can spend on > crossfire (many folks > have spouses, jobs, kids, other projects and down > time) and you can > easily see why a small change like the Navar maps > can be done (that > small change still took a few hours out of a busy > Sunday) while > something like the mlab maps is just off the scale. > Other developers > were taking on the chore of this mapset so I have > not even looked at it > for some time. > If I commit something I have to take responsibility > for it and if I > screw up and Metalforge is in chaos or down because > of something I did > and I don't want to have to go without sleep on a > work night to fix it. > > So this is why we have: > > "bronze items, ores, bars, [and] even the new > mid-east style arches" > > They were managable pieces. > > Lots of things I have been waiting for for a long > time. I have projects > on the go as well (smuggler quest has been a looong > time in the making) > I keep picking away at what I can commit and keep > the works in progress > in progress. The thing is you either wait or you do > it yourself. If > you don't have CVS access (and likely even if you > do) you have to make > your submissions as easy as possible to test and > submit them. If you > have a bug fix request you make it as easy as > possible for someone to > locate and fix it, an enhancement request, as easy > as possible for > someone to implement it, if you have new graphics > you make them as easy > as possible for people to get and test... > > You get the picture. Besides I thought Salathar or > Ryo were working on > the maps. > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From mwedel at sonic.net Thu Mar 3 02:06:01 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Mar 3 02:09:02 2005 Subject: [crossfire] proposal: quest tracking In-Reply-To: <200503030026.52176.b.t.lally@warwick.ac.uk> References: <200503030026.52176.b.t.lally@warwick.ac.uk> Message-ID: <4226C569.9090602@sonic.net> Brendan Lally wrote: > Following on from a discussion on IRC and after prompting from Lauwenmark, I > hereby submit a design proposal that might simplify questing (for a player) > within the game. Random question - any reason this couldn't be done by adding a tag type to the current message display to denote it is quest related info? Eg, something like: %quest guuhs head this is info about guuhs head The say routines could be modified to look for the %quest tag, strip them out, and update the appropriate quest object. Likewise, the enter object code could look for these messages. This reduces the work by quite a bit, as no new fields need to be added. It also has the advantage it could be used with the existing tags, so something like: @match guuh %quest guuhs head @match bandit %quest guuhs head and so on. Since it would be the actual say routine that would look for the %match, should be relatively easy to do. could be other % tags also. Presumably, when the quest is completed, you probably want to have a magic mouth present that fact, so you could do something like: %terminate_quest guuhs head Just a thought. From mwedel at sonic.net Thu Mar 3 02:31:18 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Mar 3 02:34:02 2005 Subject: [crossfire] Why does no one commit MLAB? Do you reject my maps? Is it personal?! In-Reply-To: <20050303031845.52301.qmail@web61009.mail.yahoo.com> References: <20050303031845.52301.qmail@web61009.mail.yahoo.com> Message-ID: <4226CB56.6070207@sonic.net> What Todd said is somewhat true - easy to deal with small pieces than big. Probably gets compounded that if I'm looking at a patch that takes say half an hour to verify/apply, odds pretty low that no one else will being do so in that same time frame and thus no likelihood of duplicated effort/loss of work. If something takes several hours, or perhaps enough time that the actual examination and commit will be spread accross several days, odds are higher. So then everyone sort of waits and is looking for someone else to do it, and it falls through the cracks. I'll try to find time to do it, but hard to promise anything. It's probably a wise idea to open a patch one sourceforge for this, as a person can take responsibility to avoid issue of conflicts I mention above. You probably can't update the patch to sourceforge, but can still provide pointers - that provides better tracking than e-mail messages (generally speaking, I get enough e-mails that crossfire e-mail falls into basically these 3 categories: 1) RFC - person asking question - will generally respond to those, if not, delete. 2) message from sourceforge about bug submission, patch, etc: delete - will look at sourceforge when I have time for further info. 3) report of bug or patch submission through mailing list, not on sourceforge: Generally delete, on the theory/hope someone else may take care of it and I don't want it clogging my e-mail box (and they should have submitted it on sourceforge anyways). If the issue seems trivial to answer/fix, I may take care of it, but if I have to spend appreciable time, probably deleted. All that said, personality and likability do make some difference. I think it is safe to say that it is human nature that people are more likely to help out those people they like, and less likely (or unlikely) to help out those they don't like. Probably even more so given crossfire is 100% volunteer (at work, you may work with people you don't like on the basis it keeps you employed. For a volunteer project, one can just ignore whatever they like). So your views and initial reluctance to change the layout may have made it so that some people capable of doing the commit just have zero interest in doing it for you, which then reduces the number of people willing/able to do so. From nicolas.weeger at laposte.net Thu Mar 3 04:38:34 2005 From: nicolas.weeger at laposte.net (nicolas.weeger) Date: Thu Mar 3 05:04:03 2005 Subject: [crossfire] proposal: quest tracking Message-ID: Hi. Nice idea! I'd suggest doing quest tracking like markers, though: with creators, detector and modifiers objects. So you can forbid a player entering some place if s/he isn't doing the quest, and so on - like a non transferable item, but invisible. This way you can make the player start a quest by saying something to an NPC, then end the quest when entering a room, or killing a monster (make it drop the quest modifier!), and so on. The only point is, how would you track the quest information the player has? IE if s/he got 3 hints, do we store the hints in the player as hidden fields? Of course they can be removed later on, when quest is completed. As for the say command modified, sounds like a nice idea. This way it's more flexible what an NPC can say depending on quest the player is doing. Anyone willing to work on that? I could do it, if no one wants :) Ryo who is kind of back on the net, and may just have time to work on CF some more. Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050303/f8292284/attachment.html From tchize at myrealbox.com Thu Mar 3 13:26:30 2005 From: tchize at myrealbox.com (tchize) Date: Thu Mar 3 13:29:08 2005 Subject: [crossfire] proposal: quest tracking In-Reply-To: References: Message-ID: <200503032026.35195.tchize@myrealbox.com> Nice project, overall Just a short(#) note on the way to track quests. IMHO the actual way to track things on player (using forces and other invisible objects in inventory) has it's use only when you need to check them against detectors (check-inv). This way of handling things has a major problem, i think, in terms of code readability. The main reason it was saved in the inventory is becasue the player is saved as an object and everything in crossfire is object. However, there are already specific fields for the player which are saved outside of the object saving code. I think the markers (at least new ones, like is the case for quest) should have this special behaviour too. We should maintain a simple list in player having the form 'key=value' with key and value as a string. If we used more of such marker in future (am working currently on a system to have npcs 'memorize' what they already said to a player and change their dialog according to markers stored in player) we have a problem because scanning the inventory to 'search for a keyed item' is quite slow. We can not keep the list ordered, and this list contain not only markers but also all the player inventory. And we all know players can have lot's of thing in their inventory. It should be quite easy to have check-inv code additionnaly checks this list for values which key correspond to an existing key. For the saving, we could save the player markers like this: marker quest.scorn.assasinate_gothwalte got the knive endmarker marker scorn.title knight of scorn endmarker marker quest.scorn.terrys_farm.guuhs_head pending endmarker marker quest.someQuest.someSpecialValue some multilines value endmarker The code could then implements functions like char* getPlayerMarkerString(player,key); int getPlayerMarkerInt(player,key); int getPlayerMarkerBoolean(player,key); void setPlayerMarkerString(player,key,value); void setPlayerMarkerInt(player,key,value); void setPlayerMarkerBoolean(player,key,value); So, to resume: *Positive points - marker list easier to manage - can be checked agains existence/value with check-inv - more marker intensive things like conditional dialogs with npcs easier to manage and won't risk to become bottlenecks - an admin opening player file can easily see all player markers and their value - easier to debug (i remember player losing the 'knight of scorn' tag in the past because the marker had a time out) - using a dot based marker like in example would help regroup infos from a same quest *Negative points - Need to adjust check_inv functions - May the coder implementing it will have some compatibilities nightmares (WHO said tchize? sending virtual aspros to Ryo) Now, the rest of suggestion. I like the idea to have all objects' message conditionned by the quest parameter. I like the suggestion of mwedel too, and i think it makes lots of sense. But just one thing. Why use a tag named %quest while a more generic tag named %marker would be more usefull and could be made to check the existence of a given marker, not only quest markers. And for the quests hints, maybe have an other list in player for quest, aka and array of 'quest entries' saved like this: quest guuhs_head done questmsg guuhs_head.title A troll at terry's farm endquestmsg questmsg guuhs_head.farmer The farmer tells you about the raiders who have occupied his farm, and begs you to help, telling you to take the key in his kitchen and free them from the bandits. endquestmsg questmsg guuhs_head. You have killed the leader of the brigands, and will doubtless be rewarded handsomely for your valour endquestmsg questmsg guuhs_head You have saved the farmers etc etc endquestmsg the quest guuhs_head done tell server there is a quest labeled guuhs_head and which is finished then all questmsg starting with guuhs_head will be considered as hints which could be shown by the client in som logbook Anyway, whichever implementation you choose, i approve a system where quest will be more formalized. Cya, going back to some protocol modifications. (Ryo, i just reminded, i need those aspros for tonight) (#)Just kidding, this is NOT a short note:) Le Jeudi 03 Mars 2005 11:38, nicolas.weeger a ?crit : Hi. Nice idea! I'd suggest doing quest tracking like markers, though: with creators, detector and modifiers objects. So you can forbid a player entering some place if s/he isn't doing the quest, and so on - like a non transferable item, but invisible. This way you can make the player start a quest by saying something to an NPC, then end the quest when entering a room, or killing a monster (make it drop the quest modifier!), and so on. The only point is, how would you track the quest information the player has? IE if s/he got 3 hints, do we store the hints in the player as hidden fields? Of course they can be removed later on, when quest is completed. As for the say command modified, sounds like a nice idea. This way it's more flexible what an NPC can say depending on quest the player is doing. Anyone willing to work on that? I could do it, if no one wants :) Ryo who is kind of back on the net, and may just have time to work on CF some more. Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050303/8432718a/attachment.pgp From nicolas.weeger at laposte.net Thu Mar 3 14:57:51 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Mar 3 15:04:08 2005 Subject: [crossfire] Client 1.7.1 release Message-ID: <42277A4F.50300@laposte.net> 'lo everyone. Since apparently the Evil Black Hole ate the announcement mails, i'm proud to announce the release of Crossfire Client 1.7.1. Windows version is a few minutes away :) Ryo From mikeeusaaa at yahoo.com Thu Mar 3 15:56:42 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Mar 3 15:59:09 2005 Subject: [crossfire] 4 New stair arches, please commit soon (I want to use them in a map of mine connected in bigworld) Message-ID: <20050303215643.56894.qmail@web61007.mail.yahoo.com> https://cat2.dynu.ca/crossfirearch/stair3_gstone_do.arc https://cat2.dynu.ca/crossfirearch/stair3_gstone_do.base.111.png https://cat2.dynu.ca/crossfirearch/stair3_gstone_up.arc https://cat2.dynu.ca/crossfirearch/stair3_gstone_up.base.111.png https://cat2.dynu.ca/crossfirearch/stair3_ystone_do.arc https://cat2.dynu.ca/crossfirearch/stair3_ystone_do.base.111.png https://cat2.dynu.ca/crossfirearch/stair3_ystone_up.arc https://cat2.dynu.ca/crossfirearch/stair3_ystone_up.base.111.png stair3_gstone_do.arc stair3_gstone_do.base.111.png stair3_gstone_up.arc stair3_gstone_up.base.111.png stair3_ystone_do.arc stair3_ystone_do.base.111.png stair3_ystone_up.arc stair3_ystone_up.base.111.png https://cat2.dynu.ca/crossfirearch __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From mikeeusaaa at yahoo.com Thu Mar 3 15:57:41 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Mar 3 16:06:26 2005 Subject: [crossfire] New maps (not mlab) Message-ID: <20050303215742.8201.qmail@web61002.mail.yahoo.com> Here are some new maps made for bigworld on fresh never-before touched worldmaps :) https://cat2.dynu.ca/cat2/worldpatch.tar.gz Uses chalices from https://cat2.dynu.ca/crossfirearch (are they in allready?) Please up to cvs. (Note: all maps are tested on cat2.dynu.ca crossfire server) --MikeeUSA-- __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From won_fang at yahoo.com.au Thu Mar 3 21:19:47 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Thu Mar 3 21:29:11 2005 Subject: [crossfire] I'm not allowed to spend time on this for now. Message-ID: <20050304131947.75b83972@cluster.meeting.humbug.org.au> I have to stop being a Crossfire maintainer, those that control my life have me doing too much other stuff. OTOH, I have not done anything here for a while anyway. If anybody wants to salvage my Ice Castle maps, I will happily hand them over. There are some good ideas and widgets in them. I particularly don't want to see the escalators go to waste. Since I have not worked on them for a while, things have broken as the code base moved on. The dance routines went haywire sometime ago. I may even find time to add more notes about what I was planning. One of the major things they now have me working on is creating an LSB (Linux Standard Base) compliant Linux distribution. I may still be able to do some good for Crossfire after all. The first game I will add to this distro should be Crossfire, and I can run an LSB audit on it. If the Crossfire gods will be pleased to see Crossfire turned into an LSB compliant application, they can leave me as an official maintainer with that task. Otherwise, you should probably remove my CVS write access and stuff. Thanks. it's been fun. From mikeeusaaa at yahoo.com Thu Mar 3 23:08:55 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Mar 3 23:14:12 2005 Subject: [crossfire] I'm not allowed to spend time on this for now. In-Reply-To: <20050304131947.75b83972@cluster.meeting.humbug.org.au> Message-ID: <20050304050855.3341.qmail@web61002.mail.yahoo.com> I'd love to see your maps. Could you send them to me at mikeeusaaa@yahoo.com? --- David Seikel wrote: > I have to stop being a Crossfire maintainer, those > that control my life > have me doing too much other stuff. OTOH, I have > not done anything here > for a while anyway. > > If anybody wants to salvage my Ice Castle maps, I > will happily hand them > over. There are some good ideas and widgets in > them. I particularly > don't want to see the escalators go to waste. > Since I have not worked > on them for a while, things have broken as the code > base moved on. The > dance routines went haywire sometime ago. I may > even find time to add > more notes about what I was planning. > > One of the major things they now have me working on > is creating an LSB > (Linux Standard Base) compliant Linux distribution. > I may still be able > to do some good for Crossfire after all. The first > game I will add to > this distro should be Crossfire, and I can run an > LSB audit on it. > > If the Crossfire gods will be pleased to see > Crossfire turned into an > LSB compliant application, they can leave me as an > official maintainer > with that task. Otherwise, you should probably > remove my CVS write > access and stuff. > > Thanks. it's been fun. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From won_fang at yahoo.com.au Thu Mar 3 23:44:13 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Thu Mar 3 23:49:12 2005 Subject: [crossfire] I'm not allowed to spend time on this for now. In-Reply-To: <20050304050855.3341.qmail@web61002.mail.yahoo.com> References: <20050304131947.75b83972@cluster.meeting.humbug.org.au> <20050304050855.3341.qmail@web61002.mail.yahoo.com> Message-ID: <20050304154413.4ec173bb@cluster.meeting.humbug.org.au> On Thu, 3 Mar 2005 21:08:55 -0800 (PST) Mitch Obrian wrote: > I'd love to see your maps. Could you send them to me > at mikeeusaaa@yahoo.com? Yes, but it will have to wait until next week. Any minute now I'm going away for the weekend. At least I will have some time to write some more notes. BTW, they already follow the guide lines for file and directory naming B-). From mwedel at sonic.net Fri Mar 4 01:38:38 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 4 01:44:13 2005 Subject: [crossfire] proposal: quest tracking In-Reply-To: <200503032026.35195.tchize@myrealbox.com> References: <200503032026.35195.tchize@myrealbox.com> Message-ID: <4228107E.8080100@sonic.net> tchize wrote: > Nice project, overall > > Just a short(#) note on the way to track quests. > IMHO the actual way to track things on player (using forces and other > invisible objects in inventory) has it's use only when you need to check them > against detectors (check-inv). > This way of handling things has a major problem, i think, in terms of code > readability. The main reason it was saved in the inventory is becasue the > player is saved as an object and everything in crossfire is object. However, > there are already specific fields for the player which are saved outside of > the object saving code. there are a few saved outside of objects. But it is fewer and fewer. There are lots of advantages to saving all data as objects and not add new fields to the player object: 1) Can add as many objects as necessary - not limited to potential data sizes in the player structure. 2) Having objects let all the object manipulation code work, eg, scripts don't need new hooks to get to this new information, dm commands that work on objects still work, etc. 3) Object is much more extensible - using key/value pairs gets into the case of someone asking 'I also want to store xyz in this key'. The object already has lots of fields that can be used to store data. The only disadvantage is that objects are stored in a list, so as said, performance isn't great. However, this almost is never a problem - the number of times the player inventory is typically examined/search is relatively low. And unless you have hundreds of such markers, performance shouldn't make a significant difference (and if you do have hundreds of such objects, storing them in a key/value list isn't going to be any faster). I have suggested, but never got around to doing, is making 2 inventory lists for all objects - one covering visible objects, one covering invisible objects. This helps some of the performance issues (all those markers won't slow down access for all the normal everyday objects), but can still work with all the above (the inv_invis list/last object of it could be linked to the normal inventory list, or perhaps vice versa) - this effectively sorts the inventory into invisible and non invisible, which certainly helps things out some. From mikeeusaaa at yahoo.com Fri Mar 4 09:25:28 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 4 09:29:16 2005 Subject: [crossfire] To Todd Fwd: A navarian archtype was forgotten: castle_a_navarian (or castle_a_west) Message-ID: <20050304152528.15302.qmail@web61009.mail.yahoo.com> As castle_a_west.arc etc Note: forwarded message attached. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ -------------- next part -------------- An embedded message was scrubbed... From: Mitch Obrian Subject: A navarian archtype was forgotten: castle_a_navarian (or castle_a_west) Date: Thu, 3 Mar 2005 19:09:03 -0800 (PST) Size: 1654 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050304/83bf6d48/attachment.mht From josh at woosworld.net Fri Mar 4 09:26:00 2005 From: josh at woosworld.net (Joshua Wilson) Date: Fri Mar 4 12:11:06 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/exit/Up_down In-Reply-To: References: Message-ID: <1109949960.3939.27.camel@lilwoo> Incidentally, these png's are about 10x larger then the rest of the stair png's. #1 - Do we have a requirement for the size here? Josh On Fri, 2005-03-04 at 10:23, crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: arch > Committed By: majorwoo > Date: Fri Mar 4 15:23:28 UTC 2005 > > Added Files: > arch/exit/Up_down: stair3_gstone_do.arc stair3_gstone_do.base.111.png > stair3_gstone_up.arc stair3_gstone_up.base.111.png > stair3_ystone_do.arc stair3_ystone_do.base.111.png > stair3_ystone_up.arc stair3_ystone_up.base.111.png > > Log Message: > New stone stair arches > > > > Start of context diffs > > > Index: arch/exit/Up_down/stair3_gstone_do.arc > diff -c /dev/null arch/exit/Up_down/stair3_gstone_do.arc:1.1 > *** /dev/null Fri Mar 4 07:23:29 2005 > --- arch/exit/Up_down/stair3_gstone_do.arc Fri Mar 4 07:23:28 2005 > *************** > *** 0 **** > --- 1,9 ---- > + Object stair3_gstone_do > + name stairs going down > + face stair3_gstone_do.111 > + type 66 > + no_pick 1 > + editable 2 > + visibility 100 > + magicmap brown > + end > > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs From mikeeusaaa at yahoo.com Fri Mar 4 13:20:57 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 4 13:24:19 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/exit/Up_down In-Reply-To: <1109949960.3939.27.camel@lilwoo> Message-ID: <20050304192057.5528.qmail@web61003.mail.yahoo.com> Nope they're the same size as they were made from the wooden ones. If they look bigger it's an optical illusion. Also stone stairways usually are abit larger then regular ones anyhow. I Just checked and the png's are all 32x32 just like the other stairs https://cat2.dynu.ca/crossfirearch/ --- Joshua Wilson wrote: > Incidentally, these png's are about 10x larger then > the rest of the > stair png's. > > #1 - Do we have a requirement for the size here? > > Josh > > On Fri, 2005-03-04 at 10:23, > crossfire-cvs-admin@lists.sourceforge.net > wrote: > > Module Name: arch > > Committed By: majorwoo > > Date: Fri Mar 4 15:23:28 UTC 2005 > > > > Added Files: > > arch/exit/Up_down: stair3_gstone_do.arc > stair3_gstone_do.base.111.png > > stair3_gstone_up.arc > stair3_gstone_up.base.111.png > > stair3_ystone_do.arc > stair3_ystone_do.base.111.png > > stair3_ystone_up.arc > stair3_ystone_up.base.111.png > > > > Log Message: > > New stone stair arches > > > > > > > > Start of context diffs > > > > > > Index: arch/exit/Up_down/stair3_gstone_do.arc > > diff -c /dev/null > arch/exit/Up_down/stair3_gstone_do.arc:1.1 > > *** /dev/null Fri Mar 4 07:23:29 2005 > > --- arch/exit/Up_down/stair3_gstone_do.arc Fri Mar > 4 07:23:28 2005 > > *************** > > *** 0 **** > > --- 1,9 ---- > > + Object stair3_gstone_do > > + name stairs going down > > + face stair3_gstone_do.111 > > + type 66 > > + no_pick 1 > > + editable 2 > > + visibility 100 > > + magicmap brown > > + end > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Crossfire-cvs mailing list > > Crossfire-cvs@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Fri Mar 4 13:17:25 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 4 13:24:21 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/exit/Up_down In-Reply-To: <1109949960.3939.27.camel@lilwoo> Message-ID: <20050304191725.89527.qmail@web61006.mail.yahoo.com> What do you mean, they should be 32x32 like the rest... --- Joshua Wilson wrote: > Incidentally, these png's are about 10x larger then > the rest of the > stair png's. > > #1 - Do we have a requirement for the size here? > > Josh > > On Fri, 2005-03-04 at 10:23, > crossfire-cvs-admin@lists.sourceforge.net > wrote: > > Module Name: arch > > Committed By: majorwoo > > Date: Fri Mar 4 15:23:28 UTC 2005 > > > > Added Files: > > arch/exit/Up_down: stair3_gstone_do.arc > stair3_gstone_do.base.111.png > > stair3_gstone_up.arc > stair3_gstone_up.base.111.png > > stair3_ystone_do.arc > stair3_ystone_do.base.111.png > > stair3_ystone_up.arc > stair3_ystone_up.base.111.png > > > > Log Message: > > New stone stair arches > > > > > > > > Start of context diffs > > > > > > Index: arch/exit/Up_down/stair3_gstone_do.arc > > diff -c /dev/null > arch/exit/Up_down/stair3_gstone_do.arc:1.1 > > *** /dev/null Fri Mar 4 07:23:29 2005 > > --- arch/exit/Up_down/stair3_gstone_do.arc Fri Mar > 4 07:23:28 2005 > > *************** > > *** 0 **** > > --- 1,9 ---- > > + Object stair3_gstone_do > > + name stairs going down > > + face stair3_gstone_do.111 > > + type 66 > > + no_pick 1 > > + editable 2 > > + visibility 100 > > + magicmap brown > > + end > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Crossfire-cvs mailing list > > Crossfire-cvs@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From mikeeusaaa at yahoo.com Fri Mar 4 13:22:38 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 4 13:35:37 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/exit/Up_down In-Reply-To: <1109949960.3939.27.camel@lilwoo> Message-ID: <20050304192238.5782.qmail@web61003.mail.yahoo.com> Most of the other stairs are set monocrome or palleted. --- Joshua Wilson wrote: > Incidentally, these png's are about 10x larger then > the rest of the > stair png's. > > #1 - Do we have a requirement for the size here? > > Josh > > On Fri, 2005-03-04 at 10:23, > crossfire-cvs-admin@lists.sourceforge.net > wrote: > > Module Name: arch > > Committed By: majorwoo > > Date: Fri Mar 4 15:23:28 UTC 2005 > > > > Added Files: > > arch/exit/Up_down: stair3_gstone_do.arc > stair3_gstone_do.base.111.png > > stair3_gstone_up.arc > stair3_gstone_up.base.111.png > > stair3_ystone_do.arc > stair3_ystone_do.base.111.png > > stair3_ystone_up.arc > stair3_ystone_up.base.111.png > > > > Log Message: > > New stone stair arches > > > > > > > > Start of context diffs > > > > > > Index: arch/exit/Up_down/stair3_gstone_do.arc > > diff -c /dev/null > arch/exit/Up_down/stair3_gstone_do.arc:1.1 > > *** /dev/null Fri Mar 4 07:23:29 2005 > > --- arch/exit/Up_down/stair3_gstone_do.arc Fri Mar > 4 07:23:28 2005 > > *************** > > *** 0 **** > > --- 1,9 ---- > > + Object stair3_gstone_do > > + name stairs going down > > + face stair3_gstone_do.111 > > + type 66 > > + no_pick 1 > > + editable 2 > > + visibility 100 > > + magicmap brown > > + end > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Crossfire-cvs mailing list > > Crossfire-cvs@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From b.t.lally at warwick.ac.uk Fri Mar 4 14:00:29 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Fri Mar 4 13:49:18 2005 Subject: [crossfire] regions In-Reply-To: <200502210010.41453.brenlally@ntlworld.com> References: <200502210010.41453.brenlally@ntlworld.com> Message-ID: <200503042000.29525.b.t.lally@warwick.ac.uk> My original message on this thread is now obsoleted, I have fixed the Makefile issue myself and the patch has been updated on the sourceforge tracker. http://sourceforge.net/tracker/index.php?func=detail&aid=1145089&group_id=13833&atid=313833 Whilst it won't do anything without the map files being edited It also won't do anything bad, and it has been tested with a partially updated map set. The region definitions themselves have been updated from the wiki; http://crossfire.freezope.org/wiki/CF_lore_wiki/RegionDefinitions Since I have resolved my previous issue with this patch. I now wish to request that it be merged into CVS. From temitchell at sympatico.ca Fri Mar 4 15:43:23 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Mar 4 15:50:16 2005 Subject: [crossfire] To Todd Fwd: A navarian archtype was forgotten: castle_a_navarian (or castle_a_west) In-Reply-To: <20050304152528.15302.qmail@web61009.mail.yahoo.com> References: <20050304152528.15302.qmail@web61009.mail.yahoo.com> Message-ID: <4228D67B.4060405@sympatico.ca> Howdy, I didn't forget the castle_a arch - I was going to add a thin black border in to give it some more definition. as it is now it seems too flat and blends too much in with the background. I want it to look more like your other images for the the little castle and for the Hold (that one looks really nice). It has taken me a bit longer to get to it than I thought however. Mitch Obrian wrote: >As castle_a_west.arc etc > >Note: forwarded message attached. > > > > From mikeeusaaa at yahoo.com Fri Mar 4 16:46:09 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 4 16:52:30 2005 Subject: [crossfire] To Todd Fwd: A navarian archtype was forgotten: castle_a_navarian (or castle_a_west) In-Reply-To: <4228D67B.4060405@sympatico.ca> Message-ID: <20050304224610.37388.qmail@web61002.mail.yahoo.com> Oh ok :) I was kind of thinking the same (perhapse this needs to look more crossfireish). One thing I was thinking of was adding texture... via underlay+alpha blend... but the gimp changed since I used that last and I can't find the option anywhere... The borders should look good :) Also I'm thinking of making "brestinian" arches now. Think germanic+russian like the way they decorate their buildings with spiral paint, and //\\ paint patterns on the shudders and all that stuff on the church in Red Square (bastard ivan killed the architect afterwards). What would you think of that and what should that set be called? --- Todd Mitchell wrote: > Howdy, > I didn't forget the castle_a arch - I was going to > add a thin black > border in to give it some more definition. as it is > now it seems too > flat and blends too much in with the background. I > want it to look more > like your other images for the the little castle and > for the Hold (that > one looks really nice). It has taken me a bit > longer to get to it than > I thought however. > > Mitch Obrian wrote: > > >As castle_a_west.arc etc > > > >Note: forwarded message attached. > > > > > > > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Sat Mar 5 11:21:09 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Mar 5 11:24:28 2005 Subject: [crossfire] Upcoming brestinian arch name? Message-ID: <20050305172109.79758.qmail@web61005.mail.yahoo.com> What should be the suffix name of the brestinian arches I'm making? (ie bla-navarian/brestinian/west etc). Here is a sample image (attached). __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ -------------- next part -------------- A non-text attachment was scrubbed... Name: tower1.png Type: image/png Size: 1698 bytes Desc: tower1.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/df68386d/tower1.png From mikeeusaaa at yahoo.com Sat Mar 5 20:46:45 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Mar 5 20:49:30 2005 Subject: [crossfire] New weapon, please upload to CVS Message-ID: <20050306024646.33587.qmail@web61006.mail.yahoo.com> shaxe1.arc shaxe_1.base.111.png https://cat2.dynu.ca/crossfirearch/shaxe1.arc https://cat2.dynu.ca/crossfirearch/shaxe_1.base.111.png I added the lines: arch shaxe1 magic 4 chance 1 more to: treasureone melee_weapons after dhaxe2 's stuff https://cat2.dynu.ca/crossfirearch/treasures Please upload the arc and image to cvs and update the treasure file :). Also if anyone want's any specific weapons done for CF just ask :). __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From leaf at real-time.com Sat Mar 5 21:11:10 2005 From: leaf at real-time.com (Rick Tanner) Date: Sat Mar 5 21:14:31 2005 Subject: [crossfire] IPO bank patch Message-ID: For those who might be having a similar issue.. The patch from Andreas Kirschbaum has fixed the broken bank deposit problem on crossfire.metalforge.net "The problem seems to be that a float is passed to PayAmount() (which expects an integer). After adding an explicit type cast (see attached patch), it did work for me again." Details: http://mailman.real-time.com/pipermail/crossfire/2005-February/008167.html From mikeeusaaa at yahoo.com Sat Mar 5 23:17:32 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Mar 5 23:24:37 2005 Subject: [crossfire] Brestinian Look patch (gives brest it's own style) Message-ID: <20050306051733.51139.qmail@web61008.mail.yahoo.com> Maps: https://cat2.dynu.ca/cat2/brestinianlookpatch.tar.gz Archetypes: https://cat2.dynu.ca/crossfirearch/city_tower_fant.arc https://cat2.dynu.ca/crossfirearch/city_tower_fant.base.x11.png https://cat2.dynu.ca/crossfirearch/guild_fant.arc https://cat2.dynu.ca/crossfirearch/guild_fant.base.x11.png https://cat2.dynu.ca/crossfirearch/store_gene_fant.arc https://cat2.dynu.ca/crossfirearch/store_gene_fant.base.x11.png https://cat2.dynu.ca/crossfirearch/store_magi_fant.arc https://cat2.dynu.ca/crossfirearch/store_magi_fant.base.x11.png https://cat2.dynu.ca/crossfirearch/stronghold_fant.arc https://cat2.dynu.ca/crossfirearch/stronghold_fant.base.111.png https://cat2.dynu.ca/crossfirearch/tower_tob_fant.arc https://cat2.dynu.ca/crossfirearch/tower_tob_fant.base.111.png This time I named the archetypes non-city specific :) (fant alludes to fantasy as in the style of the roofs, doors, towers etc which are derived from the germanic/northern and russian fantastical design elements they incorperated into some of their buildings (cough *red square*)) Please up to CVS :) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: brestinianlookpatch.tar.gz Type: application/x-gzip Size: 30214 bytes Desc: brestinianlookpatch.tar.gz Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/brestinianlookpatch.tar-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: city_tower_fant.arc Type: application/octet-stream Size: 243 bytes Desc: city_tower_fant.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/city_tower_fant-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: city_tower_fant.base.x11.png Type: image/png Size: 1698 bytes Desc: city_tower_fant.base.x11.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/city_tower_fant.base.x11-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: guild_fant.arc Type: application/octet-stream Size: 461 bytes Desc: guild_fant.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/guild_fant-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: guild_fant.base.x11.png Type: image/png Size: 1569 bytes Desc: guild_fant.base.x11.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/guild_fant.base.x11-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: store_gene_fant.arc Type: application/octet-stream Size: 517 bytes Desc: store_gene_fant.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/store_gene_fant-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: store_gene_fant.base.x11.png Type: image/png Size: 1646 bytes Desc: store_gene_fant.base.x11.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/store_gene_fant.base.x11-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: store_magi_fant.arc Type: application/octet-stream Size: 509 bytes Desc: store_magi_fant.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/store_magi_fant-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: store_magi_fant.base.x11.png Type: image/png Size: 2704 bytes Desc: store_magi_fant.base.x11.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/store_magi_fant.base.x11-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: stronghold_fant.arc Type: application/octet-stream Size: 1214 bytes Desc: stronghold_fant.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/stronghold_fant-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: stronghold_fant.base.111.png Type: image/png Size: 3886 bytes Desc: stronghold_fant.base.111.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/stronghold_fant.base.111-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: tower_tob_fant.arc Type: application/octet-stream Size: 119 bytes Desc: tower_tob_fant.arc Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/tower_tob_fant-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: tower_tob_fant.base.111.png Type: image/png Size: 1040 bytes Desc: tower_tob_fant.base.111.png Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050305/acd0709c/tower_tob_fant.base.111-0001.png From kirschbaum at myrealbox.com Sun Mar 6 06:29:54 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Mar 6 06:34:36 2005 Subject: [crossfire] python version check In-Reply-To: <20050220195235.GA26926@kirschbaum.myrealbox.com> References: <1106195794.5396.20.camel@oberon.kameria> <20050120222649.GC17834@idefix2.dvlp.in-medias-res.com> <20050220195235.GA26926@kirschbaum.myrealbox.com> Message-ID: <20050306122953.GA4643@kirschbaum.myrealbox.com> No feedback, therefore I'll assume that it's ok to commit these changes. Unfortunately I get lots of differences after running the autogen.sh script: The files aclocal.m4, configure, and all Makefile.in have differences. The differences in Makefile.in are minor (a few added lines like "AR = @AR@"). The differences in configure probably are because I use autoconf version 2.59; the existing files are from version 2.57. The differences in aclocal.m4 are huge even though I use the same automake version 1.6.3 that was used to generate these files. What should I do here? Just commit "my" files? From mwedel at sonic.net Sun Mar 6 19:38:38 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Mar 6 19:42:51 2005 Subject: [crossfire] python version check In-Reply-To: <20050306122953.GA4643@kirschbaum.myrealbox.com> References: <1106195794.5396.20.camel@oberon.kameria> <20050120222649.GC17834@idefix2.dvlp.in-medias-res.com> <20050220195235.GA26926@kirschbaum.myrealbox.com> <20050306122953.GA4643@kirschbaum.myrealbox.com> Message-ID: <422BB09E.9010704@sonic.net> Andreas Kirschbaum wrote: > No feedback, therefore I'll assume that it's ok to commit these changes. > > Unfortunately I get lots of differences after running the autogen.sh > script: The files aclocal.m4, configure, and all Makefile.in have > differences. > > The differences in Makefile.in are minor (a few added lines like > "AR = @AR@"). > > The differences in configure probably are because I use autoconf version > 2.59; the existing files are from version 2.57. > > The differences in aclocal.m4 are huge even though I use the same > automake version 1.6.3 that was used to generate these files. > > > What should I do here? Just commit "my" files? Generally speaking, for machine generated files, just commit them. For reference, I have aclocal (automake) version 1.9.3. I don't know if I was the last person to generate them, but I suppose it is possible that the comment is just incorrect about what version of automake generated the aclocal.m4 file. From won_fang at yahoo.com.au Sun Mar 6 23:33:48 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Sun Mar 6 23:39:42 2005 Subject: [crossfire] I'm not allowed to spend time on this for now. In-Reply-To: 6667 Message-ID: <20050307053348.9753.qmail@web51904.mail.yahoo.com> I had a look at my maps over the weekend, and I have decided to bring them up to scratch a little before handing them over to someone. For the impatient, I remember posting them to this list a while ago, so you could get a preview if you go in search of onefang's Ice Castle. Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com From won_fang at yahoo.com.au Sun Mar 6 23:33:48 2005 From: won_fang at yahoo.com.au (David Seikel) Date: Sun Mar 6 23:39:45 2005 Subject: [crossfire] I'm not allowed to spend time on this for now. In-Reply-To: 6667 Message-ID: <20050307053348.9753.qmail@web51904.mail.yahoo.com> I had a look at my maps over the weekend, and I have decided to bring them up to scratch a little before handing them over to someone. For the impatient, I remember posting them to this list a while ago, so you could get a preview if you go in search of onefang's Ice Castle. Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com From tanner at real-time.com Mon Mar 7 15:29:52 2005 From: tanner at real-time.com (Bob Tanner) Date: Mon Mar 7 15:32:46 2005 Subject: [crossfire] CFJavaEditor license? Message-ID: <200503071529.53691@www.mn-linux.org.or.transmuter.real-time.com> What license is the CFJavaEditor under? I see many of the .java files have GPL headers, but there isn't a COPYING file in the base project directory. -- Bob Tanner | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From mikeeusaaa at yahoo.com Mon Mar 7 23:52:41 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Mar 7 23:56:51 2005 Subject: [crossfire] Brestinian patch completed, please upload to CVS Message-ID: <20050308055241.42960.qmail@web61003.mail.yahoo.com> Changed/added files: https://cat2.dynu.ca/cat2/brestinianlookpatch.tar.gz https://cat2.dynu.ca/crossfirearch/prison_fant.arc https://cat2.dynu.ca/crossfirearch/prison_fant.base.111.png https://cat2.dynu.ca/crossfirearch/store_armo_fant.arc https://cat2.dynu.ca/crossfirearch/store_armo_fant.base.x11.png https://cat2.dynu.ca/crossfirearch/store_weap_fant.arc https://cat2.dynu.ca/crossfirearch/store_weap_fant.base.111.png --- Mitch Obrian wrote: > Updated > https://cat2.dynu.ca/cat2/brestinianlookpatch.tar.gz > > https://cat2.dynu.ca/crossfirearch/church_fant.arc > https://cat2.dynu.ca/crossfirearch/church_fant.base.x11.png > > --- Mitch Obrian wrote: > > > Maps: > > > https://cat2.dynu.ca/cat2/brestinianlookpatch.tar.gz > > > > Archetypes: > > > https://cat2.dynu.ca/crossfirearch/city_tower_fant.arc > > > https://cat2.dynu.ca/crossfirearch/city_tower_fant.base.x11.png > > > > https://cat2.dynu.ca/crossfirearch/guild_fant.arc > > > https://cat2.dynu.ca/crossfirearch/guild_fant.base.x11.png > > > > > https://cat2.dynu.ca/crossfirearch/store_gene_fant.arc > > > https://cat2.dynu.ca/crossfirearch/store_gene_fant.base.x11.png > > > > > https://cat2.dynu.ca/crossfirearch/store_magi_fant.arc > > > https://cat2.dynu.ca/crossfirearch/store_magi_fant.base.x11.png > > > > > https://cat2.dynu.ca/crossfirearch/stronghold_fant.arc > > > https://cat2.dynu.ca/crossfirearch/stronghold_fant.base.111.png > > > > > https://cat2.dynu.ca/crossfirearch/tower_tob_fant.arc > > > https://cat2.dynu.ca/crossfirearch/tower_tob_fant.base.111.png > > > > This time I named the archetypes non-city specific > > :) > > (fant alludes to fantasy as in the style of the > > roofs, > > doors, towers etc which are derived from the > > germanic/northern and russian fantastical design > > elements they incorperated into some of their > > buildings (cough *red square*)) > > > > Please up to CVS :) > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > http://mail.yahoo.com > > > ATTACHMENT part 2 application/x-gzip > name=brestinianlookpatch.tar.gz > > > > ATTACHMENT part 3 application/octet-stream > name=city_tower_fant.arc > > > > ATTACHMENT part 4 image/png > name=city_tower_fant.base.x11.png > > > > ATTACHMENT part 5 application/octet-stream > name=guild_fant.arc > > > > ATTACHMENT part 6 image/png > name=guild_fant.base.x11.png > > > > ATTACHMENT part 7 application/octet-stream > name=store_gene_fant.arc > > > > ATTACHMENT part 8 image/png > name=store_gene_fant.base.x11.png > > > > ATTACHMENT part 9 application/octet-stream > name=store_magi_fant.arc > > > > ATTACHMENT part 10 image/png > name=store_magi_fant.base.x11.png > > > > ATTACHMENT part 11 application/octet-stream > name=stronghold_fant.arc > > > > ATTACHMENT part 12 image/png > name=stronghold_fant.base.111.png > > > > ATTACHMENT part 13 application/octet-stream > name=tower_tob_fant.arc > > > > ATTACHMENT part 14 image/png > name=tower_tob_fant.base.111.png > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > ATTACHMENT part 2 application/x-gzip name=brestinianlookpatch.tar.gz > ATTACHMENT part 3 application/octet-stream name=church_fant.arc > ATTACHMENT part 4 image/png name=church_fant.base.x11.png __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From b.t.lally at warwick.ac.uk Tue Mar 8 14:42:57 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Tue Mar 8 14:29:01 2005 Subject: [crossfire] Information about crossfire Message-ID: <200503082042.57845.b.t.lally@warwick.ac.uk> I was going to post this to the CFMB, but on reflection here it seems more likely to meet the attention of those who can act on this. Following the release of the 1.7.1 client last weekend, I had a look at some information about cf in various places and a lot of it is now out of date. http://directory.fsf.org/games/Role-playing_and_adventure/CFClient.html points at version 1.7 as the most recent the server entry http://directory.fsf.org/games/rpg/crossfire.html is also out of date pointing at 1.6 http://freshmeat.net/projects/crossfire/ is out of date too, having the client version as 1.7 and the server version as 1.3 ! happy penguin: http://www.happypenguin.org/show?CrossFire has the latest version as 1.6.1 Can these be updated to the latest versions, pointing people at old versions is probably not a very good thing to be doing. Also AFAICT all of these sites have the newly updated entries posted to the front page. (meaning there might be a couple of new players as a result). From mikeeusaaa at yahoo.com Wed Mar 9 10:26:56 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 9 10:31:15 2005 Subject: [crossfire] Information about crossfire In-Reply-To: 6667 Message-ID: <20050309162656.30660.qmail@web61007.mail.yahoo.com> More players means more players to PK on Cat2!!!!11111111111111111 --- Brendan Lally wrote: > I was going to post this to the CFMB, but on > reflection here it seems more > likely to meet the attention of those who can act on > this. > > Following the release of the 1.7.1 client last > weekend, I had a look at some > information about cf in various places and a lot of > it is now out of date. > > http://directory.fsf.org/games/Role-playing_and_adventure/CFClient.html > > points at version 1.7 as the most recent > > the server entry > http://directory.fsf.org/games/rpg/crossfire.html > is also out of date pointing at 1.6 > > http://freshmeat.net/projects/crossfire/ > is out of date too, having the client version as 1.7 > and the server version as > 1.3 ! > > happy penguin: > http://www.happypenguin.org/show?CrossFire > > has the latest version as 1.6.1 > > Can these be updated to the latest versions, > pointing people at old versions > is probably not a very good thing to be doing. > > Also AFAICT all of these sites have the newly > updated entries posted to the > front page. (meaning there might be a couple of new > players as a result). > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From fuchs.andy at gmail.com Fri Mar 11 17:26:45 2005 From: fuchs.andy at gmail.com (Andy Fuchs) Date: Fri Mar 11 17:29:50 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg Message-ID: The Pirate Den scorn port has an exit leading to wolfsburg. Since the boat to wolfsburg has been moved to navar, this creates an easier way to get to navar. The soulution would be to move these maps, or expand the dungeon (mikeeusa's idea). The maps in question are: /wolfsburg/dungeons/pirateenter /wolfsburg/dungeons/piratedung From eracclists at bellsouth.net Fri Mar 11 18:51:07 2005 From: eracclists at bellsouth.net (ERACC) Date: Fri Mar 11 18:53:51 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: References: Message-ID: <200503111851.07952.eracclists@bellsouth.net> On Friday 11 March 2005 05:26 pm Andy Fuchs wrote: > The Pirate Den scorn port has an exit leading to wolfsburg. > Since the boat to wolfsburg has been moved to navar, this creates an > easier way to get to navar. I don't see this as a bad thing. > The soulution would be to move these maps, or expand the dungeon > (mikeeusa's idea). Nothing wrong with expanding dungeons, of course. I just do not understand why having an easier way to get to Navar is "not good". After all, one can take the dragon transport and get there as easily as using this dungeon. IMO, there should be dragon transport between all the major crossfire cities for those that want to use that method of travel. It would also be another way to remove coinage from the CF economy by making players buy tickets each time they wish to fly. FWIW, I have been looking at places to put dragon transport hangars. But if people in general think making travel between the crossfire cities easier is "Bad" then I don't want to waste my time on that. Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 18:40:07 up 58 days, 1:47, 8 users, load average: 0.27, 0.11, 0.07 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers From trhyne at MIT.EDU Fri Mar 11 19:27:34 2005 From: trhyne at MIT.EDU (Vernon T Rhyne) Date: Fri Mar 11 19:31:52 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: <200503111851.07952.eracclists@bellsouth.net> References: <200503111851.07952.eracclists@bellsouth.net> Message-ID: <1110590854.42324586556b7@webmail.mit.edu> Quoting ERACC : > On Friday 11 March 2005 05:26 pm > Andy Fuchs wrote: > > > The Pirate Den scorn port has an exit leading to wolfsburg. > > Since the boat to wolfsburg has been moved to navar, this creates an > > easier way to get to navar. > > I don't see this as a bad thing. > > > The soulution would be to move these maps, or expand the dungeon > > (mikeeusa's idea). > > Nothing wrong with expanding dungeons, of course. I just do not > understand why having an easier way to get to Navar is "not good". > After all, one can take the dragon transport and get there as easily > as using this dungeon. IMO, there should be dragon transport between > all the major crossfire cities for those that want to use that method > of travel. It would also be another way to remove coinage from the CF > economy by making players buy tickets each time they wish to fly. > > FWIW, I have been looking at places to put dragon transport hangars. > But if people in general think making travel between the crossfire > cities easier is "Bad" then I don't want to waste my time on that. > I'm an outsider here a bit, but I can't imagine whereby forcing a tedious trip is a good idea. It's not like the trip to Navar is dangerous as currently available, only long. I'd love to see more dragon hangars, as well as a teleporter to a dragon hangar "ticket counter" in the extended apartments. From mikeeusaaa at yahoo.com Fri Mar 11 20:29:54 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 11 20:33:52 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: 6667 Message-ID: <20050312022954.1452.qmail@web61004.mail.yahoo.com> I am currently adding areas to big world. There will be more stuff around when such additions are put into cvs. --- Vernon T Rhyne wrote: > Quoting ERACC : > > > On Friday 11 March 2005 05:26 pm > > Andy Fuchs wrote: > > > > > The Pirate Den scorn port has an exit leading to > wolfsburg. > > > Since the boat to wolfsburg has been moved to > navar, this creates an > > > easier way to get to navar. > > > > I don't see this as a bad thing. > > > > > The soulution would be to move these maps, or > expand the dungeon > > > (mikeeusa's idea). > > > > Nothing wrong with expanding dungeons, of course. > I just do not > > understand why having an easier way to get to > Navar is "not good". > > After all, one can take the dragon transport and > get there as easily > > as using this dungeon. IMO, there should be dragon > transport between > > all the major crossfire cities for those that want > to use that method > > of travel. It would also be another way to remove > coinage from the CF > > economy by making players buy tickets each time > they wish to fly. > > > > FWIW, I have been looking at places to put dragon > transport hangars. > > But if people in general think making travel > between the crossfire > > cities easier is "Bad" then I don't want to waste > my time on that. > > > > I'm an outsider here a bit, but I can't imagine > whereby forcing a tedious trip > is a good idea. It's not like the trip to Navar is > dangerous as currently > available, only long. I'd love to see more dragon > hangars, as well as a > teleporter to a dragon hangar "ticket counter" in > the extended apartments. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From cowboyatheart at gmail.com Fri Mar 11 20:29:38 2005 From: cowboyatheart at gmail.com (Jeremy Blain) Date: Fri Mar 11 21:05:53 2005 Subject: [crossfire] Diff styles Message-ID: <3bec7e3050311182971f87092@mail.gmail.com> What is the preferred diff format, for code submissions? From cowboyatheart at gmail.com Fri Mar 11 20:47:43 2005 From: cowboyatheart at gmail.com (Jeremy Blain) Date: Fri Mar 11 21:17:53 2005 Subject: [crossfire] new pickup Message-ID: <3bec7e305031118476cd0a3eb@mail.gmail.com> I'm working on adding to the new pickup mode, to allow it to pickup wands/staves/rods/horns. Does 'Magic Device' describe them accurately enough? While I'm doing this, are there any other categories of items that should be in new pickup? From mikeeusaaa at yahoo.com Fri Mar 11 21:39:47 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 11 21:43:53 2005 Subject: [crossfire] new pickup In-Reply-To: 6667 Message-ID: <20050312033947.45123.qmail@web61008.mail.yahoo.com> would be cool to beable to add a pickup Item name thing so i could add pick up dragon scales etc. --- Jeremy Blain wrote: > I'm working on adding to the new pickup mode, > to allow it to pickup wands/staves/rods/horns. > > Does 'Magic Device' describe them accurately enough? > > While I'm doing this, are there any other categories > of items > that should be in new pickup? > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From rbrockway at opentrend.net Fri Mar 11 21:55:00 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Fri Mar 11 21:57:53 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: <1110590854.42324586556b7@webmail.mit.edu> References: <200503111851.07952.eracclists@bellsouth.net> <1110590854.42324586556b7@webmail.mit.edu> Message-ID: On Fri, 11 Mar 2005, Vernon T Rhyne wrote: > I'm an outsider here a bit, but I can't imagine whereby forcing a > tedious trip is a good idea. It's not like the trip to Navar is The main reason Navar has been kept seperate to Scorn is to prevent players easily visiting all shops in the world. Preventing players from being able to do this has been part of Crossfire map placement for a very long time. If easy transit between Scorn and Navar becomes a reality then virtually all of the city maps are only a few ships apart. This is why I commented in the "moving Wolfsberg" thread that changing Wolfsberg to be accessible from Navar would not effect game balance as long as we broke the link to Scorn. > dangerous as currently available, only long. I'd love to see more > dragon hangars, as well as a teleporter to a dragon hangar "ticket > counter" in the extended apartments. High level characters have ways of making the trip more easily, so I'd be ok with more dragon hangars as long as they were made suitably expensive. Perhaps ships should cost money to use (discussed a few times over the years I know). If this was the case, and the cost was sufficient, we could discourage low levels from visiting all the shops while still allowing Scorn and Navar to be connected. OTOH maybe this isn't considered to be such a big deal now, with even with east and west sets of cities containing many shops each. If we want to allow easy east-west travel we should consider all the angles. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From rbrockway at opentrend.net Fri Mar 11 22:19:42 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Fri Mar 11 22:23:53 2005 Subject: [crossfire] new pickup In-Reply-To: <3bec7e305031118476cd0a3eb@mail.gmail.com> References: <3bec7e305031118476cd0a3eb@mail.gmail.com> Message-ID: On Fri, 11 Mar 2005, Jeremy Blain wrote: > I'm working on adding to the new pickup mode, > to allow it to pickup wands/staves/rods/horns. > > Does 'Magic Device' describe them accurately enough? > > While I'm doing this, are there any other categories of items > that should be in new pickup? I'd like a pickup mode which is "magic items + coins/gems". An extension of this would be a "pickup mask" where any combination descrete sets of items could be picked up. I've toyed with the idea of doing this. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From cowboyatheart at gmail.com Fri Mar 11 22:31:27 2005 From: cowboyatheart at gmail.com (Jeremy Blain) Date: Fri Mar 11 22:37:54 2005 Subject: [crossfire] new pickup In-Reply-To: References: <3bec7e305031118476cd0a3eb@mail.gmail.com> Message-ID: <3bec7e305031120316de3993d@mail.gmail.com> Valuables, + magic items is easily settable via the gtk interface. Of course, you'll also end up picking up rings/amulets, but I doubt you'd want to leave them behind anyway. And the new pickup, DOES use a pickup mask. The gtk interface, merely provides a user friendly way of generating the mask, to send to the server. Looking at the code, it wouldn't be hard to define masks for any items, that can be differentiated by type. More complicated, but cool, would be saying something like: Pickup gems/coins, wands (except burned up ones), magic items (except magic clubs), although that would mean turning the pickup code into a programming language all it's own just about. On Fri, 11 Mar 2005 23:19:42 -0500 (EST), Robert Brockway wrote: > On Fri, 11 Mar 2005, Jeremy Blain wrote: > > > I'm working on adding to the new pickup mode, > > to allow it to pickup wands/staves/rods/horns. > > > > Does 'Magic Device' describe them accurately enough? > > > > While I'm doing this, are there any other categories of items > > that should be in new pickup? > > I'd like a pickup mode which is "magic items + coins/gems". > > An extension of this would be a "pickup mask" where any combination > descrete sets of items could be picked up. I've toyed with the idea of > doing this. > From temitchell at sympatico.ca Sat Mar 12 00:09:32 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat Mar 12 00:11:55 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: References: Message-ID: <1110607772.5305.4.camel@oberon.kameria> I vote for either moving the Pirate Den to Wolfsburg or decopuling the maps so they didn't connect. Scorn can afford to loose a low level map while it would be nice to have a few more of them in Wolfsburg. It wouldn't hurt to add a bunch of maps either. On Fri, 2005-11-03 at 18:26 -0500, Andy Fuchs wrote: > The Pirate Den scorn port has an exit leading to wolfsburg. > Since the boat to wolfsburg has been moved to navar, this creates an > easier way to get to navar. > The soulution would be to move these maps, or expand the dungeon > (mikeeusa's idea). > > The maps in question are: > /wolfsburg/dungeons/pirateenter > /wolfsburg/dungeons/piratedung > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Todd Mitchell From mwedel at sonic.net Sat Mar 12 01:40:27 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Mar 12 01:41:55 2005 Subject: [crossfire] Diff styles In-Reply-To: <3bec7e3050311182971f87092@mail.gmail.com> References: <3bec7e3050311182971f87092@mail.gmail.com> Message-ID: <42329CEB.6060705@sonic.net> Jeremy Blain wrote: > What is the preferred diff format, for code submissions? Generally context diffs, because those are the only ones that are easily human readable. From temitchell at sympatico.ca Sat Mar 12 04:08:43 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat Mar 12 04:09:57 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: <1110607772.5305.4.camel@oberon.kameria> References: <1110607772.5305.4.camel@oberon.kameria> Message-ID: <1110622123.10819.5.camel@oberon.kameria> Since it was a wolfsburg map anyway I "moved" it. I also gave the place a little reno - business must be pretty good. On Sat, 2005-12-03 at 01:09 -0500, Todd Mitchell wrote: > I vote for either moving the Pirate Den to Wolfsburg or decopuling the > maps so they didn't connect. Scorn can afford to loose a low level map > while it would be nice to have a few more of them in Wolfsburg. It > wouldn't hurt to add a bunch of maps either. > > > On Fri, 2005-11-03 at 18:26 -0500, Andy Fuchs wrote: > > The Pirate Den scorn port has an exit leading to wolfsburg. > > Since the boat to wolfsburg has been moved to navar, this creates an > > easier way to get to navar. > > The soulution would be to move these maps, or expand the dungeon > > (mikeeusa's idea). > > > > The maps in question are: > > /wolfsburg/dungeons/pirateenter > > /wolfsburg/dungeons/piratedung > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Todd Mitchell From rbrockway at opentrend.net Sat Mar 12 05:25:57 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Sat Mar 12 05:29:58 2005 Subject: [crossfire] Dungeon in scorn linked to wolfsburg In-Reply-To: <1110622123.10819.5.camel@oberon.kameria> References: <1110607772.5305.4.camel@oberon.kameria> <1110622123.10819.5.camel@oberon.kameria> Message-ID: On Sat, 12 Mar 2005, Todd Mitchell wrote: > Since it was a wolfsburg map anyway I "moved" it. I also gave the place > a little reno - business must be pretty good. It's about time the pirates had some luck. Seems like every other day some "adventurer" bursts into their home and robs them blind. And they call the pirates the criminals. :) Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (http://www.spi-inc.org) From andi.vogl at gmx.net Sat Mar 12 10:48:56 2005 From: andi.vogl at gmx.net (Andreas Vogl) Date: Sat Mar 12 10:52:01 2005 Subject: [crossfire] CFJavaEditor license? Message-ID: <3587.1110646136@www48.gmx.net> In reply to Bob Tanner: > What license is the CFJavaEditor under? GPL. Quoting the source file header: * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; either version 2 of the * License, or (at your option) any later version. > I see many of the .java files have GPL headers, but there isn't a > COPYING file in the base project directory. All of the .java source files are supposed to have that header. If it is missing in any of the files, then only by mistake and it should be added. I haven't been aware that a COPYING file is neccessary. Of course you, or anyone else, is welcome to add an appropriate GPL COPYING file. AndreasV -- DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl From nicolas.weeger at laposte.net Sun Mar 13 11:20:44 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Mar 13 11:28:17 2005 Subject: [crossfire] Screenshots on Sourceforge Message-ID: <4234766C.8090101@laposte.net> Hello. Seems Sourceforge added a 'screenshots' tab to projects. Should we add some for Crossfire? Nicolas From fuchs.andy at gmail.com Mon Mar 14 14:42:00 2005 From: fuchs.andy at gmail.com (Andy Fuchs) Date: Mon Mar 14 14:46:36 2005 Subject: [crossfire] Screenshots on Sourceforge In-Reply-To: <4234766C.8090101@laposte.net> References: <4234766C.8090101@laposte.net> Message-ID: On Sun, 13 Mar 2005 18:20:44 +0100, Nicolas Weeger wrote: > Hello. > > Seems Sourceforge added a 'screenshots' tab to projects. Should we add > some for Crossfire? > > Nicolas I don't see any reson not to. From mwedel at sonic.net Tue Mar 15 00:27:42 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Mar 15 00:30:41 2005 Subject: [crossfire] Screenshots on Sourceforge In-Reply-To: References: <4234766C.8090101@laposte.net> Message-ID: <4236805E.4030003@sonic.net> Andy Fuchs wrote: > On Sun, 13 Mar 2005 18:20:44 +0100, Nicolas Weeger > wrote: > >>Hello. >> >>Seems Sourceforge added a 'screenshots' tab to projects. Should we add >>some for Crossfire? >> >>Nicolas > > > I don't see any reson not to. anyone have any good screenshots to contribute? We could probably use some from realtime, but more up to date screenshots might be desirable. From nicolas.weeger at laposte.net Tue Mar 15 02:37:51 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Mar 15 02:40:43 2005 Subject: [crossfire] Screenshots on Sourceforge Message-ID: > anyone have any good screenshots to contribute? We could probably use some > from realtime, but more up to date screenshots might be desirable. Version 1.7.0, courtesy some Wikipedia editor: http://upload.wikimedia.org/wikipedia/en/c/cf/Crossfiregame.jpg Warning: i think it's the windows version lol Or we could make some :) Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mwedel at sonic.net Tue Mar 15 03:03:02 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Mar 15 03:04:43 2005 Subject: [crossfire] Screenshots on Sourceforge In-Reply-To: References: Message-ID: <4236A4C6.70904@sonic.net> Nicolas Weeger wrote: >> anyone have any good screenshots to contribute? We could probably use some >>from realtime, but more up to date screenshots might be desirable. > > > Version 1.7.0, courtesy some Wikipedia editor: http://upload.wikimedia.org/wikipedia/en/c/cf/Crossfiregame.jpg > > Warning: i think it's the windows version lol Maybe I need to counter with some of the gtk-v2 client running on linux, since it seems I'm the only way able to run that client successfully :) > > Or we could make some :) that was sort of my thought. http://crossfire.real-time.com/screenshots/index.html has some, but some are pretty out of date. We probably don't want to use screenshots of clients that don't work anymore, otherwise we may get the question of 'well, were can I get the java client'. Actually, to be fair, we should probably only include the clients currently available as part of the project. Also, of any screenshots generated, additional details might be nice like: 1) Map where screenshot was taken. 2) type/version of client, OS. 3) If any options were used the do change the appearance (lighting levels, display options, etc), what those options were. From nicolas.weeger at laposte.net Tue Mar 15 03:49:07 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Mar 15 03:52:43 2005 Subject: [crossfire] Screenshots on Sourceforge Message-ID: > Maybe I need to counter with some of the gtk-v2 client running on linux, since > it seems I'm the only way able to run that client successfully :) I haven't even tried to compile it under Windows. Two reasons: * i'm lazy * client is designed for high resolutions iirc), and i'm using 1024x768, too small :) > that was sort of my thought. Ok, so let's get screenshoting moving! yeah! > Also, of any screenshots generated, additional details might be nice like: Yup, all details could be nice. Not sure on how much information you can put on Sourceforge's page, but we can always use it for our website. Could be nice to have pics of the java editor, too. What about "centralizing" pictures somewhere? So that people kno what pics are available, and so on. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From b.t.lally at warwick.ac.uk Tue Mar 15 08:16:03 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Tue Mar 15 08:02:48 2005 Subject: [crossfire] Screenshots on Sourceforge In-Reply-To: <4236A4C6.70904@sonic.net> References: <4236A4C6.70904@sonic.net> Message-ID: <200503151416.03760.b.t.lally@warwick.ac.uk> On Tuesday 15 Mar 2005 09:03, Mark Wedel wrote: > Nicolas Weeger wrote: > >> anyone have any good screenshots to contribute? We could probably use > >> some from realtime, but more up to date screenshots might be desirable. > > Don't know about /good/, but I had to go to navar on MF yesterday anyway (new apartments), so I ran ksnapshot while I was at it and took some up-to-date screenshots and dumped them here. http://cavetroll.uwcs.co.uk/cfscreenshots/ feel free to use any/all of them as you will. > Also, of any screenshots generated, additional details might be nice > like: 1) Map where screenshot was taken. > 2) type/version of client, OS. > 3) If any options were used the do change the appearance (lighting levels, > display options, etc), what those options were. for the 5 in the location I linked to: http://cavetroll.uwcs.co.uk/cfscreenshots/cfscreenshot1.png gtk-v2 client (initial release from CVS, haven't synced to the SDL changes yet...) - core stats tab at bottom of screen. - normal inventory view. options all defaults , except that I passed --mapsize24X24 at command line (image appears as 11x11 if I don't) scorn town centre, on metalforge. http://cavetroll.uwcs.co.uk/cfscreenshots/cfscreenshot2.png same as before - resistance tab at bottom of screen - icon inventory view scorn zoo - lower level - wanted to include some monsters from the game without getting killed.... http://cavetroll.uwcs.co.uk/cfscreenshots/cfscreenshot3.png same as before - resistances tab at the bottom of screen -icon inventory view centre of navar - with the new architecture.... http://cavetroll.uwcs.co.uk/cfscreenshots/cfscreenshot4.png gtk1-client - default settings - expanded to fit all the text into the shot. playing as my mf dragon character. (CVS checkout from 29th December ) playing chess in scorn, white about to checkmate http://cavetroll.uwcs.co.uk/cfscreenshots/cfscreenshot5.png bit of bulky one this one, gtk1-client - split window mode, across 1 and a half screens.... (this is how I normally play the game, it lets me chat on a server and #crossfire at the same time....) display tiles x and y has been bumped up, windows have been moved around all other settings are default. cat2 server, in brest with mikee's new archs (don't know if they have been committed yet) also weather and spell effects. all of these taken on a system running a slackware 9.1/10.0/10.1 hybrid, with kde 3.2.1 and the gtk-qt engine running. From b.t.lally at warwick.ac.uk Wed Mar 16 20:03:53 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Mar 16 19:49:09 2005 Subject: [crossfire] compilation of server broken on certain systems Message-ID: <200503170203.53714.b.t.lally@warwick.ac.uk> this is on the sourceforge tracker, but I'll point to it here because it is fairly serious and I'm hoping someone who knows about this stuff will take a look at it. http://sourceforge.net/tracker/index.php?func=detail&aid=1164933&group_id=13833&atid=113833 whilst I can compile fine on my system after running aclocal && automake, the same is not true of a debian woody system that compilation was attempted on. From cowboyatheart at gmail.com Wed Mar 16 21:59:47 2005 From: cowboyatheart at gmail.com (Jeremy Blain) Date: Wed Mar 16 22:03:11 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <200503170203.53714.b.t.lally@warwick.ac.uk> References: <200503170203.53714.b.t.lally@warwick.ac.uk> Message-ID: <3bec7e30503161959642adccc@mail.gmail.com> I didn't see any changes recently that affected the makefiles at all. The fact it is trying to mkdir /.lib makes me think configure was run with broken parameters. (ie: someone said configure --prefix=/. instead of configure --prefix=./) It shouldn't be trying to mkdir in the root directory. On Thu, 17 Mar 2005 02:03:53 +0000, Brendan Lally wrote: > this is on the sourceforge tracker, but I'll point to it here because it is > fairly serious and I'm hoping someone who knows about this stuff will take a > look at it. > > http://sourceforge.net/tracker/index.php?func=detail&aid=1164933&group_id=13833&atid=113833 > > whilst I can compile fine on my system after running aclocal && automake, the > same is not true of a debian woody system that compilation was attempted on. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From mikeeusaaa at yahoo.com Wed Mar 16 22:10:13 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 16 22:13:11 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: 6667 Message-ID: <20050317041013.36653.qmail@web61006.mail.yahoo.com> I think it has something to do with the automake stuff not being updated with a recent change... I could be wrong tho. It builds on some systems and not on others... --- Jeremy Blain wrote: > I didn't see any changes recently that affected the > makefiles at all. > The fact it is trying to > mkdir /.lib makes me think configure was run with > broken parameters. > > (ie: someone said configure --prefix=/. instead of > configure --prefix=./) > > It shouldn't be trying to mkdir in the root > directory. > > > > > On Thu, 17 Mar 2005 02:03:53 +0000, Brendan Lally > wrote: > > this is on the sourceforge tracker, but I'll point > to it here because it is > > fairly serious and I'm hoping someone who knows > about this stuff will take a > > look at it. > > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1164933&group_id=13833&atid=113833 > > > > whilst I can compile fine on my system after > running aclocal && automake, the > > same is not true of a debian woody system that > compilation was attempted on. > > > > _______________________________________________ > > 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 > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From b.t.lally at warwick.ac.uk Thu Mar 17 03:13:58 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Thu Mar 17 03:01:13 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <3bec7e30503161959642adccc@mail.gmail.com> References: <200503170203.53714.b.t.lally@warwick.ac.uk> <3bec7e30503161959642adccc@mail.gmail.com> Message-ID: <200503170913.58813.b.t.lally@warwick.ac.uk> On Thursday 17 Mar 2005 03:59, Jeremy Blain wrote: > I didn't see any changes recently that affected the makefiles at all. How about this one? http://cvs.sourceforge.net/viewcvs.py/crossfire/crossfire/ChangeLog?r1=1.255&r2=1.256 > The fact it is trying to > mkdir /.lib makes me think configure was run with broken parameters. > > (ie: someone said configure --prefix=/. instead of configure --prefix=./) > > It shouldn't be trying to mkdir in the root directory. > Ok, I'll paste the xterm output here (adding some linebreaks to improve clarity, but otherwise unaltered. running configure with *no* parameters: (this is a little spammy, so I'm redirecting stdout to /dev/null, it is stderr that is significant anyway - ask if you want/need me to re-run with the output of stdout or to send the config.log file ) 02:47:11 cavespider caethaver2 ~/crossfire-test $cvs -Qz9 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/crossfire co crossfire > /dev/null 02:47:27 cavespider caethaver2 ~/crossfire-test $cd crossfire/ 02:47:30 cavespider caethaver2 ~/crossfire-test/crossfire $./configure > /dev/null 02:50:00 cavespider caethaver2 ~/crossfire-test/crossfire $make > /dev/null /home/cavespider/crossfire-test/crossfire/utils/missing: automake-1.9: command not found WARNING: `automake-1.9' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. ../common/libcross.a(map.o): In function `load_map_header': /home/cavespider/crossfire-test/crossfire/common/map.c:721: undefined reference to `get_region_by_name' collect2: ld returned 1 exit status make[1]: *** [random_map] Error 1 make: *** [all-recursive] Error 1 ok this is sort of what was expected, Ryo committed my regions patch without running automake, I thought this just an issue for systems without autotools, but.... 02:51:09 cavespider caethaver2 ~/crossfire-test/crossfire $aclocal > /dev/null aclocal: both `configure.ac' and `configure.in' present: ignoring `configure.in' 02:51:38 cavespider caethaver2 ~/crossfire-test/crossfire $autoconf > /dev/null autoconf2.50: warning: both `configure.ac' and `configure.in' are present. autoconf2.50: warning: proceeding with `configure.ac'. configure.ac:32: warning: AC_PROG_LEX invoked multiple times 02:51:54 cavespider caethaver2 ~/crossfire-test/crossfire $automake > /dev/null automake: both `configure.ac' and `configure.in' present: ignoring `configure.in' configure.ac: 8: required file `./[include/autoconf.h].in' not found configure.ac: 8: required file `./[include/stamp-h.in' not found Makefile.am:6: variable `CROSSEDIT' not defined doc/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' doc/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' doc/Makefile.am:28: invalid variable `dist_noinst_DATA' doc/playbook/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' doc/playbook/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' doc/scripts/Makefile.am:2: invalid variable `dist_noinst_SCRIPTS' doc/scripts/Makefile.am:2: invalid variable `dist_noinst_SCRIPTS' lib/Makefile.am:77: invalid variable `dist_adm_SCRIPTS' lib/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' lib/Makefile.am:77: invalid variable `dist_adm_SCRIPTS' lib/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' lib/Makefile.am:39: invalid variable `dist_help_DATA' lib/Makefile.am:55: invalid variable `dist_wizhelp_DATA' lib/Makefile.am:30: invalid variable `dist_pkgdata_DATA' utils/Makefile.am:4: invalid variable `nodist_pkglib_SCRIPTS' utils/Makefile.am:2: invalid variable `nodist_bin_SCRIPTS' utils/Makefile.am:5: invalid variable `dist_pkglib_SCRIPTS' utils/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' utils/Makefile.am:3: invalid variable `dist_bin_SCRIPTS' utils/Makefile.am:4: invalid variable `nodist_pkglib_SCRIPTS' utils/Makefile.am:2: invalid variable `nodist_bin_SCRIPTS' utils/Makefile.am:5: invalid variable `dist_pkglib_SCRIPTS' utils/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' utils/Makefile.am:3: invalid variable `dist_bin_SCRIPTS' 02:52:06 cavespider caethaver2 ~/crossfire-test/crossfire $./configure > /dev/null 02:54:29 cavespider caethaver2 ~/crossfire-test/crossfire $make > /dev/null ../libtool: s,^.*/,,g: No such file or directory ../libtool: -e: command not found *** Warning: inferring the mode of operation is deprecated. *** Future versions of Libtool will require -mode=MODE be specified. ../libtool: -e: command not found ../libtool: -e: command not found ../libtool: -e: command not found ../libtool: -e: command not found ../libtool: -e: command not found mkdir: cannot create directory `/.libs': Permission denied make[1]: *** [random_map] Error 1 make: *** [all-recursive] Error 1 And for reference... 03:00:06 cavespider caethaver2 ~/crossfire-test/crossfire $automake --version | head -n 1 automake (GNU automake) 1.4-p4 03:00:16 cavespider caethaver2 ~/crossfire-test/crossfire $autoconf --version | head -n 1 autoconf (GNU Autoconf) 2.53 03:00:31 cavespider caethaver2 ~/crossfire-test/crossfire $uname -a Linux caethaver2 2.4.29-grsec #1 SMP Wed Mar 9 17:05:49 EST 2005 i686 unknown 03:01:00 cavespider caethaver2 ~/crossfire-test/crossfire $libtool --version ltmain.sh (GNU libtool) 1.4.2a (1.922.2.79 2001/11/28 21:50:31) From temitchell at sympatico.ca Thu Mar 17 10:39:22 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Mar 17 10:45:19 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <200503170913.58813.b.t.lally@warwick.ac.uk> References: <200503170203.53714.b.t.lally@warwick.ac.uk> <3bec7e30503161959642adccc@mail.gmail.com> <200503170913.58813.b.t.lally@warwick.ac.uk> Message-ID: <4239B2BA.6000406@sympatico.ca> I think this is a simple misunderstanding of intent, no one would expect you to install to / configure --prefix=/ you have to be able to write to for example configure --prefix=/usr/local/crossfire wher eyour user owns /usr/local/crossfire or --configure-prefix=/home/youraccount/crossfire From mikeeusaaa at yahoo.com Thu Mar 17 10:50:25 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Mar 17 10:55:20 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: 6667 Message-ID: <20050317165025.34064.qmail@web61008.mail.yahoo.com> That was also tried, didn't work. --- Todd Mitchell wrote: > I think this is a simple misunderstanding of intent, > no one would expect > you to install to / > > configure --prefix=/ > > you have to be able to write to > > for example configure --prefix=/usr/local/crossfire > wher eyour user owns > /usr/local/crossfire or > --configure-prefix=/home/youraccount/crossfire > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From temitchell at sympatico.ca Thu Mar 17 17:58:25 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Mar 17 18:01:23 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <20050317165025.34064.qmail@web61008.mail.yahoo.com> References: <20050317165025.34064.qmail@web61008.mail.yahoo.com> Message-ID: <1111103905.12529.3.camel@oberon.kameria> No, it wasn't a solution to the error it was an explanation of the --prefix option. The error you get isn't confined to woody BTW - I get the same error on my Sarge system. >From my vast ignorance of lex and make and autoconfig but from seeing something like this before I think that the problem has something to do with get_region_by_name not being defined in random_maps/reader.l? ? On Thu, 2005-17-03 at 08:50 -0800, Mitch Obrian wrote: > That was also tried, didn't work. > > --- Todd Mitchell wrote: > > I think this is a simple misunderstanding of intent, > > no one would expect > > you to install to / > > > > configure --prefix=/ > > > > you have to be able to write to > > > > for example configure --prefix=/usr/local/crossfire > > wher eyour user owns > > /usr/local/crossfire or > > --configure-prefix=/home/youraccount/crossfire > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Todd Mitchell From leaf at real-time.com Thu Mar 17 18:06:55 2005 From: leaf at real-time.com (Rick Tanner) Date: Thu Mar 17 18:11:23 2005 Subject: [crossfire] Post limit on the dm petition board? Message-ID: Posting here first, before the bug tracker.. Is there a limit to the number of posts to the dm petition board? Or perhaps a file size or character number limit? On crossfire.metlaforge.net server, the petition board appears to be maxed out at 28 posts. Remove a post, and then a new one can be added. -- From b.t.lally at warwick.ac.uk Thu Mar 17 18:44:05 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Thu Mar 17 18:29:23 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <1111103905.12529.3.camel@oberon.kameria> References: <20050317165025.34064.qmail@web61008.mail.yahoo.com> <1111103905.12529.3.camel@oberon.kameria> Message-ID: <200503180044.05368.b.t.lally@warwick.ac.uk> On Thursday 17 Mar 2005 23:58, Todd Mitchell wrote: > The error you get isn't confined to woody BTW - I get the same error on > my Sarge system. > > >From my vast ignorance of lex and make and autoconfig but from seeing > > something like this before I think that the problem has something to do > with get_region_by_name not being defined in random_maps/reader.l? > I know that get_region_by_name is not found by default, I expected that, Ryo didn't update automake before committing. The problem is that /after/ doing that myself, it still doesn't work, and by whinging about libtool it seems to suggest a toolchain issue rather than merely a header file/source file thing. btw, what version of automake, autoconf and libtool have you got on that system? From cowboyatheart at gmail.com Fri Mar 18 00:48:55 2005 From: cowboyatheart at gmail.com (Jeremy Blain) Date: Fri Mar 18 00:53:28 2005 Subject: [crossfire] key bindings Message-ID: <3bec7e3050317224845363dac@mail.gmail.com> >From a post in the forums at http://www.metalforge.net/cfmb/viewtopic.php?p=7117#7117 Any thoughts on whether this is worth implementing? It doesn't seem too difficult to me, and I'd be happy to take a stab at it. Any changes you'd recommend from what I mentioned? I can see this being very useful for having different keybindings to different situations. (there are only so many keys on the keyboard to bind things to, that don't interfere with otherwise expected actions... ) From mwedel at sonic.net Fri Mar 18 01:28:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 18 01:31:29 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <200503180044.05368.b.t.lally@warwick.ac.uk> References: <20050317165025.34064.qmail@web61008.mail.yahoo.com> <1111103905.12529.3.camel@oberon.kameria> <200503180044.05368.b.t.lally@warwick.ac.uk> Message-ID: <423A832B.9030207@sonic.net> The general problem is that the checkout/update of files does not always match dependency order. This, the makefiles think they need to re-run some commands, but it doesn't work, because you don't have the right versions. So try this: % rm configure.in configure % cvs update configure.in Warning: Remote host denied X11 forwarding. cvs update: warning: configure.in was lost U configure.in % cvs update configure Warning: Remote host denied X11 forwarding. cvs update: warning: configure was lost U configure It is a requirement that the update commands be run seperately, otherwise, you're just going to screw up the dependency order. Then after you do that, re-run configure, run make, and it all should be good. From temitchell at sympatico.ca Fri Mar 18 09:18:13 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Mar 18 09:23:33 2005 Subject: [crossfire] Post limit on the dm petition board? In-Reply-To: References: Message-ID: <423AF135.3050105@sympatico.ca> I don't think so - however I believe all the message boards share the same shelve file so you might be seeing a limit there. Rick Tanner wrote: >Posting here first, before the bug tracker.. > >Is there a limit to the number of posts to the dm petition board? >Or perhaps a file size or character number limit? > >On crossfire.metlaforge.net server, the petition board appears to be maxed >out at 28 posts. Remove a post, and then a new one can be added. > > > From mikeeusaaa at yahoo.com Fri Mar 18 10:45:34 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 18 10:49:34 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: 6667 Message-ID: <20050318164535.70762.qmail@web61010.mail.yahoo.com> It was done from a new clean tree. (It failed) --- Mark Wedel wrote: > > The general problem is that the checkout/update of > files does not always match > dependency order. > > This, the makefiles think they need to re-run some > commands, but it doesn't > work, because you don't have the right versions. > > So try this: > % rm configure.in configure > % cvs update configure.in > Warning: Remote host denied X11 forwarding. > cvs update: warning: configure.in was lost > U configure.in > % cvs update configure > Warning: Remote host denied X11 forwarding. > cvs update: warning: configure was lost > U configure > > It is a requirement that the update commands be > run seperately, otherwise, > you're just going to screw up the dependency order. > > Then after you do that, re-run configure, run > make, and it all should be good. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From mikeeusaaa at yahoo.com Fri Mar 18 11:35:54 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 18 11:39:35 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: 6667 Message-ID: <20050318173555.88769.qmail@web61001.mail.yahoo.com> Maby newer cvs works, not sure :P... haven't tried today. If anyone would like to have a shell on a debian stable system to test make scripts (or whatever) I can supply such a shell. --- Mitch Obrian wrote: > It was done from a new clean tree. (It failed) > > --- Mark Wedel wrote: > > > > The general problem is that the checkout/update > of > > files does not always match > > dependency order. > > > > This, the makefiles think they need to re-run > some > > commands, but it doesn't > > work, because you don't have the right versions. > > > > So try this: > > % rm configure.in configure > > % cvs update configure.in > > Warning: Remote host denied X11 forwarding. > > cvs update: warning: configure.in was lost > > U configure.in > > % cvs update configure > > Warning: Remote host denied X11 forwarding. > > cvs update: warning: configure was lost > > U configure > > > > It is a requirement that the update commands be > > run seperately, otherwise, > > you're just going to screw up the dependency > order. > > > > Then after you do that, re-run configure, run > > make, and it all should be good. > > > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > __________________________________ > Do you Yahoo!? > Make Yahoo! your home page > http://www.yahoo.com/r/hs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From b.t.lally at warwick.ac.uk Fri Mar 18 12:17:07 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Fri Mar 18 12:03:05 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: <423A832B.9030207@sonic.net> References: <20050317165025.34064.qmail@web61008.mail.yahoo.com> <200503180044.05368.b.t.lally@warwick.ac.uk> <423A832B.9030207@sonic.net> Message-ID: <200503181817.07929.b.t.lally@warwick.ac.uk> On Friday 18 Mar 2005 07:28, Mark Wedel wrote: > [snip something complicated] > Then after you do that, re-run configure, run make, and it all should be > good. > I have no idea why that worked, but it did, I had to rerun automake again, but other than that it compiled. The make install step was mangled horribly, most of the files where not placed properly, but the server ran ok after manually cp-ing the files in lib/ From mikeeusaaa at yahoo.com Fri Mar 18 12:14:47 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 18 12:19:35 2005 Subject: [crossfire] compilation of server broken on certain systems In-Reply-To: 6667 Message-ID: <20050318181447.39376.qmail@web61003.mail.yahoo.com> Works now, must have been the patches we added ontop of CVS. --- Mitch Obrian wrote: > Maby newer cvs works, not sure :P... haven't tried > today. > > If anyone would like to have a shell on a debian > stable system to test make scripts (or whatever) I > can > supply such a shell. > > --- Mitch Obrian wrote: > > It was done from a new clean tree. (It failed) > > > > --- Mark Wedel wrote: > > > > > > The general problem is that the > checkout/update > > of > > > files does not always match > > > dependency order. > > > > > > This, the makefiles think they need to re-run > > some > > > commands, but it doesn't > > > work, because you don't have the right versions. > > > > > > So try this: > > > % rm configure.in configure > > > % cvs update configure.in > > > Warning: Remote host denied X11 forwarding. > > > cvs update: warning: configure.in was lost > > > U configure.in > > > % cvs update configure > > > Warning: Remote host denied X11 forwarding. > > > cvs update: warning: configure was lost > > > U configure > > > > > > It is a requirement that the update commands > be > > > run seperately, otherwise, > > > you're just going to screw up the dependency > > order. > > > > > > Then after you do that, re-run configure, run > > > make, and it all should be good. > > > > > > > > > _______________________________________________ > > > crossfire mailing list > > > crossfire@metalforge.org > > > > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Make Yahoo! your home page > > http://www.yahoo.com/r/hs > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From mikeeusaaa at yahoo.com Fri Mar 18 14:16:48 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 18 14:21:37 2005 Subject: [crossfire] Install script is broken In-Reply-To: 6667 Message-ID: <20050318201648.93603.qmail@web61009.mail.yahoo.com> make install is borked. --- Mitch Obrian wrote: > Works now, must have been the patches we added ontop > of CVS. > > --- Mitch Obrian wrote: > > Maby newer cvs works, not sure :P... haven't tried > > today. > > > > If anyone would like to have a shell on a debian > > stable system to test make scripts (or whatever) I > > can > > supply such a shell. > > > > --- Mitch Obrian wrote: > > > It was done from a new clean tree. (It failed) > > > > > > --- Mark Wedel wrote: > > > > > > > > The general problem is that the > > checkout/update > > > of > > > > files does not always match > > > > dependency order. > > > > > > > > This, the makefiles think they need to > re-run > > > some > > > > commands, but it doesn't > > > > work, because you don't have the right > versions. > > > > > > > > So try this: > > > > % rm configure.in configure > > > > % cvs update configure.in > > > > Warning: Remote host denied X11 forwarding. > > > > cvs update: warning: configure.in was lost > > > > U configure.in > > > > % cvs update configure > > > > Warning: Remote host denied X11 forwarding. > > > > cvs update: warning: configure was lost > > > > U configure > > > > > > > > It is a requirement that the update commands > > be > > > > run seperately, otherwise, > > > > you're just going to screw up the dependency > > > order. > > > > > > > > Then after you do that, re-run configure, > run > > > > make, and it all should be good. > > > > > > > > > > > > > _______________________________________________ > > > > crossfire mailing list > > > > crossfire@metalforge.org > > > > > > > > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Make Yahoo! your home page > > > http://www.yahoo.com/r/hs > > > > > > _______________________________________________ > > > crossfire mailing list > > > crossfire@metalforge.org > > > > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Small Business - Try our new resources > site! > > http://smallbusiness.yahoo.com/resources/ > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 250MB free storage. Do more. Manage > less. > http://info.mail.yahoo.com/mail_250 > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From mikeeusaaa at yahoo.com Fri Mar 18 14:44:59 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Mar 18 14:49:36 2005 Subject: [crossfire] MWedel could you make weather smooth Message-ID: <20050318204502.37462.qmail@web61010.mail.yahoo.com> Currently the clients don't smooth tiles dropped by weather code (snow and all that stuff) because the client dosn't smooth anything thats not set floor=1 I guess... now since only things that are ment to be smoothed have smoothing set at all .... could you let things that arent floor=1 smooth so weather stuff will smooth? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From mwedel at sonic.net Sat Mar 19 01:39:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Mar 19 01:45:37 2005 Subject: [crossfire] MWedel could you make weather smooth In-Reply-To: <20050318204502.37462.qmail@web61010.mail.yahoo.com> References: <20050318204502.37462.qmail@web61010.mail.yahoo.com> Message-ID: <423BD739.1030801@sonic.net> Mitch Obrian wrote: > Currently the clients don't smooth tiles dropped by > weather code (snow and all that stuff) because the > client dosn't smooth anything thats not set floor=1 I > guess... now since only things that are ment to be > smoothed have smoothing set at all .... could you let > things that arent floor=1 smooth so weather stuff will > smooth? I did not write the smooth logic - might be better of to talk to tchize since he wrote that code. Taking a brief look at the code in question, these are my observations: 1) the server doesn't care what layer the objects are that have smoothing, and doesn't care if it is a floor or not, so is sending the right data to the client. 2) The client is getting all the right data - however, this line (from the sdl.c file, drawsmooth_sdl()) is probably the culprit: if ( (the_map.cells[mx][my].heads[0].face==0) || !CAN_SMOOTH(the_map.cells[mx][my].smooth[layer]) ) return; This basically means that objects will only smooth if the objects they are smoothing onto are also smooth capable. So at minimum, the weather effect objects need to have a smoothlevel set (I haven't checked if they do that). If this is done for all the weather objects, I think it should work OK. The problem you still will get is that spaces that have weather won't tile onto those spaces that don't. That is because the weather tile will be at layer 1, while on the other square, might be nothing at level 1 (face==0), or some other ojbect that is not smoothable. Presumably that is done because if you say have a space with a house on it, you don't want the smooth effect to go on top of the building, so instead, safer to not smooth. Perhaps making the default smooth values for objects that don't have it set to 255 would work, thus, these objects would always be on top, but not 100% sure if that would in fact work. From mikeeusaaa at yahoo.com Sat Mar 19 09:46:31 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Mar 19 09:49:49 2005 Subject: [crossfire] MWedel could you make weather smooth In-Reply-To: 6667 Message-ID: <20050319154631.41509.qmail@web61007.mail.yahoo.com> Ah.. well this has been a (visual) problem for about ... well atleast a year. I think it would be good to set 255 smoothing on all that don't have anything set also :) basically snow weather dosn't smooth at all, nor does some of the other tiles weather puts down... makes things ugly and thus players don't want to play with glorious weather turned on. --- Mark Wedel wrote: > Mitch Obrian wrote: > > Currently the clients don't smooth tiles dropped > by > > weather code (snow and all that stuff) because the > > client dosn't smooth anything thats not set > floor=1 I > > guess... now since only things that are ment to be > > smoothed have smoothing set at all .... could you > let > > things that arent floor=1 smooth so weather stuff > will > > smooth? > > I did not write the smooth logic - might be better > of to talk to tchize since > he wrote that code. > > Taking a brief look at the code in question, these > are my observations: > 1) the server doesn't care what layer the objects > are that have smoothing, and > doesn't care if it is a floor or not, so is sending > the right data to the client. > > 2) The client is getting all the right data - > however, this line (from the sdl.c > file, drawsmooth_sdl()) is probably the culprit: > > if ( (the_map.cells[mx][my].heads[0].face==0) > || > !CAN_SMOOTH(the_map.cells[mx][my].smooth[layer]) ) > return; > > This basically means that objects will only smooth > if the objects they are > smoothing onto are also smooth capable. So at > minimum, the weather effect > objects need to have a smoothlevel set (I haven't > checked if they do that). If > this is done for all the weather objects, I think it > should work OK. > > The problem you still will get is that spaces that > have weather won't tile > onto those spaces that don't. That is because the > weather tile will be at layer > 1, while on the other square, might be nothing at > level 1 (face==0), or some > other ojbect that is not smoothable. > > Presumably that is done because if you say have a > space with a house on it, > you don't want the smooth effect to go on top of the > building, so instead, safer > to not smooth. Perhaps making the default smooth > values for objects that don't > have it set to 255 would work, thus, these objects > would always be on top, but > not 100% sure if that would in fact work. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From kirschbaum at myrealbox.com Sun Mar 20 10:49:35 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Mar 20 10:54:05 2005 Subject: [crossfire] Luck penalty does not drop back to zero Message-ID: <20050320164935.GA10429@kirschbaum.myrealbox.com> There is a comment indicating a possible bug in common/living.c: /* Randomly change the players luck. Basically, we move it * back neutral (if greater>0, subtract, otherwise add) * I believe this is supposed to be > and not >= - this means * if your luck is -1/1, it won't get adjusted - only when your * luck is worse can you hope for improvment. * note that if we adjusted it with it is -1/1, that check above * for 0 luck will happen, resulting in error. */ I'd like to change the code so that the luck penalty for killing players will eventually drop back to zero. Any objections here? From kirschbaum at myrealbox.com Sun Mar 20 12:17:19 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Mar 20 12:22:06 2005 Subject: [crossfire] Re: [CF-Devel] Questions about plugin code In-Reply-To: <41782DE8.2000405@sympatico.ca> References: <20041013191013.GA26668@idefix2.dvlp.in-medias-res.com> <416D9850.2080901@sympatico.ca> <20041014181025.GA17936@idefix2.dvlp.in-medias-res.com> <1098070794.6658.8.camel@oberon.kameria> <20041018171554.GA30335@idefix2.dvlp.in-medias-res.com> <1098148031.3389.3.camel@oberon.kameria> <20041021191230.GA14113@idefix2.dvlp.in-medias-res.com> <41782DE8.2000405@sympatico.ca> Message-ID: <20050320181719.GA10717@kirschbaum.myrealbox.com> > Now there is this problem with dropping applied items... :) What is the problem here? Do you mean that the apply script should be run if you drop an applied item? From temitchell at sympatico.ca Sun Mar 20 12:34:42 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sun Mar 20 12:40:06 2005 Subject: [crossfire] Re: [CF-Devel] Questions about plugin code In-Reply-To: <20050320181719.GA10717@kirschbaum.myrealbox.com> References: <20041013191013.GA26668@idefix2.dvlp.in-medias-res.com> <416D9850.2080901@sympatico.ca> <20041014181025.GA17936@idefix2.dvlp.in-medias-res.com> <1098070794.6658.8.camel@oberon.kameria> <20041018171554.GA30335@idefix2.dvlp.in-medias-res.com> <1098148031.3389.3.camel@oberon.kameria> <20041021191230.GA14113@idefix2.dvlp.in-medias-res.com> <41782DE8.2000405@sympatico.ca> <20050320181719.GA10717@kirschbaum.myrealbox.com> Message-ID: <1111343682.3934.7.camel@oberon.kameria> Hmmm, I think you are asking this: If you drop an applied item it does not call the unapply hook for the plugin. If you unapply an applied item it does. This causes problems as scripts which run when an item is unapplied do not run when the item is dropped directly. I wrote a patch for this but it runs the apply hook twice when items are dropped (still seemed to work properly however). http://sourceforge.net/tracker/?group_id=13833&atid=113833&func=detail&aid=878949 On Sun, 2005-20-03 at 19:17 +0100, Andreas Kirschbaum wrote: > Now there is this problem with dropping applied items... :) -- Todd Mitchell From mikeeusaaa at yahoo.com Sun Mar 20 13:20:57 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Mar 20 13:24:06 2005 Subject: [crossfire] Luck penalty does not drop back to zero In-Reply-To: 6667 Message-ID: <20050320192057.74394.qmail@web61009.mail.yahoo.com> Good idea. Also there is an over flow where if you go negative luck too much it turns positive. There also aren't hardly any ways of getting more luck... --- Andreas Kirschbaum wrote: > There is a comment indicating a possible bug in > common/living.c: > > /* Randomly change the players luck. Basically, we > move it > * back neutral (if greater>0, subtract, otherwise > add) > * I believe this is supposed to be > and not >= - > this means > * if your luck is -1/1, it won't get adjusted - > only when your > * luck is worse can you hope for improvment. > * note that if we adjusted it with it is -1/1, that > check above > * for 0 luck will happen, resulting in error. > */ > > I'd like to change the code so that the luck penalty > for killing players > will eventually drop back to zero. Any objections > here? > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From yann.chachkoff at myrealbox.com Sun Mar 20 13:52:45 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Mar 20 13:56:07 2005 Subject: [crossfire] Re: [CF-Devel] Questions about plugin code In-Reply-To: <1111343682.3934.7.camel@oberon.kameria> References: <20041013191013.GA26668@idefix2.dvlp.in-medias-res.com> <20050320181719.GA10717@kirschbaum.myrealbox.com> <1111343682.3934.7.camel@oberon.kameria> Message-ID: <200503202052.52458.yann.chachkoff@myrealbox.com> Le Dimanche 20 Mars 2005 19:34, Todd Mitchell a ?crit : > Hmmm, > I think you are asking this: > If you drop an applied item it does not call the unapply hook for the > plugin. If you unapply an applied item it does. This causes problems > as scripts which run when an item is unapplied do not run when the item > is dropped directly. I wrote a patch for this but it runs the apply > hook twice when items are dropped (still seemed to work properly > however). > http://sourceforge.net/tracker/?group_id=13833&atid=113833&func=detail&aid= >878949 > > On Sun, 2005-20-03 at 19:17 +0100, Andreas Kirschbaum wrote: > > Now there is this problem with dropping applied items... :) Work on "refurbishing" of the plugin interface is under way, including correction for this bug, which has been reported some time ago, as Todd Mitchell said. A cleaner plugin management (including previous remarks about inconsistencies in the even handling WhoAmI/WhoIsActivator/WhoIsOther and runtime binding problems) should come soon for approval on the mailing list. This is not yet the case, as I want to try every CFPython function currently implemented on both *NIX and Win32 platforms before submitting the work for testing. It takes a long time, given the amount of CFPython functions to check out. So no panic, work is under way. If you have specific concerns (or wishes) about either the plugin interface or the CFPython plugin that weren't yet reported as a bug on sourceforge, please state them on this mailing list, so I can take them into account. Yours, -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://pgp.dtype.org:11371/pks/lookup?op=get&search=0x844D25E0 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050320/07a8f0de/attachment.pgp From mwedel at sonic.net Sun Mar 20 16:08:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Mar 20 16:12:08 2005 Subject: [crossfire] Luck penalty does not drop back to zero In-Reply-To: <20050320192057.74394.qmail@web61009.mail.yahoo.com> References: <20050320192057.74394.qmail@web61009.mail.yahoo.com> Message-ID: <423DF45A.9030206@sonic.net> Mitch Obrian wrote: > Good idea. > Also there is an over flow where if you go negative > luck too much it turns positive. > > There also aren't hardly any ways of getting more > luck... I think that is somewhat intentional - luck is supposed to be one those things outside of player control. If there were potions of luck, or you could get luck restored praying at altars or whatever, luck, and penalties for killing other people, would be pretty meaningless. From nicolas.weeger at laposte.net Wed Mar 23 07:58:07 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Mar 23 07:58:34 2005 Subject: [crossfire] Building materials Message-ID: Hello. A few months ago I committed my building code, which lets a player build a map at will. To correctly be used, the player needs 'Raw materials', like 'Raw floor material', one per square to be used. Currently, there is only one floor type, and one wall type, as well as the ability to remove walls. I was thinking of adding more things to build, and wondering the best way to do that. Right now, my code uses special archetypes, hardcoded with the built item in the 'slaying' field of the archetype. The idea I had is to make a python plugin to let users request materials. So the player could go to a shop, and ask for 'wood floor', or 'marble floor', or 'fountain', and so on. How I was thinking of implementing that was: * when the player asks for material, create a dummy material object. * set its slaying field with the archetype name (need a 'human name to archetype' conversion so players can say 'wood floor' instead of 'woodfloor' or whatever the archetype is) * if required, change the material type to 'wall', 'floor', 'item'. Those last 3 types are the 3 types of items my code currently handles: wall will be built on a floor, and try to connect to other floors around. Floor will destroy a wall on the square, and/or replace existing floor. Finally item is checked for 'connected' (door, lever, ...) type, connected if required (through the use of a marking rune), and inserted. The main point I have currently is that letting a player request material may lead to abuse. You could ask for 'dragon mail', then build one, if code isn't correctly done. To prevent that, I see 3 solutions: * build a 'safe list' of archetypes players can build, fill it with everything they should be allowed to create * build a 'safe list' of item types allowed. Thus you can disable 'armor' but enable 'wall'. * don't do any plugin, and make archetypes for all buildable items :) The 1st is more messy, because when you add a new floor/wall/... you need to update the list, but lets you have more control over what you can or cannot build. The 2nd may be easier to do (only let players build floor, wall, doors/level/..., and items with no type), but gives less freedom. 3rd is the current one, but will take time to make archetypes for everything you can build - and kind of duplicate many things. So, what does everyone think of that? Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mikeeusaaa at yahoo.com Wed Mar 23 11:42:30 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 23 11:44:36 2005 Subject: [crossfire] Building materials In-Reply-To: 6667 Message-ID: <20050323174230.64637.qmail@web61004.mail.yahoo.com> I suggest just making more archtypes. Python sometimes breaks depending on verison. C and text isn't as finicky. I rather like the shop way it is now and have added a material store to MLAB CityDeClouds awhile ago along with buildable plots. --- Nicolas Weeger wrote: > Hello. > > A few months ago I committed my building code, which > lets a player build a map at will. > > To correctly be used, the player needs 'Raw > materials', like 'Raw floor material', one per > square to be used. > > Currently, there is only one floor type, and one > wall type, as well as the ability to remove walls. > > I was thinking of adding more things to build, and > wondering the best way to do that. > > Right now, my code uses special archetypes, > hardcoded with the built item in the 'slaying' field > of the archetype. > > The idea I had is to make a python plugin to let > users request materials. So the player could go to a > shop, and ask for 'wood floor', or 'marble floor', > or 'fountain', and so on. > > How I was thinking of implementing that was: > * when the player asks for material, create a dummy > material object. > * set its slaying field with the archetype name > (need a 'human name to archetype' conversion so > players can say 'wood floor' instead of 'woodfloor' > or whatever the archetype is) > * if required, change the material type to 'wall', > 'floor', 'item'. > > Those last 3 types are the 3 types of items my code > currently handles: wall will be built on a floor, > and try to connect to other floors around. Floor > will destroy a wall on the square, and/or replace > existing floor. Finally item is checked for > 'connected' (door, lever, ...) type, connected if > required (through the use of a marking rune), and > inserted. > > The main point I have currently is that letting a > player request material may lead to abuse. You could > ask for 'dragon mail', then build one, if code isn't > correctly done. > > To prevent that, I see 3 solutions: > * build a 'safe list' of archetypes players can > build, fill it with everything they should be > allowed to create > * build a 'safe list' of item types allowed. Thus > you can disable 'armor' but enable 'wall'. > * don't do any plugin, and make archetypes for all > buildable items :) > > The 1st is more messy, because when you add a new > floor/wall/... you need to update the list, but lets > you have more control over what you can or cannot > build. > The 2nd may be easier to do (only let players build > floor, wall, doors/level/..., and items with no > type), but gives less freedom. > 3rd is the current one, but will take time to make > archetypes for everything you can build - and kind > of duplicate many things. > > So, what does everyone think of that? > > Nicolas > > Accédez au courrier électronique de La Poste : > www.laposte.net ; > 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 > (0,34€/mn) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tchize at myrealbox.com Wed Mar 23 14:44:34 2005 From: tchize at myrealbox.com (tchize) Date: Wed Mar 23 14:46:38 2005 Subject: [crossfire] MWedel could you make weather smooth In-Reply-To: <20050318204502.37462.qmail@web61010.mail.yahoo.com> References: <20050318204502.37462.qmail@web61010.mail.yahoo.com> Message-ID: <200503232144.39603.tchize@myrealbox.com> smooth only to floor==1: false assertion, anything with smoothlevel other than 0 will be smoothed by client if a smooth picture is available, code has never been restricted to floors. It was forseen the snow the water drops of even spell effect could use the smoothing code. code logic is pretty simple: if client supports smoothing, send smoothlevels along with map squares. Client does then applies the smooth rendering logic for everything with smoothlevel not zero. Are you sure the is a problem with weather items or did you just conclude this because currently all smoothed things are only floors things? Le Vendredi 18 Mars 2005 21:44, Mitch Obrian a ?crit : Currently the clients don't smooth tiles dropped by weather code (snow and all that stuff) because the client dosn't smooth anything thats not set floor=1 I guess... now since only things that are ment to be smoothed have smoothing set at all .... could you let things that arent floor=1 smooth so weather stuff will smooth? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050323/6c267867/attachment.pgp From tchize at myrealbox.com Wed Mar 23 14:56:13 2005 From: tchize at myrealbox.com (tchize) Date: Wed Mar 23 14:56:38 2005 Subject: [crossfire] MWedel could you make weather smooth In-Reply-To: <20050319154631.41509.qmail@web61007.mail.yahoo.com> References: <20050319154631.41509.qmail@web61007.mail.yahoo.com> Message-ID: <200503232156.18012.tchize@myrealbox.com> Just some enlightments about that test: > if ( (the_map.cells[mx][my].heads[0].face==0) This checks if the tile we are smoothing on does have at least one face. This is done to prevent smoothing at borders of map. nothing to do with buildings and so on. Correct me if i am wrong but if face at layer 0 is '0' we either don't have info about that space (because hidden from player) or there is nothing at that space on map (not even a ground). > !CAN_SMOOTH(the_map.cells[mx][my].smooth[layer]) ) This indeed check of at given layer we are smooth capable. This simply check the smoothlevel at current layer is not 0 (0 having the meaning 'do not smooth on me'). Ok, and now i am reading what is just said, i see where the bug comes from. There is no face at current layer (let' s say one) so smoothlevel is 0 and the client concludes it can't do smoothing there. Damn am going to correct this immediatly :s:s:s (Et je vais au passage aller me flageler avec des orties fra?ches). Sorry Sorry Sorry... Le Samedi 19 Mars 2005 16:46, Mitch Obrian a ?crit : Ah.. well this has been a (visual) problem for about .... well atleast a year. I think it would be good to set 255 smoothing on all that don't have anything set also :) basically snow weather dosn't smooth at all, nor does some of the other tiles weather puts down... makes things ugly and thus players don't want to play with glorious weather turned on. --- Mark Wedel wrote: > Mitch Obrian wrote: > > Currently the clients don't smooth tiles dropped > > by > > > weather code (snow and all that stuff) because the > > client dosn't smooth anything thats not set > > floor=1 I > > > guess... now since only things that are ment to be > > smoothed have smoothing set at all .... could you > > let > > > things that arent floor=1 smooth so weather stuff > > will > > > smooth? > > I did not write the smooth logic - might be better > of to talk to tchize since > he wrote that code. > > Taking a brief look at the code in question, these > are my observations: > 1) the server doesn't care what layer the objects > are that have smoothing, and > doesn't care if it is a floor or not, so is sending > the right data to the client. > > 2) The client is getting all the right data - > however, this line (from the sdl.c > file, drawsmooth_sdl()) is probably the culprit: > > if ( (the_map.cells[mx][my].heads[0].face==0) > > !CAN_SMOOTH(the_map.cells[mx][my].smooth[layer]) ) > return; > > This basically means that objects will only smooth > if the objects they are > smoothing onto are also smooth capable. So at > minimum, the weather effect > objects need to have a smoothlevel set (I haven't > checked if they do that). If > this is done for all the weather objects, I think it > should work OK. > > The problem you still will get is that spaces that > have weather won't tile > onto those spaces that don't. That is because the > weather tile will be at layer > 1, while on the other square, might be nothing at > level 1 (face==0), or some > other ojbect that is not smoothable. > > Presumably that is done because if you say have a > space with a house on it, > you don't want the smooth effect to go on top of the > building, so instead, safer > to not smooth. Perhaps making the default smooth > values for objects that don't > have it set to 255 would work, thus, these objects > would always be on top, but > not 100% sure if that would in fact work. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050323/37338787/attachment.pgp From tchize at myrealbox.com Wed Mar 23 15:56:27 2005 From: tchize at myrealbox.com (tchize) Date: Wed Mar 23 16:00:48 2005 Subject: [crossfire] client not compiling without gtk2 libraries?? Message-ID: <200503232256.35957.tchize@myrealbox.com> Hello, There has been some works currently by mwedel on making a gtk2 version of client. Is it normal configure stops if it doesn't find libgtk2? I thought this was supposed to be optional. I get this when running configure without libgtk2.0-dev package installed: checking for gtk+-2.0 >= 2.0.0... Package gtk+-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gtk+-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gtk+-2.0' found configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050323/54987432/attachment.pgp From tchize at myrealbox.com Wed Mar 23 16:20:01 2005 From: tchize at myrealbox.com (tchize) Date: Wed Mar 23 16:20:39 2005 Subject: [crossfire] [FIXED] MWedel could you make weather smooth In-Reply-To: <20050319154631.41509.qmail@web61007.mail.yahoo.com> References: <20050319154631.41509.qmail@web61007.mail.yahoo.com> Message-ID: <200503232320.09316.tchize@myrealbox.com> Fixed in latests cvs. Please note you need server cvs from 22 march according to change mwedel did in smooth face pushing protocol or your client won't do smoothing at all if server is older. Did improve the CAN_SMOOTH() define. Also, this works quite well but have problems with lots of items having a default smoothlevel of 0 (a character moving around the border of snow will prevent smoothing there). Maybe make all items with default smoothlevel of 1 on server would be good to correct this. Too late to check). Le Samedi 19 Mars 2005 16:46, Mitch Obrian a ?crit : Ah.. well this has been a (visual) problem for about .... well atleast a year. I think it would be good to set 255 smoothing on all that don't have anything set also :) basically snow weather dosn't smooth at all, nor does some of the other tiles weather puts down... makes things ugly and thus players don't want to play with glorious weather turned on. --- Mark Wedel wrote: > Mitch Obrian wrote: > > Currently the clients don't smooth tiles dropped > > by > > > weather code (snow and all that stuff) because the > > client dosn't smooth anything thats not set > > floor=1 I > > > guess... now since only things that are ment to be > > smoothed have smoothing set at all .... could you > > let > > > things that arent floor=1 smooth so weather stuff > > will > > > smooth? > > I did not write the smooth logic - might be better > of to talk to tchize since > he wrote that code. > > Taking a brief look at the code in question, these > are my observations: > 1) the server doesn't care what layer the objects > are that have smoothing, and > doesn't care if it is a floor or not, so is sending > the right data to the client. > > 2) The client is getting all the right data - > however, this line (from the sdl.c > file, drawsmooth_sdl()) is probably the culprit: > > if ( (the_map.cells[mx][my].heads[0].face==0) > > !CAN_SMOOTH(the_map.cells[mx][my].smooth[layer]) ) > return; > > This basically means that objects will only smooth > if the objects they are > smoothing onto are also smooth capable. So at > minimum, the weather effect > objects need to have a smoothlevel set (I haven't > checked if they do that). If > this is done for all the weather objects, I think it > should work OK. > > The problem you still will get is that spaces that > have weather won't tile > onto those spaces that don't. That is because the > weather tile will be at layer > 1, while on the other square, might be nothing at > level 1 (face==0), or some > other ojbect that is not smoothable. > > Presumably that is done because if you say have a > space with a house on it, > you don't want the smooth effect to go on top of the > building, so instead, safer > to not smooth. Perhaps making the default smooth > values for objects that don't > have it set to 255 would work, thus, these objects > would always be on top, but > not 100% sure if that would in fact work. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050323/2b24a66b/attachment.pgp From tchize at myrealbox.com Thu Mar 24 15:05:23 2005 From: tchize at myrealbox.com (tchize) Date: Thu Mar 24 15:06:52 2005 Subject: [crossfire] strange behaviour of movements with latest server Message-ID: <200503242205.28983.tchize@myrealbox.com> Hello, Today, i tested some changes on a local server an , while playing with it, i noticed a strange behaviour of my charchter. it was simply freezing for a few seconds and then followed a whole path of movements like recorded from before. During the whole process, the background animations were running so it was not a freeze from server of client. Here is what i did - switch to dm (so to not be blocked by walls, etc, works also without dm but easier to notice as dm) - hit the 'run' key - while key is pressed, go up, down, left, whatever - suddently, the character freeze. Don't release run key an choose another direction, then another one, then release run - wait - when character unfreeze, it runs a long way along the first path, then the second, then the third. I don't know what is causing this, occured with mf server, local server (latest cvs) but not with mikeeusa server (server a few weeks old only). My guess is someone did changes sth to protocol which could have broken this, but i have no clue. Also, while character is frozen, commands like say, shout are also frozen, but taken into consideration after the unfreeze. -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050324/1eb5d58d/attachment.pgp From alex_sch at telus.net Thu Mar 24 18:59:57 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Mar 24 19:09:22 2005 Subject: [crossfire] strange behaviour of movements with latest server In-Reply-To: <200503242205.28983.tchize@myrealbox.com> References: <200503242205.28983.tchize@myrealbox.com> Message-ID: <4243628D.5090801@telus.net> This sounds similar to the lag started getting recently on MF after a CVS update (same time a bunch of windows clients started crashing)... I managed to work around it by disabling image caching. (It happened both in cfclient and gcfclient, in both verions 1.7.0 and CVS of the client all running under linux). Don't know if this is the same thing, but it sounds similar. --Rednaxela tchize wrote: >Hello, >Today, i tested some changes on a local server an , while playing with it, i >noticed a strange behaviour of my charchter. it was simply freezing for a few >seconds and then followed a whole path of movements like recorded from >before. During the whole process, the background animations were running so >it was not a freeze from server of client. > >Here is what i did >- switch to dm (so to not be blocked by walls, etc, works also without dm but >easier to notice as dm) >- hit the 'run' key >- while key is pressed, go up, down, left, whatever >- suddently, the character freeze. Don't release run key an choose another >direction, then another one, then release run >- wait >- when character unfreeze, it runs a long way along the first path, then the >second, then the third. > >I don't know what is causing this, occured with mf server, local server >(latest cvs) but not with mikeeusa server (server a few weeks old only). My >guess is someone did changes sth to protocol which could have broken this, >but i have no clue. >Also, while character is frozen, commands like say, shout are also frozen, but >taken into consideration after the unfreeze. > > > >------------------------------------------------------------------------ > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > From fuchs.andy at gmail.com Thu Mar 24 19:09:45 2005 From: fuchs.andy at gmail.com (Andy Fuchs) Date: Thu Mar 24 19:10:53 2005 Subject: [crossfire] Bug with regions in customizeable who lines Message-ID: The server seems to crash when %R is added to 'who_format" in the config file. >From irc: >techII give me the config for who format >mikeeusa >mikeeusa who_format %N the %t%h%d%a%n[%R] >techII tried same thing here, crash >mikeeusa who_wiz_format %N the %t%h%d%nLevel %l [%m](@%i)(%c) >mikeeusa hmm is that a binary char at the end of it (not a newline) >mikeeusa irc says yes >mikeeusa # an underscore that is not escaped gives a space (or you can use a real >mikeeusa space >mikeeusa ill comment out space >mikeeusa nope still crashes on >mikeeusa who >techII seems like the %R >mikeeusa shout I put it to %r instead? >techII try it >.... >mikeeusa Total Players in The World. (1) -- WIZ(0) AFK(0) >mikeeusa mikeeusa the White Frost[DS] >mikeeusa [wilderness] >mikeeusa >mikeeusa workes with %R >techII with %r or %R >techII ? >* moppit (~moppit@66-188-193-236.roc.mn.charter.com) has joined #crossfire >mikeeusa %r >moppit hey all >mikeeusa it works with %r -- -- Andrew Fuchs From mwedel at sonic.net Fri Mar 25 01:34:58 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 25 01:36:07 2005 Subject: [crossfire] Building materials In-Reply-To: References: Message-ID: <4243BF22.6030909@sonic.net> I tend to agree with just doing it as archetypes. Then these could just go in treasure lists - thus, what shows up in the building store would be random, but maybe that adds some more interest (cool, the fountain finally showed up!). the other question which you don't address is that if players can 'request' items, how do you price them? It would seem that marble floors, for example, should be more expensive than wood, and so on. Arguably, the only thing that should be allowed as buildable objects would largely be floors and walls. There is no reason to allow chairs, swords, food, etc, because those are things that can be physically carried by the character - that can't happen with the wall (there may be a limited extension to what I say, but basically it should be limited). That said, there is find_archetype_by_object_name() which takes the human name and converts the archetype. However, not all object (human) names are unique. Thus, there could be 5 archetypes that match 'wall' - the code basically returns the first it finds. So such a system could very well prevent you from selecting all the wall types. From mwedel at sonic.net Fri Mar 25 01:59:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 25 02:00:57 2005 Subject: [crossfire] client not compiling without gtk2 libraries?? In-Reply-To: <200503232256.35957.tchize@myrealbox.com> References: <200503232256.35957.tchize@myrealbox.com> Message-ID: <4243C4E2.6050903@sonic.net> tchize wrote: > Hello, > There has been some works currently by mwedel on making a gtk2 version of > client. Is it normal configure stops if it doesn't find libgtk2? I thought > this was supposed to be optional. > I get this when running configure without libgtk2.0-dev package installed: > checking for gtk+-2.0 >= 2.0.0... Package gtk+-2.0 was not found in the > pkg-config search path. > Perhaps you should add the directory containing `gtk+-2.0.pc' > to the PKG_CONFIG_PATH environment variable > No package 'gtk+-2.0' found > > configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; consider > adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a > nonstandard prefix so pkg-config can find them. I'll fix this up - need to find a convenient system that doesn't have gtkv2 installed to make sure my change works. From mwedel at sonic.net Fri Mar 25 01:59:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 25 02:01:02 2005 Subject: [crossfire] client not compiling without gtk2 libraries?? In-Reply-To: <200503232256.35957.tchize@myrealbox.com> References: <200503232256.35957.tchize@myrealbox.com> Message-ID: <4243C4E2.6050903@sonic.net> tchize wrote: > Hello, > There has been some works currently by mwedel on making a gtk2 version of > client. Is it normal configure stops if it doesn't find libgtk2? I thought > this was supposed to be optional. > I get this when running configure without libgtk2.0-dev package installed: > checking for gtk+-2.0 >= 2.0.0... Package gtk+-2.0 was not found in the > pkg-config search path. > Perhaps you should add the directory containing `gtk+-2.0.pc' > to the PKG_CONFIG_PATH environment variable > No package 'gtk+-2.0' found > > configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; consider > adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a > nonstandard prefix so pkg-config can find them. I'll fix this up - need to find a convenient system that doesn't have gtkv2 installed to make sure my change works. From b.t.lally at warwick.ac.uk Fri Mar 25 02:23:31 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Fri Mar 25 02:06:30 2005 Subject: [crossfire] Bug with regions in customizeable who lines In-Reply-To: References: Message-ID: <200503250823.32343.b.t.lally@warwick.ac.uk> On Friday 25 Mar 2005 01:09, Andy Fuchs wrote: > The server seems to crash when %R is added to 'who_format" in the config > file. ok I've just patched this, it should now work better, seems it was occasionally referencing NULL. Bug me if this doesn't work (it does for me). From nicolas.weeger at laposte.net Fri Mar 25 02:21:37 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Mar 25 02:22:56 2005 Subject: [crossfire] Building materials Message-ID: > I tend to agree with just doing it as archetypes. Then these could just go in > treasure lists - thus, what shows up in the building store would be random, but > maybe that adds some more interest (cool, the fountain finally showed up!). Guess I'll do it that way, then :) > the other question which you don't address is that if players can 'request' > items, how do you price them? It would seem that marble floors, for example, > should be more expensive than wood, and so on. Would need to define a price in the item's archetype itself, maybe? I doubt the floor or wall archetypes define a value, so we could use it :) > > Arguably, the only thing that should be allowed as buildable objects would > largely be floors and walls. There is no reason to allow chairs, swords, food, > etc, because those are things that can be physically carried by the character - > that can't happen with the wall (there may be a limited extension to what I say, > but basically it should be limited). Hum. I was thinking that we could let players build rivers, and such - wouldn't it be fun to create a garden? :) Or to plant tree we could add a new skill :p Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mwedel at sonic.net Fri Mar 25 02:49:22 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 25 02:50:57 2005 Subject: [crossfire] strange behaviour of movements with latest server In-Reply-To: <200503242205.28983.tchize@myrealbox.com> References: <200503242205.28983.tchize@myrealbox.com> Message-ID: <4243D092.5090609@sonic.net> tchize wrote: > Hello, > Today, i tested some changes on a local server an , while playing with it, i > noticed a strange behaviour of my charchter. it was simply freezing for a few > seconds and then followed a whole path of movements like recorded from > before. During the whole process, the background animations were running so > it was not a freeze from server of client. > > Here is what i did > - switch to dm (so to not be blocked by walls, etc, works also without dm but > easier to notice as dm) > - hit the 'run' key > - while key is pressed, go up, down, left, whatever > - suddently, the character freeze. Don't release run key an choose another > direction, then another one, then release run > - wait > - when character unfreeze, it runs a long way along the first path, then the > second, then the third. > > I don't know what is causing this, occured with mf server, local server > (latest cvs) but not with mikeeusa server (server a few weeks old only). My > guess is someone did changes sth to protocol which could have broken this, > but i have no clue. > Also, while character is frozen, commands like say, shout are also frozen, but > taken into consideration after the unfreeze. I just tried to reproduce this on my test server and was unable to do. I ran all around, and never did it freeze. Analysis of the server when it is in that state is probably necessary to see what it was doing. My understanding of the cause of metalforge freezes last weekend was high level casters casting large area of effect spells, but could be wrong on that. The only thing that changed on the protocol level is how smoothing is handled. So one can eliminate that as a possible cause by turning off smoothing and see if it still happens or not. If you're not using smoothing, the change to the server should be non existent. From mwedel at sonic.net Fri Mar 25 02:49:22 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Mar 25 02:51:03 2005 Subject: [crossfire] strange behaviour of movements with latest server In-Reply-To: <200503242205.28983.tchize@myrealbox.com> References: <200503242205.28983.tchize@myrealbox.com> Message-ID: <4243D092.5090609@sonic.net> tchize wrote: > Hello, > Today, i tested some changes on a local server an , while playing with it, i > noticed a strange behaviour of my charchter. it was simply freezing for a few > seconds and then followed a whole path of movements like recorded from > before. During the whole process, the background animations were running so > it was not a freeze from server of client. > > Here is what i did > - switch to dm (so to not be blocked by walls, etc, works also without dm but > easier to notice as dm) > - hit the 'run' key > - while key is pressed, go up, down, left, whatever > - suddently, the character freeze. Don't release run key an choose another > direction, then another one, then release run > - wait > - when character unfreeze, it runs a long way along the first path, then the > second, then the third. > > I don't know what is causing this, occured with mf server, local server > (latest cvs) but not with mikeeusa server (server a few weeks old only). My > guess is someone did changes sth to protocol which could have broken this, > but i have no clue. > Also, while character is frozen, commands like say, shout are also frozen, but > taken into consideration after the unfreeze. I just tried to reproduce this on my test server and was unable to do. I ran all around, and never did it freeze. Analysis of the server when it is in that state is probably necessary to see what it was doing. My understanding of the cause of metalforge freezes last weekend was high level casters casting large area of effect spells, but could be wrong on that. The only thing that changed on the protocol level is how smoothing is handled. So one can eliminate that as a possible cause by turning off smoothing and see if it still happens or not. If you're not using smoothing, the change to the server should be non existent. From temitchell at sympatico.ca Thu Mar 24 09:20:45 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Mar 25 09:25:02 2005 Subject: [crossfire] Building materials In-Reply-To: References: Message-ID: <1111677645.3355.2.camel@oberon.kameria> I think that arches would be best as well, a good treasure list for the shops would make things interesting. I think the prices are a bit low for building materials right now, but then again you just have wood now - I expect marble and landscape materials would be a lot more expensive. From nicolas.weeger at laposte.net Fri Mar 25 09:35:03 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Mar 25 09:35:00 2005 Subject: [crossfire] Building materials Message-ID: We can always change prices later on :) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From nicolas.weeger at laposte.net Fri Mar 25 09:36:54 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Mar 25 09:37:02 2005 Subject: [crossfire] strange behaviour of movements with latest server Message-ID: Maybe not related, but worth mentioning. Yesterday evening, I noticed the client crashing on some cache freeing routine, just because the pointer was NULL. And it's code that dates back to latest official client release that crashed (crashes on cvs version, and 1.7.1). Don't remember the line straight, but was with some CacheFace* pi or something like that (variable is definitely pi), and was called with things like free( pi->xxx ) <= bad when pi is NULL! I'll check later where exactly the crash is. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From fuchs.andy at gmail.com Fri Mar 25 09:37:14 2005 From: fuchs.andy at gmail.com (Andy Fuchs) Date: Fri Mar 25 09:40:36 2005 Subject: [crossfire] Building materials In-Reply-To: <1111677645.3355.2.camel@oberon.kameria> References: <1111677645.3355.2.camel@oberon.kameria> Message-ID: It might also be a good idea to add some code to limit the type of objects that can be built, and who can build them. Such as you can't build a house in a house, and I don't think it would be a good idea to let people build walls around other people's houses. -- -- Andrew Fuchs From nicolas.weeger at laposte.net Fri Mar 25 09:51:16 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Mar 25 09:53:17 2005 Subject: [crossfire] Building materials Message-ID: > It might also be a good idea to add some code to limit the type of > objects that can be built, and who can build them. Such as you can't > build a house in a house, and I don't think it would be a good idea to > let people build walls around other people's houses. Already done, kind of. You can only build on squares that have the special 'is_buildable' flag - which is activated only in the guild storage rooms, afaik. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From fuchs.andy at gmail.com Fri Mar 25 10:04:23 2005 From: fuchs.andy at gmail.com (Andy Fuchs) Date: Fri Mar 25 10:05:01 2005 Subject: [crossfire] Building materials In-Reply-To: References: Message-ID: On Fri, 25 Mar 2005 16:51:16 +0100, Nicolas Weeger people build walls around > Already done, kind of. > You can only build on squares that have the special 'is_buildable' flag - which is activated only in the guild storage rooms, afaik. > > Nicolas This is for the posibility of building houses and the like in the future. And I made use of the building code in the new Navar apartments. -- -- Andrew Fuchs From pc-crossfire04 at crowcastle.net Fri Mar 25 10:23:25 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Fri Mar 25 10:25:01 2005 Subject: [crossfire] Apartment connections Message-ID: <1111767804.17693.37.camel@d5110227.lss.emc.com> Here's an idea I've had floating around for a while: There are a number of teleporters in the game to take players from city to city, including many in apartments. I was thinking that it might be better to instead of having teleporters to cities in the apartments, to have each apartment have a gateway into a room that they all share. You would have to pay a price to get access to this room from any given apartment, but eventually, you could get all your apartments connected. This would probably be implemented by having something in each apartment where you could buy a pair of keys, one of which would open a door letting you get to a teleporter, and one which would open the door on the other side of the teleporter in the gate room. Of course, the cost of the keys could be a combination of cash and quest items, with higher prices for the more important locations (e.g., Pup Land). The two downsides of this are that it would require some tricky conversion to switch over current apartments when upgrading servers, and the problem would arise again as more apartments are added to the game. --PC From mwedel at sonic.net Sat Mar 26 00:25:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Mar 26 00:25:09 2005 Subject: [crossfire] Apartment connections In-Reply-To: <1111767804.17693.37.camel@d5110227.lss.emc.com> References: <1111767804.17693.37.camel@d5110227.lss.emc.com> Message-ID: <42450040.7060004@sonic.net> Preston Crow wrote: > Here's an idea I've had floating around for a while: > > There are a number of teleporters in the game to take players from city > to city, including many in apartments. I was thinking that it might be > better to instead of having teleporters to cities in the apartments, to > have each apartment have a gateway into a room that they all share. You > would have to pay a price to get access to this room from any given > apartment, but eventually, you could get all your apartments connected. > > This would probably be implemented by having something in each apartment > where you could buy a pair of keys, one of which would open a door > letting you get to a teleporter, and one which would open the door on > the other side of the teleporter in the gate room. > > Of course, the cost of the keys could be a combination of cash and quest > items, with higher prices for the more important locations (e.g., Pup > Land). > > The two downsides of this are that it would require some tricky > conversion to switch over current apartments when upgrading servers, and > the problem would arise again as more apartments are added to the game. Converting the apartments would be very tricky, because the private apartment maps are saved as the entire map. so one would have to find a way to 'patch' the existing saved apartments. One question might be why are there teleporters in the apartments at all. Maybe they should be in guilds, and/or in various guilds in each town, where you have to pay a large amount for access to the teleporter (eg, put it behind a grate requiring a large contribution). In practice, players could share the cost (dump the money, everyone scoot through before the gate closes), but that perhaps wouldn't be a bad thing. Would be a a way to use money (no pay a gob of money once, need to pay xyz each time you want to use it). Alternatively, perhaps an easier way to allow access in all apartments is to instead use passes, just like the library card (these could perhaps be done via invisible objects, so that the player doesn't have to physically worry about carrying them). So you get the teleporter pass for brest, and the gate in all your apartments would open. But this still has the problem of patching the existing apartments. From mwedel at sonic.net Sat Mar 26 01:28:03 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Mar 26 01:33:09 2005 Subject: [crossfire] Screenshots on Sourceforge In-Reply-To: References: Message-ID: <42450F03.2090203@sonic.net> I've added a few screenshots to sourceforge web page. A few notes: sourceforge has a max screenshot size of 640x480, and will resize anything larger to that size. It does allow short annotations. It allows 6 screenshots per project. I have 4 up right now, trying to cover the gtk and gtkv2 client, as well as different scenes/options. I'll leave the remaining 2 slots for future screenshots or ones that show something different enough to warrant it. Perhaps more with 'action' would be nice. From alex_sch at telus.net Sat Mar 26 09:06:26 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Mar 26 09:07:14 2005 Subject: [crossfire] Valgrind results Message-ID: <42457A72.7010700@telus.net> Hi, I just thought it would be neat to see the results of valgrind on crossfire so here's the results and the gdefaults file I used in testing. I tested using gcfclient CVS version (2005/03/21) connecting to the MetalForge server. Due to how much slower valgrind caused it to run, it wasn't practical to do much more than simple go and banish a few zombies in the scorn TC. From what I can see, the main leak problems are in image.c in the function create_and_rescale_image_from_data. Thanks, Alex Schultz (aka Rednaxela) -------------- next part -------------- A non-text attachment was scrubbed... Name: gcfclient.log Type: text/x-log Size: 32645 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050326/9b7b9eaa/gcfclient-0001.bin -------------- next part -------------- # This file is generated automatically by gcfclient. # Manually editing is allowed, however gcfclient may be a bit finicky about # some of the matching it does. all comparisons are case sensitive. # 'True' and 'False' are the proper cases for those two values # 'True' and 'False' have been replaced with 1 and 0 respectively server: crossfire.metalforge.net sound_server: cfsndserv faceset: standard colorinv: 1 colortext: 1 download_all_images: 0 echo_bindings: 0 fasttcpsend: 1 command_window: 10 cacheimages: 0 fog_of_war: 1 iconscale: 100 mapscale: 100 popups: 1 sdl: 1 showicon: 0 tooltips: 1 sound: 0 splitinfo: 1 split: 0 show_grid: 0 lighting: 3 trim_info_window: 0 map_width: 13 map_height: 13 foodbeep: 0 darkness: 1 port: 13327 grad_color_bars: 0 resists: 1 smoothing: 0 nosplash: 1 auto_apply_container: 1 From kirschbaum at myrealbox.com Sat Mar 26 11:36:54 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat Mar 26 11:37:14 2005 Subject: [crossfire] Valgrind results In-Reply-To: <42457A72.7010700@telus.net> References: <42457A72.7010700@telus.net> Message-ID: <20050326173654.GA9005@kirschbaum.myrealbox.com> Alex Schultz wrote: > From what I can see, the main leak problems are in image.c in the > function create_and_rescale_image_from_data. I'm currently trying to fix this problem. There are at least two bugs as far as I can see: - The server keeps sending the image information for face 0 over and over. This seems incorrect to me (both sending it over and over, and sending it at all), because the client already preallocates the face 0 as a black face. - The client (that is, all clients) cannot handle "updated" face information: the function create_and_rescale_image_from_data() does not free the previous contents of pixmaps[] before writing the new value. From alex_sch at telus.net Sat Mar 26 13:10:56 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Mar 26 13:11:15 2005 Subject: [crossfire] Valgrind results In-Reply-To: <20050326173654.GA9005@kirschbaum.myrealbox.com> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> Message-ID: <4245B3C0.6080606@telus.net> Andreas Kirschbaum wrote: >I'm currently trying to fix this problem. There are at least two bugs as >far as I can see: > > - The server keeps sending the image information for face 0 over and > over. > > This seems incorrect to me (both sending it over and over, and > sending it at all), because the client already preallocates the face > 0 as a black face. > > - The client (that is, all clients) cannot handle "updated" face > information: the function create_and_rescale_image_from_data() does > not free the previous contents of pixmaps[] before writing the new > value > > Ah... so most of this leakage likely is the combination of both bugs: the server keeps sending face 0 over and over, that counts to the client as a face update, and each time face 0 is sent, the old face 0 (which is exactly the same anyways) isn't freed properly. Is that correct? I also seem to be seeing the X memory usage increasing alot with CF, which appears to be upstream leaks triggered by cfclient. As I understand, the leaks in X itself aren't being tracked by valgrind as that memory isn't owned by cfclient, and running all of X in valgrind would be impractically slow. So exactly why cf is causing X itself to leak may be more difficult to track down. Thanks, Alex Schultz (aka Rednaxela) From kirschbaum at myrealbox.com Sat Mar 26 15:04:44 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat Mar 26 15:05:17 2005 Subject: [crossfire] Valgrind results In-Reply-To: <4245B3C0.6080606@telus.net> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> <4245B3C0.6080606@telus.net> Message-ID: <20050326210444.GA22912@kirschbaum.myrealbox.com> Alex Schultz wrote: > Ah... so most of this leakage likely is the combination of both bugs: > the server keeps sending face 0 over and over, that counts to the > client as a face update, and each time face 0 is sent, the old face 0 > (which is exactly the same anyways) isn't freed properly. Is that > correct? Yes, that is the problem. > I also seem to be seeing the X memory usage increasing alot with CF, > which appears to be upstream leaks triggered by cfclient. As I > understand, the leaks in X itself aren't being tracked by valgrind as > that memory isn't owned by cfclient, and running all of X in valgrind > would be impractically slow. So exactly why cf is causing X itself to > leak may be more difficult to track down. I don't think the X server itself has a memory leak. The problem is that the crossfire client requests many X resources which makes the X server allocate memory. And because the client leaks the old handles when allocating a new resources, the X server itself cannot free the old resources until the client exits. After the crossfire client exits, these resources are freed by the X server. But as far as I know, the (virtual) memory usage of an Unix processes normally does not shrink. Therefore the X server's memory usage does not shrink after the crossfire client exits. From alex_sch at telus.net Sat Mar 26 16:14:27 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Mar 26 16:15:18 2005 Subject: [crossfire] Valgrind results In-Reply-To: <20050326210444.GA22912@kirschbaum.myrealbox.com> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> <4245B3C0.6080606@telus.net> <20050326210444.GA22912@kirschbaum.myrealbox.com> Message-ID: <4245DEC3.2020303@telus.net> Andreas Kirschbaum wrote: >I don't think the X server itself has a memory leak. The problem is that >the crossfire client requests many X resources which makes the X server >allocate memory. And because the client leaks the old handles when >allocating a new resources, the X server itself cannot free the old >resources until the client exits. > >After the crossfire client exits, these resources are freed by the X >server. But as far as I know, the (virtual) memory usage of an Unix >processes normally does not shrink. Therefore the X server's memory >usage does not shrink after the crossfire client exits. > > Ah. That makes sense. Is there any sort of way to get X to get the memory from freed X resources back? (other than restarting X) From kirschbaum at myrealbox.com Sun Mar 27 05:15:28 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Mar 27 05:17:25 2005 Subject: [crossfire] Valgrind results In-Reply-To: <4245DEC3.2020303@telus.net> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> <4245B3C0.6080606@telus.net> <20050326210444.GA22912@kirschbaum.myrealbox.com> <4245DEC3.2020303@telus.net> Message-ID: <20050327111527.GA1771@kirschbaum.myrealbox.com> Alex Schultz wrote: > > Therefore the X server's memory usage does not shrink after the > > crossfire client exits. > > Ah. That makes sense. Is there any sort of way to get X to get the > memory from freed X resources back? (other than restarting X) No, I think you have to restart the X server. From mwedel at sonic.net Mon Mar 28 00:51:51 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Mar 28 00:53:36 2005 Subject: [crossfire] Valgrind results In-Reply-To: <20050327111527.GA1771@kirschbaum.myrealbox.com> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> <4245B3C0.6080606@telus.net> <20050326210444.GA22912@kirschbaum.myrealbox.com> <4245DEC3.2020303@telus.net> <20050327111527.GA1771@kirschbaum.myrealbox.com> Message-ID: <4247A987.7040600@sonic.net> Andreas Kirschbaum wrote: > Alex Schultz wrote: > >>>Therefore the X server's memory usage does not shrink after the >>>crossfire client exits. >> >>Ah. That makes sense. Is there any sort of way to get X to get the >>memory from freed X resources back? (other than restarting X) > > > No, I think you have to restart the X server. That said, assuming the allocated memory is contiguous, this unused memory should be swapped out to disk. also, any future memory allocation will come from this pool of freed memory. Eg, crossfire allocated 20 MB in X resources, and you quit crossfire, but the 20 MB is still held by the X-server. However, when you run other apps that need x-resources, that 20 MB of memory will be used before it starts allocating any additional memory. From mwedel at sonic.net Mon Mar 28 00:59:16 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Mar 28 00:59:37 2005 Subject: [crossfire] Valgrind results In-Reply-To: <20050326173654.GA9005@kirschbaum.myrealbox.com> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> Message-ID: <4247AB44.4070304@sonic.net> Andreas Kirschbaum wrote: > Alex Schultz wrote: > > >>From what I can see, the main leak problems are in image.c in the >>function create_and_rescale_image_from_data. > > > I'm currently trying to fix this problem. There are at least two bugs as > far as I can see: > > - The server keeps sending the image information for face 0 over and > over. > > This seems incorrect to me (both sending it over and over, and > sending it at all), because the client already preallocates the face > 0 as a black face. Ok. double checked the server code. Think I found one case where I had the if statement wrong. Also, the check in esrv_send_face is <0, see no reason that shouldn't be <=0 I'll make sure that doesn't break anything and check in a fix. From kirschbaum at myrealbox.com Mon Mar 28 04:48:39 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Mar 28 04:49:38 2005 Subject: [crossfire] Valgrind results In-Reply-To: <4247AB44.4070304@sonic.net> References: <42457A72.7010700@telus.net> <20050326173654.GA9005@kirschbaum.myrealbox.com> <4247AB44.4070304@sonic.net> Message-ID: <20050328104839.GA32243@kirschbaum.myrealbox.com> Mark Wedel wrote: > Ok. double checked the server code. Think I found one case where I had > the if statement wrong. Also, the check in esrv_send_face is <0, see > no reason that shouldn't be <=0 > > I'll make sure that doesn't break anything and check in a fix. I've committed my client changes a few hours ago. For testing, I cleared a whole dragon TC and did not notice resource leaks anymore. From alex_sch at telus.net Mon Mar 28 13:06:47 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Mar 28 13:07:43 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses Message-ID: <424855C7.7020503@telus.net> Hi all, I just finished some nice patches to make lighting circular instead of square, and it also allows one to use negative glow_radius values for special effects and such. Tests on a private testing server show that it works great with no noticeable server overhead. I submitted it to the SF tracker here: http://sourceforge.net/tracker/index.php?func=detail&aid=1171646&group_id=13833&atid=313833 Due to the fact that it encompasses so many files in the server code I hope that it can get reviewed merged into CVS before other changes happen to those files so the diff doesn't break. I also have some screenshots of it if anybody want them (too big for mailing list of course). --Rednaxela From mwedel at sonic.net Tue Mar 29 00:38:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Mar 29 00:39:51 2005 Subject: [crossfire] client not compiling without gtk2 libraries?? In-Reply-To: <4243C4E2.6050903@sonic.net> References: <200503232256.35957.tchize@myrealbox.com> <4243C4E2.6050903@sonic.net> Message-ID: <4248F7ED.7050002@sonic.net> Mark Wedel wrote: > tchize wrote: > >> Hello, There has been some works currently by mwedel on making a gtk2 >> version of client. Is it normal configure stops if it doesn't find >> libgtk2? I thought this was supposed to be optional. >> I get this when running configure without libgtk2.0-dev package >> installed: >> checking for gtk+-2.0 >= 2.0.0... Package gtk+-2.0 was not found in >> the pkg-config search path. >> Perhaps you should add the directory containing `gtk+-2.0.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'gtk+-2.0' found >> >> configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; >> consider adjusting the PKG_CONFIG_PATH environment variable if your >> libraries are in a nonstandard prefix so pkg-config can find them. > > > I'll fix this up - need to find a convenient system that doesn't have > gtkv2 installed to make sure my change works. I checked a fix for this into CVS last night. From mwedel at sonic.net Tue Mar 29 00:38:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Mar 29 00:39:56 2005 Subject: [crossfire] client not compiling without gtk2 libraries?? In-Reply-To: <4243C4E2.6050903@sonic.net> References: <200503232256.35957.tchize@myrealbox.com> <4243C4E2.6050903@sonic.net> Message-ID: <4248F7ED.7050002@sonic.net> Mark Wedel wrote: > tchize wrote: > >> Hello, There has been some works currently by mwedel on making a gtk2 >> version of client. Is it normal configure stops if it doesn't find >> libgtk2? I thought this was supposed to be optional. >> I get this when running configure without libgtk2.0-dev package >> installed: >> checking for gtk+-2.0 >= 2.0.0... Package gtk+-2.0 was not found in >> the pkg-config search path. >> Perhaps you should add the directory containing `gtk+-2.0.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'gtk+-2.0' found >> >> configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; >> consider adjusting the PKG_CONFIG_PATH environment variable if your >> libraries are in a nonstandard prefix so pkg-config can find them. > > > I'll fix this up - need to find a convenient system that doesn't have > gtkv2 installed to make sure my change works. I checked a fix for this into CVS last night. From mwedel at sonic.net Tue Mar 29 01:40:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Mar 29 01:41:52 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <424855C7.7020503@telus.net> References: <424855C7.7020503@telus.net> Message-ID: <4249066E.3000906@sonic.net> Some notes about the patch: General: Never use // comment style. common/living.c: Making the glow radius additive is probably a bad thing. A player shouldn't be able to light a few torches and get an effect to see everything about them (plus in real life, given the (pi)r? of real lighting, doesn't much up very well.). Same note applies for map.c and server/spell_attack.c common/object.c: op->glow_radius !=0 would be clearer checks that >0 and <0 server/monster.c: while seeing how well lighted the creatuer is may make sense, until we do something with that, I'd much rather just return once we know if the creatuer is illuminated or not for performance reason - checking for all the spaces for all the monsters could prove to be a pretty big cpu hog. From mwedel at sonic.net Tue Mar 29 02:27:59 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Mar 29 02:27:53 2005 Subject: [crossfire] Lighting changes. Message-ID: <4249118F.7040005@sonic.net> After working on the opengl draw client and seeing the circular lighting patch, this brings up the discussion of more wholesale lighting changes. The current lighting with max brightness of 4 is woefully outdated. It made sense back when the max map size was 11x11, and we only cared if a space was lit or not (and not how well lit). With 25x25 map sizes and graduated lighting, this doesn't work nearly so well. I'd personally like to see lighting reworked with many more levels. Perhaps 32 (0->31) as that fits nicely in 5 bits for client/server protocol purposes. This is where one of my concerns (additive light) with the patch comes in. Right now, not a big deal. But a player shouldn't be able to light 3 torches and be as well illuminated as something really really bright (which is what you'd need for a lighting of 9). Doing this from a basic level isn't hard (change a few defines, change a few archs and maps). The problem is existing maps with 'darkness' set. if the number of lightlevels is changed, all those values are perhaps meaningless. I'd also like to see some changes on how darkness is handled/calculated. Right now, darkness levels is calculated for each player. This doesn't make a lot of sense. Imagine scorn at night - the darkness/brightness for all the spaces are the same for all players, so there is no reason that how dark/bright the square is should be calculated for all the players. So rather, just like there is a 'light' value for each map space, a darkness field would be added, and the server woudl fill in those values universally. This, the logic to determine if the player can see a space would be checking the players blocked line of sight, and checking the darkness of the space. This also helps out the case of know if a creature is in a lighted space - simply can check the light level of the space - don't need to find light sources and calculate, etc. There are a couple oddities that would have to be handled: 1) players currently can see at least a few spaces on outdoor maps - this would need a little special handling. 2) Players that have see in dark effecively see everything as a little less dark - this could presumably be fairly easily handled 3) current darkness levels basically determine how much the players can see about them without any lightsource. A low darkness means you can see a few spaces around you without any light source. Trying to maintain compatibility with this gets tricky. Perhaps easiest is to add a new map header value, something like brightness which represents your default viewable area very clearly. Maps with darkness are converted to this brightness value at load. One wish also was for light not to go through walls. This is perhaps doable, more so if light is calculated on a per map basis, as extra cost of doing this is not quite so bad. But you get cases like this (pardon my ascii art): ----------------- A -------------- B ----------------- B is holding a lightsource, A is other player. PRoblem is that light is a per space thing, so A will see the wall down the corrider illuminated (note this happens right now). The only solution I can think to this is to make sure walls are 2 spaces wide. However, related to these changes would be changing how the client is notified of light changes. Better effects can be done if the client knows where the light sources are - that'd actually use less bandwidth. But the case above gets compounded in this example - how does the client for player A know that B's light shouldn't go through the wall (suppose B has a really bright light that will reach spaces that A can see). Is this a case we just shouldn't worry about (its only cosmetic)? Notify client of what spaces block view (light) so client can adjust accordingly? From alex_sch at telus.net Tue Mar 29 09:16:04 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Mar 29 09:15:54 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <4249066E.3000906@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> Message-ID: <42497134.6060109@telus.net> > General: Never use // comment style. I know, I just used some for temporary tests, I thought I took them all out but I guess I might have missed a few. I'll grep for that and fix that. > > common/living.c: Making the glow radius additive is probably a bad > thing. A player shouldn't be able to light a few torches and get an > effect to see everything about them (plus in real life, given the > (pi)r? of real lighting, doesn't much up very well.). Same note > applies for map.c and server/spell_attack.c As I understand the additive lighting does accurately act like in real life due to to the formulas I used in los.c which is essentially a condensation of the pythagorean theorem and the inverse square law (except with different constants to make up for the different units). Like the old comment said, 2 lights doesn't go twice as far as one, but the new formulas in los.c do actually account for that and each successive light is less and less important to the range. However, due to gameplay balance issues, it may be best to take additive lighting out. Perhaps additive lighting should happen everywhere except in the player's inventory, that way the player couldn't just get a ton of lanterns and use them all at once for such. Also spell effects with negative glow_radiuses that could be made in the future would work much better with additive lighting on the ground anyways. > common/object.c: op->glow_radius !=0 would be clearer checks that >0 > and <0 I would have done that in many places, except the old check in many places was just "if (op->glow_radius)" which would return false upon glow_radius being null, which as I understand glow_radius != 0 would return true upon null, which wouldn't be good. > server/monster.c: while seeing how well lighted the creatuer is may > make sense, until we do something with that, I'd much rather just > return once we know if the creatuer is illuminated or not for > performance reason - checking for all the spaces for all the monsters > could prove to be a pretty big cpu hog. My tests showed that it had very very little effect even with all the monsters in the goblin TC, but yeah, I'll take that out of this patch as it's cpu usage that doesn't need to be used at this point, but keep a copy of that code in case we do want to do something with this in the future. I'll make these fixes to my patch at post here when I update it on the SF tracker. --Alex Schultz (aka Rednaxela) From alex_sch at telus.net Tue Mar 29 09:36:39 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Mar 29 09:37:54 2005 Subject: [crossfire] Lighting changes. In-Reply-To: <4249118F.7040005@sonic.net> References: <4249118F.7040005@sonic.net> Message-ID: <42497607.6020706@telus.net> > The current lighting with max brightness of 4 is woefully outdated. > It made sense back when the max map size was 11x11, and we only cared > if a space was lit or not (and not how well lit). > > With 25x25 map sizes and graduated lighting, this doesn't work nearly > so well. > > I'd personally like to see lighting reworked with many more levels. > Perhaps 32 (0->31) as that fits nicely in 5 bits for client/server > protocol purposes. Yeah, I agree, (for one thing it would make the look of the circular lighting nicer). > > Right now, darkness levels is calculated for each player. This > doesn't make a lot of sense. Imagine scorn at night - the > darkness/brightness for all the spaces are the same for all players, > so there is no reason that how dark/bright the square is should be > calculated for all the players. So rather, just like there is a > 'light' value for each map space, a darkness field would be added, and > the server woudl fill in those values universally. > Makes sense, and I think I know how to implement such. It wouldn't involve much more than moving some of the algorithms that are normally in los.c into map.c. I think I might be able to integrate this part of what you mention here into my lighting patch if you think that's a good idea. > This also helps out the case of know if a creature is in a lighted > space - simply can check the light level of the space - don't need to > find light sources and calculate, etc. Which would be good for the stuff in monster.c that you mentioned in you e-mail about my lighting patch > > There are a couple oddities that would have to be handled: > 1) players currently can see at least a few spaces on outdoor maps - > this would need a little special handling. I don't think that will be too hard to just adapt the existing los.c logic with very little changes to all of this in such a way that this part would be kept intact. > 2) Players that have see in dark effecively see everything as a little > less dark - this could presumably be fairly easily handled Yeah, that would definitely be a bit better than the existing see in dark code which is sort of ugly. > > However, related to these changes would be changing how the client is > notified of light changes. Better effects can be done if the client > knows where the light sources are - that'd actually use less bandwidth. Very true, but that would require rather widespread changes to all of the lighting code, and we would still have to not sent the client data for that which that can't see at all which would depend on calculating lighting data on the server end. Also, we would still have to worry about monsters knowing about such lighting. Very good ideas. I could try implementing the move from calculating lighting for each player to just for each map in my lighting patch if you think it's a good idea. --Alex Schultz (aka Rednaxela) From mikeeusaaa at yahoo.com Tue Mar 29 10:17:47 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Mar 29 10:19:55 2005 Subject: [crossfire] Lighting changes. In-Reply-To: 6667 Message-ID: <20050329161747.39629.qmail@web61004.mail.yahoo.com> One thing about light not going through walls. What if the lightsource is under the wall? (I use this to illuminate certain points in the underground area of the Dark Elf lord's castle in MLAB). /me also uses darkness and likes the change-to-brightness at load.... so he dosn't have to change the files :P Lighting looks great now, hope it goes into CVS soon. Perhapse being able to set the light color next (default is white... unless you set color (hexcode)? --- Mark Wedel wrote: > > After working on the opengl draw client and seeing > the circular lighting > patch, this brings up the discussion of more > wholesale lighting changes. > > The current lighting with max brightness of 4 is > woefully outdated. It made > sense back when the max map size was 11x11, and we > only cared if a space was lit > or not (and not how well lit). > > With 25x25 map sizes and graduated lighting, this > doesn't work nearly so well. > > I'd personally like to see lighting reworked with > many more levels. Perhaps > 32 (0->31) as that fits nicely in 5 bits for > client/server protocol purposes. > > This is where one of my concerns (additive light) > with the patch comes in. > Right now, not a big deal. But a player shouldn't > be able to light 3 torches > and be as well illuminated as something really > really bright (which is what > you'd need for a lighting of 9). > > Doing this from a basic level isn't hard (change a > few defines, change a few > archs and maps). The problem is existing maps with > 'darkness' set. if the > number of lightlevels is changed, all those values > are perhaps meaningless. > > I'd also like to see some changes on how darkness > is handled/calculated. > > Right now, darkness levels is calculated for each > player. This doesn't make a > lot of sense. Imagine scorn at night - the > darkness/brightness for all the > spaces are the same for all players, so there is no > reason that how dark/bright > the square is should be calculated for all the > players. So rather, just like > there is a 'light' value for each map space, a > darkness field would be added, > and the server woudl fill in those values > universally. > > This, the logic to determine if the player can see > a space would be checking > the players blocked line of sight, and checking the > darkness of the space. > > This also helps out the case of know if a creature > is in a lighted space - > simply can check the light level of the space - > don't need to find light sources > and calculate, etc. > > There are a couple oddities that would have to be > handled: > 1) players currently can see at least a few spaces > on outdoor maps - this would > need a little special handling. > 2) Players that have see in dark effecively see > everything as a little less dark > - this could presumably be fairly easily handled > 3) current darkness levels basically determine how > much the players can see > about them without any lightsource. A low darkness > means you can see a few > spaces around you without any light source. Trying > to maintain compatibility > with this gets tricky. Perhaps easiest is to add a > new map header value, > something like brightness which represents your > default viewable area very > clearly. Maps with darkness are converted to this > brightness value at load. > > > One wish also was for light not to go through > walls. This is perhaps doable, > more so if light is calculated on a per map basis, > as extra cost of doing this > is not quite so bad. But you get cases like this > (pardon my ascii art): > > > ----------------- > A > -------------- > B > ----------------- > > B is holding a lightsource, A is other player. > PRoblem is that light is a per > space thing, so A will see the wall down the > corrider illuminated (note this > happens right now). The only solution I can think > to this is to make sure walls > are 2 spaces wide. > > However, related to these changes would be > changing how the client is notified > of light changes. Better effects can be done if the > client knows where the > light sources are - that'd actually use less > bandwidth. > > But the case above gets compounded in this example > - how does the client for > player A know that B's light shouldn't go through > the wall (suppose B has a > really bright light that will reach spaces that A > can see). Is this a case we > just shouldn't worry about (its only cosmetic)? > Notify client of what spaces > block view (light) so client can adjust accordingly? > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From mikeeusaaa at yahoo.com Tue Mar 29 10:19:17 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Mar 29 10:19:59 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: 6667 Message-ID: <20050329161918.27535.qmail@web61001.mail.yahoo.com> // == C99 right? (C99 is not supported by debian stable etc... please don't use C99 :) ) --- Mark Wedel wrote: > > Some notes about the patch: > > General: Never use // comment style. > > common/living.c: Making the glow radius additive is > probably a bad thing. A > player shouldn't be able to light a few torches and > get an effect to see > everything about them (plus in real life, given the > (pi)r³ of real lighting, > doesn't much up very well.). Same note applies for > map.c and server/spell_attack.c > > common/object.c: op->glow_radius !=0 would be > clearer checks that >0 and <0 > > server/monster.c: while seeing how well lighted the > creatuer is may make sense, > until we do something with that, I'd much rather > just return once we know if the > creatuer is illuminated or not for performance > reason - checking for all the > spaces for all the monsters could prove to be a > pretty big cpu hog. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From alex_sch at telus.net Tue Mar 29 13:42:05 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Mar 29 13:41:57 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <42497134.6060109@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> Message-ID: <4249AF8D.2050301@telus.net> Alex Schultz wrote: > I'll make these fixes to my patch at post here when I update it on the > SF tracker. Adjustments made and the updated diff is posted on the SF tracker. I fixed the one "//" comment I accidentally left behind, made the prescribed changes in monster.c, and changed the >0 and <0 stuff in object.c to !=0 and !=NULL to make it clearer. I removed the additive behavior from living.c to prevent abuse but left it in map.c and spell_attack.c as per my notes in my previous reply. --Alex Schultz (aka Rednaxela) From fuchs.andy at gmail.com Tue Mar 29 17:48:30 2005 From: fuchs.andy at gmail.com (Andy Fuchs) Date: Tue Mar 29 17:49:59 2005 Subject: [crossfire] Bug: Cave entrances can be obsured by weather In-Reply-To: <20050301045216.55551.qmail@web61005.mail.yahoo.com> References: <20050301045216.55551.qmail@web61005.mail.yahoo.com> Message-ID: On Mon, 28 Feb 2005 20:52:16 -0800 (PST), Mitch Obrian wrote: > This dosn't happen with other exits but cave entrances > can be covered by the weather and weather generated > terrain (swamps). Trying to start a discussion on this... Seems to be caused by the exit tiles being the same as the floor. Could be fixed by having the weather code change the 'style' of the exit, or adding these tiles to an exclude list (in server/weather.c). Another solution would be a 'noweather' tag put on these tiles. -- -- Andrew Fuchs From mwedel at sonic.net Wed Mar 30 00:48:00 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Mar 30 00:48:02 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <20050329161918.27535.qmail@web61001.mail.yahoo.com> References: <20050329161918.27535.qmail@web61001.mail.yahoo.com> Message-ID: <424A4BA0.3010401@sonic.net> Mitch Obrian wrote: > // == C99 right? > (C99 is not supported by debian stable etc... please > don't use C99 :) ) Yes, that is a C99 standard. while C99 compilers may not be that hard to find, I don't see a big reason to break backwards compatibility when it is pretty easy to maintain it in this case. From mwedel at sonic.net Wed Mar 30 00:55:32 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Mar 30 00:55:31 2005 Subject: [crossfire] Lighting changes. In-Reply-To: <20050329161747.39629.qmail@web61004.mail.yahoo.com> References: <20050329161747.39629.qmail@web61004.mail.yahoo.com> Message-ID: <424A4D64.9070808@sonic.net> Mitch Obrian wrote: > One thing about light not going through walls. What if > the lightsource is under the wall? (I use this to > illuminate certain points in the underground area of > the Dark Elf lord's castle in MLAB). > /me also uses darkness and likes the > change-to-brightness at load.... so he dosn't have to > change the files :P > > Lighting looks great now, hope it goes into CVS soon. > Perhapse being able to set the light color next > (default is white... unless you set color (hexcode)? light sources under walls would certainly cause problems. Checking for light propogation would probably start checking for spaces away from the light source. But if you have a case like: ----L---- (where L is the light source, and also the place of a wall) - having light propogate to north, south, northwest, etc, could easily work fine. But the problem is true east/west - space next would be blocked, so light wouldn't go there, so the wall itself wouldn't be properly lit. And this case may not be that uncommon, and thus hard to handle. However, if light values increase, this is probably something that would need to be fixed, even if it does break some maps. That is because if you do have brighter light sources, they'd obviously go farther, and that'd probably create bad effects - imagine a player with a light source two rooms away illuminating where the player is. From mikeeusaaa at yahoo.com Wed Mar 30 01:18:32 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Mar 30 01:20:03 2005 Subject: [crossfire] Lighting changes. In-Reply-To: 6667 Message-ID: <20050330071832.31820.qmail@web61008.mail.yahoo.com> Ah, ok, I'll fix my map then :). Btw when is MLAB going to be uploaded into CVS (someone was working on it?). --- Mark Wedel wrote: > Mitch Obrian wrote: > > One thing about light not going through walls. > What if > > the lightsource is under the wall? (I use this to > > illuminate certain points in the underground area > of > > the Dark Elf lord's castle in MLAB). > > /me also uses darkness and likes the > > change-to-brightness at load.... so he dosn't have > to > > change the files :P > > > > Lighting looks great now, hope it goes into CVS > soon. > > Perhapse being able to set the light color next > > (default is white... unless you set color > (hexcode)? > > light sources under walls would certainly cause > problems. > > Checking for light propogation would probably > start checking for spaces away > from the light source. But if you have a case like: > > ----L---- > > (where L is the light source, and also the place > of a wall) - having light > propogate to north, south, northwest, etc, could > easily work fine. But the > problem is true east/west - space next would be > blocked, so light wouldn't go > there, so the wall itself wouldn't be properly lit. > > And this case may not be that uncommon, and thus > hard to handle. > > However, if light values increase, this is > probably something that would need > to be fixed, even if it does break some maps. That > is because if you do have > brighter light sources, they'd obviously go farther, > and that'd probably create > bad effects - imagine a player with a light source > two rooms away illuminating > where the player is. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From mwedel at sonic.net Wed Mar 30 01:43:50 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Mar 30 01:44:03 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <42497134.6060109@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> Message-ID: <424A58B6.8070703@sonic.net> Alex Schultz wrote: >> >> common/living.c: Making the glow radius additive is probably a bad >> thing. A player shouldn't be able to light a few torches and get an >> effect to see everything about them (plus in real life, given the >> (pi)r? of real lighting, doesn't much up very well.). Same note >> applies for map.c and server/spell_attack.c > > > As I understand the additive lighting does accurately act like in real > life due to to the formulas I used in los.c which is essentially a > condensation of the pythagorean theorem and the inverse square law > (except with different constants to make up for the different units). > Like the old comment said, 2 lights doesn't go twice as far as one, but > the new formulas in los.c do actually account for that and each > successive light is less and less important to the range. However, due > to gameplay balance issues, it may be best to take additive lighting > out. Perhaps additive lighting should happen everywhere except in the > player's inventory, that way the player couldn't just get a ton of > lanterns and use them all at once for such. Also spell effects with > negative glow_radiuses that could be made in the future would work much > better with additive lighting on the ground anyways. Well, that fixes the lantern problem. But I also wonder how it will work with spell effects, like say a firebolt or some others. While this is one logical spell effect, oftentimes, the way merging code and whatever happens, there may be in fact be many spell effects objects on the same space (certainly true with cone and ball type spells). This change could make those spells very very bright. Also, I'm not 100% convinced of your changes. The various code sets the total light level for a space, and the LOS code then figures out effective lighting on each space. The LOS code doesn't know about stacked light effects. So this seems to me that if there are 2 brightness 2 objects on the space, for all purposes, that is indistinguishable from a 1 brightness 4 object. So it seems that either the code would be additive, or objects are effectively dimmer than they were before because a more realistic distance calcuation is used. To me, that could create its own problems (I'm thinking that some maps were designed with light sources placed at various distances to illuminate the right things). My initial thought when the circular lighting code was put in was that it would handle the corners more properly, not necessarily make things dimmer. Although breaking the maps probably isn't that much an issue (biggest issue in all this is the rounding errors that are happening) > >> common/object.c: op->glow_radius !=0 would be clearer checks that >0 >> and <0 > > > I would have done that in many places, except the old check in many > places was just "if (op->glow_radius)" which would return false upon > glow_radius being null, which as I understand glow_radius != 0 would > return true upon null, which wouldn't be good. if (op->glow_radius) is a zero/nonzero check. IF glow_radius is non zero, it will progress through the code in the if block. When using pointers, it does the check against null and not against 0 (although, on probably most every system out there, null is 0). So that said, the updated check in common/object.c is still not right - checking for non zero against an integer field is not proper code. The line should really just be: if(QUERY_FLAG(op,FLAG_BLOCKSVIEW)|| (op->glow_radius!=0)) ... so all places where you are comparing glow_radius against NULL are incorrect (it is effectively the same as comparing against 0, which you are already doing). However, most compilers will warn against such a structure, because NULL is usually defined as (void*)0, so you are comparing an integer against a pointer which most compilers don't like. From mwedel at sonic.net Wed Mar 30 01:54:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Mar 30 01:56:03 2005 Subject: [crossfire] Lighting changes. In-Reply-To: <42497607.6020706@telus.net> References: <4249118F.7040005@sonic.net> <42497607.6020706@telus.net> Message-ID: <424A5B35.8050200@sonic.net> Alex Schultz wrote: >> >> Right now, darkness levels is calculated for each player. This >> doesn't make a lot of sense. Imagine scorn at night - the >> darkness/brightness for all the spaces are the same for all players, >> so there is no reason that how dark/bright the square is should be >> calculated for all the players. So rather, just like there is a >> 'light' value for each map space, a darkness field would be added, and >> the server woudl fill in those values universally. >> > Makes sense, and I think I know how to implement such. It wouldn't > involve much more than moving some of the algorithms that are normally > in los.c into map.c. I think I might be able to integrate this part of > what you mention here into my lighting patch if you think that's a good > idea. I'd consider you're current patch and what I describe here as seperate projects - there is no reason you're current patch shouldn't go in, and then work on this, since I think it is a bit bigger change, and there isn't any real dependency on the other patch. I'd also suggest addition of a field in the map header to something like 'update_darkness'. When something happens on the map that would change lighting/darkness, it sets that. When update los is called and that is set on a map, then it goes and updates the map - this is almost certainly going to be more efficient than doing it everything when the object is inserted/removed. > >> >> There are a couple oddities that would have to be handled: >> 1) players currently can see at least a few spaces on outdoor maps - >> this would need a little special handling. > > > I don't think that will be too hard to just adapt the existing los.c > logic with very little changes to all of this in such a way that this > part would be kept intact. yeah - it may make the most sense for LOS to calculate true LOS issues, and then look at the darkness levels on the map and copy those into the LOS array as needed - then, special customizations based on the players attribute could be done at that time. >> >> However, related to these changes would be changing how the client is >> notified of light changes. Better effects can be done if the client >> knows where the light sources are - that'd actually use less bandwidth. > > > Very true, but that would require rather widespread changes to all of > the lighting code, and we would still have to not sent the client data > for that which that can't see at all which would depend on calculating > lighting data on the server end. Also, we would still have to worry > about monsters knowing about such lighting. yes - the biggest issue is light sources the player can't see. The hardest part is those light sources the player can't see but which they can see the effects off. Since they see some of the light emanating, might not be bad to send the player location of that (it is something that could be inferred), but gets hard to handle. I'd have to think about this more on the best way to deal with handling this data, and figuring out a fast way to calculate that information. From tchize at myrealbox.com Wed Mar 30 04:10:10 2005 From: tchize at myrealbox.com (tchize) Date: Wed Mar 30 04:12:04 2005 Subject: [crossfire] server stopping on SIGPIPE Message-ID: <200503301210.16969.tchize@myrealbox.com> Hello, i noticed the following problem when debugging some client code on cvs first, by default, cvs compilation of server does put a #define DEBUG on config.h. Am not sure this is a correct behaviour to activate debugging by default. This should be added by people wanting to debug their code. second, a test in init_signals() is deactivating signal interception on sigpipe. This is quite a problem as sigpipe is quite common to get in sockets manipulations third, if client crash during the setup process, the server tries to send datas to a disconnected client and does generate a sigpipe, which by default is not handled and make the server simply exist without a message. I suggest either one of those 2 solutions (and i'll recommend both) - do not activate DEBUG by default in configure script - do not exclude sigpipe handling in DEBUG mode (this is non sense imho) -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050330/cb45ea66/attachment.pgp From alex_sch at telus.net Wed Mar 30 07:00:57 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Mar 30 07:02:05 2005 Subject: [crossfire] Lighting changes. In-Reply-To: <424A4D64.9070808@sonic.net> References: <20050329161747.39629.qmail@web61004.mail.yahoo.com> <424A4D64.9070808@sonic.net> Message-ID: <424AA309.60908@telus.net> Mark Wedel wrote: > light sources under walls would certainly cause problems. That nexus map when selecting scorn or navar also does that, but I doubt it would cause problems, as the type of wall it uses isn't meant to block light. From alex_sch at telus.net Wed Mar 30 07:37:15 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Mar 30 07:38:06 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <424A58B6.8070703@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> Message-ID: <424AAB8B.9000800@telus.net> Mark Wedel wrote: > Well, that fixes the lantern problem. But I also wonder how it will > work with spell effects, like say a firebolt or some others. While > this is one logical spell effect, oftentimes, the way merging code and > whatever happens, there may be in fact be many spell effects objects > on the same space (certainly true with cone and ball type spells). > This change could make those spells very very bright. Well, I think that would be rather realistic, for example if to firebolts are intersecting the same spot at once, then they should emit the total combined light of both from where they intersect. However this may mean that some spells might need their effects glow_radius tweaked. > Also, I'm not 100% convinced of your changes. The various code sets > the total light level for a space, and the LOS code then figures out > effective lighting on each space. The LOS code doesn't know about > stacked light effects. > > So this seems to me that if there are 2 brightness 2 objects on the > space, for all purposes, that is indistinguishable from a 1 brightness > 4 object. Exactly, and assuming the lights aren't directional then I don't see how it's not realistic. > So it seems that either the code would be additive, or objects are > effectively dimmer than they were before because a more realistic > distance calcuation is used. To me, that could create its own > problems (I'm thinking that some maps were designed with light sources > placed at various distances to illuminate the right things). Yeah, a brightness 4 object would have previously added 1 lightness at distance 4, but with the current formula, it would add 0.35 which would round to 0. However I could adjust the 1.5 multiplier in the code to make a streetlight just as bright as normal at distance 4... which would mean that the multiplier would need to be changed to 4.25 however I think that then, many things might be too bright, perhaps 2.2 would be better as it would make a streetlight about 0.5 and distance 4 which would round to 1. > Although breaking the maps probably isn't that much an issue > (biggest issue in all this is the rounding errors that are happening) Yeah, as you proposed in a separate topic, adding more lighting levels would be very nice; It's what we really need for the above problem. > So that said, the updated check in common/object.c is still not right > - checking for non zero against an integer field is not proper code. > The line should really just be: > > if(QUERY_FLAG(op,FLAG_BLOCKSVIEW)|| (op->glow_radius!=0)) > ... > > so all places where you are comparing glow_radius against NULL are > incorrect (it is effectively the same as comparing against 0, which > you are already doing). However, most compilers will warn against > such a structure, because NULL is usually defined as (void*)0, so you > are comparing an integer against a pointer which most compilers don't > like. Ok. I'll correct that. --Alex Schultz (aka Rednaxela) From mwedel at sonic.net Thu Mar 31 01:38:46 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Mar 31 01:40:16 2005 Subject: [crossfire] server stopping on SIGPIPE In-Reply-To: <200503301210.16969.tchize@myrealbox.com> References: <200503301210.16969.tchize@myrealbox.com> Message-ID: <424BA906.1060203@sonic.net> tchize wrote: > Hello, i noticed the following problem when debugging some client code on cvs > > first, by default, cvs compilation of server does put a #define DEBUG on > config.h. Am not sure this is a correct behaviour to activate debugging by > default. This should be added by people wanting to debug their code. > > second, a test in init_signals() is deactivating signal interception on > sigpipe. This is quite a problem as sigpipe is quite common to get in sockets > manipulations > > third, if client crash during the setup process, the server tries to send > datas to a disconnected client and does generate a sigpipe, which by default > is not handled and make the server simply exist without a message. > > > I suggest either one of those 2 solutions (and i'll recommend both) > > - do not activate DEBUG by default in configure script > - do not exclude sigpipe handling in DEBUG mode (this is non sense imho) yes - that makes sense. I imagine the not setting up signal handlers for sigpipe and others in debug mode was to allow better debugging. That perhaps makes sense for everything but sigpipe, since sigpipe is a normal signal. From mwedel at sonic.net Thu Mar 31 02:01:59 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Mar 31 02:02:16 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <424AAB8B.9000800@telus.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> Message-ID: <424BAE77.6020500@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> Well, that fixes the lantern problem. But I also wonder how it will >> work with spell effects, like say a firebolt or some others. While >> this is one logical spell effect, oftentimes, the way merging code and >> whatever happens, there may be in fact be many spell effects objects >> on the same space (certainly true with cone and ball type spells). >> This change could make those spells very very bright. > > > Well, I think that would be rather realistic, for example if to > firebolts are intersecting the same spot at once, then they should emit > the total combined light of both from where they intersect. However this > may mean that some spells might need their effects glow_radius tweaked. But the issue is that the way a cone propogates, it will put multiple burning spell effects per space. So cone spells will become much brighter than before (and big spells could have upwards of 10-20 spell effects on a space due to the way the expand). So in these cases, these spells then become much brighter (this is also ignoring the fact that a fireball also covers a 8 space wide area) > > >> So it seems that either the code would be additive, or objects are >> effectively dimmer than they were before because a more realistic >> distance calcuation is used. To me, that could create its own >> problems (I'm thinking that some maps were designed with light sources >> placed at various distances to illuminate the right things). > > > Yeah, a brightness 4 object would have previously added 1 lightness at > distance 4, but with the current formula, it would add 0.35 which would > round to 0. However I could adjust the 1.5 multiplier in the code to > make a streetlight just as bright as normal at distance 4... which would > mean that the multiplier would need to be changed to 4.25 however I > think that then, many things might be too bright, perhaps 2.2 would be > better as it would make a streetlight about 0.5 and distance 4 which > would round to 1. Ok. so things are not as bright as before. IMO, that is a regression that should perhaps be fixed. I think the expectation is that if I set an object with glow_radius 4, it will go 4 spaces, not 3. I'd think this would become a bigger problem if more light levels are added ('I added a glow radius 10 object, but it is only going 7 spaces - what's up?') This could to some extent be a problem with the variable name 'glow_radius', which to anyone looking at it, would have pretty clear meaning. Actually, doing some quick calculations, it appears the formula you use produces highly inaccurate results as brightness increases. Even a glow_radius 4 objects will only go 2 spaces. At 3 spaces, the light level would be (6 / 10) or .6, which amounts to zero (when doing doing integer math, any remainder is dropped, not rounded). But as the number goes up, a glow_radius 8 would only go 5 spaces. Couple thoughts on this - effective light for spaces could be stored in floats - at least then for overlapping light sources, you don't lose accuracy by rounding results. Also, what may be needed is some conversion/new name, since as it is now, glow_radius is a very inaccurate name. So perhaps changing the name to light_level or brightness or something which is more ambiguous to what it means. Then at loading, these old glow_radius values could be adjusted to 'do the right thing' and get stored into the brightness field. The other thought is the light levels could be precalculated, and thus desired light levels set up. For example, for a 3x3 light, could set up a table like: 1 1 2 1 2 3 (or something) to determine light levels. Only a quadrant for is needed for each light source (although, directional light sources could be interesting...) But these toubles could be hand created/adjusted to give real light levels that are desired and/or tweaked so that the marginal cases were calculated results could be rounded down, instead, the high value included. This would also be slightly faster than calculating it every time. From alex_sch at telus.net Thu Mar 31 06:31:36 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Mar 31 06:32:19 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: <424BAE77.6020500@sonic.net> References: <424855C7.7020503@telus.net> <4249066E.3000906@sonic.net> <42497134.6060109@telus.net> <424A58B6.8070703@sonic.net> <424AAB8B.9000800@telus.net> <424BAE77.6020500@sonic.net> Message-ID: <424BEDA8.3020107@telus.net> > But the issue is that the way a cone propogates, it will put multiple > burning spell effects per space. So cone spells will become much > brighter than before (and big spells could have upwards of 10-20 spell > effects on a space due to the way the expand). So in these cases, > these spells then become much brighter (this is also ignoring the fact > that a fireball also covers a 8 space wide area) > Ah, so bolts some others are fine, it's just mainly the cone spells... yes that is a problem. Wouldn't that also mean that cone spells are more powerful at farther away distances? Is this intentional. > Ok. so things are not as bright as before. > > IMO, that is a regression that should perhaps be fixed. I think the > expectation is that if I set an object with glow_radius 4, it will go > 4 spaces, not 3. I'd think this would become a bigger problem if more > light levels are added ('I added a glow radius 10 object, but it is > only going 7 spaces - what's up?') > > This could to some extent be a problem with the variable name > 'glow_radius', which to anyone looking at it, would have pretty clear > meaning. > > Actually, doing some quick calculations, it appears the formula you > use produces highly inaccurate results as brightness increases. Even > a glow_radius 4 objects will only go 2 spaces. At 3 spaces, the light > level would be (6 / 10) or .6, which amounts to zero (when doing doing > integer math, any remainder is dropped, not rounded). > > But as the number goes up, a glow_radius 8 would only go 5 spaces. > > Couple thoughts on this - effective light for spaces could be stored > in floats - at least then for overlapping light sources, you don't > lose accuracy by rounding results. > Yeah, forgot about it dropping remainders like that, however I could fix that with some casting etc. Using floats for storing that might work well, and adding a greater number of lighting levels like you proposed in the other topic would fix most of these problems other than the misnaming. > Also, what may be needed is some conversion/new name, since as it is > now, glow_radius is a very inaccurate name. So perhaps changing the > name to light_level or brightness or something which is more ambiguous > to what it means. Then at loading, these old glow_radius values could > be adjusted to 'do the right thing' and get stored into the brightness > field. > Possibly, but I'm not sure what the best place in the code to convert it would be. I know a couple places that it would work, but those would recalculate it more than needed. > The other thought is the light levels could be precalculated, and > thus desired light levels set up. For example, for a 3x3 light, could > set up a table like: > > 1 > 1 2 > 1 2 3 > > (or something) to determine light levels. Only a quadrant for is > needed for each light source (although, directional light sources > could be interesting...) > > But these toubles could be hand created/adjusted to give real light > levels that are desired and/or tweaked so that the marginal cases were > calculated results could be rounded down, instead, the high value > included. > > This would also be slightly faster than calculating it every time. It would be faster and many of these issues could be dealt with outside of the code; My tests have shown that amount of processor power used by by the formula is rather insignificant, but using a lookup table has other merits. However a lookup table does become more cumbersome if we implement a greater number of lighting levels as you proposed. --Alex Schultz (aka Rednaxela) From mikeeusaaa at yahoo.com Thu Mar 31 08:17:18 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Mar 31 08:18:20 2005 Subject: [crossfire] Circular lighting & negetive glow_radiuses In-Reply-To: 6667 Message-ID: <20050331141718.75236.qmail@web61005.mail.yahoo.com> About the look uptables... I think going with the formula is the best to create the most expandable results. --- Alex Schultz wrote: > > > But the issue is that the way a cone propogates, > it will put multiple > > burning spell effects per space. So cone spells > will become much > > brighter than before (and big spells could have > upwards of 10-20 spell > > effects on a space due to the way the expand). So > in these cases, > > these spells then become much brighter (this is > also ignoring the fact > > that a fireball also covers a 8 space wide area) > > > Ah, so bolts some others are fine, it's just mainly > the cone spells... > yes that is a problem. Wouldn't that also mean that > cone spells are more > powerful at farther away distances? Is this > intentional. > > > Ok. so things are not as bright as before. > > > > IMO, that is a regression that should perhaps be > fixed. I think the > > expectation is that if I set an object with > glow_radius 4, it will go > > 4 spaces, not 3. I'd think this would become a > bigger problem if more > > light levels are added ('I added a glow radius 10 > object, but it is > > only going 7 spaces - what's up?') > > > > This could to some extent be a problem with the > variable name > > 'glow_radius', which to anyone looking at it, > would have pretty clear > > meaning. > > > > Actually, doing some quick calculations, it > appears the formula you > > use produces highly inaccurate results as > brightness increases. Even > > a glow_radius 4 objects will only go 2 spaces. At > 3 spaces, the light > > level would be (6 / 10) or .6, which amounts to > zero (when doing doing > > integer math, any remainder is dropped, not > rounded). > > > > But as the number goes up, a glow_radius 8 would > only go 5 spaces. > > > > Couple thoughts on this - effective light for > spaces could be stored > > in floats - at least then for overlapping light > sources, you don't > > lose accuracy by rounding results. > > > Yeah, forgot about it dropping remainders like that, > however I could fix > that with some casting etc. Using floats for storing > that might work > well, and adding a greater number of lighting levels > like you proposed > in the other topic would fix most of these problems > other than the > misnaming. > > > Also, what may be needed is some conversion/new > name, since as it is > > now, glow_radius is a very inaccurate name. So > perhaps changing the > > name to light_level or brightness or something > which is more ambiguous > > to what it means. Then at loading, these old > glow_radius values could > > be adjusted to 'do the right thing' and get stored > into the brightness > > field. > > > Possibly, but I'm not sure what the best place in > the code to convert it > would be. I know a couple places that it would > work, but those would > recalculate it more than needed. > > > The other thought is the light levels could be > precalculated, and > > thus desired light levels set up. For example, > for a 3x3 light, could > > set up a table like: > > > > 1 > > 1 2 > > 1 2 3 > > > > (or something) to determine light levels. Only a > quadrant for is > > needed for each light source (although, > directional light sources > > could be interesting...) > > > > But these toubles could be hand created/adjusted > to give real light > > levels that are desired and/or tweaked so that the > marginal cases were > > calculated results could be rounded down, instead, > the high value > > included. > > > > This would also be slightly faster than > calculating it every time. > > It would be faster and many of these issues could be > dealt with outside > of the code; My tests have shown that amount of > processor power used by > by the formula is rather insignificant, but using a > lookup table has > other merits. However a lookup table does become > more cumbersome if we > implement a greater number of lighting levels as you > proposed. > > --Alex Schultz (aka Rednaxela) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/ From mikeeusaaa at yahoo.com Thu Mar 31 09:19:20 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Mar 31 09:20:22 2005 Subject: [crossfire] Layers need to be upped from 3 Message-ID: <20050331151920.40896.qmail@web61006.mail.yahoo.com> Currently only 3 image layers are displayed on the screen... could this be upped? It causes visual problems when stacking some Items to create the desired effect. Perhapse 5 or 6 or even more is better? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/