From jdraugr at soznet.net Thu Jun 14 13:53:48 2001 From: jdraugr at soznet.net (John Draugr) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] Admin Questions Message-ID: <006401c0f503$58b8ffc0$0a00a8c0@soznet> Hello All, I am new to the crossfire community. I did play a bit many years ago, but now I am attempting to run my own Windows32 server. I have the compiled W32 server running right now, but before I open the game to the public, I am doing some testing, I also may decide to build my own world from scratch. Anyhow, I have some questions. First, how do I make myself a GM? I followed the instructions I found and I edited the dm_file. I forgot the exact name, but it was the right file. I put in the following line Draugr:password:* Yet when I log in and type the command dm, i am told Sorry Pal. What do I have to do to get admin access to my server? Also, is there any online tools for account management or typical Admin necessary tools? I appreciate any help I get. Also, could you please mail me direct at Jdraugr@soznet.net I just signed up for this list and sometimes I dont get the mails from the actual list. The above questions are very important for me to successfully run my server. Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010614/c90effad/attachment.html From helfesrieder at netscape.net Fri Jun 1 01:48:36 2001 From: helfesrieder at netscape.net (helfesrieder@netscape.net) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Re: Crossfire IT-Project Message-ID: <2C0DC028.5F262AF2.79055386@netscape.net> Hi Adam, In my opinion CF needs a new and improved Map-Editor, ideally in Java to be available cross platform. The current Crossedit Editor is only available for Unix and XWindows. This closes out potential map-makers that have a Windows OS (which are 95% of all desktop users). End-User usability is a big issue. In my opinion it is close to unusable for technically non-skilled people. In many cases you need to enter bitmask-numbers, data fields change meaning depending on object context etc. This can probably done much better with a good dialog and interface design. Maybe you want to have your students tackle this ? An open source approach would be nice. Regards, Zack __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From peterm at tonks.EECS.Berkeley.EDU Fri Jun 1 02:05:02 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] Re: Crossfire IT-Project In-Reply-To: Your message of "Fri, 01 Jun 2001 02:48:36 EDT." <2C0DC028.5F262AF2.79055386@netscape.net> Message-ID: <200106010705.f51752i08084@tonks.EECS.Berkeley.EDU> Hello, Wait a while before you decide on doing a java editor. I think some work is already in progress on producing a map editor. This would be a good time for people to remind the list what they're working on. PeterM > Hi Adam, > > In my opinion CF needs a new and improved Map-Editor, ideally > in Java to be available cross platform. > > The current Crossedit Editor is only available for Unix and > XWindows. This closes out potential map-makers that have > a Windows OS (which are 95% of all desktop users). > > End-User usability is a big issue. In my opinion it is close > to unusable for technically non-skilled people. In many cases > you need to enter bitmask-numbers, data fields change meaning > depending on object context etc. This can probably done much > better with a good dialog and interface design. > > Maybe you want to have your students tackle this ? An open > source approach would be nice. > > Regards, > > Zack > > > > __________________________________________________________________ > Get your own FREE, personal Netscape Webmail account today at http://webmail. >netscape.com/ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From yann.chachkoff at mailandnews.com Fri Jun 1 10:55:19 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] Re: Crossfire IT-Project Message-ID: <01060111551900.01561@Terminus.magellan.fpms.ac.be> Some things I would like to see for Crossfire: 1 - Java Map Editor: Portable and user-friendly (Knowing how the archetypes are built should not be needed anymore to modify an object on a map). 2 - Portable Client: Although there is already a Java Client, it seems that only few people are working on it today. Maybe your help could be welcome ? 3 - A 'character builder' tool: It is sometimes difficult to create characters with complex behaviour (complex dialogs, moves, ...). It requires a good knowledge of the archetypes 'tags'. I'd like to see a tool to help you to create custom NPCs whithout having to learn archetypes internals. This tool should also be able to create a library of custom NPCs/Objects you can reuse in many maps. I do not consider XML integration as a priority, but it is just my opinion. Chachkoff Y. From dnh at hawthorn.csse.monash.edu.au Fri Jun 1 06:22:56 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] Re: Crossfire IT-Project In-Reply-To: <2C0DC028.5F262AF2.79055386@netscape.net> Message-ID: LOL, talk to Mich tomorrow ;) dnh On Fri, 1 Jun 2001 helfesrieder@netscape.net wrote: > Hi Adam, > > In my opinion CF needs a new and improved Map-Editor, ideally > in Java to be available cross platform. > > The current Crossedit Editor is only available for Unix and > XWindows. This closes out potential map-makers that have > a Windows OS (which are 95% of all desktop users). > > End-User usability is a big issue. In my opinion it is close > to unusable for technically non-skilled people. In many cases > you need to enter bitmask-numbers, data fields change meaning > depending on object context etc. This can probably done much > better with a good dialog and interface design. > > Maybe you want to have your students tackle this ? An open > source approach would be nice. > > Regards, > > Zack > > > > __________________________________________________________________ > Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Fri Jun 1 09:47:00 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] Re: Crossfire IT-Project - The Editor is ready!! In-Reply-To: <2C0DC028.5F262AF2.79055386@netscape.net> Message-ID: Hm, believe me or not, i had spend a week to make the java editor. And he is nearly finished. He is a GREAT piece of java code, i used the Gridder source as base (but at this time, most is changed). I will release him later in this night. Perhaps he goes ASAP to a first CVS, so all of you can grap him. At the moment he reads in all arches, read and blt maps, he can make makes iso AND rectangel (in fact, you click a button and the view is changed). You can load in a map twice and look in one window in iso style in it, in other in normal. I added menues for RandomMaps and Scripts and try to reserve space in the GUI for it, thats for peterm and gros to include them. Well, the weak point is arch parsing, most goes over text. Thats only a question of time. When every guys graps a arch type wrotes a paser for it, it will need a week to make them. Ok, i will try to bring it to an end now and then you all can see. Michael PS: Java Editors are like Sex: Don't talk about it, do it! > Hi Adam, > > In my opinion CF needs a new and improved Map-Editor, ideally > in Java to be available cross platform. > > The current Crossedit Editor is only available for Unix and > XWindows. This closes out potential map-makers that have > a Windows OS (which are 95% of all desktop users). > > End-User usability is a big issue. In my opinion it is close > to unusable for technically non-skilled people. In many cases > you need to enter bitmask-numbers, data fields change meaning > depending on object context etc. This can probably done much > better with a good dialog and interface design. > > Maybe you want to have your students tackle this ? An open > source approach would be nice. > > Regards, > > Zack > > > > __________________________________________________________________ > Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From michael.toennies at nord-com.net Sat Jun 2 00:59:01 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] CF Java Editor - beta release! Message-ID: Hi And here we go! The CFJavaEditor! http://mids.student.utwente.nl/~michtoen/CFJavaEditor/CFJavaEditor.zip At this time, i had coded 8 days on him. The whole GUI is working. You can load maps, insert arches and safe them. They work so far i can see, i saved/changed scorn and the server eats the map (they saved in unix style so you can copy it 1:1 also from windows or mac systems). ARCH Files ----------- The Editor looks for the arch folder in his directory. ** Copy a FULL arch folder over the arch folder in the CFJavaEditor directory. You can get a arch and a map package here: http://www.futt.org/crossfire_html (the single files version, not the packed stuff from server) You can set the arch files folder in the option panel of the editor. The editor will load ALL arches and png and SORT them in the panels. At the moment this is only 1:1 from folder to folder, so no type info is used. But the look is great. To avoid to many panels, you can copy things like food, flesh, optical and some more in a folder items. The editor use the first folder level in arch as panel name. The 2nd subfolder row as combobox names. All other folder will be ignored. The left mouse button will always SELECT a item. With the right mouse button will set (on the map) or delete (on he panel to the right). The panel down will show data about the arch selected on map and in the right map tile panel. The info in the panel is very basic: only the arch name :) I had no time to put in more yet, but its easy and there will come many. In the right down corner is the text windows with the arch text! BLACK text is from default arch, red text is from arch in map and changed from default! You can write in the text panel but i dont parse this yet! In fact, you can insert and delete arches but you can't change then yet! Save will work, but carful - is tested only 30 min as i write this. Ok, this whole editor piece is - great. I like it very much. The work is damn easy and it shows what can be done. There are many menu items: RandomMap - build a random map interface here peterm! Script - Gros, here comes your scripts! Maps - A collect and controlling system about the maps and and and... Guys, you look to 8 days work. Assume a month. The full source is included! Put this in CVS ASAP! iam sleepy Michael From michael.toennies at nord-com.net Sat Jun 2 01:01:58 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] Java Editor 2nd Message-ID: Ah, i forgot! You can set in the options the IsoDefault Key. Then the editor is in Iso map modus. You can FOR EVERY map toggle from rectangle to iso map. Also, you can load a map twice and look to there in one window in rectangle and in other in iso (don't know why you should do it, because one looks always ugly :). Michael PS: i forgot other good features too of this sucker, search for yourself PPS: I WILL SEE CODE FROM YOU GUYS EXTENDING THIS SUCKER! From michael.toennies at nord-com.net Sat Jun 2 01:16:38 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] CF Java Editor - compile and runtime Message-ID: HI For run the CF Java Editor you need the 1.3.1 runtime or the 1.3.1. java standard edition. http://java.sun.com/j2se/1.3/ runtime & standard edition link When you had download the runtime, read the docs. After installing the runtime and downloading the CFJavaEditor.zip, you can start the Editor with the CFJavaEditor.jar. the command line java -jar CFJavaEditor.jar will start it. i *hope* it will run, because sometimes jar files from other systems (windows -> java) will not run. In this case you has to recompile it. You CAN also start it with the *.class files in the source directory or recompile it. Look in the run.bat how its starting. I had not included a make file, i used the MS Visual Studio Java editor, so you must do ti for yourself. Michael From michael.toennies at nord-com.net Sat Jun 2 10:34:49 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] DX Client 1.25 Message-ID: I fixed the Dx Client. http://mids.student.utwente.nl/~michtoen/crossfire/ Some small bug fixes, changed so its working with 1.0 and current CVS. I added a new console picture from Devin Watson. From reeve at ductape.net Sat Jun 2 17:07:07 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] CVS access Message-ID: <20010602180707.A24972@terra.localnet> Ok, the Gnome client code is fully ready to be put into CVS, but I need an account :) I've checked and it doesn't break anything, it works perfectly, I've switched over to gdk-pixbuf and made a few modifications that have made it even faster than the GTK client. -- -- -- Reeve the cat ----BEGIN FORTUNE---- Love the sea? I dote upon it -- from the beach. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From michael.toennies at nord-com.net Sun Jun 3 15:50:54 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] java editor bug Message-ID: Sometimes, when i move the mouse over the editor (doing nothing else) or scrolling the map when holding the map scroll slider, i get this exception. I can't force it, it come at random. Anyone has a idea? exception occurred during event dispatching: java.lang.InternalError: getGraphics not implemented for this component at sun.awt.windows.WGraphics.createFromComponent(Native Method) at sun.awt.windows.WGraphics.(Unknown Source) at sun.awt.windows.WComponentPeer.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JComponent.getGraphics(Unknown Source) at javax.swing.JComponent._paintImmediately(Unknown Source) at javax.swing.JComponent.paintImmediately(Unknown Source) at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) From jajcus at bnet.pl Sun Jun 3 06:14:25 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] BUG: Crossfire 1.0.0: 100th level with 'cause cold' Message-ID: <20010603131425.B5141@nic.nigdzie> Hi, Yesterday I found out, that a player who had got overal level of 16 the day before has over 85,000,000 exp. points. After talking to him it turned out, that all he done was casting 'cause cold' on some goblins. He got 100th level in wisdom in a few moments after. It seems there is a bug somewhere in the 'disease' code. Greets, Jacek From michael.toennies at nord-com.net Sun Jun 3 20:16:30 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:11 2005 Subject: [CF-Devel] strange type number Message-ID: Any idea what the "type 6-7" is? Typo? Object charwoman name cleaning woman race human face charwoman.171 animation charwoman monster 1 unaggressive 1 random_movement 1 alive 1 ac 10 wc 25 dam 1 hp 8 maxhp 8 Pow 1 sp 1 maxsp 1 exp 0 speed 0.15 type 6-7 <--- weight 50000 level 1 run_away 90 editable 1 end From michael.toennies at nord-com.net Sun Jun 3 20:54:00 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:12 2005 Subject: [CF-Devel] new java editor 0.910 Message-ID: Bugs removed, arch anaylse boosted. The editor now reads the arch types in. There will be a file called typedef.def. In this, all arch types will listed. After the name of the type will come a cmd - field - rule field will add a formular piece to the arch panel. These are special fields like archname, attack type list, connection etc. rule will tell the editor - which will the command do for this arch (for this type). how it will be named and what it will use (field and others). The field etc. will coded in java, but all other will be setup by the arch defines. For this, we need to setup ALL arches with the right type number. There are many without, we need to change this. Well, we want add types in the past for a better server<->client communication. So, we can do it here. Iam sleepy, just try it out for bugs. I think i can release tommorow the first editable and full usable version, so give me some response. Michael From dnh at hawthorn.csse.monash.edu.au Sun Jun 3 21:33:16 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:12 2005 Subject: [CF-Devel] BUG: Crossfire 1.0.0: 100th level with 'cause cold' In-Reply-To: <20010603131425.B5141@nic.nigdzie> Message-ID: Peterm........................................... Do you remember me finding this exact bug? getting to level 45 in around 1 minute. It seems to occur at random but I guess it is something like an overflow. The first time it happen I disarmed a trap just as the first goblin died, then suddenly my wisdom started gaining a levels very quickly. I thought it had somehow started to give me the amount of points I would get in mental experience and putting them on wisdom, of course mental would not then rise so it would constinue to give that percentage of points. This is a guess and I never managed to prove it, I would be interested to know the exact circumstances for the below mentioned players massive gain in exp. dnh On Sun, 3 Jun 2001, Jacek Konieczny wrote: > Hi, > > Yesterday I found out, that a player who had got overal level of 16 the > day before has over 85,000,000 exp. points. After talking to him it > turned out, that all he done was casting 'cause cold' on some goblins. > He got 100th level in wisdom in a few moments after. > > It seems there is a bug somewhere in the 'disease' code. > > Greets, > Jacek > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Sun Jun 3 21:37:36 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:12 2005 Subject: [CF-Devel] new java editor 0.910 In-Reply-To: Message-ID: Yarg I still don't know how to install a java file in debian. Can anyone help me? what packages do I need, what commands do i run.. ? Sorry Mich until I can install it there isn't much I can do =( dnh On Mon, 4 Jun 2001, Michael Toennies wrote: > Bugs removed, arch anaylse boosted. > > The editor now reads the arch types in. > > There will be a file called typedef.def. > > In this, all arch types will listed. > > After the name of the type will come a cmd > - field > - rule > > field will add a formular piece to the arch panel. > > These are special fields like archname, attack type list, > connection etc. > > rule will tell the editor > - which will the command do for this arch (for this type). > how it will be named and what it will use (field and others). > > The field etc. will coded in java, but all other will be setup by > the arch defines. > > For this, we need to setup ALL arches with the right type number. > There are many without, we need to change this. > > Well, we want add types in the past for a better server<->client > communication. > So, we can do it here. > > Iam sleepy, just try it out for bugs. > > I think i can release tommorow the first editable and full usable version, > so > give me some response. > > Michael > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From smurf at CSUA.Berkeley.EDU Mon Jun 4 00:33:13 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:12 2005 Subject: [CF-Devel] SDL enable GTK client / Fog of war Message-ID: <20010603223313.A7458@soda.csua.berkeley.edu> I've been working on enabling SDL on the GTK client and also adding a fog of war feature where seen but currently out of view tiles are still displayed but with a black square with 50% translucense set. It pretty much works at this point, and SDL seems to blit about 3x faster the gdk although it doesn't feel any faster. I have run into two problems though. First problem is the server doesn't send the client an update when it jumps to a new map, which is a problem since I keep state on what has been seen on the current map so far. I fixed this easily enough by adding a newmap( x,y) protocol command to the server which is called at the end of enter_map. Second problem is a bit tricker I think. When the player gets teleported the server just sends mapupdate commands.. Since I have to keep track of where the character is on a 255x255 array, this tends to cause me to overrun my array bounds.. This only seems to be a problem when teleporting within the same map, like in shops since teleporting to a new map causes the newmap command to be sent. What is the best solution for this? And are thier anymore problems similar to this that I might run into? -Scott From tanner at real-time.com Mon Jun 4 00:42:22 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:12 2005 Subject: [CF-Devel] new java editor 0.910 In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Mon, Jun 04, 2001 at 12:37:36PM +1000 References: Message-ID: <20010604004222.B18947@real-time.com> Quoting dnh (dnh@hawthorn.csse.monash.edu.au): > Yarg I still don't know how to install a java file in debian. Can anyone > help me? what packages do I need, what commands do i run.. ? > > Sorry Mich until I can install it there isn't much I can do =( Grab IBM's jdk, goto google, search for 'jdk ibm'. You can use alien to convert and rpm to deb, goto google, search 'rpm debian convert alien'. Download MT's editor. make sure java is in your path. cp the arch file into the directory ABOVE the CFJEditor directory. java -jar CFJEditor.jar -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From dnh at hawthorn.csse.monash.edu.au Mon Jun 4 02:23:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] poisoning Message-ID: Currently gnarg is probably the worst god out there. While in a discussion about it peterm posed the question of whether the attack type poison actually did anything. After some testing I found I couldn't kill an ogre or gnoll with poion even after taking 83 or so hp off it to begin with. Unless I am mistaken this is alittle silly. Using a level 69 physique 110 overall character I couldn't kill a gnoll with the venomtooth's poison. looking at the code, in the function poison_player peterm left this comment, /* peterm: give poisoning some teeth. It should be able to kill things better than it does: damage should be dependent something--I choose to do this: if it's a monster, the damage from the poisoning goes as the level of the monster/2. If anything else, goes as damage. */ Currently I can safely say poison doesn't have teeth, it seems not even the venomtooth has teeth ;). What should we do? I think we need to incorparate level into the poison calculations, any ideas? This should probably changed pretty soon =). dnh From reeve at ductape.net Mon Jun 4 08:40:46 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] Gnome Patch Message-ID: <20010604094046.A15824@terra.localnet> Here's the diff for testing. -- -- -- Reeve the cat ----BEGIN FORTUNE---- The control of the production of wealth is the control of human life itself. -- Hilaire Belloc ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 394092 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010604/b6a838f5/patch.bin From bugs at real-time.com Mon Jun 4 02:38:27 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] [Bug 369] New - Kills via "sword of poisoning" don't assign any exp Message-ID: <200106040738.f547cRM01919@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=369 *** shadow/369 Mon Jun 4 02:38:27 2001 --- shadow/369.tmp.1916 Mon Jun 4 02:38:27 2001 *************** *** 0 **** --- 1,21 ---- + +============================================================================+ + | Kills via "sword of poisoning" don't assign any exp | + +----------------------------------------------------------------------------+ + | Bug #: 369 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: All | + | Severity: normal OS/Version: Linux | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: peterm@tonks.eecs.berkeley.edu | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Poison something with a sword of poisoning. Watch it die of poison. + You get no message that you killed it, nor, I believe, do you get + any exp. + + PeterM \ No newline at end of file From reeve at ductape.net Mon Jun 4 11:41:29 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] Sorry about that patch Message-ID: <20010604124129.A17617@terra.localnet> I know that patch kinda sucked, here's a cleaner (gzipped) one that works MUCH better :) -- -- -- Reeve the cat ----BEGIN FORTUNE---- "I'd love to go out with you, but I did my own thing and now I've got to undo it." ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome.patch.gz Type: application/x-gzip Size: 84801 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010604/8421573b/gnome.patch.bin From jbontje at suespammers.org Mon Jun 4 16:52:10 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] Sorry about that patch In-Reply-To: <20010604124129.A17617@terra.localnet> References: <20010604124129.A17617@terra.localnet> Message-ID: <20010604235210.A31844@mids.student.utwente.nl> I had problems compiling the latest gnome-client, here is what I did to resolve the problems: (make gave errors about dmalloc) change lines 156-157 in Makefile from: gnome-cfclient: $(GNOME_OBJS) $(CC) -o gnome-cfclient $(GNOME_OBJS) $(GNOME_LIBS) $(LDFLAGS) $(LIBS) into: gnome-cfclient: $(GNOME_OBJS) $(CC) -o gnome-cfclient $(GNOME_OBJS) $(GNOME_LIBS) $(LDFLAGS) $(LIBS) $(DMALLOC_LIB) Now the client compiles... Joris Bontje / mids From mwedel at scruz.net Tue Jun 5 01:41:28 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] client support for big map checked in. Message-ID: <3B1C7F18.EFFFCEE2@scruz.net> I've just checked in the code that lets the client use the larger viewable map size that I checked into the server last night. There is a bug in that if you use the -pngximage option, the client will spew these to stderr: Gtk-CRITICAL **: file gtkobject.c: line 1070 (gtk_object_get_data_by_id): assertion `GTK_IS_OBJECT (object)' failed. Gtk-WARNING **: invalid class type `(unknown)' in cast to `GtkObject' I'm not sure of a fix. I know it is related to the drawing function in some way (as if I comment out the calls to gdk_draw_rgb_image I don't get those errors, OTOH, you don't get a viewable map, so that doesn't seem like a very good solution. As best as I can tell, there is nothing in the calls themselves that look to be wrong. In any case, in my short testing, I haven't noticed any problems with the actual working of the code, other than those annoying messages. Do note that you may really want to check the performance of your system/client when using the larger maps. a 25x25 map is really 5 times the number of pixels (800x800 in png mode). I noticed in simple testing (running around the town) that before I did some optimization, after I stopped hitting the control key, and I would still keep moving for a while because the client fell behind. you can uncomment the TIME_MAP_REDRAW at the end of cconfig.h - if using the gtk client it will print how long the redraw/updates have taken. since each tick is 120 ms, anything more than that your really in trouble - having it below 100 ms seems to be a good thing. Note if you do use the -pngximage option, you get cooler lighting effects - a demo picture is at http://tavern.santa-clara.ca.us/inter.gif If you do nott use -pngximage option, there is no lighting modification for big maps (small maps (<15 in both directions) still use the old lighting bitmask. I thought of implementing that bitmask for the other drawing modes, but IMO its pretty ugly, and probably just better to give the reduced sight (which the server takes care of) than go through that ugliness (not that this is pretty easy to do with old map/client anyways - just make a new dark1,dark2,dark3 images and put them in the .crossfire/gfx directory - these new ones should just be completely transparent. ). I've played around a bit on 19x25 maps, so non square maps certainly do work. And in fact, given the layout of the client, I find such rectangular maps make more use of the space. Note that the x11 client does also support the big maps - I just did not (nor am I likely) to bother with adding in these other features for that. From jbontje at suespammers.org Tue Jun 5 03:12:20 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] Gnome client compiling from CVS Message-ID: <20010605101220.A2458@mids.student.utwente.nl> Hello, I get fatal errors when compiling the latest CVS version of the crossfire client (with the Gnome client checkin from Scott). gnome.c: In function `do_timeout': gnome.c:3868: too few arguments to function `display_map_doneupdate' gnome.c: In function `display_map_doneupdate': gnome.c:4169: number of arguments doesn't match prototype proto.h:141: prototype declaration make: *** [gnome.o] Error 1 that makes sense because the function is defined as the following: proto.h:extern void display_map_doneupdate ( int redraw ); the gnome client calles it: gnome.c: display_map_doneupdate(); and its defined as: gnome.c: display_map_doneupdate(); So I think something has to change... Joris Bontje / mids From tanner at real-time.com Wed Jun 6 02:14:05 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:13 2005 Subject: [CF-Devel] Large view area screenshots? Message-ID: <20010606021405.H21629@real-time.com> I know it's not released yet, but any large view area screenshots? I'd like to update CF's freshmeat entry with a new screenshot, to whet the appetite. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From dnh at hawthorn.csse.monash.edu.au Wed Jun 6 03:01:35 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Large view area screenshots? In-Reply-To: <20010606021405.H21629@real-time.com> Message-ID: I'd like to see large view area + Mark's light guessing stuff + iso and/or new graphics set dnh On Wed, 6 Jun 2001, Bob Tanner wrote: > I know it's not released yet, but any large view area screenshots? > > I'd like to update CF's freshmeat entry with a new screenshot, to whet the > appetite. > > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruznet.com Wed Jun 6 13:43:52 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Started isometric version of the client (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 06 Jun 2001 18:00:21 +0100 From: Ben Norrington Reply-To: ben@norrington.net To: mwedel@nic.scruz.net Subject: Started isometric version of the client I have started an isometric version of the client (see the attached screenshot.) It uses an almost standard server (the only change is in the max image size XPM_BUF 65536 and in the max message size up to 65536 also). The server changes should be backwards compatible with the old clients. As you can see it is a long way from complete (and it is very buggy at the moment). It would need for the server to have a new image catagory for the isometric tiles (it uses the png ones at the moment which would stop backward complatibility). I haven't really got the time to redo all of the tiles at the moment but my exams end on the 22nd so I should have loads of time then. If you are interested then email me and I will send you the code (a complete hack/mess). It goes against some of the rules (images are in truecolour) and it uses sdl for all the windows and drawing. There is no console or inventory yet. I also broke the keys since some of the key code needs an x window open to work; sdl seems to have a good solution to this. Ben P.S. Please could you fordward this to the mailing list as I still can't post to it -------------- next part -------------- A non-text attachment was scrubbed... Name: isocrossfire.jpg Type: application/octet-stream Size: 76413 bytes Desc: Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010606/c7c89d13/isocrossfire.obj From michael.toennies at nord-com.net Wed Jun 6 15:43:54 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Started isometric version of the client (fwd) In-Reply-To: Message-ID: He, funny. Well, i will contact him so he can then work on the iso stuff with me... I will make there a major release which will give this a kick start. The new editor will native work with it and a patch for linux and dx client to use iso maps is very very easy. > > > ---------- Forwarded message ---------- > Date: Wed, 06 Jun 2001 18:00:21 +0100 > From: Ben Norrington > Reply-To: ben@norrington.net > To: mwedel@nic.scruz.net > Subject: Started isometric version of the client > > > I have started an isometric version of the client (see the attached > screenshot.) It uses an almost standard server (the only change is in the > max image size XPM_BUF 65536 and in the max message size up to > 65536 also). > The server changes should be backwards compatible with the old clients. > > As you can see it is a long way from complete (and it is very buggy at the > moment). It would need for the server to have a new image catagory for the > isometric tiles (it uses the png ones at the moment which would stop > backward complatibility). I haven't really got the time to redo all of the > tiles at the moment but my exams end on the 22nd so I should have loads of > time then. > > If you are interested then email me and I will send you the code (a > complete hack/mess). It goes against some of the rules (images are in > truecolour) and it uses sdl for all the windows and drawing. There is no > console or inventory yet. I also broke the keys since some of the key code > needs an x window open to work; sdl seems to have a good solution to this. > > Ben > > P.S. Please could you fordward this to the mailing list as I still can't > post to it > From michael.toennies at nord-com.net Wed Jun 6 22:07:24 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] CF Java Editor 0.960... full usable Message-ID: Here is the first full usable release. http://mids.student.utwente.nl/~michtoen/CFJavaEditor You can load, edit and save CF maps. You can look at them in iso style or normal style. The editor has some features inside. So you can see inventory in normal way as map tiles and edit then too. You can attach inventory with a click to add inv. to a selected tile in the right panel (the left panel item will insert then). You can change name, face, msg area on the form. All other yet comes in the arch text part. The rule is: If a arch text i BLACK, it comes from the default arch (in will not insert in the map arch). If it blue, it comes from the map arch (and overrule the default arch settings). If there is not, default and map arch don't have text about it. Well, we will need to write a help for it. Ah yes, don't forget to press Apply when you had insert changes, i had not included autofocus changes. Michael PS: this is still a untested version ,so report bugs and be careful.. From bugs at real-time.com Wed Jun 6 21:39:02 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] [Bug 370] New - FREE ITEMS IN SHOPS ON MiDS SERVER Message-ID: <200106070239.f572d2r01028@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=370 *** shadow/370 Wed Jun 6 21:39:02 2001 --- shadow/370.tmp.1025 Wed Jun 6 21:39:02 2001 *************** *** 0 **** --- 1,28 ---- + +============================================================================+ + | FREE ITEMS IN SHOPS ON MiDS SERVER | + +----------------------------------------------------------------------------+ + | Bug #: 370 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: Other | + | Severity: major OS/Version: Windows 95 | + | Priority: P1 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: nazgarn@hotmail.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + FREE ITEMS IN SHOPS ON MiDS SERVER + + On MiDS's server, the current shop listings are deemed "empty". Upon picking up + an item in the shop, the status of the item is paid so therefore can take it, + and upon dropping the item it sells for the price it is, thereby allowing + unlimited amount of platinum to anyone who knows about this. Currently I + cleaned out the weapon shop, dropped all items in armory and made about 2k + platinum. Realising that this is immoral and silly of me I discontinued my + testing of this bug and sent the bug report. I told noone else of this so noone + will abuse this bug, including me. + + - Sizor \ No newline at end of file From mwedel at scruz.net Wed Jun 6 23:15:55 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Large view area screenshots? References: <20010606021405.H21629@real-time.com> Message-ID: <3B1EFFFB.38AB52E3@scruz.net> Bob Tanner wrote: > > I know it's not released yet, but any large view area screenshots? > > I'd like to update CF's freshmeat entry with a new screenshot, to whet the > appetite. The code is checked in. Realistically, I'm not sure what the future release schedule will look at. I see many fairly big projects on the works, and I'm not sure if interim releases when this is still work in progress or doesn't have much testing really a good thing or not - official releases tend to have a suggestion of more reliability - if they end up really buggy, people download the 'official' release, install it, find it buggy, tell their friends its buggy, and never look at it again. So what I see going on for the future is not much in the way of official releases, but developers are of course still free to set up servers based off CVS - it gets testing, the new features are out there, and it gets some testing. If it proves too buggy, the server can of course be backed out, presuming previous versions of the data files remain compatible. From mwedel at scruz.net Wed Jun 6 23:47:08 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] SDL enable GTK client / Fog of war References: <20010603223313.A7458@soda.csua.berkeley.edu> Message-ID: <3B1F074C.F71D9617@scruz.net> Scott MacFiggen wrote: > > I've been working on enabling SDL on the GTK client and also > adding a fog of war feature where seen but currently out of view > tiles are still displayed but with a black square with 50% > translucense set. It pretty much works at this point, and SDL seems > to blit about 3x faster the gdk although it doesn't feel any faster. That may be a really good gain then with the latest client that does shading for darkness. Performance on that is pretty poor. Note that the client and server now support the sending of larger viewable maps - I don't know how much need there will still be for a fog of war, but its probably still useful for servers that have a max viewable map smaller than what the players really want. > First problem is the server doesn't send the client an update when it jumps > to a new map, which is a problem since I keep state on what has been > seen on the current map so far. I fixed this easily enough by adding > a newmap( x,y) protocol command to the server which is called at the end of > enter_map. > > Second problem is a bit tricker I think. When the player gets teleported > the server just sends mapupdate commands.. Since I have to keep track of > where the character is on a 255x255 array, this tends to cause me to > overrun my array bounds.. This only seems to be a problem when teleporting > within the same map, like in shops since teleporting to a new map causes > the newmap command to be sent. > > What is the best solution for this? And are thier anymore problems similar > to this that I might run into? The problem here is that the client is presumed non trust worthy. Depending on peoples opinion, sending the players x,y coordinate may be giving away extra knowledge. Not for example it would then make it very easy to have it also automap, and this then may let players find secret treasure chambers or their way around mazes much more easily (I remember one maze map in brest which was no magic in a lot of it as well as having teleports to make life more difficult - if client knows the x,y whenever they hit a teleporter, such a map now becomes trivially easy). OTOH, this may not be a really bad thing - the number of maps that use that feature are small, and having an automap is a pretty cool thing in of its own. That said, there are more than just teleporters that move players around. pit traps for example - and this may be another case where knowing where you got dropped to pretty precisely could be helpful (think for example going through a dungeon but not exploring every side door, and going down a pit. You wander your way out, and you know that behind that door is the passage you hand wandered through earlier, so despite being beat up, you know its safe..) I'd have to let others comment on how big a security issue this may be. Like most things, security is balanced by usability. And this may very well be a case where it is determined that the usability of this information for fog of war or automapper is greater than the secrets it may give away about some dungeons. That said, another problem I do see you running into is automatic map tiling. The main point of this is that the movement between the tiled maps should be invisible - so this also means that things like monsters, spells, etc will cross the boundries without problems. And the way I envision doing it would not have the player go through enter_exit, so you would get no notification that he changed maps. This could be changed, and giving away the 'seams' of the map tiling probably would not be a big deal. And in some level, your fog of war code would probably also want to be able to handle this. > > -Scott > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From reeve at ductape.net Thu Jun 7 09:53:05 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Skills Message-ID: <20010607105305.A4318@terra.localnet> Is there any way to get a list of the skills a player knows from the server? I'm hoping to improve the keybindings editor in the Gnome client by giving the player a drop-down list of commands and a drop-down list of possible options to the commands rather than just having them type them out, but I need a way to get that information. If it's considered a security risk, I understand, I'm just wondering though. I'm sure if it's a problem I can find a work around for it like I did with the spell dialog that comes up when you choose the Cast... menu item. -- -- -- Reeve the cat ----BEGIN FORTUNE---- I sold my memoirs of my love life to Parker Brothers -- they're going to make a game out of it. -- Woody Allen ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From bugs at real-time.com Thu Jun 7 01:07:42 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] [Bug 370] Changed - FREE ITEMS IN SHOPS ON MiDS SERVER Message-ID: <200106070607.f5767gW04105@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=370 *** shadow/370 Wed Jun 6 21:39:02 2001 --- shadow/370.tmp.4100 Thu Jun 7 01:07:42 2001 *************** *** 2,9 **** | FREE ITEMS IN SHOPS ON MiDS SERVER | +----------------------------------------------------------------------------+ | Bug #: 370 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: Other | | Severity: major OS/Version: Windows 95 | | Priority: P1 Component: server | +----------------------------------------------------------------------------+ --- 2,9 ---- | FREE ITEMS IN SHOPS ON MiDS SERVER | +----------------------------------------------------------------------------+ | Bug #: 370 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: Other | | Severity: major OS/Version: Windows 95 | | Priority: P1 Component: server | +----------------------------------------------------------------------------+ *************** *** 26,28 **** --- 26,32 ---- will abuse this bug, including me. - Sizor + + ------- Additional Comments From mwedel@scruz.net 2001-06-07 01:07 ------- + server/shop.c: Fix bug that resulted in items in shop being paid, + as well as not generating proper listing. MSW 2001-06-06. From bugs at real-time.com Thu Jun 7 02:10:01 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200106070710.f577A1j05072@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 From smurf at CSUA.Berkeley.EDU Thu Jun 7 14:54:54 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] SDL enable GTK client / Fog of war In-Reply-To: <3B1F074C.F71D9617@scruz.net>; from mwedel@scruz.net on Wed, Jun 06, 2001 at 09:47:08PM -0700 References: <20010603223313.A7458@soda.csua.berkeley.edu> <3B1F074C.F71D9617@scruz.net> Message-ID: <20010607125454.A62288@CSUA.Berkeley.EDU> On Wed, Jun 06, 2001 at 09:47:08PM -0700, Mark Wedel wrote: > Scott MacFiggen wrote: > > > > I've been working on enabling SDL on the GTK client and also > > adding a fog of war feature where seen but currently out of view > > tiles are still displayed but with a black square with 50% > > translucense set. It pretty much works at this point, and SDL seems > > to blit about 3x faster the gdk although it doesn't feel any faster. > > That may be a really good gain then with the latest client that does shading > for darkness. Performance on that is pretty poor. > > Note that the client and server now support the sending of larger viewable maps > - I don't know how much need there will still be for a fog of war, but its > probably still useful for servers that have a max viewable map smaller than what > the players really want. Well, currently the fog code is only used for squares that are in the viewable area but out of LOS. So if you run over and peek down a hallway then run back, you will still see the hallway, shaded down 50%, and any monsters that might have been standing down there. I'll merge my changes in with your client changes this weekend and also add support for using large views on a server with smaller update areas. I think it goes a long way towards making the game look nicer... > The problem here is that the client is presumed non trust worthy. Depending on > peoples opinion, sending the players x,y coordinate may be giving away extra > knowledge. > > Not for example it would then make it very easy to have it also automap, and > this then may let players find secret treasure chambers or their way around > mazes much more easily (I remember one maze map in brest which was no magic in a > lot of it as well as having teleports to make life more difficult - if client > knows the x,y whenever they hit a teleporter, such a map now becomes trivially > easy). This is workable.. What I can do is store the map state in a 510x510 array and just always start from the middle and use a virtual coordinate system. Each map cell in the array is an array of 5 shorts, an 8 bit count value and an 8 bit cleared value. So 12 bytes * 255*255 comes out to be 780K. If I bring it up to 510*510, it comes to 3 meg. Thats why I would rather have the client know about the x,y coordinates. But if I use the virtual coordinate idea then all I need to know from the server is when to reset state. I'll do it that way in my patch and we can go from there. -Scott From bugs at real-time.com Thu Jun 7 14:52:00 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] [Bug 371] New - Mapsize lower than 11x11 or between 11x11 and 16x16 crashes the server and client Message-ID: <200106071952.f57Jq0U17201@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=371 *** shadow/371 Thu Jun 7 14:52:00 2001 --- shadow/371.tmp.17198 Thu Jun 7 14:52:00 2001 *************** *** 0 **** --- 1,19 ---- + +============================================================================+ + | Mapsize lower than 11x11 or between 11x11 and 16x16 crashes the server and | + +----------------------------------------------------------------------------+ + | Bug #: 371 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Linux | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: reeve@ductape.net | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + If you connect to a server with the mapsize code and specify a map size that is + lower than 11x11 or is higher than 11x11 but lower than 16x16 it will crash both + the server and the client. \ No newline at end of file From mwedel at scruznet.com Thu Jun 7 17:09:10 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] SDL enable GTK client / Fog of war In-Reply-To: <20010607125454.A62288@CSUA.Berkeley.EDU> Message-ID: On Thu, 7 Jun 2001, Scott MacFiggen wrote: > > Well, currently the fog code is only used for squares that are in the > viewable area but out of LOS. So if you run over and peek down a hallway > then run back, you will still see the hallway, shaded down 50%, and any > monsters that might have been standing down there. I'll merge my changes in > with your client changes this weekend and also add support for using > large views on a server with smaller update areas. I think it goes a long way > towards making the game look nicer... OK. Thats pretty cool then. A lot of the game right now really looks pretty poor with the larger viewable map area. The world map looks downright strange, but many other buildings sort of presume a 11x11 viewing area. The gatehouse to the city sort of falls into that - with the larger map, you can now see the entire north/south extent of the building, and the blackness beyond the map boundaries. From mwedel at scruznet.com Thu Jun 7 17:14:31 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] Skills In-Reply-To: <20010607105305.A4318@terra.localnet> Message-ID: On Thu, 7 Jun 2001, Scott Barnes wrote: > Is there any way to get a list of the skills a player knows from the > server? I'm hoping to improve the keybindings editor in the Gnome client > by giving the player a drop-down list of commands and a drop-down list of > possible options to the commands rather than just having them type them > out, but I need a way to get that information. If it's considered a > security risk, I understand, I'm just wondering though. I'm sure if it's > a problem I can find a work around for it like I did with the spell dialog > that comes up when you choose the Cast... menu item. If you type 'skills' with no option, it will display the characters current skills. There is currently no way to get a cleaner version than that. Unfortunately, that may not be a really complete list. Skill objects, like lock picks, holy symbols, talismans only give the skill when they are used, and thus don't appear in the skills listing (or only the skill that is currently used does). But when you then go to try and use the skill, the server tries to find an appropriate object in the characters inventory that grants that skill. But skills by those objects should certainly be available from pull down menus. But this gets a little trickier to track, as a player can gain/lose a skill whenever they may pick up/drop an object. So maintiaining a 100% accurate skill list could be difficult. Of course, you could just list all the skills in the game, and if the player selects one they don't know, it presents an error message. Not ideal either. From bugs at real-time.com Fri Jun 8 01:22:26 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:14 2005 Subject: [CF-Devel] [Bug 371] Changed - Mapsize lower than 11x11 or between 11x11 and 16x16 crashes the server and client Message-ID: <200106080622.f586MQd26208@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=371 *** shadow/371 Thu Jun 7 14:52:00 2001 --- shadow/371.tmp.26204 Fri Jun 8 01:22:26 2001 *************** *** 2,9 **** | Mapsize lower than 11x11 or between 11x11 and 16x16 crashes the server and | +----------------------------------------------------------------------------+ | Bug #: 371 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: PC | | Severity: normal OS/Version: Linux | | Priority: P2 Component: server | +----------------------------------------------------------------------------+ --- 2,9 ---- | Mapsize lower than 11x11 or between 11x11 and 16x16 crashes the server and | +----------------------------------------------------------------------------+ | Bug #: 371 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: PC | | Severity: normal OS/Version: Linux | | Priority: P2 Component: server | +----------------------------------------------------------------------------+ *************** *** 17,19 **** --- 17,26 ---- If you connect to a server with the mapsize code and specify a map size that is lower than 11x11 or is higher than 11x11 but lower than 16x16 it will crash both the server and the client. + + ------- Additional Comments From mwedel@scruz.net 2001-06-08 01:22 ------- + I am unable to find any way this caused the server to crash, but the + client was certainly unusable. Have updated the server to use the map1 + protocol command for any map above 11x11, because those could not be properly + supported with old protocol command. Updated client to be able to deal + with the smaller map size properly. From bugs at real-time.com Fri Jun 8 08:11:42 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] [Bug 372] New - Free items in shops on damn.* server Message-ID: <200106081311.f58DBg331908@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=372 *** shadow/372 Fri Jun 8 08:11:42 2001 --- shadow/372.tmp.31905 Fri Jun 8 08:11:42 2001 *************** *** 0 **** --- 1,28 ---- + +============================================================================+ + | Free items in shops on damn.* server | + +----------------------------------------------------------------------------+ + | Bug #: 372 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: Other | + | Severity: major OS/Version: Windows 95 | + | Priority: P1 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: nazgarn@hotmail.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Free items in shops on damn.* server, see bug #370 on MiDS server which is + currently fixed. When one views sign in store, all items are then free and + listing is shown as none. + + Additional comments from bug #370: + + server/shop.c: Fix bug that resulted in items in shop being paid, + as well as not generating proper listing. MSW 2001-06-06. + + - Sizor + (NB - This bug could be on other servers which I haven't played at, would be + wise to check those too) \ No newline at end of file From jbontje at suespammers.org Fri Jun 8 12:03:12 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] [Bug 372] New - Free items in shops on damn.* server In-Reply-To: <200106081311.f58DBg331908@crusader.real-time.com> References: <200106081311.f58DBg331908@crusader.real-time.com> Message-ID: <20010608190312.A7564@mids.student.utwente.nl> On Fri, Jun 08, 2001 at 08:11:42AM -0500, bugs@real-time.com wrote: > http://bugzilla.real-time.com/show_bug.cgi?id=372 > You have submitted the following bugreport: > + | Free items in shops on damn.* server | > + +----------------------------------------------------------------------------+ > + | Bug #: 372 Product: Crossfire | > + | Status: NEW Version: CVS | > + | Resolution: Platform: Other | > + | Severity: major OS/Version: Windows 95 | > + | Priority: P1 Component: server | > + +----------------------------------------------------------------------------+ > + | Assigned To: crossfire-devel@lists.real-time.com | > + | Reported By: nazgarn@hotmail.com | > + | CC list: Cc: | > + +----------------------------------------------------------------------------+ > + | URL: | > + +============================================================================+ > + | DESCRIPTION | > + Free items in shops on damn.* server, see bug #370 on MiDS server which is > + currently fixed. When one views sign in store, all items are then free and > + listing is shown as none. > + > + Additional comments from bug #370: > + > + server/shop.c: Fix bug that resulted in items in shop being paid, > + as well as not generating proper listing. MSW 2001-06-06. > + > + - Sizor > + (NB - This bug could be on other servers which I haven't played at, would be > + wise to check those too) Its good to report bugs on servers, but there is no need to report bugs for every server... Best thing to do is to email the serveradmin and ask to update his server, or just wait till its updated. Thanks, Joris Bontje / mids From highway at cstone.net Fri Jun 8 12:47:57 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Wraith/devourers and nightfall Message-ID: <3B210FCD.4AF694BA@cstone.net> I have a character who is a wraith worshipping the Devourers. He got the spell "Nightfall" from praying but it's listed as denied. Is that a mistake, or just something odd? SeanMike From e_vestal at hotmail.com Sat Jun 9 02:24:37 2001 From: e_vestal at hotmail.com (Dany Talbot) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] [Bug 372] New - Free items in shops on damn.* server Message-ID: Any idea when that bug was put into the CVS? ----Original Message Follows---- From: Joris Bontje To: nazgarn@hotmail.com On Fri, Jun 08, 2001 at 08:11:42AM -0500, bugs@real-time.com wrote: > http://bugzilla.real-time.com/show_bug.cgi?id=372 > You have submitted the following bugreport: > + | Free items in shops on damn.* server | > + +----------------------------------------------------------------------------+ > + | Bug #: 372 Product: Crossfire | > + | Status: NEW Version: CVS | > + | Resolution: Platform: Other | > + | Severity: major OS/Version: Windows 95 | > + | Priority: P1 Component: server | > + +----------------------------------------------------------------------------+ > + | Assigned To: crossfire-devel@lists.real-time.com | > + | Reported By: nazgarn@hotmail.com | > + | CC list: Cc: | > + +----------------------------------------------------------------------------+ > + | URL: | > + +============================================================================+ > + | DESCRIPTION | > + Free items in shops on damn.* server, see bug #370 on MiDS server which is > + currently fixed. When one views sign in store, all items are then free and > + listing is shown as none. > + > + Additional comments from bug #370: > + > + server/shop.c: Fix bug that resulted in items in shop being paid, > + as well as not generating proper listing. MSW 2001-06-06. > + > + - Sizor > + (NB - This bug could be on other servers which I haven't played at, would be > + wise to check those too) Its good to report bugs on servers, but there is no need to report bugs for every server... Best thing to do is to email the serveradmin and ask to update his server, or just wait till its updated. Thanks, Joris Bontje / mids _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From michael.toennies at nord-com.net Sat Jun 9 10:09:58 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Iso CF start phase Message-ID: Hi I will now start to setup the arch, maps and server to ISO cf. The Editor is ready for it. ** PLEASE don't touch the CVS until i do the release today or next day** I will use the CVS snapshot to do the client/server changes. Because the script engine will included and i will make a windows server/binary (with guile script) i will make some changes. ** same for arch and maps ** Iso CF transfering needs there some work too! This means: 1.) the editor do the collect for the arches. It will write: - bmaps. - crossfire.png - archetypes - animations All this will done from loaded stuff (expect the pngs) Notice, that there will be no faces. file and no crossfire.xbm/crossfirexpm anymore. This will be first step to remove it. I had find out a quick patch for the server (change to lines) to do this. So, we can use this as test. 2.) transfering arches and maps I will setup the arch and maps in a way, we must touch every pieces to transfer it to iso. The editor will have some commands to automate this, for example a find & replace thing. This means: When you have a map, think about 2x2 all of grass.arc, using grass.111. Then this grass.arc will be old type. In Iso, there will be a /ground/grass/grass_1.arc. For transfering the one, it is needed to transfer grass.arc to grass_1.arc. Ok, i can hear you: "why in hell? so much work! ..." Let me say that this will give us the chance: - to restyle some maps - using more intelligence style sets! - style sets will give the power to use mask, i will introduce this later - rework the painful looking of some maps - and so on Remember: ** No logic and no technical part of a map will touched ** And not the look, the logic is the hard one. But we have MANY unfinished maps! - bad style - unused exits - unfinished quest - broken maps! When we now transer this all step by step we can do - a doc for every map - finally a description We NEED this. Ask AV about how long he needs to finds out the puplands map and how much work it was. There will come new stuff in future and we don't want work over and over through map we don't understand anymore to fix it. This is the big cut we need to face lift the maps AND do some rework. 3.) Scripting: Scriptfire Scripting is so great and gros scriptfire works fine. This will give us the chance to include this from bottom up. MW will put it in CVS, so we can use it in all versions. 4.) Client hacks for windows and linux I will do a fast patch so linux and dx client can show & play iso maps. 5.) writing a SDL client later I wish to drop dx client (SDL use on windows directx) and the linux clients to make ONE client as Iso standard. This inflation of clients don't help CF, it binds dev power to double work. From dnh at hawthorn.csse.monash.edu.au Sat Jun 9 10:35:40 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Wraith/devourers and nightfall In-Reply-To: <3B210FCD.4AF694BA@cstone.net> Message-ID: lol, devourers is denied light, and NIGHT fall is considered a light spell... lol! dnh On Fri, 8 Jun 2001, Sean Michael Whipkey wrote: > I have a character who is a wraith worshipping the Devourers. He got > the spell "Nightfall" from praying but it's listed as denied. > > Is that a mistake, or just something odd? > > SeanMike > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Sat Jun 9 16:45:15 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Iso CF start phase References: Message-ID: <3B2298EB.7302293A@scruz.net> Michael Toennies wrote: > > ** PLEASE don't touch the CVS until i do the release today or next day** I strongly disagree that CVS should be frozen for other updates in pretty much all cases. cvs provides automatic update and merging capabilities, so generally this should not be a problem. If it ends up that the merge doesn't happen automatically, and needs to be done by hand, this is effectively saying 'I can't be bothered to do the merges by hand, so you should merge in your changes by hand instead'. IMO this is not a good thing for a community project, and if such freezes happen, I think it will be detrimental to people coding (hmm.. I shouldn't do any coding this weekend because I'll have to merge it in by hand. Then next weekend, someone else may do a 'freeze' for their own, same result, so I shouldn't do any coding then, etc.) > 1.) the editor do the collect for the arches. It will write: > - bmaps. > - crossfire.png > - archetypes > - animations The current collection method must remain available. If I'm just doing some quick change for some arch, I don't want to have to load up the java editor just to collect those. Maybe the server doesn't even have java installed, or is set up such a way that I can display back to my system. And really, it would probably make more sense for the java editor to just use the existing collect scripts. If the java editor creates the files in the same form, no big deal, and I don't have a problem with the java editor having a collection option, but that must not be the only way they can be collected. I'm also really suspect about having the editor actually create archs - yes, it may allow for better checking on integretity, but at the same time may lead to a lot of new archs being created when they in fact should not be. > 2.) transfering arches and maps > > I will setup the arch and maps in a way, we must touch every pieces to > transfer > it to iso. The editor will have some commands to automate this, for example > a > find & replace thing. I'm unclear what exactly this means. Non ISO support MUST REMAIN. (or not, but if overhead view goes away, so might I). I really really really dislike iso views for most games. Yes, it looks nicer, but I find the playing of it a PITA. I'm going to send out another message about more large scale map updates. But IMO if every map needs to get touched up for ISO, in addition for every archetype/image, this results in a ton of work. > Let me say that this will give us the chance: > - to restyle some maps > - using more intelligence style sets! > - style sets will give the power to use mask, i will introduce this later > - rework the painful looking of some maps > - and so on Some maps need that. But I'm fearful of this ever getting done. Doing something like updating every map will take a ton of time - I've seen this with the images. > But we have MANY unfinished maps! > - bad style > - unused exits > - unfinished quest > - broken maps! That of course has nothing to do with iso or map form. It is just a matter of resources - the person doing the map ran out of time, moved on to somethign else, or may just ran out of ideas. I don't see how having to rework all the current maps is going to help that out at all, except to maybe get a more conistent step. > Ask AV about how long he needs to finds out the puplands map and how much > work it was. documentation about maps (and anything else) is a pure developer issue. Rework all the maps you want, but if the developers don't write the docs about the new maps, you run into the same problem. The reason of lack of docs is (either map or programming/arch/whatever) is simply because people don't write them. Unless we force them somehow (don't accept anything without doc), I think we will get into the same program again. But if we get too anal about what we accept, then you get into the problem of people saying 'I don't want to jump through those hoops', and thus don't develope. > 3.) Scripting: Scriptfire > > Scripting is so great and gros scriptfire works fine. > This will give us the chance to include this from bottom up. > MW will put it in CVS, so we can use it in all versions. I said it should probably be put it, but didn't actually volunteer myself to do it Gros - do you think it is ready for inclusion? > > 4.) Client hacks for windows and linux > > I will do a fast patch so linux and dx client can show & play iso maps. Don't do fast patches, do proper patches. One of my pet peeves is the 'fast patch' which takes the easy approach and then needs to get fixed up later to do the properly thing. IMO, what proper means in this context is command line option to switch between iso and non iso display. From helfesrieder at netscape.net Sat Jun 9 18:26:16 2001 From: helfesrieder at netscape.net (helfesrieder@netscape.net) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Iso CF start phase Message-ID: <102491CA.3A8CF8EC.79055386@netscape.net> Hi there, I think this is a very good idea. Probably some sort of GUI-component framework is also needed. I would suggest to take a look at ParaGUI. It sits on top of SDL and therefore is cross-platform by nature. http://www.bms-austria.com/projects/paragui/ Also take a look at the screenshot section ! Kind Regards, Bjoern (aka Zack) > 5.) writing a SDL client later > I wish to drop dx client (SDL use on windows directx) and the linux > clients > to make ONE client as Iso standard. > > This inflation of clients don't help CF, it binds dev power to > double work. __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From mwedel at scruz.net Sat Jun 9 19:25:56 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Future of maps. Message-ID: <3B22BE94.B4243A33@scruz.net> Regardless of what is need to be done with ISO, the current state of maps needs to be updated. If you have played on a server with a map area larger than 11x11, you will quickly see what I mean when you traverse the outside world. As you move north, a black band appears at the top, and as you keep moving, it disappears and appears at the bottom. This is because the world maps have an extra 5 spaces along the edges that it draws, and then when you change maps, that goes to the other side. The solution for this, which I plan to work on soon, is to implement automatic map tiling. Thus, when you approach the edge of one of hte maps, it automatically loads the map that should come into view. This would be done by extending the map header to say what maps should be loaded in the different directions. With that, it should be easier to make very large autojoin continents. There are really 3 possible future directions: 1) Keep outdoor continent basically the way it is, just use autojoining. 2) Go to an indoor/outdoor scale. The continent would be increased 20-30 times in size (in each direction, meaning 400-900 overall scale). Cities would not appear as the little images you enter, but instead by placed on the world maps. Thus, alternative ways of entering cities, like flying over the walls, would work. But the shops, caves, towers, etc, would still be buildings you enter from this. 3) Go to unified scale. Take #2 above, and increase the scale another order of magnitude or two. In this mode, everything is the same scale - the shops don't have buildings, but rather just appear as spaces on the map (walls, floors, etc). In this way, to go accross a city would probably be several hundred spaces, and the continent would be thousands to tens of thousands. #3 creates the humungous world some people want, but is also a lot of work. It also means that travelling from say navar city to scorn overland would be a tremendous journey, probably taking an hour or more of real time. It would be very difficult for anyone to explore the entire world. #2 is a bit more modest. The world becomes a bit larger, but instead of taking 20 seconds for that navar to scorn journey, may now take a few minutes. Dungeons would not be piled so much on top of each other. The split between indoor/outdoor would be very clear, and if/when things like day/night and weather are added, not a lot of maps would need to be modified (compared to #3, where you would probalby need to note which spaces are indoor and which are out). Presumably with either #2 or #3, the actual expansion could be done pretty automatically, with hand clean up (eliminating some of the blockiness and adding some more variety). In cases of both #2 and #3, all exits leading too/from the world maps would need to be redone due to the new coordinates. As a note, if the continents get expanded, some rething may also be in order. If things like player controlled boats are added, we would really need to think about such things like 'just where is pupland/port joseph/lake county?'. Is dtabb really needed as a seperate continent if the first is greatly expanded? Some of these could very well get merged into the main continent. Anyways, food for thought/discussion. From michael.toennies at nord-com.net Sat Jun 9 19:38:11 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Iso CF start phase In-Reply-To: <3B2298EB.7302293A@scruz.net> Message-ID: > 1.) the editor do the collect for the arches. It will write: > > - bmaps. > > - crossfire.png > > - archetypes > > - animations > > The current collection method must remain available. If I'm > just doing some > quick change for some arch, I don't want to have to load up the > java editor just > to collect those. Maybe the server doesn't even have java > installed, or is set > up such a way that I can display back to my system. > > And really, it would probably make more sense for the java > editor to just use > the existing collect scripts. If the java editor creates the > files in the same > form, no big deal, and I don't have a problem with the java > editor having a > collection option, but that must not be the only way they can be > collected. I'm > also really suspect about having the editor actually create archs > - yes, it may > allow for better checking on integretity, but at the same time > may lead to a lot > of new archs being created when they in fact should not be. The editor collect 100% compatible scripts. The bad thing is that you need to load all - well, when packed later, this need only seconds. The good thing is the strong control. I found without really looking for 2 small bugs in the arches. I don't think people will create arches like wild when the arch editor is out (and this will need some time, i don't have it on priority list). For this, the whole action is to hard, setting up all the stuff. > > 2.) transfering arches and maps > > > > I will setup the arch and maps in a way, we must touch every pieces to > > transfer > > it to iso. The editor will have some commands to automate this, > for example > > a > > find & replace thing. > > I'm unclear what exactly this means. > > Non ISO support MUST REMAIN. (or not, but if overhead view goes > away, so might > I). I really really really dislike iso views for most games. > Yes, it looks > nicer, but I find the playing of it a PITA. > > I'm going to send out another message about more large scale map > updates. But > IMO if every map needs to get touched up for ISO, in addition for every > archetype/image, this results in a ton of work. Well, thats the old discussion. The maps will not be compatible - and should not. I mean the look of course - not the logic (mashines, quests). This is a clear point i think? Why we are using iso? Because it give us other option for the look. So, thinking the old maps can be transformed, is childish. I don't know why every one think this is good. it is possible, yes. Its also possible to make a ascii client... In real: - Our maps look BAD. Our gfx set is bad. - the game is great. All people whinning about bad look, unfinished maps and broken quests. Repairing this is the smae amount of work. So, you can't avoid the work when you need results. If you want to stay for flat - stay. The server will not be effected, nor the gameplay. The bad point is, that we will split dev power. Btw: showing ISO maps flat is much better. Bad thing is , that you have to draw new or special monsters. Iso multi monsters don't need so much place like flat ones. Well, this only effect a few monsters, 90% will be untouched i think. For this, it is possible to do create new flat monsters. > > > Let me say that this will give us the chance: > > - to restyle some maps > > - using more intelligence style sets! > > - style sets will give the power to use mask, i will introduce > this later > > - rework the painful looking of some maps > > - and so on > > Some maps need that. But I'm fearful of this ever getting done. Doing > something like updating every map will take a ton of time - I've > seen this with > the images. > > > > But we have MANY unfinished maps! > > - bad style > > - unused exits > > - unfinished quest > > - broken maps! > > That of course has nothing to do with iso or map form. It is > just a matter of > resources - the person doing the map ran out of time, moved on to > somethign > else, or may just ran out of ideas. I don't see how having to > rework all the > current maps is going to help that out at all, except to maybe get a more > conistent step. > > > Ask AV about how long he needs to finds out the puplands map > and how much > > work it was. > > documentation about maps (and anything else) is a pure developer > issue. Rework > all the maps you want, but if the developers don't write the docs > about the new > maps, you run into the same problem. The reason of lack of docs > is (either map > or programming/arch/whatever) is simply because people don't > write them. Unless > we force them somehow (don't accept anything without doc), I > think we will get > into the same program again. But if we get too anal about what > we accept, then > you get into the problem of people saying 'I don't want to jump > through those > hoops', and thus don't develope. You haven't understand this mark. MAP LOGIC is not touched! And i will include a replace system . Working over a map, changing style and look is not the big work. Thats a "eye work" not a "brain work". Setting up the logic, connection and game play - thats was hard in maps. > > 3.) Scripting: Scriptfire > > > > Scripting is so great and gros scriptfire works fine. > > This will give us the chance to include this from bottom up. > > MW will put it in CVS, so we can use it in all versions. > > I said it should probably be put it, but didn't actually > volunteer myself to do > it Gros - do you think it is ready for inclusion? > > > > > 4.) Client hacks for windows and linux > > > > I will do a fast patch so linux and dx client can show & play iso maps. > > Don't do fast patches, do proper patches. > > One of my pet peeves is the 'fast patch' which takes the easy > approach and then > needs to get fixed up later to do the properly thing. > > IMO, what proper means in this context is command line option to > switch between > iso and non iso display. Then we need 2 skins for the client. One for iso, one for flat. But thats not hard. Remember that even the editor handles booth mode. And you can change at runtime and for every part. From dnh at hawthorn.csse.monash.edu.au Sat Jun 9 21:46:45 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Future of maps. In-Reply-To: <3B22BE94.B4243A33@scruz.net> Message-ID: I am interested in this auto join feature? will it auto join monsters/items? Will the AI run with the monsters on another map? might this cause problems? For example, if the ai is working, then all the monsters will walk to the edge of the map, but for some magical reason they can't cross it.. =) dnh From andi.vogl at gmx.net Sun Jun 10 07:19:26 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Iso CF start phase In-Reply-To: <3B2298EB.7302293A@scruz.net> Message-ID: Mark W. wrote: > > I will now start to setup the arch, maps and server to ISO cf. > > The Editor is ready for it. > > > > ** PLEASE don't touch the CVS until i do the release today or next day** > > > > I will use the CVS snapshot to do the client/server changes. > > Because the script engine will included and i will make a windows > > server/binary (with guile script) i will make some changes. > > I strongly disagree that CVS should be frozen for other updates in pretty > much all cases. Look, he didn't demand a freeze, he just politely asked to wait one single day before doing big checkins. > > [...] > > I will setup the arch and maps in a way, we must touch every pieces to > > transfer it to iso. The editor will have some commands to automate this, > > for example a find & replace thing. > > I'm unclear what exactly this means. > > Non ISO support MUST REMAIN. (or not, but if overhead view goes away, so > might I). I really really really dislike iso views for most games. Yes, > it looks nicer, but I find the playing of it a PITA. [...] I just wanted to say that I am very excited about the work Michael is doing here. Sometimes I wish his work would get a little more appreciation. I personally believe that iso-view is great and worth going for - As it evens the way to smooth gameplay with tiles being almost not noticeable (for example). All the great games like Starcraft, Diablo, Baldur's Gate etc, they all use iso for good reason. On the other hand, of course, I am also very grateful for the incredible amount of time and work that Mark is donating to the CF project. The CF project can only rise and shine as long as the dev-team is a team ;-) When I look at the Angband project (another roguelike), there's an "angband", "bangband", "cangband", ..., "zangband" - And all are split-offs from a formerly single project. I hope this will never happen to CF. Andreas V. From andi.vogl at gmx.net Sun Jun 10 07:53:20 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Future of maps. In-Reply-To: <3B22BE94.B4243A33@scruz.net> Message-ID: Mark W. wrote: > Regardless of what is need to be done with ISO, the current state of maps > needs to be updated. I agree, oh yes. > The solution for this, which I plan to work on soon, is to implement > automatic map tiling. [...] > > With that, it should be easier to make very large autojoin continents. > There are really 3 possible future directions: > > 1) Keep outdoor continent basically the way it is, just use autojoining. > 2) Go to an indoor/outdoor scale. [...] Cities would not appear as the > little images you enter, but instead by placed on the world maps. > [...] But the shops, caves, towers, etc, would still be buildings you > enter from this. > 3) Go to unified scale. Take #2 above, and increase the scale another > order of magnitude or two. In this mode, everything is the same scale. > I definitly vote for #2. #1 means the continents (worldmaps) are just plain boring (like they are now). Travelling is short, but still so pointless that people want teleporters in their apartments. The continents don't have any serious "structure". The worldmap is just a big bunch of linked exits. The sole advantage of this concept is the simplicity of design. #3 is in my opinion an overdue. We might get the opposite problem: Lack of detail due to the incredible size of maps. Huge roads and buildings, a player must walk about hundred squares only to get from the magic store to the weapon store. Not to speak of the immense work to create maps like that. #2 seems perfect since only the worldmaps need to get redone (not the cities). And the worldmaps are in bad need for a redo anyways. :) We would need to introduce a set of blocking worldmap tiles (mountains, dense forest, etc) to get a "structure" into the new, scaled-up worldmaps. Basically like walls in dungeons. Another issue is monster generation/control, but it could be handled just like in dungeons. Having that set, the worldmaps act pretty much like dungeons and provide some adventure for travellers. Reaching certain places might require a certain character level - That is terrific IMHO. Andreas V. From dnh at hawthorn.csse.monash.edu.au Sun Jun 10 08:32:22 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Iso CF start phase In-Reply-To: Message-ID: Hmm yeah I somewhat agree with AV here. Firstly Mich does spend alot of time working on these projects and while we may not ALL agree with everything. I think we all share a responsebility to assist and help other members. In regards to the world map, I to agree with #2 for pretty much the same reasons as AV. I really wanna see this premap loading stuff Mark >=). While on the topic I always like the idea of random wandering monsters around the world map.. what do you think... ? In regards to splitting, crossfire is always splitting and reforming. We split of the image libs, we split over ISO and it certainly doesn't surprise me that we might differ over many many things to come. That is a good thing. If everyone just agreed with everything the quality would probably drop. People have to prove their ideas, not just say em. I will put in that Mich has certainly shown us a thing or too and Mark doesn't cease to amaze me with new lighting and client features. ps. Mark.. njh's is getting somewhere with this binary tree based fog of war stuff. I don't invisage crossfire every going to the extremes of Angband though, and it would certainly be a sad day if it did. Keep up the good work guys >=) dnh On Sun, 10 Jun 2001, Andreas Vogl wrote: > Mark W. wrote: > > > > I will now start to setup the arch, maps and server to ISO cf. > > > The Editor is ready for it. > > > > > > ** PLEASE don't touch the CVS until i do the release today or next day** > > > > > > I will use the CVS snapshot to do the client/server changes. > > > Because the script engine will included and i will make a windows > > > server/binary (with guile script) i will make some changes. > > > > I strongly disagree that CVS should be frozen for other updates in pretty > > much all cases. > > Look, he didn't demand a freeze, he just politely asked to wait one single > day before doing big checkins. > > > > [...] > > > I will setup the arch and maps in a way, we must touch every pieces to > > > transfer it to iso. The editor will have some commands to automate this, > > > for example a find & replace thing. > > > > I'm unclear what exactly this means. > > > > Non ISO support MUST REMAIN. (or not, but if overhead view goes away, so > > might I). I really really really dislike iso views for most games. Yes, > > it looks nicer, but I find the playing of it a PITA. [...] > > I just wanted to say that I am very excited about the work Michael is > doing here. Sometimes I wish his work would get a little more appreciation. > I personally believe that iso-view is great and worth going for - As > it evens the way to smooth gameplay with tiles being almost not noticeable > (for example). All the great games like Starcraft, Diablo, Baldur's Gate > etc, > they all use iso for good reason. > > On the other hand, of course, I am also very grateful for the incredible > amount of time and work that Mark is donating to the CF project. > The CF project can only rise and shine as long as the dev-team is a team ;-) > > When I look at the Angband project (another roguelike), there's an > "angband", "bangband", "cangband", ..., "zangband" - And all are split-offs > from a formerly single project. I hope this will never happen to CF. > > > Andreas V. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From reeve at ductape.net Sun Jun 10 11:46:58 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:15 2005 Subject: [CF-Devel] Alchemy Suggestion Message-ID: <20010610124658.A20247@terra.localnet> I have an idea on how alchemy could be made more useful. First, add an item (for instance, an empty bottle) that could be like a one time use cauldron that the player could carry around, then formulae could be added for things like making bombs or raising corpses into zombie "pets". I think it would be a fun addition to the game, not really unbalancing, and would alchemy a much more useful feature. So, what do you think? -- -- -- Reeve the cat ----BEGIN FORTUNE---- It's easy to solve the halting problem with a shotgun. :-) -- Larry Wall in <199801151836.KAA14656@wall.org> ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From yann.chachkoff at mailandnews.com Sun Jun 10 19:52:23 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Hot projects Message-ID: <01061020522300.01580@Terminus.magellan.fpms.ac.be> I - About Scripts ------------ >>?3.) Scripting: Scriptfire >>? >>?Scripting is so great and gros scriptfire works fine. >>?This will give us the chance to include this from bottom up. >>?MW will put it in CVS, so we can use it in all versions. >?I said it should probably be put it, but didn't actually volunteer myself > to do it ?Gros - do you think it is ready for inclusion? No big problems have been encountered on the MiDS test server, so I think it should be ready for inclusion into the official Crossfire server. I'll post the latest revision (b11) Monday 10th before 8:00PM (GMT+2 time) with a simple sample quest. Feel free to include it into CVS (as a side effect, if scripts are included into main CVS stream, people will start to play with it, bugs will be quicker to find). II - About MT's work --------------- > I just wanted to say that I am very excited about the work Michael is > doing here. Sometimes I wish his work would get a little more appreciation. That's true. So I say it: I find Michael's work great. > I personally believe that iso-view is great and worth going for - As > it evens the way to smooth gameplay with tiles being almost not noticeable > (for example). All the great games like Starcraft, Diablo, Baldur's Gate > etc, they all use iso for good reason. Yes, iso-view would be great. Of course,it causes some problems, as any new stuff. But it is not a sufficient reason to continue to ignore iso-view. Yes, it'll need work. But the results will be worth doing it. Chachkoff Y. From mwedel at scruz.net Sun Jun 10 16:20:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Future of maps. References: Message-ID: <3B23E4A6.69F2F3E2@scruz.net> dnh wrote: > > I am interested in this auto join feature? will it auto join > monsters/items? Will the AI run with the monsters on another map? > might this cause problems? For example, if the ai is working, then all the > monsters will walk to the edge of the map, but for some magical reason > they can't cross it.. =) The maps will be autojoined, but the way I see doing it, everything on the maps won't see the joining - ie, 4 autojoined maps will effectively appear as just one large map. This means that monsters can run accross it, arrows fly accross the boundaries, dimension door would do the right thing, etc. I am sure there will be lots of bugs. Just thinking about it, monster logic uses the coordinates to find distances, and that probably won't work right if players are on different maps. And in fact, a lot of things that check for map would need to be redone (for example, checking to see if object is on the same map is pretty vague in such a case - if two characters are on the tiled maps standing at the edge, they would be considered on different maps, but for everything else, should be able to interact properly. Probably everything that looks at the map or x,y values would need to be re-examined in the code. > #1 means the continents (worldmaps) are just plain boring (like they > are now). Travelling is short, but still so pointless that people want > teleporters in their apartments. The continents don't have any serious > "structure". The worldmap is just a big bunch of linked exits. > The sole advantage of this concept is the simplicity of design. I'm thinking more with scale than implementation. If map tiling is added, the linking of exits could be removed. But you still have the problem of a pretty small and pretty congested area. > > #3 is in my opinion an overdue. We might get the opposite problem: > Lack of detail due to the incredible size of maps. Huge roads > and buildings, a player must walk about hundred squares only to get > from the magic store to the weapon store. > Not to speak of the immense work to create maps like that. Yes - its a lot of work. Movement speed would be much more important, as otherwise journeys could really drag on. And I'm not really sure how much it helps in the wilderness. While everything is farther apart, the stuff you do find is bigger - ie, the tower of demonology, at least the first floor, would be something like a 30x30 area on the map, so you only need to get somewhat close. > > #2 seems perfect since only the worldmaps need to get redone (not > the cities). And the worldmaps are in bad need for a redo anyways. :) The hard part in basically all the proposals is fixing all the exits. It isn't hard work, just a lot of it. Some scripts could probably be written to automate that pretty easily (city 5,5 is now world_g3 12,12, and it could apply similar offsets for most everything else). And of course broken exits would get discovered quite quickly. > > We would need to introduce a set of blocking worldmap tiles (mountains, > dense forest, etc) to get a "structure" into the new, scaled-up worldmaps. > Basically like walls in dungeons. Another issue is monster > generation/control, but it could be handled just like in dungeons. Note this already exists (some mountains do block view, as do jungle spaces). IMO what would be cooler than absolute blockage would be incremental blockage of some sort. Ie, you can't see through a 10 deep thick forest, but could through perhaps a 2-3 deep forest (maybe it blocks absolute at say 5 spaces). This could probably borrow from the darkness code in some sense. Thus could of course get extended to other effects. Rain may add a blocking factor of .2/space, so you can only see 5 spaces along a clear road in the rain, but only 2-3 (really 2.5) spaces through the forest when its raining. > Having that set, the worldmaps act pretty much like dungeons and > provide some adventure for travellers. Reaching certain places might > require a certain character level - That is terrific IMHO. on the todo list is the idea of spontaneous monster creation without generators. Ie, a forest space has some % chance of generate a forest_creature. I'm sure that could get optimized such that you wouldn't need to have all the forest spaces have speed - instead, in the map object itself (internal), it could tally number of each time of space and just store that in the map object, and periodically generate from that or the like. Some thing would generate nastier creatures - mountains/badlands could generate stuff nasty enough to be a dangerous for low level people (say like wyverns or hill giants from the hills) - if your travelling through a lot of hills, you may run into one, or you may be lucky and not. This could effectively block some areas from low level people. From mwedel at scruz.net Sun Jun 10 16:44:20 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Iso CF start phase References: Message-ID: <3B23EA34.1E31275D@scruz.net> A few clarifications/thoughts. I realized after I sent my last message it may be taken in the wrong way (ie, my leaving crossfire). What I really meant to say in that is that if crossfire evolves into a game that I don't want to play (only isomorphic view), then its a pretty sure bet that I won't develope for it anymore. I also just wanted to make it clear that IMO non isomorphic view should continue to be supported. If nothing else because I think it is going to take quite a while for the isomorphic view to get completed (in terms of maps and images). This is from prior experience on crossfire. Now I may be wrong about this - it wouldn't be the first time I am wrong about something. Note that MT never said that the overhead view was going away. I just want to hopefully be clear that his changes do not remove that support for 'traditional' play. Re CVS freeze (or non checkin - amounts to the same thing): Now its only my opinion, but IMO I just don't think its good for development. Part of CVS is anyone being able to do updates at most any time. And that said, the normal cvs process is: 1) cvs update 2) make changes 3) cvs commit - if you have modified files that are not current in CVS, cvs won't let you commit them, so continue on to step 4 below - if other people have modified files that you have no modified, no problem 4) cvs update old files 5) may or may not need to do hand merging 6) compile, run quick test (quick test may not be much more than verify it does compile and runs, presuming that more thorough testing was done before) 7) cvs commit again. Now to me, the idea of making a 'non commit except for me' phase is that its basically saying the other guy should do steps 4-7 and not me. I just don't think thats good for a community project. As a coder, it basically says to me that perhaps I should wait before starting any changes, otherwise I'll most definately have to do step 4-7 because someone else is doing a big check in, even if my changes may be smaller and I could get them done before that other checkin is done. But if we agree its OK (which it sounds like we do), then I'll start using it in the future also (like when I start on the map tiling). Not having to do steps 4-7 will probably save me some amount of work. Now perhaps MT overstated the amount of freeze really needed, but from the message: ** PLEASE don't touch the CVS until i do the release today or next day** This suggest to me that no change no matter how small should be made to CVS. As said, if we agree that developers can 'freeze' cvs for times while they work on big projects, I can live with that. I just wanted to state that I think that will be bad for development in the long run - especially if it starts to get overused. From mwedel at scruz.net Sun Jun 10 16:54:47 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Iso CF start phase References: Message-ID: <3B23ECA7.FC5D2C19@scruz.net> Michael Toennies wrote: > The editor collect 100% compatible scripts. > The bad thing is that you need to load all - well, when packed later, this > need only seconds. > The good thing is the strong control. That is of course one reason why all the images and archetypes get packed into a single file - load time is much much faster. > I don't think people will create arches like wild when the arch editor is > out (and this will > need some time, i don't have it on priority list). For this, the whole > action is to hard, setting > up all the stuff. This of course is hard to predict. Even with people having to hand create archetypes right now, there are probably quite a few that should not exist simply because people did not realize they could just make the changes in the maps. If a front end tool is provided, you may get more people creating archetypes simply because its easier. But this isn't really a big deal - for it to make any real difference, they would still need to get committed to CVS, and presumably the people with CVS would have the knowledge to say whether that should really get be a new arch or just an in map modification. > Well, thats the old discussion. The maps will not be compatible - and should > not. > I mean the look of course - not the logic (mashines, quests). > > This is a clear point i think? Why we are using iso? Because it give us > other option > for the look. So, thinking the old maps can be transformed, is childish. I think some of my confusion here is terminology. I think you really want to be saying images here, and not maps? If maps are not compatible, that means that game is not compatible. I certainly understand that the images will not be compatible. > The bad point is, that we will split dev power. > > Btw: showing ISO maps flat is much better. > > Bad thing is , that you have to draw new or special monsters. > Iso multi monsters don't need so much place like flat ones. > Well, this only effect a few monsters, 90% will be untouched i think. > > For this, it is possible to do create new flat monsters. I certainly don't mind one image display mode looking nicer than the other. Thats pretty much expected. I just want overhead view support to remain. And I won't disagree that iso generally looks nicer. I just don't find the gameplay as nice, and thats what I really care about for my playing. nice graphics will grab a player, but the look of the graphics doesn't last really long - in the end it is gameplay which determines how good the game really is. > > You haven't understand this mark. > MAP LOGIC is not touched! > And i will include a replace system . As said, I think it is because you were using the word 'map' too many places, which is what created confusion. > > Working over a map, changing style and look is not the big work. > Thats a "eye work" not a "brain work". > Setting up the logic, connection and game play - thats was hard in maps. eye work still equals time. I know that making maps generally isn't mentally hard, but just takes a bit of time to do right. Unless we can get a lot of developers to start working on maps, I just think it will take quite a while. > Then we need 2 skins for the client. > One for iso, one for flat. > > But thats not hard. > > Remember that even the editor handles booth mode. And you can change at > runtime and for every part. Yeah, thats fine. Being able to change it on the fly in the editor could actually be pretty cool also (of course, there are problems with image sets and so on that make it harder). but even if it was seperate clients, that works for me. From lusena at cs.uky.edu Sun Jun 10 15:16:31 2001 From: lusena at cs.uky.edu (Chris Lusena) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Alchemy Suggestion In-Reply-To: <20010610124658.A20247@terra.localnet>; from reeve@ductape.net on Sun, Jun 10, 2001 at 12:46:58PM -0400 References: <20010610124658.A20247@terra.localnet> Message-ID: <20010610161631.A8988@mars.cs.engr.uky.edu> On Sun, Jun 10, 2001 at 12:46:58PM -0400, Scott Barnes wrote: > I have an idea on how alchemy could be made more useful. First, add an > item (for instance, an empty bottle) that could be like a one time use > cauldron that the player could carry around, then formulae could be added > for things like making bombs or raising corpses into zombie "pets". I > think it would be a fun addition to the game, not really unbalancing, and > would alchemy a much more useful feature. So, what do you think? Alchemy used to be very useful. One of the best money makers in the game once you knew how. How, ever since .98 or so with drop in value of a block of true lead 1/10 it's previous value and cost ingredients going up, it is much less useful until you get sufficient level to produce the really hard stuff. Note that you can still make money a little if you engage in the right sort of scavenger hunts for ingredients. But I think that now its not worth ones time unless you have very high charisma for buy/selling purposes. There are already those sort of recipes out there but you have to be > lv 20 or 30 ment. before they start being practical. Well you can get golem like things not pets. But I find golems much more useful than pets. In any case you also do get exp I think for killing stuff with alchemy tools thus making them less desirable as well. If you did get exp. that would increase alchemy usefulness too. -- Chris Lusena Office: 762 AH Department of Computer Science Phone: 859-257-3678 773 Anderson Hall Fax: 859-323-1971 University of Kentucky Email: lusena@cs.uky.edu Lexington, KY 40506-0046 U.S.A. http://www.cs.uky.edu/~lusena From michael.toennies at nord-com.net Sun Jun 10 18:48:29 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Iso CF start phase In-Reply-To: <3B23EA34.1E31275D@scruz.net> Message-ID: Only a shot note to this (i am hard on work on iso). true to booth here: - Overlook will not go away as long people support it. Ther will be differences in map sets, thats the worst one, but perhaps this can be reworked (that the iso maps will be used for flat). this is needed, because from (ok my) technical point it is better to see flat as downcasted iso and not iso as a boosted flat perspective. Iso has more tricks in it. But the discussion goes in a worng way: We don't talk about Diablo gfx. Ok, from some points, it is same, but our CF iso is more a hybrid, a not so die hard iso style with not so extreme views. Think more about it in a boosted flat mode, which will hopefully be liked from most people - hopefully Mark too. :) - There will be no game play change or server differences I strongly look in this. Changing the dx client to iso is done in 12 lines different code. - the CVS freeze: i do some strong cuts in maps, arches and clients. Its hard to make this without mistakes and so on. Also, i must rework the windows server (is broken trough some changes to source) and include the scripts in it (need much libs) and drop out a binary. I really only want a "hold on folks, here comes a bunch of code and work". > > A few clarifications/thoughts. > > I realized after I sent my last message it may be taken in the > wrong way (ie, > my leaving crossfire). What I really meant to say in that is > that if crossfire > evolves into a game that I don't want to play (only isomorphic > view), then its a > pretty sure bet that I won't develope for it anymore. > > I also just wanted to make it clear that IMO non isomorphic view should > continue to be supported. If nothing else because I think it is > going to take > quite a while for the isomorphic view to get completed (in terms > of maps and > images). This is from prior experience on crossfire. Now I may > be wrong about > this - it wouldn't be the first time I am wrong about something. > > Note that MT never said that the overhead view was going away. > I just want to > hopefully be clear that his changes do not remove that support > for 'traditional' > play. > > Re CVS freeze (or non checkin - amounts to the same thing): > Now its only my opinion, but IMO I just don't think its good for > development. > Part of CVS is anyone being able to do updates at most any time. > > And that said, the normal cvs process is: > > 1) cvs update > 2) make changes > 3) cvs commit - if you have modified files that are not current > in CVS, cvs > won't let you commit them, so continue on to step 4 below - if > other people have > modified files that you have no modified, no problem > 4) cvs update old files > 5) may or may not need to do hand merging > 6) compile, run quick test (quick test may not be much more than > verify it does > compile and runs, presuming that more thorough testing was done before) > 7) cvs commit again. > > Now to me, the idea of making a 'non commit except for me' phase > is that its > basically saying the other guy should do steps 4-7 and not me. I > just don't > think thats good for a community project. As a coder, it > basically says to me > that perhaps I should wait before starting any changes, otherwise > I'll most > definately have to do step 4-7 because someone else is doing a > big check in, > even if my changes may be smaller and I could get them done > before that other > checkin is done. > > But if we agree its OK (which it sounds like we do), then I'll > start using it in > the future also (like when I start on the map tiling). Not > having to do steps > 4-7 will probably save me some amount of work. > > Now perhaps MT overstated the amount of freeze really needed, > but from the > message: > ** PLEASE don't touch the CVS until i do the release today or next day** > > This suggest to me that no change no matter how small should be > made to CVS. > > As said, if we agree that developers can 'freeze' cvs for times > while they work > on big projects, I can live with that. I just wanted to state > that I think that > will be bad for development in the long run - especially if it > starts to get > overused. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Sun Jun 10 19:07:09 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Iso CF start phase In-Reply-To: <3B23ECA7.FC5D2C19@scruz.net> Message-ID: The change in maps can be shown in a good example: the demon lords! In Iso, a demon lord will be a little smaller (through the iso looking, he will look big too). This means, i had for iso maps to rework the maps with demon lords and change it to "iso demon lord". This is the big "umpf". In the first step, flat and iso maps will be not compatible because booth arche sets are then different. But i have a plan for this which should finally make it campatible again. Because we got so many nice gfx from other artist (iso style), i had fast included a nice new arch set. There is no usable way to hold this compatible (in ground, floor or wall sets). Really not, in the old maps and the old sets are too much assembled (and really bad looking) artwork in. Let do it in this way: We include the new tile (they look great) in the iso set and rework the maps in a more intelligent way. Better TYPES, intelligent layers - all the stuff we want include in the past! Lets use the Iso set for this! We rework it from cratch, so we can try here some out! The flat crew then graps the tested parts and include it in the normal arches too. Also, they can slowly redraw or collect tile. Also, the few monster, which had changed in multi tile size (thats not so many!), can be changed too in usable flat ones. At the end, both should meet workable and both set will profite from others (the flat more from iso i think). Because scripting is SO powerful you WILL change many maps. Well, perhaps you people don't want this. I will release the iso stuff and then we all can look. Other changes are topics for booth sets! One is for example, to include 8 way direction moving. This is really not the new part. Look in the docs, it was a old topic in the game and even the picture logic depend on it. But its dropped for some reason (btw: you remember why mark? not enough pictures or so? I always had hate, that you can't see your sw, se,nw and ne direction on map... Don't want remember how often i die after crushing a spell in the false direction...). Michael > Michael Toennies wrote: > > > The editor collect 100% compatible scripts. > > The bad thing is that you need to load all - well, when packed > later, this > > need only seconds. > > The good thing is the strong control. > > That is of course one reason why all the images and archetypes > get packed into > a single file - load time is much much faster. > > > > I don't think people will create arches like wild when the arch > editor is > > out (and this will > > need some time, i don't have it on priority list). For this, the whole > > action is to hard, setting > > up all the stuff. > > This of course is hard to predict. Even with people having to > hand create > archetypes right now, there are probably quite a few that should not exist > simply because people did not realize they could just make the > changes in the > maps. If a front end tool is provided, you may get more people creating > archetypes simply because its easier. But this isn't really a > big deal - for it > to make any real difference, they would still need to get > committed to CVS, and > presumably the people with CVS would have the knowledge to say > whether that > should really get be a new arch or just an in map modification. > > > > > Well, thats the old discussion. The maps will not be compatible > - and should > > not. > > I mean the look of course - not the logic (mashines, quests). > > > > This is a clear point i think? Why we are using iso? Because it give us > > other option > > for the look. So, thinking the old maps can be transformed, is childish. > > I think some of my confusion here is terminology. I think you > really want to > be saying images here, and not maps? If maps are not compatible, > that means > that game is not compatible. I certainly understand that the > images will not be > compatible. > > > > The bad point is, that we will split dev power. > > > > Btw: showing ISO maps flat is much better. > > > > Bad thing is , that you have to draw new or special monsters. > > Iso multi monsters don't need so much place like flat ones. > > Well, this only effect a few monsters, 90% will be untouched i think. > > > > For this, it is possible to do create new flat monsters. > > I certainly don't mind one image display mode looking nicer than > the other. > Thats pretty much expected. I just want overhead view support to remain. > > And I won't disagree that iso generally looks nicer. I just > don't find the > gameplay as nice, and thats what I really care about for my playing. nice > graphics will grab a player, but the look of the graphics doesn't > last really > long - in the end it is gameplay which determines how good the > game really is. > > > > > > You haven't understand this mark. > > MAP LOGIC is not touched! > > And i will include a replace system . > > As said, I think it is because you were using the word 'map' too > many places, > which is what created confusion. > > > > > Working over a map, changing style and look is not the big work. > > Thats a "eye work" not a "brain work". > > Setting up the logic, connection and game play - thats was hard in maps. > > eye work still equals time. I know that making maps generally > isn't mentally > hard, but just takes a bit of time to do right. Unless we can > get a lot of > developers to start working on maps, I just think it will take > quite a while. > > > > Then we need 2 skins for the client. > > One for iso, one for flat. > > > > But thats not hard. > > > > Remember that even the editor handles booth mode. And you can change at > > runtime and for every part. > > Yeah, thats fine. Being able to change it on the fly in the editor could > actually be pretty cool also (of course, there are problems with > image sets and > so on that make it harder). but even if it was seperate clients, > that works for > me. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Sun Jun 10 20:17:45 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Iso CF start phase References: Message-ID: <3B241C39.940FE37C@scruz.net> Michael Toennies wrote: > > The change in maps can be shown in a good example: > the demon lords! > In Iso, a demon lord will be a little smaller (through the iso looking, he > will > look big too). This means, i had for iso maps to rework the maps with demon > lords > and change it to "iso demon lord". > > This is the big "umpf". In the first step, flat and iso maps will be not > compatible > because booth arche sets are then different. I take it what you mean by this is that monsters will have a 'foot print', but their height will just be controlled by the images? Ie, take the hill giant, currently a 2 space high monster. In your change, his footprint will only be once space, but effectively he would be 64 pixels high (thinking flat here- I know the iso uses some different scaling there). If so, this should also work with overhead, just the results would be uglier (and client redraw would need to be able to handle taller images). This does change the dynamics of maps and monsters however. Many multi space monsters right now may take fewer spaces - this effectively means that are more spell resistant (ie, when hit by a fireball, they have fewer spaces, and thus won't take as much damage as they did before). And in the case of the hill giants above, it means taht if you have a 2 high east/west passage, it now means that 2 hill giants could attack you, and not just one. Is chaning the size/footprint a bad thing? Not necessarily - I'm just stating some of the other effects this will have, which will mean many maps and monsters may need to get rebalanced. > Well, perhaps you people don't want this. I will release the iso stuff and > then we all can > look. What people want and what can realistically be done are two completely different things of course. I would probably say that most everyone would agree that making the maps cooler/better is a good thing. It only takes 1 minute to agree to something. It takes a lot more time to actually have it get done. That is one reason that it is typically better to try to take things in steps than re-work everything at once. With steps, you see incremental progress, and even if it only gets half done, it means that half of the work that was done was useful. Compared to it being an all or nothing. If it gets half done and never completed for whatever reason, that work is wasted. Is this a good way to write software? Perhaps not. But until I see that there are resources to do a major overhaul at all once, it is probably the easier thing to do. Look at the TODO list for a list of things that at one point were thought to be good things to do. There is no shortage of of ideas, but there is a shortage of people to do the work. > One is for example, to include 8 way direction moving. This is really not > the new part. > Look in the docs, it was a old topic in the game and even the picture logic > depend on it. > But its dropped for some reason (btw: you remember why mark? not enough > pictures or so? I always > had hate, that you can't see your sw, se,nw and ne direction on map... Don't > want remember how often > i die after crushing a spell in the false direction...). Just to be clear - what you are talking about here is 8 direction animation, not actual moving. You can of course move all 8 directions currently. Probably lack of images or making images distinct enough to see the different directions. Putting in support for this should only be a matter of making the images and updating the archs. Some creatures (like the fireborn) of course don't have images that lend themselves good to the different direction. And even for many of the humanoids, I'm not positive with N vs NE vs E would look like (or at least how distinctive it really would be). From dnh at hawthorn.csse.monash.edu.au Sun Jun 10 20:18:09 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:16 2005 Subject: [CF-Devel] Alchemy Suggestion In-Reply-To: <20010610124658.A20247@terra.localnet> Message-ID: This sounds like a nice idea, can you code it? dnh On Sun, 10 Jun 2001, Scott Barnes wrote: > I have an idea on how alchemy could be made more useful. First, add an > item (for instance, an empty bottle) that could be like a one time use > cauldron that the player could carry around, then formulae could be added > for things like making bombs or raising corpses into zombie "pets". I > think it would be a fun addition to the game, not really unbalancing, and > would alchemy a much more useful feature. So, what do you think? > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > It's easy to solve the halting problem with a shotgun. :-) > -- Larry Wall in <199801151836.KAA14656@wall.org> > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From yann.chachkoff at mailandnews.com Mon Jun 11 11:24:51 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:17 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 Message-ID: <01061112245100.01739@Terminus.magellan.fpms.ac.be> This is the latest revision of Crossfire Scripting Extensions. What's new from b10 ? - Event-handling functions completely rewritten (much more simple). - Various bugfixes in death and attack handling. - Preliminary support for multithreaded scripts using the pthread library (very early development stage for now). - Some minor modifications in crossfire-message function (now allows an optional color arg). - New crossfire-write function. - The error-handling code should now be able to compile under Win32. What is planned for b12 ? - New script event triggered for armours whenever the wearer is being attacked; - Basic multithread capabilities for asynchronous script execution; - Character controller modification by scripts. Those were initially planned for b11 release, but were too unstable or too less tested to be included now. The b11 release may be now stable and complete enough to be included into the main CVS tree. See the README_SCRIPT file for details on how to create your own scripts. A special scripted quest will soon be available (be patient !) Feel free to send suggestions, bug reports and other things. Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b11.bz2 Type: application/x-bzip2 Size: 73113 bytes Desc: Crossfire Scripting Extension Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/65988a4a/patch-scriptfire-1.0.0b11.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b11.tar.bz2 Type: application/x-bzip2 Size: 16619 bytes Desc: Latest Sample Maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/65988a4a/scriptfire-maps-1.0.0b11.tar.bin From yann.chachkoff at mailandnews.com Mon Jun 11 12:12:42 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:17 2005 Subject: [CF-Devel] Fwd: Crossfire Scripting Extension, version 1.0.0b11 Message-ID: <01061113124200.03077@Terminus.magellan.fpms.ac.be> ---------- Message transmis ---------- Subject: Crossfire Scripting Extension, version 1.0.0b11 Date: Mon, 11 Jun 2001 12:24:51 -0400 From: gros To: crossfire-devel@lists.real-time.com This is the latest revision of Crossfire Scripting Extensions. What's new from b10 ? - Event-handling functions completely rewritten (much more simple). - Various bugfixes in death and attack handling. - Preliminary support for multithreaded scripts using the pthread library (very early development stage for now). - Some minor modifications in crossfire-message function (now allows an optional color arg). - New crossfire-write function. - The error-handling code should now be able to compile under Win32. What is planned for b12 ? - New script event triggered for armours whenever the wearer is being attacked; - Basic multithread capabilities for asynchronous script execution; - Character controller modification by scripts. Those were initially planned for b11 release, but were too unstable or too less tested to be included now. The b11 release may be now stable and complete enough to be included into the main CVS tree. See the README_SCRIPT file for details on how to create your own scripts. A special scripted quest will soon be available (be patient !) Feel free to send suggestions, bug reports and other things. Chachkoff Y. ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b11.bz2 Type: application/x-bzip2 Size: 73113 bytes Desc: Crossfire Scripting Extension Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/4b40bbab/patch-scriptfire-1.0.0b11.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b11.tar.bz2 Type: application/x-bzip2 Size: 16619 bytes Desc: Latest Sample Maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/4b40bbab/scriptfire-maps-1.0.0b11.tar.bin From yann.chachkoff at mailandnews.com Mon Jun 11 12:14:18 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:17 2005 Subject: [CF-Devel] Fwd: Crossfire Scripting Extension, version 1.0.0b11 Message-ID: <01061113141801.03077@Terminus.magellan.fpms.ac.be> ---------- Message transmis ---------- Subject: Crossfire Scripting Extension, version 1.0.0b11 Date: Mon, 11 Jun 2001 12:24:51 -0400 From: gros To: crossfire-devel@lists.real-time.com This is the latest revision of Crossfire Scripting Extensions. What's new from b10 ? - Event-handling functions completely rewritten (much more simple). - Various bugfixes in death and attack handling. - Preliminary support for multithreaded scripts using the pthread library (very early development stage for now). - Some minor modifications in crossfire-message function (now allows an optional color arg). - New crossfire-write function. - The error-handling code should now be able to compile under Win32. What is planned for b12 ? - New script event triggered for armours whenever the wearer is being attacked; - Basic multithread capabilities for asynchronous script execution; - Character controller modification by scripts. Those were initially planned for b11 release, but were too unstable or too less tested to be included now. The b11 release may be now stable and complete enough to be included into the main CVS tree. See the README_SCRIPT file for details on how to create your own scripts. A special scripted quest will soon be available (be patient !) Feel free to send suggestions, bug reports and other things. Chachkoff Y. ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b11.bz2 Type: application/x-bzip2 Size: 73113 bytes Desc: Crossfire Scripting Extension Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/9bba138e/patch-scriptfire-1.0.0b11.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b11.tar.bz2 Type: application/x-bzip2 Size: 16619 bytes Desc: Latest Sample Maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/9bba138e/scriptfire-maps-1.0.0b11.tar.bin From chachkoffyann at usa.net Mon Jun 11 06:11:59 2001 From: chachkoffyann at usa.net (Yann Chachkoff) Date: Thu Jan 13 18:01:17 2005 Subject: [CF-Devel] Crossfire Scripting Extensions, version b11 Message-ID: <20010611111159.23350.qmail@nwcst338.netaddress.usa.net> This is the latest revision of scriptfire extensions (seems that the previous post didn't worked). ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b11.bz2 Type: application/octet-stream Size: 73113 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/e56a5008/patch-scriptfire-1.0.0b11.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b11.tar.bz2 Type: application/octet-stream Size: 16619 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010611/e56a5008/scriptfire-maps-1.0.0b11.tar.obj From michael.toennies at nord-com.net Mon Jun 11 13:28:16 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Include Scriptfire in CVS - first step Message-ID: Scriptfire depends yet on 1.0.0. To include it in current CVS and make it win32 compatible, we need a little work. I need first to change a define in CVS source. The define HANDLE is in CVS a map/arch type like GATE or BUTTON. In win32 thread libs, HANDLE is a system define. Because scriptfire use now pthread.lib, i must change the define. I'll change HANDLE to CF_HANDLE. It effects only a few modules. I make this change before i include scriptfire. From jbontje at suespammers.org Mon Jun 11 18:05:17 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Include Scriptfire in CVS - first step In-Reply-To: References: Message-ID: <20010612010517.A315@mids.student.utwente.nl> On Mon, Jun 11, 2001 at 08:28:16PM +0200, Michael Toennies wrote: > Scriptfire depends yet on 1.0.0. > To include it in current CVS and make it win32 compatible, we > need a little work. Would you PLEASE do what Mark has asked all of us about CVS? If you commit something, add the following information in the message: - description + why you did it - your name - the date Maybe I forgot some more important things, but it really helps if you include this. Joris Bontje / mids From leaf at real-time.com Mon Jun 11 18:13:55 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Include Scriptfire in CVS - first step In-Reply-To: <20010612010517.A315@mids.student.utwente.nl> Message-ID: As a reference.. http://crossfire.real-time.com/CVS/cvs_checkin.html - Rick Tanner leaf@real-time.com On Tue, 12 Jun 2001, Joris Bontje wrote: > Would you PLEASE do what Mark has asked all of us about CVS? > If you commit something, add the following information in the message: > - description + why you did it > - your name > - the date > > Maybe I forgot some more important things, but it really helps if you include this. > > Joris Bontje / mids From dnh at hawthorn.csse.monash.edu.au Mon Jun 11 22:29:52 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Include Scriptfire in CVS - first step In-Reply-To: <20010612010517.A315@mids.student.utwente.nl> Message-ID: Agreed dnh On Tue, 12 Jun 2001, Joris Bontje wrote: > On Mon, Jun 11, 2001 at 08:28:16PM +0200, Michael Toennies wrote: > > Scriptfire depends yet on 1.0.0. > > To include it in current CVS and make it win32 compatible, we > > need a little work. > > Would you PLEASE do what Mark has asked all of us about CVS? > If you commit something, add the following information in the message: > - description + why you did it > - your name > - the date > > Maybe I forgot some more important things, but it really helps if you include this. > > Joris Bontje / mids > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Mon Jun 11 22:33:29 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] ISO Test release Message-ID: I drop the first iso test release. All stuff is here. http://mids.student.utwente.nl/~michtoen/ISO_stuff All is just in work. All is working and usable but not playable. I don't had transformed maps yet, just a demo map... but this looks great. Also, the player char moves in 8 directions. Iso Client ----------- You need the cfdx125iso.exe DirectX client to see the stuff. Linux will come. ISo server ---------- You must get the newest CVS release and enable the ENABLE_PLAYER_8_DIRECTION option in config.h. To setup a server, download serverdata.zip and copy it over the stuff same named stuff in share folder (or where you have configured it). **The xmb/xpm files are dummys - don't connect with xpm/xbm to a iso server ** Copy the HallOfSelection in the maps folder over the orignal HallOfSelection. new Arch Files -------------- In arch.zip are the new arch files. Thats the stuff we need to work with. Copy it in the editor arch to play with it. Java Editor ----------- The Java Editor now can show html as online help. All the stuff need alot of work. Reworking the maps and including the arches. In the arches are a in_work_stuff folder. This is unchanged stuff. All stuff in dev folder will be automatically excluded from editor, later this need to be included for map transforming. I don't include yet needed replace function or so, and save and map folder selection from editor don't find the folder automatically - this will be changed. Ok, this is just to give a look what it goes. As you can see, moving is easy and the game feeling is very same as flat. The look is great, is all seems much more "3d" - and the demo map is really "nacked". Most items not fit right in map, this must be changed. Also, i must transform more of the critical stuff. This are not so many stuff (buttons, magic mouth, special floors). Most of the arches are monsters and walls. If you work through the arches, you will see in the original stuff how bad it is. Most of the wall stuff for example are crap - and many are broken (not usable tiles). Michael From mwedel at scruz.net Mon Jun 11 23:16:21 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 References: <01061112245100.01739@Terminus.magellan.fpms.ac.be> Message-ID: <3B259795.23800FA8@scruz.net> gros wrote: > > This is the latest revision of Crossfire Scripting Extensions. > > What's new from b10 ? > - Some minor modifications in crossfire-message function (now allows an > optional color arg). Note that that feature may very well go away. AT some time, the message handling between server and client will get updated, such that the server will tell the client the type of content the message has, and the client will then choose appropriate font and color to display it in. In theory, these settings would also be customizable by each player, so some could have level gain info in red, while another could be using a bold font in blue. I haven't come up wtih a complete list of message types - there will probably be somewhere under 30. But a quick list off the top of my head would be: attack messages (you hit/you miss) kill messages (you kill or your pet kills) ability gain/less messages resistance gain/loss messages level/gain loss messages (overall level + skill would use the same code most likely) spell listing shop listing connected object related stuff. and probably some others. When this is done, probably new categories will be found when going through the code. the scripts should probably not 'spoof' these messages, unless it is really doing that action but the normal procedure that would print the message would not be called. > What is planned for b12 ? > - New script event triggered for armours whenever the wearer is being > attacked; > - Basic multithread capabilities for asynchronous script execution; > - Character controller modification by scripts. do we have any performance related information on the use of scripting? While having most every object have its own script (armor trigger event, weapon triggered events, etc), what will be the end result for having thousands of scripts potentially active? Memory consumption? cpu consumption (even if threaded, unless on a multi cpu system, it means it will still be taking cpu time from other processes). What I'm really getting at here is that before pursuing lots of objects having their own scripts, we may want to find out if the server will be able to reasonably handle that. From reeve at ductape.net Mon Jun 11 23:39:07 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Alchemy Suggestion In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Sun, Jun 10, 2001 at 21:18:09 -0400 References: <20010610124658.A20247@terra.localnet> Message-ID: <20010612003907.A29497@terra.localnet> On Sun, 10 Jun 2001 21:18:09 dnh wrote: > This sounds like a nice idea, can you code it? > I'll give it a shot if noone else does it first, but right now I'm a little pressed for time :) -- -- -- Reeve the cat ----BEGIN FORTUNE---- BOFH excuse #39: terrorist activities ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From mwedel at scruz.net Mon Jun 11 23:48:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] darkness in client display. Message-ID: <3B259F2C.4C221950@scruz.net> Soliciting thoughts for how to deal with darkness in the client. This is because with the new map1 protocol command for sending larger maps, the way darkness is sent is now different. For referance, with the old code, darkness was not actually sent as a value. Instead, the server would notice the relative darkness of a space, and send an masking image that would then make it appear darker (basically, for 25% darkness, the masking image had 25% of its pixels set to black, the other 75% transparent, for 50% darkness, 50% black, 50% transparent, and so on for 75% darkness). This works, but IMO the results were not all that great looking. Also, a player could easily avoid this by using image caching and replacing those masking images with ones that are 100% transparent. With the new map1 protocol command, instead of sending masking images, instead that actual darkness value is sent. In this way, the client can do appropriate cleverness for displays. An example of that is at http://tavern.santa-clara.ca.us/inter.gif (this requires using the -pngximage on the client). Currently, if not using pngximage, the client does not do anything at with darkness when using the larger map area. This then gets me thinking - if the client isn't going to use the information, why send it to the client. Adding an option in the server to enable/disable darkness would be pretty easy to do. I had thought of adding the masking pixmaps to the client and have it use that same logic for the other display mode, but IMO the quality of that is really pretty questionable. Hopefully, with the SDL additions to the client, performance will improve a bit on the drawing to making that lighting code more usable on all systems. So the basic questions is: 1) Should players/clients be able to turn off darkness pixmaps/information as sent from the server? Such a change is easy to make, and would also apply to the old (11x11 and smaller) map code. 2) Is there demand/want to use the masking information on the client side for slower systems/people that don't want to use pngximage for whatever reason? NOTE - in all cases, this does not turn off darkness on the server - you will still only be able to see some number of spaces as dictated by lighting conditions. What changes here is what we do with half dark spaces. From dnh at hawthorn.csse.monash.edu.au Tue Jun 12 03:25:39 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Alchemy Suggestion In-Reply-To: <20010612003907.A29497@terra.localnet> Message-ID: righto, well I would expect not many others would take this on right now either.. so when you have a spare moment.. feel free to try it. dnh On Tue, 12 Jun 2001, Scott Barnes wrote: > > On Sun, 10 Jun 2001 21:18:09 dnh wrote: > > This sounds like a nice idea, can you code it? > > > > I'll give it a shot if noone else does it first, but right now I'm a > little pressed for time :) > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > BOFH excuse #39: > > terrorist activities > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > From yann.chachkoff at mailandnews.com Tue Jun 12 08:29:07 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 In-Reply-To: <3B259795.23800FA8@scruz.net> References: <01061112245100.01739@Terminus.magellan.fpms.ac.be> <3B259795.23800FA8@scruz.net> Message-ID: <01061209290701.01944@Terminus.magellan.fpms.ac.be> Le Mardi 12 Juin 2001 00:16, vous avez ?crit : > gros wrote: > > This is the latest revision of Crossfire Scripting Extensions. > > > > What's new from b10 ? > > > > - Some minor modifications in crossfire-message function (now allows an > > optional color arg). > > Note that that feature may very well go away. AT some time, the message > handling between server and client will get updated, such that the server > will tell the client the type of content the message has, and the client > will then choose appropriate font and color to display it in. In theory, > these settings would also be customizable by each player, so some could > have level gain info in red, while another could be using a bold font in > blue. I included it because of some players/map makers suggests. I didn't knew there was a project about new message formatting system. > > What is planned for b12 ? > > - New script event triggered for armours whenever the wearer is being > > attacked; > > - Basic multithread capabilities for asynchronous script execution; > > - Character controller modification by scripts. > > do we have any performance related information on the use of scripting? > > While having most every object have its own script (armor trigger event, > weapon triggered events, etc), what will be the end result for having > thousands of scripts potentially active? Memory consumption? cpu > consumption (even if threaded, unless on a multi cpu system, it means it > will still be taking cpu time from other processes). What I'm really > getting at here is that before pursuing lots of objects having their own > scripts, we may want to find out if the server will be able to reasonably > handle that. Only 127 simultaneous scripts are allowed right now, so 'thousands of scripts potentially active' is not going to happen. I also admit that I didn't had multithreaded scripts in mind when I first thought about using the pthread lib - I was thinking about solving some problems with spellcasting (A player can sometimes be locked for several seconds before being able to react to spells cast on him). I also think the multithreading of scripts could cause some problems; that's why I didn't included any code related to that. I'm doing lots of tests to see if it is truly useful/efficient. From bugs at real-time.com Tue Jun 12 10:03:13 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] [Bug 373] New - beholders crash crossfire.csua.berkeley.edu server Message-ID: <200106121503.f5CF3Dj25787@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=373 *** shadow/373 Tue Jun 12 10:03:13 2001 --- shadow/373.tmp.25783 Tue Jun 12 10:03:13 2001 *************** *** 0 **** --- 1,21 ---- + +============================================================================+ + | beholders crash crossfire.csua.berkeley.edu server | + +----------------------------------------------------------------------------+ + | Bug #: 373 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: All | + | Severity: blocker OS/Version: All | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: jinxm@hotmail.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Moving or using a skill in any direction other than "stay" upon rejoining the + game as a Beholder on the crossfire.csua.berkeley.edu server causes everyone in + the game to exit. (the dx client 1.25 says "socket error 10054" for me) + It looks like the server also resets as well, because things I had just killed + (using invoke holy word with no direction) are back when I relog. \ No newline at end of file From yann.chachkoff at mailandnews.com Tue Jun 12 11:34:03 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Crossfire Scripting Extensions, version 1.0.0b11 for CVS Message-ID: <01061212340300.03452@Terminus.magellan.fpms.ac.be> This is the latest patch for scripting stuff, made for using with latest CVS server version. I removed the pthread preliminary support (controversial and still not useful); I also corrected a bug in the attack handling. Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b11-cvs.bz2 Type: application/x-bzip2 Size: 66259 bytes Desc: Patch for CVS server Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010612/1ecd7803/patch-scriptfire-1.0.0b11-cvs.bin From mwedel at scruz.net Tue Jun 12 23:58:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 References: <01061112245100.01739@Terminus.magellan.fpms.ac.be> <3B259795.23800FA8@scruz.net> <01061209290701.01944@Terminus.magellan.fpms.ac.be> Message-ID: <3B26F2FE.F5CC7CB3@scruz.net> gros wrote: > > I included it because of some players/map makers suggests. I didn't knew > there was a project about new message formatting system. It got put out on a possible future projects. Nothing has happened yet on this. In fact, it should actually be a fairly easy (no brainpower) change to make, but make take a little time to find all the referances. The cvs client supports an option for splitting the information pane into two panes - right now, one gets colored text, the other the black/white text. the option is -splitinfo - gtk client only). If you play with that, you will in fact notice there are lots of messages that are currently printed in black which probably should be more noticable. The color text code was never really integrated to much an extent in the code, so by default most everything is still black. > Only 127 simultaneous scripts are allowed right now, so 'thousands of scripts > potentially active' is not going to happen. I also admit that I didn't had > multithreaded scripts in mind when I first thought about using the pthread > lib - I was thinking about solving some problems with spellcasting (A player > can sometimes be locked for several seconds before being able to react to > spells cast on him). I also think the multithreading of scripts could cause > some problems; that's why I didn't included any code related to that. I'm > doing lots of tests to see if it is truly useful/efficient. So what then happens when your at that 127 limit and some other script comes about? Does it just not run? From your previous message, it sounds like a lot of objects might have scripts attached to them, so getting to 127 scripts could happen prety quickly on a busy server. Ideally, the solution should probably be allowed to scale to whatever number the system is capable of (in terms of cpu and/or memory). There is of course still some practical limit in all cases. From michael.toennies at nord-com.net Wed Jun 13 06:13:35 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Compiling CVS warnings Message-ID: I got some warnings as i compile CVS. The compile success but the authors of the code should look at this. ------------------------ /home/unitel/cf/crossfire/install/crossfire loader.l: In function `load_object': loader.l:759: warning: assignment makes pointer from integer without a cast script.c: In function `Script_getFirstOnSquare': script.c:565: warning: passing arg 1 of `gh_long2scm' makes integer from pointer without a cast client: configure, make depend, make /home/unitel/cf/crossfire/install/client /usr/X11R6/bin/makedepend: warning: gx11.c (reading /usr/include/glib.h, line 66): cannot find include file "glibconfig.h" not in ./glibconfig.h not in /usr/X11R6/include/glibconfig.h not in /usr/local/lib/gcc-include/glibconfig.h not in /usr/include/glibconfig.h not in /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/glibconfig.h In file included from gx11.c:111: png.c: In function `png_to_gdkpixmap': png.c:201: warning: variable `has_alpha' might be clobbered by `longjmp' or `vfork' In file included from x11.c:294: png.c: In function `png_to_xpixmap': png.c:565: warning: variable `has_alpha' might be clobbered by `longjmp' or `vfork' png.c:565: warning: variable `cmask' might be clobbered by `longjmp' or `vfork' png.c:565: warning: variable `lastcolor' might be clobbered by `longjmp' or `vfork' From michael.toennies at nord-com.net Wed Jun 13 07:52:00 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] cvs commit Message-ID: Huch, last commit graped some files i commit before. i tried recursive commit - was working a bit to perfect. From yann.chachkoff at mailandnews.com Wed Jun 13 15:41:40 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:18 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 In-Reply-To: <3B26F2FE.F5CC7CB3@scruz.net> References: <01061112245100.01739@Terminus.magellan.fpms.ac.be> <01061209290701.01944@Terminus.magellan.fpms.ac.be> <3B26F2FE.F5CC7CB3@scruz.net> Message-ID: <01061316414002.02281@Terminus.magellan.fpms.ac.be> Le Mercredi 13 Juin 2001 00:58, vous avez ?crit : > > Only 127 simultaneous scripts are allowed right now, so 'thousands of > > scripts potentially active' is not going to happen. I also admit that I > > didn't had multithreaded scripts in mind when I first thought about using > > the pthread lib - I was thinking about solving some problems with > > spellcasting (A player can sometimes be locked for several seconds before > > being able to react to spells cast on him). I also think the > > multithreading of scripts could cause some problems; that's why I didn't > > included any code related to that. I'm doing lots of tests to see if it > > is truly useful/efficient. > > From your previous message, it sounds like a lot of objects might have > scripts attached to them, so getting to 127 scripts could happen prety > quickly on a busy server. Ideally, the solution should probably be allowed > to scale to whatever number the system is capable of (in terms of cpu > and/or memory). There is of course still some practical limit in all > cases. That's not a real problem if there's no multithreading support. When scripted object A gets its 'quantum time', its script gets executed if necessary. When the whole script has ended, crossfire switches to object B, then object C, ... Two objects can never move at the same time in the current implementation of crossfire. The only case now where you can have multiple scripts running at the same time is when a script triggers another script event (for example, the BroadSword of Scripting has an attack script and can trigger a script_death event when killing a scripted monster). So, the 127 limit means that you can only have a 'chain of scripts' 127 scripts long (which sounds very unlikely to happen). Now for the multithread problem: it is indeed true that following my own tests, it does not seem to be needed. That's why I removed any references to it from my CVS patch. I still don't know if I'll continue to work on it or not. Chachkoff Y. From michael.toennies at nord-com.net Wed Jun 13 10:04:55 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Crossfire win32 binary release 1.0.0b11 & win32 compiler package Message-ID: I had released a windows binary package of Crossfire. It includes all what you need to run a full server, including maps. Sources and dev stuff are not included. You get the binary package here http://mids.student.utwente.nl/~michtoen/cfwin32_server/crossfire32_server.z ip just entpack and start run_win32.bat. 2nd, because GUILE are not a part of win32, you need to inlcude some libs and dlls for compiling the current CVS. I had released a library package, which you copy over the cvs source. It includes then the needed libs to the source. After this, you can compile the source to a win32 server. Without this package, the CVS compile under windows will fail! You get the compiler package here http://mids.student.utwente.nl/~michtoen/cfwin32_server/cf_win32_libs.zip Michael From michael.toennies at nord-com.net Wed Jun 13 12:18:15 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] archtype not in style maps? Message-ID: oad_original_map: /styles/floorstyles/dirt (8) load_original_map: /styles/wallstyles/trees (8) Couldn't find archetype tree4_2_2_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 Couldn't find archetype tree4_3_2 From peterm at tonks.EECS.Berkeley.EDU Wed Jun 13 12:46:31 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] archtype not in style maps? In-Reply-To: Your message of "Wed, 13 Jun 2001 19:18:15 +0200." Message-ID: <200106131746.f5DHkVH16760@tonks.EECS.Berkeley.EDU> These messages are normal and may safely be ignored. They result from the code attempting to make pretty, auto joined walls out of trees, which don't autojoin. PeterM > oad_original_map: /styles/floorstyles/dirt (8) > load_original_map: /styles/wallstyles/trees (8) > Couldn't find archetype tree4_2_2_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > Couldn't find archetype tree4_3_2 > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruznet.com Wed Jun 13 16:01:08 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] cvs commit In-Reply-To: Message-ID: On Wed, 13 Jun 2001, Michael Toennies wrote: > Huch, last commit graped some files i commit before. > i tried recursive commit - was working a bit to perfect. I've seen CVS do this a bit. IT seems that CVS looks at something other than contents to determine if a file has changed (either time or inode number I guess). Often with the client, it will says the sounds and soundsdef.h files are modified, even though a cvs diff shows them to be exactly the same as what is in CVS (these files perhaps should not even be in CVS, since they are automatically generated anyways). From michael.toennies at nord-com.net Wed Jun 13 16:49:10 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] cvs commit In-Reply-To: Message-ID: I tried a simple cvs.... -f commit... Following the CVS docs, this should run through the active directory and try to submit the files in it. That was what happend, except that there was no cotent check from cvs. All files are grapped and forced to check in. I can't see hy this happend. A mistake by me, a cvs bug or a setup problem by our cvs? Michael > > > On Wed, 13 Jun 2001, Michael Toennies wrote: > > > Huch, last commit graped some files i commit before. > > i tried recursive commit - was working a bit to perfect. > > > I've seen CVS do this a bit. > > IT seems that CVS looks at something other than contents to determine > if a file has changed (either time or inode number I guess). Often with > the client, it will says the sounds and soundsdef.h files are modified, > even though a cvs diff shows them to be exactly the same as what is in CVS > (these files perhaps should not even be in CVS, since they are > automatically > generated anyways). > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruznet.com Wed Jun 13 17:58:48 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] cvs commit In-Reply-To: Message-ID: On Wed, 13 Jun 2001, Michael Toennies wrote: > I tried a simple cvs.... -f commit... > Following the CVS docs, this should run through the active directory and > try to submit the files in it. > > That was what happend, except that there was no cotent check from cvs. > All files are grapped and forced to check in. > > I can't see hy this happend. > > A mistake by me, a cvs bug or a setup problem by our cvs? I think this is a bug in CVS, in that it doesn't do content check and uses some other mechanism to determine changed files. I don't think there is anything involved on the CVS server in this case (its really the local cvs command determining what is different) - the cvs server presumes that if the client says the file is different, that it really is different. My only solution is to just watch what CVS says it will be committing, and if it is grabbing files it shouldn't, I abort that commit and see what it is really doing. At least with the unix CVS, it pops up an editor for commands, and in that it includes a bunch of cvs comment lines which do include what files it will be committing. From mwedel at scruznet.com Wed Jun 13 18:47:43 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Compiling CVS warnings In-Reply-To: Message-ID: On Wed, 13 Jun 2001, Michael Toennies wrote: > /home/unitel/cf/crossfire/install/client > /usr/X11R6/bin/makedepend: warning: gx11.c (reading /usr/include/glib.h, > line 66): cannot find include file "glibconfig.h" > not in ./glibconfig.h > not in /usr/X11R6/include/glibconfig.h > not in /usr/local/lib/gcc-include/glibconfig.h > not in /usr/include/glibconfig.h > not in > /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/glibconfig.h I'm not too concerned with make depend errors. This is somewhat because there are actually quite a few of them, mostly caused because makedepend doesn't get all the same flags the compiler gets (and doesn't know about custom install directories for the compiler I believe). Such errors, while obnoxious, end up being harmless. > In file included from gx11.c:111: > png.c: In function `png_to_gdkpixmap': > png.c:201: warning: variable `has_alpha' might be clobbered by `longjmp' or > `vfork' > In file included from x11.c:294: > png.c: In function `png_to_xpixmap': > png.c:565: warning: variable `has_alpha' might be clobbered by `longjmp' or > `vfork' > png.c:565: warning: variable `cmask' might be clobbered by `longjmp' or > `vfork' > png.c:565: warning: variable `lastcolor' might be clobbered by `longjmp' or > `vfork' I'll fix those up. in our particular case, this won't happen (if longjmp is in fact called, the function will exit, and thus won't use any of those variables). But making the code compile cleaner is always a good thing. From mwedel at scruznet.com Wed Jun 13 19:59:00 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Compile errors with scriptfire Message-ID: The guile scripting code as checked into crossfire is making use of // for comments in several places. // is not a valid comment starter, and any ANSI C compliant compiler will result in error messages. As per for the coding guidelines, // comments should not be used. Someone please fix this. From mwedel at scruznet.com Wed Jun 13 20:16:14 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 In-Reply-To: <01061316414002.02281@Terminus.magellan.fpms.ac.be> Message-ID: On Wed, 13 Jun 2001, gros wrote: > That's not a real problem if there's no multithreading support. When scripted > object A gets its 'quantum time', its script gets executed if necessary. When > the whole script has ended, crossfire switches to object B, then object C, > ... Two objects can never move at the same time in the current implementation > of crossfire. The only case now where you can have multiple scripts running > at the same time is when a script triggers another script event (for example, > the BroadSword of Scripting has an attack script and can trigger a > script_death event when killing a scripted monster). So, the 127 limit means > that you can only have a 'chain of scripts' 127 scripts long (which sounds > very unlikely to happen). Ok. It is basically a stack depth of 127, which should be sufficient. But what does happen if it is reached? does the last one just not execute? I could see some error, or a situation where the like script A says something which script B hears and says something in return, which script A hears and says something in return, and at some point, one of the scripts says something that starts it all over again. > Now for the multithread problem: it is indeed true that following my own > tests, it does not seem to be needed. That's why I removed any references to > it from my CVS patch. I still don't know if I'll continue to work on it or > not. If multithreading comes about, I think it will be at a higher level than scripts. IMO, if multithreading is done for the server, it would probably be done at the map level (each map has its own thread). The separation at that point would result in the fewest mutexes needed I think, and probably work the best even for single cpu systems (won't have too many threads going about, but does let the performance of one bad map only affect the players on that map, and not the entire server). It also means map loading/saving can be done in its own thread, so that those actions don't affect performance for players (except for the player who has just transferred to the map that needs to be loaded). This currently is a fairly low priority project - there are a lot of other things should be done first. Threads don't help out much if the code handles some things poorly (like many spell effects). From yann.chachkoff at mailandnews.com Thu Jun 14 14:41:50 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b11 In-Reply-To: References: Message-ID: <01061415415000.19850@Terminus.magellan.fpms.ac.be> Le Mercredi 13 Juin 2001 21:16, vous avez ?crit : > On Wed, 13 Jun 2001, gros wrote: > > That's not a real problem if there's no multithreading support. When > > scripted object A gets its 'quantum time', its script gets executed if (...) > Ok. It is basically a stack depth of 127, which should be sufficient. > But what does happen if it is reached? does the last one just not execute? > Yes, that's what happens (and you also receive a warning message on the server console). > I could see some error, or a situation where the like script A says > something which script B hears and says something in return, which script > A hears and says something in return, and at some point, one of the scripts > says something that starts it all over again. > That could happen, but because of script stack limit, an infinite loop would be very difficult to be run that way. Infinite loops are difficult to prevent; that's one of the reasons that made me put the stack limit on 128, not higher. The other reason is of course memory requirement, although script data tend to be small. (short note: I fixed the maximal index of the stack to 128, giving a total of 129 stack levels, not 127 as I said before). > > Now for the multithread problem: it is indeed true that following my own > > tests, it does not seem to be needed. That's why I removed any references > > to it from my CVS patch. I still don't know if I'll continue to work on > > it or not. (...) > This currently is a fairly low priority project - there are a lot of > other things should be done first. Threads don't help out much if the > code handles some things poorly (like many spell effects). I definitely agree with you. Chachkoff Y. From dnh at hawthorn.csse.monash.edu.au Thu Jun 14 21:43:38 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] High angel Message-ID: Can someone please inform me of what the heck is going on in /monsters/angel/ ? I was looking for the highangel.arc to add some new animation and it would appear to me that it doesn't exist. Searching through the archetypes file I found this entry: Object ArchAngel randomitems archangel name Arch Angel race angel face highangel.111 but, looking at the .arc (archangel.arc) file it has: Object HighAngel randomitems rich name High Angel race angel face archangel.118 I seem to remember peterm changing a few names around, this is really tragic.. I can't find a whole angel now.. =) since there are still only a few angels, can I suggest we fix these names now then patch the broken maps (random at the top of valriel church, zoo2). I guess we will have to leave the 'angel' (which is a really dodgy name) as is, because I know there are more than enough of those to create quite a headache ;). There are actually quite a few .arc's in there which give me a headache, can anyone say rustmonste? But unless we want to redo every map, and every arch these are things for another day. dnh ps. If no one else does it, I suppose I will. From dnh at hawthorn.csse.monash.edu.au Fri Jun 15 04:16:06 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Server Message-ID: My server isn't compiling... Reading artifacts from /usr/games/crossfire/share/crossfire/artifacts...Unkown input in artifact file: Just to fix probability some. Unrecognized string: start_script_attack Unrecognized string: (define rresult (random 100)); Unrecognized string: (if (<= rresult 1) Unrecognized string: (begin Unrecognized string: (crossfire-message "Your weapon suddenly seems lighter !") Unrecognized string: (set-damage (who-am-I) (+ 10 (get-damage (who-am-I)))) Unrecognized string: (set-identified (who-am-I) #f) Unrecognized string: (set-been-applied (who-am-I) #f) Unrecognized string: ) Unrecognized string: (if (<= rresult 2) Unrecognized string: (begin Unrecognized string: (crossfire-message "Your weapon suddenly seems darker !") Unrecognized string: (set-damage (who-am-I) (- (get-damage (who-am-I)) 10)) Unrecognized string: (set-identified (who-am-I) #f) Unrecognized string: (set-been-applied (who-am-I) #f) Unrecognized string: ) Unrecognized string: (if (<= rresult 3) Unrecognized string: (begin Unrecognized string: (crossfire-message "Your weapon suddenly seems to become colder !") Unrecognized string: (set-attack-type (who-am-I) (+ (attack-type-physical) (attack-type-cold))) Unrecognized string: (set-identified (who-am-I) #f) Unrecognized string: (set-been-applied (who-am-I) #f) Unrecognized string: ) Emergency saves disabled, no save attempted Fatal: Too many errors Emergency saves disabled, no save attempted Cleaning up... Exiting... This = bad. I can see this is the scripting stuff, please make sure you leave the cvs runable as I am currently trying to add new monster graphics etc etc. Until I have a working server I can do no work (I don't want to add something that doesn't work..). If this is my error can someone please tell me ASAP what I need to do to fix... dnh From dnh at hawthorn.csse.monash.edu.au Fri Jun 15 05:13:41 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] High angel In-Reply-To: Message-ID: .arc file was found archangel2.arc.. dnh On Fri, 15 Jun 2001, dnh wrote: > Can someone please inform me of what the heck is going on in > /monsters/angel/ ? > > I was looking for the highangel.arc to add some new animation and it would > appear to me that it doesn't exist. Searching through the archetypes file > I found this entry: > > Object ArchAngel > randomitems archangel > name Arch Angel > race angel > face highangel.111 > > but, looking at the .arc (archangel.arc) file it has: > > Object HighAngel > randomitems rich > name High Angel > race angel > face archangel.118 > > I seem to remember peterm changing a few names around, this is really > tragic.. I can't find a whole angel now.. =) > > since there are still only a few angels, can I suggest we fix these names > now then patch the broken maps (random at the top of valriel church, > zoo2). I guess we will have to leave the 'angel' (which is a really dodgy > name) as is, because I know there are more than enough of those to create > quite a headache ;). > > There are actually quite a few .arc's in there which give me a headache, > can anyone say rustmonste? But unless we want to redo every map, and every > arch these are things for another day. > > dnh > > ps. If no one else does it, I suppose I will. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Fri Jun 15 05:17:05 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:19 2005 Subject: [CF-Devel] Server In-Reply-To: Message-ID: Ahhh ahhhhhhhhhhh installing guile would help with this situation lol! dnh On Fri, 15 Jun 2001, dnh wrote: > My server isn't compiling... > > Reading artifacts from > /usr/games/crossfire/share/crossfire/artifacts...Unkown input in artifact > file: Just to fix probability some. > Unrecognized string: start_script_attack > Unrecognized string: (define rresult (random 100)); > Unrecognized string: (if (<= rresult 1) > Unrecognized string: (begin > Unrecognized string: (crossfire-message "Your weapon suddenly seems > lighter !") > Unrecognized string: (set-damage (who-am-I) (+ 10 (get-damage > (who-am-I)))) > Unrecognized string: (set-identified (who-am-I) #f) > Unrecognized string: (set-been-applied (who-am-I) #f) > Unrecognized string: ) > Unrecognized string: (if (<= rresult 2) > Unrecognized string: (begin > Unrecognized string: (crossfire-message "Your weapon suddenly seems > darker !") > Unrecognized string: (set-damage (who-am-I) (- (get-damage > (who-am-I)) 10)) > Unrecognized string: (set-identified (who-am-I) #f) > Unrecognized string: (set-been-applied (who-am-I) #f) > Unrecognized string: ) > Unrecognized string: (if (<= rresult 3) > Unrecognized string: (begin > Unrecognized string: (crossfire-message "Your weapon suddenly > seems to become colder !") > Unrecognized string: (set-attack-type (who-am-I) (+ > (attack-type-physical) (attack-type-cold))) > Unrecognized string: (set-identified (who-am-I) #f) > Unrecognized string: (set-been-applied (who-am-I) #f) > Unrecognized string: ) > Emergency saves disabled, no save attempted > Fatal: Too many errors > Emergency saves disabled, no save attempted > Cleaning up... > Exiting... > > This = bad. > > I can see this is the scripting stuff, please make sure you leave the cvs > runable as I am currently trying to add new monster graphics etc etc. > Until I have a working server I can do no work (I don't want to add > something that doesn't work..). If this is my error can someone please > tell me ASAP what I need to do to fix... > > dnh > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From smurf at CSUA.Berkeley.EDU Fri Jun 15 23:13:56 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:20 2005 Subject: [CF-Devel] Patch to enable SDL support in the Gtk client Message-ID: <20010615211356.A29768@CSUA.Berkeley.EDU> The following patch enables the Gtk client to use SDL to blit png images instead of using GdkPixbuf. Initial tests on my machines show about a 30% increase in blit speeds but I'm pretty sure that will be very machine dependent. The code isn't all that optimized yet either. In particular, when the map scrolls the whole screen image is regenerated instead of just memcpy'ed. This patch also provides the same interpolated darkness that the -pngximage option uses. An option in the config menu allows dynamic switching between this per-pixel darkness and tile based darkness. The tile based option uses an alpha blended surface, not stipple maps like the older clients. Thier is also an option to turn on a grid overlay, I was using this to help debug a few things and left it in, might be useful to someone someday. To use this patch, you must have SDL 1.1.3 installed and SDL_image 1.x. The configure scripts check for the proper version of SDL and that the SDL_image library has the proper PNG image loading routine. Default is to use SDL if available, if not it falls back to Gtk. It is a compile time option, once compiled in you can't use pngximage and vice versa. If you have SDL but don't want to use it, pass configure the --disable-sdl option. I left 'configure' out of the patch so you'll have to run aclocal;autoconf;automake to regenerate it. Current state of the code is 'works for me'. I have only tested it on 32 bit displays although code is in place for 16 bit displays. SDL_image has very poor support for XPM images so this patch will only work with PNG images. We are dropping XPM anyway right? umm.. Oh yeah, the patch is against the lastest CVS code. -Scott -------------- next part -------------- Common subdirectories: client/CVS and /home/smf/projects/crossfire/cvs/client/CVS diff -c5 --exclude-from=exclude client/client.man /home/smf/projects/crossfire/cvs/client/client.man *** client/client.man Mon Jun 4 23:24:14 2001 --- /home/smf/projects/crossfire/cvs/client/client.man Fri Jun 15 17:05:35 2001 *************** *** 79,98 **** --- 79,102 ---- further down.) Png have all the same features of XPM, but are slightly larger (32x32 instead of 24x24), appear better, and do the the efficiency of the png format, actually take less bandwidth to transmit than the xpm images. Using the png images require that the client has been compiled with png support. + Note: If the client is compiled with SDL support, -png is the only + supported image type .TP .B -pngximage gcfclient only. This option is only meaningful if png graphics are being used. It uses a GdkRgb structure - this allows much better effects (especially darkness). Performance may be worse when using this option - this depends on many factors. Like the mapsize option above, it is suggested the experimentation is done to make performance is still acceptable. This option does not affect bandwidth - it only affects cpu performancs. + Note: This option is not available if compiled with SDL support + but all the functionality exists in the SDL client. .TP .B -showicon This shows a little icon next to items in your inventory that contains a brief description of some of the item properties (magic, cursed, *************** *** 266,275 **** --- 270,280 ---- .PP Please let me know about any bugs you find in the client. .SH AUTHOR Copyright (C) 1994,2000 Mark Wedel (mwedel@scruz.net) GTK port by David Sundqvist (azzie@netpolicy.com) + SDL support added by Scott MacFiggen (smurf@CSUA.Berkeley.EDU) There are a great many other contributors to both the client and server that are not mentioned here. .ft R diff -c5 --exclude-from=exclude client/config.h.in /home/smf/projects/crossfire/cvs/client/config.h.in *** client/config.h.in Mon Jun 4 20:01:48 2001 --- /home/smf/projects/crossfire/cvs/client/config.h.in Fri Jun 15 13:43:59 2001 *************** *** 70,79 **** --- 70,81 ---- #undef HAVE_LIBM /* Define if you have the png library (-lpng). */ #undef HAVE_LIBPNG + #undef HAVE_SDL + /* Name of package */ #undef PACKAGE /* Version number of package */ #undef VERSION diff -c5 --exclude-from=exclude client/configure.in /home/smf/projects/crossfire/cvs/client/configure.in *** client/configure.in Thu Jun 7 16:20:12 2001 --- /home/smf/projects/crossfire/cvs/client/configure.in Fri Jun 15 15:47:46 2001 *************** *** 72,81 **** --- 72,85 ---- gtk=no, gtk=yes ) AC_ARG_ENABLE(gnome, [ --disable-gnome don't make gnome client [default=make gnome client if available]], gnome=no, gnome=yes ) + AC_ARG_ENABLE(sdl, [ --disable-sdl Disable linking with the SDL library, default is to use it if available ], + use_sdl=no, use_sdl=yes) + + AC_PROG_CC AC_C_BIGENDIAN networklibs="yes" *************** *** 221,230 **** --- 225,255 ---- AC_SUBST(GUI_SRCS) AC_SUBST(SND_LIBS) AC_SUBST(LDFLAGS) AC_SUBST(TARGET) + dnl Check for SDL 1.1.3 and sdl_image + dnl note SDL_image does not ship with an sdl-image-config + dnl so I'll just assume it is in the same dir as SDL + if eval "test x$use_sdl = xyes"; then + AM_PATH_SDL(1.1.3) + if eval "test x$no_sdl = x"; then + AC_CHECK_LIB( SDL_image, IMG_LoadPNG_RW, + have_sdlimage="yes", have_sdlimage="no", $SDL_CFLAGS) + if eval "test x$have_sdlimage = xyes"; then + SDL_LIBS="$SDL_LIBS -lSDL_image" + else + no_sdl= "yes" + fi + fi + + if eval "test x$no_sdl = x"; then + AC_DEFINE(HAVE_SDL) + CFLAGS="$CFLAGS $SDL_CFLAGS" + LIBS="$LIBS $SDL_LIBS" + fi + fi dnl The following hacks for modifying CFLAGS were borrowed from the GIMP. if test -n "$DEBUGFLAG"; then CFLAGS="$DEBUGFLAG $CFLAGS" fi diff -c5 --exclude-from=exclude client/gx11.c /home/smf/projects/crossfire/cvs/client/gx11.c *** client/gx11.c Wed Jun 13 00:01:20 2001 --- /home/smf/projects/crossfire/cvs/client/gx11.c Fri Jun 15 20:54:06 2001 *************** *** 109,118 **** --- 109,140 ---- #ifdef HAVE_LIBPNG #define PNG_GDK #include "png.c" #endif + #ifdef HAVE_SDL + #include + #include + + static void do_SDL_error( gchar* SDL_function, gchar* file, int line) + { + fprintf( stderr, "ERROR on %s in file %s line %d\n%s\n", SDL_function, + file, line, SDL_GetError()); + SDL_Quit(); + exit( 1); + } + + typedef struct + { + SDL_Surface *surface; + } SurfaceInfo; + + static int per_pixel_lighting= 1; + static int per_tile_lighting= 0; + static int show_grid= FALSE; + #endif /* HAVE_SDL */ + #define MAXPIXMAPNUM 10000 #define GDK_XUTIL static int image_size=24; *************** *** 248,258 **** --- 270,285 ---- #define MAX_INFO_WIDTH 80 #define MAXNAMELENGTH 50 static int gargc; + #ifdef HAVE_SDL + Display_Mode display_mode = Png_Display; + #else Display_Mode display_mode = DISPLAY_MODE; + #endif + static uint8 split_windows=FALSE, cache_images=FALSE, nopopups=FALSE, *************** *** 319,328 **** --- 346,364 ---- static GdkGC *map_gc; static GtkWidget *mapvbox; static struct PixmapInfo pixmaps[MAXPIXMAPNUM]; + + #ifdef HAVE_SDL + static SurfaceInfo surfaces[MAXPIXMAPNUM]; + + /* Actual SDL surface the game view is painted on */ + static SDL_Surface* mapsurface; + static SDL_Surface* lightmap; + #endif + #define INFOLINELEN 500 #define XPMGCS 100 static GtkWidget *ccheckbutton1; static GtkWidget *ccheckbutton2; *************** *** 332,341 **** --- 368,383 ---- static GtkWidget *ccheckbutton6; static GtkWidget *ccheckbutton7; static GtkWidget *ccheckbutton8; static GtkWidget *inv_notebook; + #ifdef HAVE_SDL + static GtkWidget *cradiobutton1; + static GtkWidget *cradiobutton2; + static GtkWidget *ccheckbutton9; + #endif + static GtkTooltips *tooltips; static GtkWidget *dialogtext; static GtkWidget *dialog_window; static GtkWidget *drawingarea; *************** *** 429,445 **** #define BPP 3 /* Pixels representing entire viewable screen. This amounts to about mb */ #define SCREEN_SIZE MAP_MAX_SIZE * MAP_MAX_SIZE*32*32*BPP static uint8 screen[SCREEN_SIZE]; ! ! static guchar map_did_scroll=0; #include "xutil.c" void create_windows (void); /* Convert xpm memory buffer to xpm data (needed since GTK/GDK doesnt have a * function to create from buffer rather than data --- 471,571 ---- #define BPP 3 /* Pixels representing entire viewable screen. This amounts to about mb */ #define SCREEN_SIZE MAP_MAX_SIZE * MAP_MAX_SIZE*32*32*BPP + #ifndef HAVE_SDL static uint8 screen[SCREEN_SIZE]; ! #endif static guchar map_did_scroll=0; #include "xutil.c" + #ifdef HAVE_SDL + /* + * Takes two args, the first is the GtkWindow to draw on, this should always + * be 'drawingarea'. The second is a boolean, if 0 then the whole + * SDL system in initialized or reinited if already run once before, + * if non zero then only the lightmap is rebuilt, if we switch between + * per-pixel or per-tile lighting + */ + static void init_SDL( GtkWidget* sdl_window, int just_lightmap) + { + + char SDL_windowhack[32]; + + if( just_lightmap == 0) + { + + g_assert( sdl_window != NULL); + if( SDL_WasInit( SDL_INIT_VIDEO) != 0) + { + if( lightmap) + SDL_FreeSurface( lightmap); + if( mapsurface) + SDL_FreeSurface( mapsurface); + + SDL_Quit(); + } + + /* + * SDL hack to tell SDL which xwindow to paint onto + */ + sprintf( SDL_windowhack, "SDL_WINDOWID=%ld", + GDK_WINDOW_XWINDOW(sdl_window->window) ); + putenv( SDL_windowhack); + + if( SDL_Init( SDL_INIT_VIDEO) < 0) + { + fprintf( stderr, "Could not initialize SDL: %s\n", SDL_GetError()); + gtk_main_quit(); + } + + mapsurface= SDL_SetVideoMode( image_size*mapx, image_size*mapy, 0, SDL_HWSURFACE|SDL_DOUBLEBUF); + + if( mapsurface == NULL) + { + do_SDL_error( "SetVideoMode", __FILE__, __LINE__); + } + } + + if( just_lightmap != 0) + { + if( lightmap) SDL_FreeSurface( lightmap); + } + + + lightmap= SDL_CreateRGBSurface( SDL_HWSURFACE|SDL_SRCALPHA, image_size, + image_size, + mapsurface->format->BitsPerPixel, + mapsurface->format->Rmask, + mapsurface->format->Gmask, + mapsurface->format->Bmask, + mapsurface->format->Amask); + if( lightmap == NULL) + { + do_SDL_error( "SDL_CreateRGBSurface", __FILE__, __LINE__); + } + + if( per_pixel_lighting) + { + /* Convert surface to have a full alpha channel if we are doing + * per-pixel lighting */ + lightmap= SDL_DisplayFormatAlpha( lightmap); + if( lightmap == NULL) + { + do_SDL_error( "DisplayFormatAlpha", __FILE__, __LINE__); + } + } + + if( show_grid == TRUE) + { + overlay_grid( TRUE, 0, 0); + } + } + #endif + void create_windows (void); /* Convert xpm memory buffer to xpm data (needed since GTK/GDK doesnt have a * function to create from buffer rather than data *************** *** 729,745 **** --- 855,897 ---- pixmaps[0].gdkpixmap = gdk_pixmap_create_from_xpm_d(gtkwin_root->window, &pixmaps[0].gdkmask, &style->bg[GTK_STATE_NORMAL], (gchar **)question); + #ifdef HAVE_SDL + /* SDL has totally lame support for loading XPM images, its rgb.txt database + * consists of 6 colors so we will just use a blue tile or something + * instead of a question mark + */ + surfaces[0].surface= SDL_CreateRGBSurface( SDL_HWSURFACE, + image_size, + image_size, + mapsurface->format->BitsPerPixel, + mapsurface->format->Rmask, + mapsurface->format->Gmask, + mapsurface->format->Bmask, + mapsurface->format->Amask); + + if( surfaces[0].surface == NULL) + do_SDL_error( "CreateRGBSurface", __FILE__, __LINE__); + + if ( SDL_FillRect( surfaces[0].surface, NULL, + SDL_MapRGB( mapsurface->format, 0, 0, 255)) < 0) + do_SDL_error( "FillRect", __FILE__, __LINE__); + + #endif + pixmaps[0].bg = 0; pixmaps[0].fg = 1; facetoname[0]=NULL; /* Initialize all the images to be of the same value. */ for (i=1; iwindow); display_map_doneupdate(TRUE); return TRUE; } /* Redraw the screen from the backing pixmap */ static gint expose_event (GtkWidget *widget, GdkEventExpose *event) { display_map_doneupdate(TRUE); return FALSE; } /* * Sets up player game view window, implemented as a gtk table. Cells are initialized * with the bg.xpm pixmap to avoid resizes and to initialize GC's and everything for the * actual drawing routines later. */ - - - - static int get_game_display(GtkWidget *frame) { GtkWidget *gtvbox, *gthbox; - gtvbox = gtk_vbox_new (FALSE, 0); gtk_container_add (GTK_CONTAINER (frame), gtvbox); gthbox = gtk_hbox_new (FALSE, 0); gtk_box_pack_start (GTK_BOX (gtvbox), gthbox, FALSE, FALSE, 1); ! ! drawingarea = gtk_drawing_area_new(); gtk_drawing_area_size(GTK_DRAWING_AREA(drawingarea), image_size*mapx,image_size*mapy); /* Add mouseclick events to the drawing area */ gtk_widget_set_events (drawingarea, GDK_BUTTON_PRESS_MASK); --- 1054,1102 ---- static gint configure_event (GtkWidget *widget, GdkEventConfigure *event) { + #ifdef HAVE_SDL + if( mapsurface) + SDL_UpdateRect( mapsurface, 0, 0, 0, 0); + #else mapgc = gdk_gc_new (drawingarea->window); display_map_doneupdate(TRUE); + #endif return TRUE; } /* Redraw the screen from the backing pixmap */ static gint expose_event (GtkWidget *widget, GdkEventExpose *event) { + #ifdef HAVE_SDL + if( mapsurface) + SDL_UpdateRect( mapsurface, 0, 0, 0, 0); + #else display_map_doneupdate(TRUE); + #endif return FALSE; } /* * Sets up player game view window, implemented as a gtk table. Cells are initialized * with the bg.xpm pixmap to avoid resizes and to initialize GC's and everything for the * actual drawing routines later. */ static int get_game_display(GtkWidget *frame) { GtkWidget *gtvbox, *gthbox; gtvbox = gtk_vbox_new (FALSE, 0); gtk_container_add (GTK_CONTAINER (frame), gtvbox); gthbox = gtk_hbox_new (FALSE, 0); gtk_box_pack_start (GTK_BOX (gtvbox), gthbox, FALSE, FALSE, 1); ! ! drawingarea = gtk_drawing_area_new(); gtk_drawing_area_size(GTK_DRAWING_AREA(drawingarea), image_size*mapx,image_size*mapy); /* Add mouseclick events to the drawing area */ gtk_widget_set_events (drawingarea, GDK_BUTTON_PRESS_MASK); *************** *** 961,971 **** --- 1118,1140 ---- gtk_widget_show(drawingarea); gtk_widget_show(gthbox); gtk_widget_show(gtvbox); + + + gtk_signal_connect (GTK_OBJECT (frame), "expose_event", + (GtkSignalFunc) expose_event, NULL); + gtk_signal_connect (GTK_OBJECT(frame),"configure_event", + (GtkSignalFunc) configure_event, NULL); + gtk_widget_show (frame); + + + #ifdef HAVE_SDL + /* init_SDL( drawingarea, 0); */ + #endif return 0; } *************** *** 3378,3387 **** --- 3547,3584 ---- if (nopopups) { gtk_tooltips_disable(tooltips); nopopups=FALSE; } } + #ifdef HAVE_SDL + if( GTK_TOGGLE_BUTTON( cradiobutton1)->active) { + if( per_pixel_lighting == 0) + { + per_pixel_lighting= 1; + per_tile_lighting= 0; + init_SDL( NULL, 1); + if( csocket.fd) + cs_write_string( csocket.fd, "mapredraw", 9); + } + } else { + if( per_pixel_lighting == 1) + { + per_pixel_lighting= 0; + per_tile_lighting= 1; + init_SDL( NULL, 1); + if( csocket.fd) + cs_write_string( csocket.fd, "mapredraw", 9); + } + } + if( GTK_TOGGLE_BUTTON( ccheckbutton9)->active) { + if( show_grid == FALSE) + show_grid= TRUE; + } else { + if( show_grid == TRUE) + show_grid= FALSE; + } + #endif } /* Ok, here it sets the config and saves it. This is sorta dangerous, and I'm not sure * if it's actually possible to do dynamic reconfiguration of everything this way. */ *************** *** 3490,3499 **** --- 3687,3724 ---- if (nopopups) { gtk_tooltips_disable(tooltips); nopopups=FALSE; } } + #ifdef HAVE_SDL + if( GTK_TOGGLE_BUTTON( cradiobutton1)->active) { + if( per_pixel_lighting == 0) + { + per_pixel_lighting= 1; + per_tile_lighting= 0; + init_SDL( NULL, 1); + if( csocket.fd) + cs_write_string( csocket.fd, "mapredraw", 9); + } + } else { + if( per_pixel_lighting == 1) + { + per_pixel_lighting= 0; + per_tile_lighting= 1; + init_SDL( NULL, 1); + if( csocket.fd) + cs_write_string( csocket.fd, "mapredraw", 9); + } + } + if( GTK_TOGGLE_BUTTON( ccheckbutton9)->active) { + if( show_grid == FALSE) + show_grid= TRUE; + } else { + if( show_grid == TRUE) + show_grid= FALSE; + } + #endif save_defaults(); } /*void cknumentry_callback (GtkWidget *widget, GdkEventKey *event, GtkWidget *window) { gtk_entry_set_text (GTK_ENTRY(ckeyentrytext), XKeysymToString(event->keyval)); *************** *** 3735,3745 **** if(!gtkwin_config) { gtkwin_config = gtk_window_new (GTK_WINDOW_DIALOG); gtk_window_position (GTK_WINDOW (gtkwin_config), GTK_WIN_POS_CENTER); ! gtk_widget_set_usize (gtkwin_config,450,360); gtk_window_set_title (GTK_WINDOW (gtkwin_config), "Crossfire Configure"); gtk_window_set_policy (GTK_WINDOW (gtkwin_config), TRUE, TRUE, FALSE); gtk_signal_connect (GTK_OBJECT (gtkwin_config), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), >kwin_config); --- 3960,3970 ---- if(!gtkwin_config) { gtkwin_config = gtk_window_new (GTK_WINDOW_DIALOG); gtk_window_position (GTK_WINDOW (gtkwin_config), GTK_WIN_POS_CENTER); ! gtk_widget_set_usize (gtkwin_config,450,400); gtk_window_set_title (GTK_WINDOW (gtkwin_config), "Crossfire Configure"); gtk_window_set_policy (GTK_WINDOW (gtkwin_config), TRUE, TRUE, FALSE); gtk_signal_connect (GTK_OBJECT (gtkwin_config), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), >kwin_config); *************** *** 3827,3844 **** --- 4052,4111 ---- gtk_toggle_button_set_state(GTK_TOGGLE_BUTTON(ccheckbutton8), TRUE); } else { gtk_toggle_button_set_state(GTK_TOGGLE_BUTTON(ccheckbutton8), FALSE); } + #ifdef HAVE_SDL + { + GtkWidget* label; + GtkWidget* separator = gtk_hseparator_new (); + gtk_box_pack_start (GTK_BOX (vbox1), separator, FALSE, TRUE, 0); + + + label= gtk_label_new((gchar*)"Lighting options, per pixel is prettier, per tile is faster"); + gtk_box_pack_start( GTK_BOX( vbox1), label, FALSE, FALSE, 0); + + + + cradiobutton1= gtk_radio_button_new_with_label( NULL, (gchar*)"Per Pixel Lighting"); + cradiobutton2 = gtk_radio_button_new_with_label_from_widget(GTK_RADIO_BUTTON(cradiobutton1), + (gchar*)"Per Tile Lighting"); + + gtk_box_pack_start( GTK_BOX( vbox1), cradiobutton1, FALSE, FALSE, 0); + gtk_box_pack_start( GTK_BOX( vbox1), cradiobutton2, FALSE, FALSE, 0); + + gtk_widget_show( separator); + gtk_widget_show( label); + + separator= gtk_hseparator_new(); + gtk_box_pack_start( GTK_BOX( vbox1), separator, FALSE, TRUE, 0); + gtk_widget_show( separator); + + ccheckbutton9= gtk_check_button_new_with_label( "Print Grid Overlay -- Slow, only really useful for debugging/development"); + gtk_box_pack_start( GTK_BOX(vbox1), ccheckbutton9, FALSE, FALSE, 0); + if( show_grid) { + gtk_toggle_button_set_state( GTK_TOGGLE_BUTTON( ccheckbutton9), TRUE); + } else { + gtk_toggle_button_set_state( GTK_TOGGLE_BUTTON( ccheckbutton9), FALSE); + } + } + + #endif /* HAVE_SDL */ + gtk_widget_show (ccheckbutton1); gtk_widget_show (ccheckbutton2); gtk_widget_show (ccheckbutton3); gtk_widget_show (ccheckbutton4); gtk_widget_show (ccheckbutton5); gtk_widget_show (ccheckbutton6); gtk_widget_show (ccheckbutton7); gtk_widget_show (ccheckbutton8); + #ifdef HAVE_SDL + gtk_widget_show (cradiobutton1); + gtk_widget_show (cradiobutton2); + gtk_widget_show (ccheckbutton9); + #endif gtk_widget_show (vbox1); gtk_widget_show (frame1); gtk_widget_show (vbox2); *************** *** 4758,4768 **** gtk_paned_add1 (GTK_PANED (game_bar_vpane), gameframe); get_game_display (gameframe); gtk_widget_show (gameframe); ! /* stats frame */ stat_frame = gtk_frame_new (NULL); gtk_frame_set_shadow_type (GTK_FRAME(stat_frame), GTK_SHADOW_ETCHED_IN); if (bigmap) gtk_paned_add1 (GTK_PANED (game_bar_vpane), stat_frame); --- 5025,5035 ---- gtk_paned_add1 (GTK_PANED (game_bar_vpane), gameframe); get_game_display (gameframe); gtk_widget_show (gameframe); ! /* stats frame */ stat_frame = gtk_frame_new (NULL); gtk_frame_set_shadow_type (GTK_FRAME(stat_frame), GTK_SHADOW_ETCHED_IN); if (bigmap) gtk_paned_add1 (GTK_PANED (game_bar_vpane), stat_frame); *************** *** 4811,4821 **** gtk_signal_connect_object (GTK_OBJECT (gtkwin_root), "key_press_event", GTK_SIGNAL_FUNC(keyfunc), GTK_OBJECT(gtkwin_root)); gtk_signal_connect_object (GTK_OBJECT (gtkwin_root), "key_release_event", GTK_SIGNAL_FUNC(keyrelfunc), GTK_OBJECT(gtkwin_root)); gtk_widget_show (gtkwin_root); ! } else { /* split window mode */ /* game window */ --- 5078,5091 ---- gtk_signal_connect_object (GTK_OBJECT (gtkwin_root), "key_press_event", GTK_SIGNAL_FUNC(keyfunc), GTK_OBJECT(gtkwin_root)); gtk_signal_connect_object (GTK_OBJECT (gtkwin_root), "key_release_event", GTK_SIGNAL_FUNC(keyrelfunc), GTK_OBJECT(gtkwin_root)); gtk_widget_show (gtkwin_root); ! ! #ifdef HAVE_SDL ! init_SDL( drawingarea, 0); ! #endif } else { /* split window mode */ /* game window */ *************** *** 4825,4835 **** gtk_widget_set_uposition (gtkwin_root, 300, 160); gtk_widget_set_usize (gtkwin_root,(image_size*mapx)+6,(image_size*mapy)+6); gtk_window_set_title (GTK_WINDOW (gtkwin_root), "Crossfire - view"); gtk_window_set_policy (GTK_WINDOW (gtkwin_root), TRUE, TRUE, FALSE); gtk_signal_connect (GTK_OBJECT (gtkwin_root), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), >kwin_root); ! gtk_container_border_width (GTK_CONTAINER (gtkwin_root), 0); rootvbox = gtk_vbox_new(FALSE, 0); gtk_container_add (GTK_CONTAINER (gtkwin_root), rootvbox); --- 5095,5106 ---- gtk_widget_set_uposition (gtkwin_root, 300, 160); gtk_widget_set_usize (gtkwin_root,(image_size*mapx)+6,(image_size*mapy)+6); gtk_window_set_title (GTK_WINDOW (gtkwin_root), "Crossfire - view"); gtk_window_set_policy (GTK_WINDOW (gtkwin_root), TRUE, TRUE, FALSE); gtk_signal_connect (GTK_OBJECT (gtkwin_root), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), >kwin_root); ! ! gtk_container_border_width (GTK_CONTAINER (gtkwin_root), 0); rootvbox = gtk_vbox_new(FALSE, 0); gtk_container_add (GTK_CONTAINER (gtkwin_root), rootvbox); *************** *** 4876,4886 **** gtkwin_info = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_widget_set_events (gtkwin_info, GDK_KEY_RELEASE_MASK); gtk_widget_set_uposition (gtkwin_info, 570, 0); gtk_widget_set_usize (gtkwin_info,400,600); gtk_window_set_title (GTK_WINDOW (gtkwin_info), "Crossfire - info"); ! gtk_window_set_policy (GTK_WINDOW (gtkwin_info), TRUE, TRUE, FALSE); gtk_signal_connect (GTK_OBJECT (gtkwin_info), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), >kwin_info); gtk_container_border_width (GTK_CONTAINER (gtkwin_info), 0); /* Alloc colors - not entirely necessary, really, since GTK should do this */ --- 5147,5157 ---- gtkwin_info = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_widget_set_events (gtkwin_info, GDK_KEY_RELEASE_MASK); gtk_widget_set_uposition (gtkwin_info, 570, 0); gtk_widget_set_usize (gtkwin_info,400,600); gtk_window_set_title (GTK_WINDOW (gtkwin_info), "Crossfire - info"); ! gtk_window_set_policy (GTK_WINDOW (gtkwin_info), TRUE, TRUE, FALSE); gtk_signal_connect (GTK_OBJECT (gtkwin_info), "destroy", GTK_SIGNAL_FUNC(gtk_widget_destroyed), >kwin_info); gtk_container_border_width (GTK_CONTAINER (gtkwin_info), 0); /* Alloc colors - not entirely necessary, really, since GTK should do this */ *************** *** 4997,5014 **** --- 5268,5291 ---- gtk_signal_connect_object (GTK_OBJECT (gtkwin_stats), "key_press_event", GTK_SIGNAL_FUNC(keyfunc), GTK_OBJECT(gtkwin_stats)); gtk_signal_connect_object (GTK_OBJECT (gtkwin_stats), "key_release_event", GTK_SIGNAL_FUNC(keyrelfunc), GTK_OBJECT(gtkwin_stats)); + + #ifdef HAVE_SDL + init_SDL( drawingarea, 0); + #endif + } /* else split windows */ /* load window positions from file */ set_window_pos(); gtk_tooltips_set_delay(tooltips, 1000 ); if (tool_tips) { gtk_tooltips_enable(tooltips); } + } int sync_display = 0; static int get_root_display(char *display_name,int gargc, char **gargv) { gtk_init (&gargc,&gargv); *************** *** 5021,5031 **** */ if (display_mode == Png_Display) { gdk_rgb_init(); } create_windows(); ! return 0; } /* null procedures. gtk does this for us. */ --- 5298,5308 ---- */ if (display_mode == Png_Display) { gdk_rgb_init(); } create_windows(); ! return 0; } /* null procedures. gtk does this for us. */ *************** *** 5552,5563 **** puts("-port - Use port instead of the standard port number"); puts("-display - Use instead if DISPLAY environment variable.\n"); puts("-split - Use split windows."); puts("-echo - Echo the bound commands"); #ifdef Xpm_Pix puts("-xpm - Use color pixmaps (XPM) for display."); ! #endif #ifdef HAVE_LIBPNG puts("-png - Use png images for display."); #endif puts("-showicon - Print status icons in inventory window"); puts("-scrolllines - number of lines for scrollback"); --- 5829,5842 ---- puts("-port - Use port instead of the standard port number"); puts("-display - Use instead if DISPLAY environment variable.\n"); puts("-split - Use split windows."); puts("-echo - Echo the bound commands"); #ifdef Xpm_Pix + #ifndef HAVE_SDL puts("-xpm - Use color pixmaps (XPM) for display."); ! #endif /* HAVE_SDL */ ! #endif /* Xpm_Pix */ #ifdef HAVE_LIBPNG puts("-png - Use png images for display."); #endif puts("-showicon - Print status icons in inventory window"); puts("-scrolllines - number of lines for scrollback"); *************** *** 5570,5580 **** --- 5849,5861 ---- puts("-keepcache - Keep already cached images even if server has different ones."); puts("-pngfile - Use for source of images"); puts("-nopopups - Don't use pop up windows for input"); puts("-splitinfo - Use two information windows, segregated by information type."); puts("-mapsize xXy - Set the mapsize to be X by Y spaces."); + #ifndef HAVE_SDL puts("-pngximage - Use ximage for drawing png (may not work on all hardware"); + #endif exit(0); } /* init_windows: This initiliazes all the windows - it is an *************** *** 5769,5788 **** --- 6050,6087 ---- /* Do the pixmap copy with gc to tile it onto the stack in the cell */ static void gen_draw_face(int face,int x,int y) { + #ifdef HAVE_SDL + + SDL_Rect dst; + dst.x= x* image_size; + dst.y= y* image_size; + dst.w= image_size; + dst.h= image_size; + + if( SDL_BlitSurface( surfaces[ facecachemap[face]].surface, NULL, + mapsurface, &dst) < 0) + { + do_SDL_error( "BlitSurface", __FILE__, __LINE__); + } + return; + + #else + if (face == 0) fprintf(stderr,"gen draw face called with 0 face"); #if 0 if (pixmaps[0].gdkpixmap == pixmaps[facecachemap[face]].gdkpixmap) fprintf(stderr,"gen_draw_face - called with ? pixmap - num = %d, (%d,%d)\n", face, x,y); #endif gdk_gc_set_clip_mask (mapgc, pixmaps[facecachemap[face]].gdkmask); gdk_gc_set_clip_origin (mapgc, image_size*x, image_size*y); gdk_window_copy_area (drawingarea->window, mapgc, image_size*x, image_size*y, pixmaps[facecachemap[face]].gdkpixmap,0,0,image_size,image_size); + #endif /* else NO SDL */ } /* Draw the tiled pixmap tiles in the mapcell */ *************** *** 5805,5814 **** --- 6104,6265 ---- /* this differs from below in that we use one big image struture * for the entire screen. That is the 'screen' value above. */ + #ifdef HAVE_SDL + int sdl_add_png_faces( int ax, int ay, int *faces, int num_faces, int dark[5]) + { + + int x, y, darkness, on_face, darkx[32], darky; + Uint32 pixel; + SDL_PixelFormat *fmt; + int semi= 0; + SDL_Rect dst; + + dst.x= ax* image_size; + dst.y= ay* image_size; + dst.w= image_size; + dst.h= image_size; + + + + /* Nothing to draw here, so paint a black square */ + if( !num_faces) + { + if( SDL_FillRect( mapsurface, &dst, + SDL_MapRGB( mapsurface->format, 0, 0, 0)) < 0) + do_SDL_error( "FillRect", __FILE__, __LINE__); + return 0; + } + + for( on_face= num_faces -1; on_face > -1; on_face--) + { + if( SDL_BlitSurface( surfaces[faces[on_face]].surface, NULL, + mapsurface, &dst) < 0) + { + do_SDL_error( "BlitSurface", __FILE__, __LINE__); + } + } + + if( per_tile_lighting) + { + if( dark[0] == 255) + { + /* Fully bright, no reason to blit a light map */ + return 0; + } + else if( dark[0] == 0) + { + /* Fully dark, just paint black */ + SDL_FillRect( lightmap, NULL, + SDL_MapRGB( lightmap->format, 0, 0, 0)); + SDL_BlitSurface( lightmap, NULL, mapsurface, &dst); + + return 0; + } + else { + SDL_FillRect( lightmap, NULL, + SDL_MapRGB( lightmap->format, 0, 0, 0)); + /* Set per surface alpha channel */ + SDL_SetAlpha( lightmap, SDL_SRCALPHA, SDL_ALPHA_OPAQUE - dark[0]); + SDL_BlitSurface( lightmap, NULL, mapsurface, &dst); + + return 0; + } + + } + else if( per_pixel_lighting) + { + for( x= 0; x < 16; x++) + { + darkx[x]= (dark[4]*(16-x) + dark[0]*x) / 16; + } + for( x= 16; x < 32; x++) + { + darkx[x] = (dark[0]*(32-x) + dark[2]*(x-16)) / 16; + } + + /* + * Make sure lightmap in initialized to full bright + */ + SDL_FillRect( lightmap, NULL, + SDL_MapRGBA( lightmap->format, 0, 0, 0, + SDL_ALPHA_TRANSPARENT)); + + fmt= lightmap->format; + SDL_LockSurface( lightmap); + for( y= 0; y < image_size; y++) + { + if( y < 16) + { + darky = ((dark[1]*((image_size/2)-y)) + dark[0]*y) / + (image_size / 2); + } + else + { + darky= (dark[0]*(image_size-y) + dark[3]*(y-(image_size/2))) / + (image_size / 2); + } + + for( x= 0; x < image_size; x++) + { + + darkness= (darkx[x] + darky) / 2; + if( darkness == 255) + continue; + else + semi++; + + /* Need to invert the transparancy level.. */ + pixel= SDL_MapRGBA( fmt, 0, 0, 0, SDL_ALPHA_OPAQUE - darkness); + + switch (fmt->BytesPerPixel) + { + case 1: + *((Uint8 *)lightmap->pixels+y*lightmap->pitch+x) = pixel; + break; + case 2: + *((Uint16 *)lightmap->pixels+y*lightmap->pitch/2+x) = pixel; + break; + case 3: + /* Don't think we will get here if we have a full alpha + * channel. If so that implies 6|6|6|6 RGBA packing which + * is kinda weird.. + */ + ((Uint8 *)lightmap->pixels+y*lightmap->pitch+x)[0] = 0; + ((Uint8 *)lightmap->pixels+y*lightmap->pitch+x)[1] = 0; + ((Uint8 *)lightmap->pixels+y*lightmap->pitch+x)[2] = 0; + break; + case 4: + *((Uint32 *)lightmap->pixels+y*lightmap->pitch/4+x) = pixel; + break; + } + } + } + SDL_UnlockSurface( lightmap); + + if( semi > 0) + { + if( SDL_BlitSurface( lightmap, NULL, mapsurface, &dst) < 0) + { + do_SDL_error( "BlitSurface", __FILE__, __LINE__); + } + } + } + else + { + /* Unknown lighting style */ + fprintf( stderr, "Error, unknowing lighting style in %s at line %d\n", + __FILE__, __LINE__); + } + + return 0; + } + + #else /* HAVE_SDL */ + int add_png_faces(int ax, int ay, int *faces, int num_faces, int dark[5]) { int x,y, a, darkness ,pos=0, on_face,darkx[32], darky, screen_pos, rowy; /* If we don't have png_data, can't proceed further */ *************** *** 5942,5960 **** pos+=4; } /* for x loop */ } return 0; } ! void display_mapcell_pixmap(int ax,int ay) { ! int k, got_face=0, faces[MAXFACES],num_faces, darkness[5]; /* we use a different logic in this mode */ if (display_mode == Png_Display && pngximage) { ! num_faces=0; if (map1cmd) { for(k=the_map.cells[ax][ay].count-1;k>-1;k--) { if (the_map.cells[ax][ay].faces[k] >0 ) faces[num_faces++] = the_map.cells[ax][ay].faces[k]; --- 6393,6417 ---- pos+=4; } /* for x loop */ } return 0; } ! #endif /* HAVE_SDL */ void display_mapcell_pixmap(int ax,int ay) { ! int k, faces[MAXFACES],num_faces, darkness[5]; ! #ifndef HAVE_SDL ! int got_face= 0; ! #endif /* we use a different logic in this mode */ + #ifndef HAVE_SDL if (display_mode == Png_Display && pngximage) { ! #else ! if (display_mode == Png_Display) { ! #endif num_faces=0; if (map1cmd) { for(k=the_map.cells[ax][ay].count-1;k>-1;k--) { if (the_map.cells[ax][ay].faces[k] >0 ) faces[num_faces++] = the_map.cells[ax][ay].faces[k]; *************** *** 5981,5994 **** --- 6438,6456 ---- faces[num_faces++] = the_map.cells[ax][ay].faces[k]; } /* old mode doesn't have darkness, so just set to full bright */ darkness[0]=255;darkness[1]=255;darkness[2]=255;darkness[3]=255;darkness[4]=255; } + #ifndef HAVE_SDL if (add_png_faces(ax,ay, faces, num_faces,darkness)) goto bail; + #else + sdl_add_png_faces( ax, ay, faces, num_faces, darkness); + #endif return; } + #ifndef HAVE_SDL bail: #if 0 /* commenting this out eliminates flickering you will otherwise see. * The problem is that if there are any maps that still don't have * floors, this probably won't draw objects on top properly. *************** *** 6023,6036 **** } } else for(k=the_map.cells[ax][ay].count-1;k>-1;k--) { gen_draw_face(the_map.cells[ax][ay].faces[k], ax,ay); } } - /* Do the map drawing */ void display_map_doneupdate(int redraw) { int ax,ay, need_updates=0; --- 6485,6498 ---- } } else for(k=the_map.cells[ax][ay].count-1;k>-1;k--) { gen_draw_face(the_map.cells[ax][ay].faces[k], ax,ay); } + #endif } /* Do the map drawing */ void display_map_doneupdate(int redraw) { int ax,ay, need_updates=0; *************** *** 6044,6053 **** --- 6506,6527 ---- updatelock++; /* draw black on all non-visible squares, and tile pixmaps on the others */ for(ax=0;ax 0 || map_did_scroll) { + if( SDL_Flip( mapsurface) == 1 ) + do_SDL_error( "Flip", __FILE__, __LINE__); + + map_did_scroll= 0; + } + #endif #ifdef TIME_MAP_REDRAW gettimeofday(&tv2, NULL); #endif + #ifndef HAVE_SDL if (pngximage) { int draw_each_space=1; /* if we need to redraw the entire thing or the number of changed spaces is * more than a quarter of the map, just put the the entire image to the * screen. *************** *** 6109,6118 **** --- 6594,6604 ---- the_map.cells[ax][ay].need_update=0; } } map_did_scroll=0; } + #endif /* ! HAVE_SDL */ } /* if updatelock */ #ifdef TIME_MAP_REDRAW /* this else branches fro the if updatelock above - without it * tv2 is uninitialized. */ *************** *** 6157,6166 **** --- 6643,6653 ---- * narrow, we then will have the stats on top, with message down below * the map window. IF the map window is wide, we put these side * by side at the top */ if (bigmap && x<15) { + /* reverse of below basically. */ GtkWidget *newpane; /* will take place of game_bar_vpane */ bigmap =FALSE; *************** *** 6186,6207 **** gtk_widget_ref(gameframe); gtk_container_remove(GTK_CONTAINER(stat_game_vpane), gameframe); gtk_paned_add1(GTK_PANED(newpane), gameframe); gtk_widget_unref(gameframe); - gtk_paned_add2(GTK_PANED(stat_game_vpane), newpane); gtk_widget_show(newpane); /* This should also destroy it */ gtk_widget_unref(game_bar_vpane); game_bar_vpane = newpane; } else if (!bigmap && x>=15) { GtkWidget *newpane; /* will take place of game_bar_vpane */ bigmap=TRUE; - newpane = gtk_hpaned_new(); /* We need to remove this here - the game pane is goind to * take game_bar_vpane as second position in the stat_game_vpane. * add a refcount so it isn't destroyed. --- 6673,6693 ---- gtk_widget_ref(gameframe); gtk_container_remove(GTK_CONTAINER(stat_game_vpane), gameframe); gtk_paned_add1(GTK_PANED(newpane), gameframe); gtk_widget_unref(gameframe); gtk_paned_add2(GTK_PANED(stat_game_vpane), newpane); gtk_widget_show(newpane); /* This should also destroy it */ gtk_widget_unref(game_bar_vpane); game_bar_vpane = newpane; } else if (!bigmap && x>=15) { + GtkWidget *newpane; /* will take place of game_bar_vpane */ bigmap=TRUE; newpane = gtk_hpaned_new(); /* We need to remove this here - the game pane is goind to * take game_bar_vpane as second position in the stat_game_vpane. * add a refcount so it isn't destroyed. *************** *** 6238,6249 **** gtk_widget_unref(game_bar_vpane); game_bar_vpane = newpane; } gtk_widget_set_usize (gameframe, (image_size*mapx)+6, (image_size*mapy)+6); } else { ! gtk_widget_set_usize (gtkwin_root,(image_size*mapx)+6,(image_size*mapy)+6); } } /* If we are using ximage logic, we use a different mechanism to load the * image. */ --- 6724,6741 ---- gtk_widget_unref(game_bar_vpane); game_bar_vpane = newpane; } gtk_widget_set_usize (gameframe, (image_size*mapx)+6, (image_size*mapy)+6); } else { ! gtk_widget_set_usize (gtkwin_root,(image_size*mapx)+6,(image_size*mapy)+6); } + + #ifdef HAVE_SDL + init_SDL( drawingarea, FALSE); + #endif + + } /* If we are using ximage logic, we use a different mechanism to load the * image. */ *************** *** 6270,6280 **** if (pngximage) { if (!(pixmaps[face].png_data = png_to_data(buf, (int)buflen))) { fprintf(stderr,"unable to create image %ld\n", face); } } ! /* even if using pngximage, we standard image for the inventory list */ if (png_to_gdkpixmap(gtkwin_root->window, buf, buflen, &pixmaps[face].gdkpixmap, &pixmaps[face].gdkmask, gtk_widget_get_colormap(gtkwin_root))) { fprintf(stderr,"Got error on png_to_gdkpixmap\n"); } --- 6762,6788 ---- if (pngximage) { if (!(pixmaps[face].png_data = png_to_data(buf, (int)buflen))) { fprintf(stderr,"unable to create image %ld\n", face); } } ! #ifdef HAVE_SDL ! { ! SDL_RWops* ops= SDL_RWFromMem( buf, (int)buflen); ! surfaces[face].surface= IMG_LoadTyped_RW( ops, 1, (char*)"PNG"); ! if( surfaces[face].surface == NULL) ! { ! do_SDL_error( "IMG_LoadTyped_RW", __FILE__, __LINE__); ! } ! /* If this surface has transparent elements, enable RLE acceleration */ ! if( (surfaces[face].surface->flags & SDL_SRCCOLORKEY) == SDL_SRCCOLORKEY) ! { ! SDL_SetColorKey( surfaces[face].surface, SDL_SRCCOLORKEY|SDL_RLEACCEL, ! surfaces[face].surface->format->colorkey); ! } ! } ! #endif ! /* even if using pngximage or SDL, we standard image for the inventory list */ if (png_to_gdkpixmap(gtkwin_root->window, buf, buflen, &pixmaps[face].gdkpixmap, &pixmaps[face].gdkmask, gtk_widget_get_colormap(gtkwin_root))) { fprintf(stderr,"Got error on png_to_gdkpixmap\n"); } *************** *** 6380,6389 **** --- 6888,6901 ---- } if (cache_images && facetoname[i]!=NULL) { free(facetoname[i]); facetoname[i]=NULL; } + #ifdef HAVE_SDL + if( surfaces[i].surface && (surfaces[i].surface != surfaces[0].surface) ) + SDL_FreeSurface( surfaces[i].surface); + #endif } memset(&the_map, 0, sizeof(struct Map)); look_list.env=cpl.below; } Common subdirectories: client/help and /home/smf/projects/crossfire/cvs/client/help Common subdirectories: client/macros and /home/smf/projects/crossfire/cvs/client/macros Common subdirectories: client/pixmaps and /home/smf/projects/crossfire/cvs/client/pixmaps Common subdirectories: client/utils and /home/smf/projects/crossfire/cvs/client/utils diff -c5 --exclude-from=exclude client/xutil.c /home/smf/projects/crossfire/cvs/client/xutil.c *** client/xutil.c Wed Jun 13 00:01:20 2001 --- /home/smf/projects/crossfire/cvs/client/xutil.c Fri Jun 15 19:34:21 2001 *************** *** 269,283 **** requestface(pnum, face, buf); } } else if (display_mode == Png_Display) { #ifdef HAVE_LIBPNG if (pngximage && !(pixmaps[pnum].png_data = png_to_data(data, (int)len))) { fprintf(stderr,"Got error on png_to_data, file=%s\n",buf); requestface(pnum, face, buf); } ! /* even if using pngximage, we standard image for the inventory list */ if (png_to_gdkpixmap(gtkwin_root->window, data, len, &pixmaps[pnum].gdkpixmap, &pixmaps[pnum].gdkmask,gtk_widget_get_colormap(gtkwin_root))) { fprintf(stderr,"Got error on png_to_gdkpixmap, file=%s\n",buf); requestface(pnum, face, buf); } --- 269,303 ---- requestface(pnum, face, buf); } } else if (display_mode == Png_Display) { #ifdef HAVE_LIBPNG + #ifndef HAVE_SDL if (pngximage && !(pixmaps[pnum].png_data = png_to_data(data, (int)len))) { fprintf(stderr,"Got error on png_to_data, file=%s\n",buf); requestface(pnum, face, buf); } ! #else ! fprintf( stdout, "Getting PNG face %d data from memory\n", pnum); ! { ! SDL_RWops *ops= SDL_RWFromMem( data, len); ! surfaces[pnum].surface= IMG_LoadTyped_RW( ops, 1, (char*)"PNG"); ! ! /* ! * Not sure if this is an error condition or not... ! * below it makes a call to requestface but if he does it, ! * we don't have to. ! */ ! if( surfaces[pnum].surface == NULL) ! { ! } ! else ! { ! } ! } ! #endif /* HAVE_SDL */ ! /* even if using pngximage or SDL we still need standard image for the inventory list */ if (png_to_gdkpixmap(gtkwin_root->window, data, len, &pixmaps[pnum].gdkpixmap, &pixmaps[pnum].gdkmask,gtk_widget_get_colormap(gtkwin_root))) { fprintf(stderr,"Got error on png_to_gdkpixmap, file=%s\n",buf); requestface(pnum, face, buf); } *************** *** 306,316 **** requestface(pnum, face, buf); } else { pixmaps[pnum].pixmap = pixmap; pixmaps[pnum].mask = mask; } ! #endif } else if (display_mode==Pix_Display) { pixmaps[pnum].bitmap = XCreateBitmapFromData(display, RootWindow(display,DefaultScreen(display)), (char*)data,24,24); pixmaps[pnum].fg = (data[24] << 24) + (data[25] << 16) + (data[26] << 8) + --- 326,359 ---- requestface(pnum, face, buf); } else { pixmaps[pnum].pixmap = pixmap; pixmaps[pnum].mask = mask; } ! ! #ifdef GDK_XUTIL ! #ifdef HAVE_SDL ! fprintf( stdout, "Getting PNG face %d data from memory\n", pnum); ! { ! SDL_RWops *ops= SDL_RWFromMem( data, len); ! surfaces[pnum].surface= IMG_LoadTyped_RW( ops, 1, (char*)"PNG"); ! ! /* ! * Not sure if this is an error condition or not... ! * below it makes a call to requestface but if he does it, ! * we don't have to. ! */ ! if( surfaces[pnum].surface == NULL) ! { ! } ! else ! { ! } ! } ! #endif /* HAVE_SDL */ ! #endif /* GDK_XUTIL */ ! ! #endif /* HAVE_LIBPNG */ } else if (display_mode==Pix_Display) { pixmaps[pnum].bitmap = XCreateBitmapFromData(display, RootWindow(display,DefaultScreen(display)), (char*)data,24,24); pixmaps[pnum].fg = (data[24] << 24) + (data[25] << 16) + (data[26] << 8) + *************** *** 1496,1505 **** --- 1539,1565 ---- if (!strcmp(inbuf,"nopopups")) { if (!strcmp(cp,"True")) nopopups=TRUE; else nopopups=FALSE; continue; } + #ifdef HAVE_SDL + if( !strcmp( inbuf,"Lighting")) { + if( !strcmp( cp, "per_pixel")) { + per_pixel_lighting= 1; + per_tile_lighting= 0; + } else if( !strcmp( cp, "per_tile")) { + per_pixel_lighting= 0; + per_tile_lighting= 1; + } + continue; + } + if( !strcmp( inbuf,"show_grid")) { + if( !strcmp( cp, "True")) show_grid = TRUE; + else show_grid = FALSE; + continue; + } + #endif #endif fprintf(stderr,"Got line we did not understand: %s: %s\n", inbuf, cp); } fclose(fp); } *************** *** 1550,1560 **** fprintf(fp,"colorinv: %s\n", color_inv?"True":"False"); fprintf(fp,"colortext: %s\n", color_text?"True":"False"); fprintf(fp,"tooltips: %s\n", color_text?"True":"False"); fprintf(fp,"splitinfo: %s\n", splitinfo?"True":"False"); fprintf(fp,"nopopups: %s\n", nopopups?"True":"False"); ! #endif fclose(fp); sprintf(buf,"Defaults saved to %s",path); draw_info(buf,NDI_BLUE); } --- 1610,1628 ---- fprintf(fp,"colorinv: %s\n", color_inv?"True":"False"); fprintf(fp,"colortext: %s\n", color_text?"True":"False"); fprintf(fp,"tooltips: %s\n", color_text?"True":"False"); fprintf(fp,"splitinfo: %s\n", splitinfo?"True":"False"); fprintf(fp,"nopopups: %s\n", nopopups?"True":"False"); ! #ifdef HAVE_SDL ! if( per_pixel_lighting) ! fprintf( fp, "Lighting: per_pixel\n"); ! else ! fprintf( fp, "Lighting: per_tile\n"); ! fprintf( fp,"show_grid: %s\n", show_grid?"True":"False"); ! #endif /* HAVE_SDL */ ! #endif /* GDK_XUTIL */ ! fclose(fp); sprintf(buf,"Defaults saved to %s",path); draw_info(buf,NDI_BLUE); } *************** *** 1756,1765 **** --- 1824,1952 ---- the_map.cells[x][y].have_darkness = 0; for (i=0; iformat->BitsPerPixel, + mapsurface->format->Rmask, + mapsurface->format->Gmask, + mapsurface->format->Bmask, + mapsurface->format->Amask); + if( grid_overlay == NULL) + abort(); + + grid_overlay= SDL_DisplayFormatAlpha( grid_overlay); + + first_pass= 0; + } + + /* + * If this is our first time drawing the grid, we need to build up the + * grid overlay + */ + if( first_pass== 0) + { + + /* Red pixels around the edge and along image borders + * fully transparent pixels everywhere else + */ + + fmt= grid_overlay->format; + for( x= 0; x < image_size*mapx; x++) + { + for( y= 0; y < image_size*mapy; y++) + { + /* FIXME: Only works for 32 bit displays right now */ + pixel= (Uint32*)grid_overlay->pixels+y*grid_overlay->pitch/4+x; + + if( x == 0 || y == 0 || + ((x % image_size) == 0) || ((y % image_size) == 0 ) ) + { + *pixel= SDL_MapRGBA( fmt, 255, 0, 0, SDL_ALPHA_OPAQUE); + } + else + { + *pixel= SDL_MapRGBA( fmt, 0, 0, 0, SDL_ALPHA_TRANSPARENT); + } + } + } + first_pass= 1; + + /* + * If this is our first pass then we need to overlay the entire grid + * now. Otherwise we just update the tile we are on + */ + dst.x= 0; + dst.y= 0; + dst.w= image_size*mapx; + dst.h= image_size*mapy; + SDL_BlitSurface( grid_overlay, NULL, mapsurface, &dst); + } + else + { + dst.x= ax* image_size; + dst.y= ay* image_size; + dst.w= image_size; + dst.h= image_size; + /* One to one pixel mapping of grid and mapsurface so we + * can share the SDL_Rect + */ + SDL_BlitSurface( grid_overlay, &dst, mapsurface, &dst); + } + + return; + } + #endif + #endif + void set_map_darkness(int x, int y, uint8 darkness) { the_map.cells[x][y].have_darkness = 1; if (darkness != (255 - the_map.cells[x][y].darkness )) { the_map.cells[x][y].darkness = 255 - darkness; *************** *** 1768,1784 **** /* pretty ugly - since the light code with pngximage uses * neighboring spaces to adjust the darkness, we now need to * let the neighbors know they should update their darkness * now. */ if (pngximage) { if (x-1>0) the_map.cells[x-1][y].need_update = 1; if (y-1>0) the_map.cells[x][y-1].need_update = 1; if (x+10) the_map.cells[x-1][y].need_update = 1; if (y-1>0) the_map.cells[x][y-1].need_update = 1; if (x+10) the_map.cells[x-1][y].need_update = 1; ! if (y-1>0) the_map.cells[x][y-1].need_update = 1; ! if (x+1 Could the following please be done with the scriptfire mods: 1) Add in the standard copyright (and version id) heading to the files? 2) Perhaps change the autoconf stuff so that it doesn't put the guile flags into EXTRA_.. flags and instead puts it into the CFLAGS And LIBS and LDFLAGS autoconf values? Reason is twofold - by putting it in those, you can actually run the 'make' from one of the subdirectories and get all the needed values and second, the EXTRA_... flags were really meant for customizations the end user may want to put in, and were not met for putting in stuff found by autoconf 3) Fix the following compiling warnings (these were found with gcc -Wall). Many of these are harmles, but crossfire generally compiles cleanly with -Wall, and some of these are probably real errors (the only warnings that should show up when compiling with -Wall is for the files automatically generated from the .l files (ie, loader.c, reader.c, ...) - there isn't much that can be done since the .c files are automatically generated save for hand editing (or doing greps or sed or other goofy stuff) with the files that flex generates. Thanks. arch.c: In function `find_archetype_by_object_name': arch.c:56: warning: unused variable `i' arch.c:55: warning: unused variable `index' arch.c: In function `find_best_weapon_used_match': arch.c:104: warning: implicit declaration of function `item_matched_string' (btw, I really don't think item_matched_string should be in this file - if needed by the common side, then perhaps in item.c, but that is not an arch related function) apply.c: In function `manual_apply': apply.c:1981: warning: `return' with no value, in function returning non-void apply.c:1986: warning: `return' with no value, in function returning non-void attack.c: In function `attack_ob_simple': attack.c:415: warning: `return' with no value, in function returning non-void gcc -ggdb -pg -Wall -I/usr/include -I../include -I./../include -c ban.c attack.c: In function `kill_object': attack.c:1028: warning: `return' with no value, in function returning non-void attack.c:1036: warning: `return' with no value, in function returning non-void attack.c:1018: warning: unused variable `hitter_tag' attack.c:1018: warning: unused variable `op_tag' attack.c:1017: warning: unused variable `simple_attack' attack.c:1016: warning: unused variable `body_attack' attack.c:1015: warning: unused variable `magic' attack.c:1015: warning: unused variable `attacknum' attack.c:1015: warning: unused variable `attacktype' attack.c:1015: warning: unused variable `ndam' attack.c: In function `hit_player': attack.c:1258: warning: unused variable `battleg' attack.c:1253: warning: unused variable `old_hitter' attack.c:1252: warning: unused variable `buf' main.c: In function `main': main.c:1051: warning: control reaches end of non-void function monster.c: In function `talk_to_npc': monster.c:1355: warning: `return' with no value, in function returning non-void script.c: In function `guile_init_functions': script.c:227: warning: implicit declaration of function `guile_init_spell_functions' script.c: In function `guile_call_event': script.c:240: warning: unused variable `buf' script.c: In function `guile_call_event_str': script.c:274: warning: unused variable `buf' script.c: In function `guile_use_weapon_script': script.c:308: warning: unused variable `buf' script.c: In function `Script_setCursed': script.c:474: warning: control reaches end of non-void function script.c: In function `Script_activateRune': script.c:479: warning: control reaches end of non-void function script.c: In function `Script_checkTrigger': script.c:484: warning: control reaches end of non-void function script.c: In function `Script_setUnaggressive': script.c:497: warning: control reaches end of non-void function script.c: In function `Script_setGod': script.c:529: warning: control reaches end of non-void function script.c: In function `Script_setWeight': script.c:534: warning: control reaches end of non-void function script.c: In function `Script_teleport': script.c:558: warning: control reaches end of non-void function script.c: In function `Script_pickUp': script.c:568: warning: control reaches end of non-void function script.c: In function `Script_getMap': script.c:600: warning: control reaches end of non-void function script.c: In function `Script_setQuantity': script.c:605: warning: control reaches end of non-void function script.c: In function `Script_insertObjectInside': script.c:621: warning: control reaches end of non-void function script.c: In function `Script_drop': script.c:649: warning: control reaches end of non-void function script.c: In function `Script_take': script.c:657: warning: control reaches end of non-void function script.c: In function `Script_setInvisible': script.c:677: warning: control reaches end of non-void function script.c: In function `Script_setXP': script.c:687: warning: control reaches end of non-void function script.c: In function `Script_setReturnValue': script.c:696: warning: control reaches end of non-void function script.c: In function `Script_setDirection': script.c:707: warning: control reaches end of non-void function script.c: In function `Script_setScriptDeath': script.c:757: warning: control reaches end of non-void function script.c: In function `Script_setScriptLoad': script.c:764: warning: control reaches end of non-void function script.c: In function `Script_setScriptApply': script.c:771: warning: control reaches end of non-void function script.c: In function `Script_setScriptSay': script.c:778: warning: control reaches end of non-void function script.c: In function `Script_setScriptTrigger': script.c:785: warning: control reaches end of non-void function script.c: In function `Script_setScriptTime': script.c:799: warning: control reaches end of non-void function script.c: In function `Script_setScriptAttack': script.c:806: warning: control reaches end of non-void function script.c: In function `Script_setScriptDrop': script.c:813: warning: control reaches end of non-void function script.c: In function `Script_setScriptThrow': script.c:820: warning: control reaches end of non-void function script.c: In function `Script_setScriptStop': script.c:827: warning: control reaches end of non-void function script.c: In function `Script_setSpeed': script.c:832: warning: control reaches end of non-void function script.c: In function `Script_setLastSP': script.c:846: warning: control reaches end of non-void function script.c: In function `Script_setLastGP': script.c:856: warning: control reaches end of non-void function script.c: In function `Script_fixObject': script.c:861: warning: control reaches end of non-void function script.c: In function `Script_setFace': script.c:870: warning: control reaches end of non-void function script.c: In function `Script_setAttackType': script.c:875: warning: control reaches end of non-void function script.c: In function `Script_setDamage': script.c:885: warning: control reaches end of non-void function script.c: In function `Script_getDamage': script.c:890: warning: control reaches end of non-void function script.c: In function `Script_setBeenApplied': script.c:902: warning: control reaches end of non-void function script.c: In function `Script_setIdentified': script.c:914: warning: control reaches end of non-void function script.c: In function `Script_killObject': script.c:930: warning: implicit declaration of function `kill_object' script.c:942: warning: control reaches end of non-void function script.c: In function `Script_castAbility': script.c:982: warning: control reaches end of non-void function script.c: In function `Script_castSpell': script.c:990: warning: control reaches end of non-void function script.c: In function `Script_forgetSpell': script.c:995: warning: control reaches end of non-void function script.c: In function `Script_acquireSpell': script.c:1000: warning: control reaches end of non-void function script.c: In function `Script_removeObject': script.c:1174: warning: control reaches end of non-void function script.c: In function `Script_crossfireSay': script.c:1211: warning: control reaches end of non-void function script.c: In function `Script_crossfireWrite': script.c:1216: warning: unused variable `buf' script.c:1234: warning: control reaches end of non-void function script.c: In function `Script_crossfireMessage': script.c:1239: warning: unused variable `buf' script.c:1254: warning: control reaches end of non-void function gcc -ggdb -pg -Wall -I/usr/include -I../include -I./../include -c script_types.c script.c: In function `Script_setPosition': script.c:1475: warning: control reaches end of non-void function script.c: In function `Script_setTitle': script.c:1502: warning: control reaches end of non-void function script.c: In function `Script_setAC': script.c:1510: warning: control reaches end of non-void function script.c: In function `Script_setHP': script.c:1574: warning: control reaches end of non-void function script.c: In function `Script_setSP': script.c:1582: warning: control reaches end of non-void function script.c: In function `Script_setFP': script.c:1590: warning: control reaches end of non-void function script.c: In function `Script_setGP': script.c:1598: warning: control reaches end of non-void function script.c: In function `Script_setMaxHP': script.c:1606: warning: control reaches end of non-void function script.c: In function `Script_setMaxSP': script.c:1614: warning: control reaches end of non-void function script.c: In function `Script_setCha': script.c:1622: warning: unused variable `buf' script.c:1629: warning: control reaches end of non-void function script.c: In function `Script_setStr': script.c:1642: warning: control reaches end of non-void function script.c: In function `Script_setDex': script.c:1655: warning: control reaches end of non-void function script.c: In function `Script_setInt': script.c:1668: warning: control reaches end of non-void function script.c: In function `Script_setWis': script.c:1681: warning: control reaches end of non-void function script.c: In function `Script_setPow': script.c:1694: warning: control reaches end of non-void function script.c: In function `Script_setCon': script.c:1707: warning: control reaches end of non-void function From mwedel at scruz.net Sat Jun 16 02:59:10 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:20 2005 Subject: [CF-Devel] Scripting notes/questions Message-ID: <3B2B11CE.DDD9DB5E@scruz.net> Really meant to send this to the dev list, and not the cvs list. -------------- next part -------------- An embedded message was scrubbed... From: crossfire-cvs-admin@lists.sourceforge.net Subject: Re: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.34,1.35 Date: Thu, 14 Jun 2001 15:11:50 -0700 (PDT) Size: 11597 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010616/3aa5094d/attachment.mht From dnh at hawthorn.csse.monash.edu.au Sat Jun 16 03:50:05 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:20 2005 Subject: [CF-Devel] major bug Message-ID: Monks can wield weapons! They just need a scroll of melee weapons! - Havoc. - cloak of Gaea +4 * (worn) 7.3 - girdle of damage * (worn) 2.5 - ring of War * (worn) 0.0 - gauntlets of Sorig +4 * (worn) 2.3 - bracers +4 * (worn) 2.2 - Midnight Robe +5 * (worn) 5 - amulet of Free Action * (worn) 0.5 - Flame Tongue of Mostrai +5 * (wielde 22 - full helmet of Might +4 * (worn) 10.6 - holy shield +4 * (worn) 24.3 - ring of Strife * (worn) 0.0 This is the inv of a monk... this bug needs to be fixed NOW! dnh From dnh at hawthorn.csse.monash.edu.au Sat Jun 16 07:45:26 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:20 2005 Subject: [CF-Devel] In terms of my broken server Message-ID: I assume it is that the make script hasn't been made yet. This is possibly why my server still isn't working. How long can I expect to wait before the make is done? Should I add these new animations punga has given me (ps even if I do make a mistake it should take only minamal time for me to fix it)... is anyone alive out there? dnh From mwedel at scruz.net Sat Jun 16 14:15:36 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:20 2005 Subject: [CF-Devel] In terms of my broken server References: Message-ID: <3B2BB058.8F617C0E@scruz.net> dnh wrote: > > I assume it is that the make script hasn't been made yet. This is possibly > why my server still isn't working. How long can I expect to wait before > the make is done? Should I add these new animations punga has given me (ps > even if I do make a mistake it should take only minamal time for me to fix > it)... > > is anyone alive out there? You need to re-run configure, then it should all work. Not you need to install guile and the guile developement packages or the configure script will not properly run. And in this case, you really do need to re-run configure, and not the config.cache (or is it .status), because it needs to go out and find the guile stuff. From bugs at real-time.com Sat Jun 16 02:10:02 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:20 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200106160710.f5G7A2613414@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 http://bugzilla.real-time.com/show_bug.cgi?id=369 http://bugzilla.real-time.com/show_bug.cgi?id=372 From bugs at real-time.com Sat Jun 16 23:05:53 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] [Bug 372] Changed - Free items in shops on damn.* server Message-ID: <200106170405.f5H45rG30595@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=372 *** shadow/372 Fri Jun 8 08:11:42 2001 --- shadow/372.tmp.30591 Sat Jun 16 23:05:53 2001 *************** *** 2,9 **** | Free items in shops on damn.* server | +----------------------------------------------------------------------------+ | Bug #: 372 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: Other | | Severity: major OS/Version: Windows 95 | | Priority: P1 Component: server | +----------------------------------------------------------------------------+ --- 2,9 ---- | Free items in shops on damn.* server | +----------------------------------------------------------------------------+ | Bug #: 372 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: DUPLICATE Platform: Other | | Severity: major OS/Version: Windows 95 | | Priority: P1 Component: server | +----------------------------------------------------------------------------+ *************** *** 26,28 **** --- 26,33 ---- - Sizor (NB - This bug could be on other servers which I haven't played at, would be wise to check those too) + + ------- Additional Comments From mwedel@scruz.net 2001-06-16 23:05 ------- + + + *** This bug has been marked as a duplicate of 370 *** \ No newline at end of file From bugs at real-time.com Sat Jun 16 23:05:52 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] [Bug 370] Changed - FREE ITEMS IN SHOPS ON MiDS SERVER Message-ID: <200106170405.f5H45qE30590@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=370 *** shadow/370 Thu Jun 7 01:07:42 2001 --- shadow/370.tmp.30586 Sat Jun 16 23:05:52 2001 *************** *** 30,32 **** --- 30,36 ---- ------- Additional Comments From mwedel@scruz.net 2001-06-07 01:07 ------- server/shop.c: Fix bug that resulted in items in shop being paid, as well as not generating proper listing. MSW 2001-06-06. + + + ------- Additional Comments From mwedel@scruz.net 2001-06-16 23:05 ------- + *** Bug 372 has been marked as a duplicate of this bug. *** \ No newline at end of file From bugs at real-time.com Sat Jun 16 23:06:36 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] [Bug 373] Changed - beholders crash crossfire.csua.berkeley.edu server Message-ID: <200106170406.f5H46am30613@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=373 *** shadow/373 Tue Jun 12 10:03:13 2001 --- shadow/373.tmp.30609 Sat Jun 16 23:06:36 2001 *************** *** 2,9 **** | beholders crash crossfire.csua.berkeley.edu server | +----------------------------------------------------------------------------+ | Bug #: 373 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: All | | Severity: blocker OS/Version: All | | Priority: P2 Component: server | +----------------------------------------------------------------------------+ --- 2,9 ---- | beholders crash crossfire.csua.berkeley.edu server | +----------------------------------------------------------------------------+ | Bug #: 373 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: All | | Severity: blocker OS/Version: All | | Priority: P2 Component: server | +----------------------------------------------------------------------------+ *************** *** 19,21 **** --- 19,25 ---- the game to exit. (the dx client 1.25 says "socket error 10054" for me) It looks like the server also resets as well, because things I had just killed (using invoke holy word with no direction) are back when I relog. + + ------- Additional Comments From mwedel@scruz.net 2001-06-16 23:06 ------- + Peter has fixed this bug on his server (only server it should occur on, as its + the only server with beholder player characters) From bugs at real-time.com Sat Jun 16 23:22:55 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] [Bug 368] Changed - 'lock'-commands doesn't work Message-ID: <200106170422.f5H4Mtu30838@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=368 *** shadow/368 Wed May 30 04:53:43 2001 --- shadow/368.tmp.30834 Sat Jun 16 23:22:55 2001 *************** *** 4,11 **** | Bug #: 368 Product: Crossfire | | Status: NEW Version: CVS | | Resolution: Platform: PC | ! | Severity: normal OS/Version: Linux | ! | Priority: P2 Component: server | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | | Reported By: gour@mail.ru | --- 4,11 ---- | Bug #: 368 Product: Crossfire | | Status: NEW Version: CVS | | Resolution: Platform: PC | ! | Severity: minor OS/Version: Linux | ! | Priority: P4 Component: server | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | | Reported By: gour@mail.ru | *************** *** 22,24 **** --- 22,33 ---- WBR Gour + + ------- Additional Comments From mwedel@scruz.net 2001-06-16 23:22 ------- + This is a client/documentation issue. The unix clients do support locking items + via mouse/shift key combination. If players want to be able to use extended + text commands to lock entries, this should be added to the client, but IMO most + people will probably prefer the the mouse method instead. + + While the server may have support for 'marking' objects, that is really a left + over and is something the client should do. From jbontje at suespammers.org Sun Jun 17 18:29:39 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems Message-ID: <20010618012939.A20558@mids.student.utwente.nl> Hello, When trying to compile the latest client 'configure' gives me problems: I get a 'y' flood after the line "checking for IMG_LoadPNG_RW in -lSDL_image... no" Just like the 'yes' command was executed... Joris Bontje / mids From smurf at CSUA.Berkeley.EDU Sun Jun 17 23:40:51 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: <20010618012939.A20558@mids.student.utwente.nl>; from jbontje@suespammers.org on Mon, Jun 18, 2001 at 01:29:39AM +0200 References: <20010618012939.A20558@mids.student.utwente.nl> Message-ID: <20010617214051.A7629@CSUA.Berkeley.EDU> On Mon, Jun 18, 2001 at 01:29:39AM +0200, Joris Bontje wrote: > Hello, > > When trying to compile the latest client 'configure' gives me problems: > I get a 'y' flood after the line "checking for IMG_LoadPNG_RW in -lSDL_image... no" > Just like the 'yes' command was executed... > > Joris Bontje / mids My bad, I had a space between the = sign and "yes". Fixed. -Scott From smurf at CSUA.Berkeley.EDU Mon Jun 18 12:56:57 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Mon, Jun 18, 2001 at 05:32:49PM +1000 References: <20010617214051.A7629@CSUA.Berkeley.EDU> Message-ID: <20010618105657.A21894@CSUA.Berkeley.EDU> On Mon, Jun 18, 2001 at 05:32:49PM +1000, dnh wrote: > Firstly I would just like to say WOOOOOOOO HOOOOO! The SDL client is > running around 200x faster on my machine and that isn't an exxageration. I > was getting 10 second delays while gcfclient busily resized the window. > Now you don't even notice the redraw! I think we can safely say gdk's png > stuff is dodgy. =) I figured the speed improvments would be pretty hardware specific. I saw about 30% speed improvments with SDL, maybe 40% with the speed enchancments I commited last night, mark saw almost no improvment, I dunno if my changes last night made things better for him or not though. > * Tiles left in memory. When you walk towards a wall, the tile immediatly > preceeding the 'blackness' is repeated in there and we see no blackness. > This only seems to happen with walls. > /me 's best guess: either the tiler isn't considering parts of the map > which don't exist (ie the map is 4 x 4, it doesn't just paste black for 5, > 4. The tiler isn't removing tiles from the cache and is leaving them there.. > or something. Is this any wall or a specific place on a map? I haven't seen this before. Can you give me a specific example? ie: Map location that I can try? > * Funny colours. The hallofselection's tiles grey tiles are coming up > wrong, for me I got a nice cyan colour, for mids I believe a fine yellow. > I have no idea what is causing this.. maybe a debian thing, or maybe SDL > lacks that particular colour. Yeah, I get yellow.. I haven't looked at that one yet. -Scott From dnh at hawthorn.csse.monash.edu.au Mon Jun 18 20:22:52 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: <20010618105657.A21894@CSUA.Berkeley.EDU> Message-ID: On Mon, 18 Jun 2001, Scott MacFiggen wrote: > On Mon, Jun 18, 2001 at 05:32:49PM +1000, dnh wrote: > > Firstly I would just like to say WOOOOOOOO HOOOOO! The SDL client is > > running around 200x faster on my machine and that isn't an exxageration. I > > was getting 10 second delays while gcfclient busily resized the window. > > Now you don't even notice the redraw! I think we can safely say gdk's png > > stuff is dodgy. =) > > I figured the speed improvments would be pretty hardware specific. > I saw about 30% speed improvments with SDL, maybe 40% with the speed > enchancments I commited last night, mark saw almost no improvment, I > dunno if my changes last night made things better for him or not though. Well you have got at least one happy customer =)). > > * Tiles left in memory. When you walk towards a wall, the tile immediatly > > preceeding the 'blackness' is repeated in there and we see no blackness. > > This only seems to happen with walls. > > /me 's best guess: either the tiler isn't considering parts of the map > > which don't exist (ie the map is 4 x 4, it doesn't just paste black for 5, > > 4. The tiler isn't removing tiles from the cache and is leaving them there.. > > or something. > > Is this any wall or a specific place on a map? I haven't seen this before. > Can you give me a specific example? ie: Map location that I can try? There are heaps, the walls in the perm apartment, the walls around the city. You obviously aren't experiencing this bug cause it happens every.. I will take a screenshot when I switch to linux. > > * Funny colours. The hallofselection's tiles grey tiles are coming up > > wrong, for me I got a nice cyan colour, for mids I believe a fine yellow. > > I have no idea what is causing this.. maybe a debian thing, or maybe SDL > > lacks that particular colour. > > Yeah, I get yellow.. I haven't looked at that one yet. Hmmmm dnh > -Scott > From dnh at hawthorn.csse.monash.edu.au Mon Jun 18 20:48:15 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: Message-ID: Here is a link to this very affect. http://mids.student.utwente.nl/~dnh/screen_shots/SDL_client.jpg dnh On Tue, 19 Jun 2001, dnh wrote: > > > On Mon, 18 Jun 2001, Scott MacFiggen wrote: > > > On Mon, Jun 18, 2001 at 05:32:49PM +1000, dnh wrote: > > > Firstly I would just like to say WOOOOOOOO HOOOOO! The SDL client is > > > running around 200x faster on my machine and that isn't an exxageration. I > > > was getting 10 second delays while gcfclient busily resized the window. > > > Now you don't even notice the redraw! I think we can safely say gdk's png > > > stuff is dodgy. =) > > > > I figured the speed improvments would be pretty hardware specific. > > I saw about 30% speed improvments with SDL, maybe 40% with the speed > > enchancments I commited last night, mark saw almost no improvment, I > > dunno if my changes last night made things better for him or not though. > > Well you have got at least one happy customer =)). > > > > * Tiles left in memory. When you walk towards a wall, the tile immediatly > > > preceeding the 'blackness' is repeated in there and we see no blackness. > > > This only seems to happen with walls. > > > /me 's best guess: either the tiler isn't considering parts of the map > > > which don't exist (ie the map is 4 x 4, it doesn't just paste black for 5, > > > 4. The tiler isn't removing tiles from the cache and is leaving them there.. > > > or something. > > > > Is this any wall or a specific place on a map? I haven't seen this before. > > Can you give me a specific example? ie: Map location that I can try? > > There are heaps, the walls in the perm apartment, the walls around the > city. You obviously aren't experiencing this bug cause it happens every.. > I will take a screenshot when I switch to linux. > > > > * Funny colours. The hallofselection's tiles grey tiles are coming up > > > wrong, for me I got a nice cyan colour, for mids I believe a fine yellow. > > > I have no idea what is causing this.. maybe a debian thing, or maybe SDL > > > lacks that particular colour. > > > > Yeah, I get yellow.. I haven't looked at that one yet. > > Hmmmm > > dnh > > > -Scott > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From smurf at CSUA.Berkeley.EDU Mon Jun 18 21:54:44 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Tue, Jun 19, 2001 at 11:48:15AM +1000 References: Message-ID: <20010618195444.A26014@CSUA.Berkeley.EDU> On Tue, Jun 19, 2001 at 11:48:15AM +1000, dnh wrote: > Here is a link to this very affect. > > http://mids.student.utwente.nl/~dnh/screen_shots/SDL_client.jpg > > dnh Odd, I had that problem at first and thought I had fixed it. It looks like the client isn't getting a map_clearcell command from the server and isn't marking those tiles as empty. I need some more info to debug this. o What server version are you playing on? o What command line options are you giving the client? o Are you running that latest CVS code? o Send me the output of 'ldd gcfclient' o The gcc command line options the client was compiled with would be great too. -Scott From dnh at hawthorn.csse.monash.edu.au Mon Jun 18 22:36:40 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: <20010618195444.A26014@CSUA.Berkeley.EDU> Message-ID: On Mon, 18 Jun 2001, Scott MacFiggen wrote: > On Tue, Jun 19, 2001 at 11:48:15AM +1000, dnh wrote: > > Here is a link to this very affect. > > > > http://mids.student.utwente.nl/~dnh/screen_shots/SDL_client.jpg > > > > dnh > > Odd, I had that problem at first and thought I had fixed it. > It looks like the client isn't getting a map_clearcell command > from the server and isn't marking those tiles as empty. > > I need some more info to debug this. > > o What server version are you playing on? crossfire.csua.berkeley.edu.au > o What command line options are you giving the client? gcfclient -png -cache -darkness -sdl (ps. -darkness doesn't work yet AFAICS but the bug still exists without -darkness) > o Are you running that latest CVS code? of course > o Send me the output of 'ldd gcfclient' dnh@Chiton:/usr/local/bin$ ldd gcfclient libpng.so.2 => /usr/lib/libpng.so.2 (0x6ffb0000) libm.so.6 => /lib/libm.so.6 (0x6ff18000) libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x6fe7f000) libpthread.so.0 => /lib/libpthread.so.0 (0x6fe48000) libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0x6fe11000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x6fde2000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x6fc20000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x6fbbe000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x6fb9b000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x6fb4a000) libdl.so.2 => /lib/libdl.so.2 (0x6fb27000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x6fafe000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x6facd000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x6f9ab000) libc.so.6 => /lib/libc.so.6 (0x6f85c000) libggi.so.2 => /usr/lib/libggi.so.2 (0x6f831000) libz.so.1 => /usr/lib/libz.so.1 (0x6f801000) libgii.so.0 => /usr/lib/libgii.so.0 (0x6f7da000) libgg.so.0 => /usr/lib/libgg.so.0 (0x6f7b4000) libasound.so.1 => /usr/lib/libasound.so.1 (0x6f778000) libartsc.so.0 => /usr/lib/libartsc.so.0 (0x6f752000) libesd.so.0 => /usr/lib/libesd.so.0 (0x6f72b000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x6f6e7000) libaa.so.1 => /usr/lib/libaa.so.1 (0x6f6ae000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x6f66b000) /lib/ld.so.1 => /lib/ld.so.1 (0x30000000) libslang.so.1 => /lib/libslang.so.1 (0x6f5cf000) libgpm.so.1 => /usr/lib/libgpm.so.1 (0x6f5a8000) libncurses.so.5 => /lib/libncurses.so.5 (0x6f52f000) > o The gcc command line options the client was compiled with would be > great too. none I just ran make clean, configure, make, make install dnh > -Scott > From smurf at CSUA.Berkeley.EDU Tue Jun 19 00:53:28 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Tue, Jun 19, 2001 at 01:36:40PM +1000 References: <20010618195444.A26014@CSUA.Berkeley.EDU> Message-ID: <20010618225328.A49127@CSUA.Berkeley.EDU> On Tue, Jun 19, 2001 at 01:36:40PM +1000, dnh wrote: > > o What server version are you playing on? > crossfire.csua.berkeley.edu.au Is that a private server? I can't get a dns lookup on it. > > o Send me the output of 'ldd gcfclient' > libggi.so.2 => /usr/lib/libggi.so.2 (0x6f831000) Interesting that you are linking with the ggi lib, I don't think sdl would use the ggi driver though since it has to paint to an xwindow.. Maybe you aren't running on a 32 bit display? I never tested on a 16 bit or 24 bit display.. Can you send me the output of 'xdpyinfo'? -Scott From smurf at CSUA.Berkeley.EDU Tue Jun 19 01:44:03 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Tue, Jun 19, 2001 at 01:36:40PM +1000 References: <20010618195444.A26014@CSUA.Berkeley.EDU> Message-ID: <20010618234403.A56371@CSUA.Berkeley.EDU> Ah, I see.. It is just the 1.0.0 server, it is doing something different then the current CVS server. Mark, any idea what is different? -Scott From dnh at hawthorn.csse.monash.edu.au Tue Jun 19 02:33:36 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: <20010618234403.A56371@CSUA.Berkeley.EDU> Message-ID: I thought MiDS was having the same problems... his server is.. mids.student.utwente.nl dnh On Mon, 18 Jun 2001, Scott MacFiggen wrote: > > Ah, I see.. It is just the 1.0.0 server, it is doing something different > then the current CVS server. Mark, any idea what is different? > > -Scott > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From jbontje at suespammers.org Tue Jun 19 03:53:26 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: References: Message-ID: <20010619105326.A6879@mids.student.utwente.nl> On Tue, Jun 19, 2001 at 05:33:36PM +1000, dnh wrote: > I thought MiDS was having the same problems... his server is.. > > mids.student.utwente.nl > It is afaik NOT a server problem. the 'normal' gcfclient also had this problem, but Mark has fixed it. The fix should be here (somewhere :) : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/crossfire/client/gx11.c Joris Bontje / mids From michael.toennies at nord-com.net Tue Jun 19 19:22:05 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] new release: CFJavaEditor 0.971 Message-ID: A new release for the java editor. Version 0.971 is full usable. Try it out. I had reorginized the CVS directory structure. I had removed the src folder stuff. How can i delete the folder? In the docs it stand it will be removed automatically, but the folder still is empty in cvs? Also, as i add i copy&paste a false name, so i make a yoyodyme folder in CVS main tree. Can one remove it? Mark, Tanners? I don't want try delete function on main tree. Sorry for it. I had now setup the whole editor tree. So feel free to add stuff. If you look in the HelpFiles folder, you will find *,html stuff. All online help can be html, so add here you stuff. If one here knows some about java, please look in the source. Iam still a java beginner and i had coded this fast as possible. So, the code is ugly, the structure is ugly, and so on. Feel free to lift the source. The Editor can collect the archfiles and generate the server data - except the .xbm/.xpm file and the faces file. The face file should be also removed, its nonsense to assign xpm/xbm color values to the faces. As i understand, this is used for the magic map command. This must be reworked for the png only set, so i drop it too. Michael From michael.toennies at nord-com.net Tue Jun 19 19:47:38 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] ISO Crossfire Set - first release Message-ID: I had finished the first usable release for the crossfire Iso set. I had added here some screenshots: http://mids.student.utwente.nl/~michtoen/crossfire_iso How to use? 1. download the iso arches http://mids.student.utwente.nl/~michtoen/crossfire_iso/iso_arch.zip 2. Install the CFJavaEditor 3. run the CFJavaEditor and set in arch path in the options to the iso set 4. Load a normal map The iso set will use 99% of the old arches. Monsters and items look like as they stuck in the ground, thats because i don't have shift them to the new position for the new tile width/height. Some walls are not right, i had changed the arches with copy & past and sometimes i had swapped the horizontal with vertical. But thats easy to fix, just change the 2 faces in the arch files. You CAN play the iso set. * You don't need change/recompile the server, except you must copy files for the other arches!* * Make a copy of the folder, where your crossfire.png and archetypes file is in. * 5. Download a iso client (there is yet only the dx client, gros will make the linux client) 6. Run "Collect Archfile" from the CFJavaEditor Archfile menu 7. Look in the copydata.bat file and copy the files named inside thereover a installed server ( be sure to copy a renamed crossfire.png over crossfire.xbm/crossfire.xpm file to avoid error messages from server). 8. If the server gives a error about the faces, delete all lines inside the files and save it. The commands inside are not used for png set. 9. make a map! Or convert a old map! Make new quest! 10. play and enjoy The look and the game feeling is wonderful!! As you can see, i had put scorn in ruins. :) Thats a bit more than a symbol, i have no good houses pictures... So, sit down and draw ... Its a perfect mixture from old crossfire, flat playing feeling and iso look. I think even Mark will love it... :) As you see, the player char now moves in 8 directions! This is a real good thing - i had put in a option in the setup command to the server, so this can also be used for normal set! All what you need is to draw 8 direction player pictures. Well, there is some work to do! If wanted, we can put the new arch set in the cvs. And add collected iso server files. We will setup mids 2nd server as a iso server. The converting/changing of the old maps is really easy and fast. Because we have so many bad and idiotic maps inside our mapset, i think it is a good way to touch all of them and decide what we will still use! Michael From smurf at CSUA.Berkeley.EDU Tue Jun 19 23:38:15 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:21 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Mon, Jun 18, 2001 at 05:32:49PM +1000 References: <20010617214051.A7629@CSUA.Berkeley.EDU> Message-ID: <20010619213815.A55137@CSUA.Berkeley.EDU> > * Tiles left in memory. When you walk towards a wall, the tile immediatly > preceeding the 'blackness' is repeated in there and we see no blackness. > This only seems to happen with walls. This is fixed. Turns out it was a problem with both the pngximage and sdl clients. > Could someone please put these into the readme or something, I really > think we need to include these packages in the debian 'crossfire' package > along with other things like jpg support, so that debian users don't have > to spend hours searching for the right package for the job. mids could > you try and work out what packages we need? Added stuff about SDL in the README. -Scott From mwedel at scruz.net Tue Jun 19 23:58:40 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] new release: CFJavaEditor 0.971 References: Message-ID: <3B302D80.7FC1B977@scruz.net> Michael Toennies wrote: > Also, as i add i copy&paste a false name, so i make a yoyodyme folder in CVS > main tree. > Can one remove it? Mark, Tanners? Since the CVS repository is hosted on sourceforge, everyone basically has the same power to create/destroy. > The face file should be also removed, its nonsense to assign xpm/xbm color > values to the faces. > As i understand, this is used for the magic map command. This must be > reworked for the png only > set, so i drop it too. Do you have a better suggestion for what to do? Its easy to say what is currently there is not ideal, but often harder to come up with a good solution. For png, if magic map is to be supported in the same form, that information is needed. The server otherwise has no way of knowing what color the different items are (and since as far as the server is concerned, the images are just a bunch of bits which it does not understand, so it can't really look at the images and generate what color it should be). Since the color/face data already exists, it makes keeping and using it the easiest solution. Now magic mapping could of course get reworked to do something else, like send the actual faces for all the spaces, and the client can then scale it down or the like (which many other games do for the larger view). This would consume much more bandwidth (at minimum, twice as much of only 1 face/square is sent), and may be much more useful (if all faces on a space are sent) or less useful (if bottom space (typically terrain/floor/wall) is sent, or somewhere between depending on what all gets sent. > > Michael > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From michael.toennies at nord-com.net Wed Jun 20 00:20:26 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] new release: CFJavaEditor 0.971 In-Reply-To: <3B302D80.7FC1B977@scruz.net> Message-ID: Also the old methode needs some bytes to submit information, the bandwith is not a problem here- how much is this spell invoked? To bind the color information on xbm and face is ugly and bad. Just send a type information to the client. And let him decide how and what he do with it. If we include a real layer system, what very easy is, because the whole information and technic is since long time included in Cf, client can do fancy thing with it. If spell and map submit type information, we can easily include automapping. Also, if we layer, we only must send ONE time a floor or wall information - or even a special layer like a tree. Include for every player a dirty flag map, where differences like changed walls or floor are marked (which should happens not very often) and all is fine. THIS will safe alot of bandwith. And the whole system is ready in CF. > Michael Toennies wrote: > > > Also, as i add i copy&paste a false name, so i make a yoyodyme > folder in CVS > > main tree. > > Can one remove it? Mark, Tanners? > > Since the CVS repository is hosted on sourceforge, everyone > basically has the > same power to create/destroy. > > > The face file should be also removed, its nonsense to assign > xpm/xbm color > > values to the faces. > > As i understand, this is used for the magic map command. This must be > > reworked for the png only > > set, so i drop it too. > > Do you have a better suggestion for what to do? Its easy to say what is > currently there is not ideal, but often harder to come up with a > good solution. > > For png, if magic map is to be supported in the same form, that > information is > needed. The server otherwise has no way of knowing what color > the different > items are (and since as far as the server is concerned, the > images are just a > bunch of bits which it does not understand, so it can't really look at the > images and generate what color it should be). > > Since the color/face data already exists, it makes keeping and > using it the > easiest solution. > > Now magic mapping could of course get reworked to do something > else, like send > the actual faces for all the spaces, and the client can then > scale it down or > the like (which many other games do for the larger view). This > would consume > much more bandwidth (at minimum, twice as much of only 1 > face/square is sent), > and may be much more useful (if all faces on a space are sent) or > less useful > (if bottom space (typically terrain/floor/wall) is sent, or > somewhere between > depending on what all gets sent. > > > > > > Michael > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed Jun 20 00:47:34 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: <20010619213815.A55137@CSUA.Berkeley.EDU> Message-ID: Thanks alot, will test it out now. dnh On Tue, 19 Jun 2001, Scott MacFiggen wrote: > > * Tiles left in memory. When you walk towards a wall, the tile immediatly > > preceeding the 'blackness' is repeated in there and we see no blackness. > > This only seems to happen with walls. > > This is fixed. Turns out it was a problem with both the pngximage > and sdl clients. > > > Could someone please put these into the readme or something, I really > > think we need to include these packages in the debian 'crossfire' package > > along with other things like jpg support, so that debian users don't have > > to spend hours searching for the right package for the job. mids could > > you try and work out what packages we need? > > Added stuff about SDL in the README. > > -Scott > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed Jun 20 00:56:56 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] new release: CFJavaEditor 0.971 In-Reply-To: <3B302D80.7FC1B977@scruz.net> Message-ID: Hmm i tend to agree with mark here, while it may be silly to put face colour in there when we aready have the images. It seems both wasteful and very time consuming to create a new method. I don't really have a better suggestion for how to do it, though I would like to point out. There are some cases where certain tiles have been given strange colours to make sure if people use magic map it stands out. I can think of one classic example where there is a river, and they only way to get across is by dim dooring on the right angle. To help the player the correct path is a different colour on magic map. Now how else could map makers store this sort of information? dnh On Tue, 19 Jun 2001, Mark Wedel wrote: > Michael Toennies wrote: > > > Also, as i add i copy&paste a false name, so i make a yoyodyme folder in CVS > > main tree. > > Can one remove it? Mark, Tanners? > > Since the CVS repository is hosted on sourceforge, everyone basically has the > same power to create/destroy. > > > The face file should be also removed, its nonsense to assign xpm/xbm color > > values to the faces. > > As i understand, this is used for the magic map command. This must be > > reworked for the png only > > set, so i drop it too. > > Do you have a better suggestion for what to do? Its easy to say what is > currently there is not ideal, but often harder to come up with a good solution. > > For png, if magic map is to be supported in the same form, that information is > needed. The server otherwise has no way of knowing what color the different > items are (and since as far as the server is concerned, the images are just a > bunch of bits which it does not understand, so it can't really look at the > images and generate what color it should be). > > Since the color/face data already exists, it makes keeping and using it the > easiest solution. > > Now magic mapping could of course get reworked to do something else, like send > the actual faces for all the spaces, and the client can then scale it down or > the like (which many other games do for the larger view). This would consume > much more bandwidth (at minimum, twice as much of only 1 face/square is sent), > and may be much more useful (if all faces on a space are sent) or less useful > (if bottom space (typically terrain/floor/wall) is sent, or somewhere between > depending on what all gets sent. > > > > > > Michael > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed Jun 20 01:08:18 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: Message-ID: YAY woo hoo alright! No more crazy all bug, that's all cleaned up. Things are getting quite wierd in regards to joining and leaving servers (via savebeds), If I log on and off a few servers I get this error. Got error on read (error 0) gtk_main exited, returning from event_loop Fatal signal: Segmentation Fault (SDL Parachute Deployed) could this be server incompatability? I can't keep track of what servers are cvs or not now =).. I must be growing old. Any ideas? dnh On Wed, 20 Jun 2001, dnh wrote: > Thanks alot, will test it out now. > > dnh > > On Tue, 19 Jun 2001, Scott MacFiggen wrote: > > > > * Tiles left in memory. When you walk towards a wall, the tile immediatly > > > preceeding the 'blackness' is repeated in there and we see no blackness. > > > This only seems to happen with walls. > > > > This is fixed. Turns out it was a problem with both the pngximage > > and sdl clients. > > > > > Could someone please put these into the readme or something, I really > > > think we need to include these packages in the debian 'crossfire' package > > > along with other things like jpg support, so that debian users don't have > > > to spend hours searching for the right package for the job. mids could > > > you try and work out what packages we need? > > > > Added stuff about SDL in the README. > > > > -Scott > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From smurf at CSUA.Berkeley.EDU Wed Jun 20 01:11:13 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] Fix for slowness of gtkclient when not connection to server Message-ID: <20010619231113.B55137@CSUA.Berkeley.EDU> I found the gtk client annoying slow when it wasn't connected to a server. I tracked it down to repeated calls to gtk_main_iteration in get_metaserver. This is really really really slooow. gtk_main_iteration() is mostly there for use in really long running functions that want to process UI input along the way. I changed it to call gtk_main() instead and had enter_callback() call gtk_main_quit() after the user entered a server to connect to. Changes are in CVS. -Scott From michael.toennies at nord-com.net Wed Jun 20 01:24:06 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] new release: CFJavaEditor 0.971 In-Reply-To: Message-ID: Type information is a absolut unique identifier. To advance it, we also talked about to make a second byte which is then the under type typ. like type x = weapon. x,1 = swords, x,2 = axes... This is absolut enough information for the client. Also, the color information submited with the magic map command is more than worse. You will not have different colors... magic map is normally build up by 13 or 16 colors ors so. Seems a relict from 16 colors days. And, it its the xbm/xpm color system. Really, this is another discussion which blocks the game and make much work in the future, only to safe yet some time. I had removed the visiblity and magicmap command from the iso arches and i will not use it anymore. If no one build here a better magic map spell, i hack in a short type to color transformation in the server. I had remove it, when one miss it (what will not happens so fast) he can build something better. > > Hmm i tend to agree with mark here, while it may be silly to put face > colour in there when we aready have the images. It seems both wasteful and > very time consuming to create a new method. I don't really have a better > suggestion for how to do it, though I would like to point out. There are > some cases where certain tiles have been given strange colours to make > sure if people use magic map it stands out. I can think of one classic > example where there is a river, and they only way to get across is by dim > dooring on the right angle. To help the player the correct path is a > different colour on magic map. Now how else could map makers store this > sort of information? Using a different water arch. > dnh > > On Tue, 19 Jun 2001, Mark Wedel wrote: > > > Michael Toennies wrote: > > > > > Also, as i add i copy&paste a false name, so i make a > yoyodyme folder in CVS > > > main tree. > > > Can one remove it? Mark, Tanners? > > > > Since the CVS repository is hosted on sourceforge, everyone > basically has the > > same power to create/destroy. > > > > > The face file should be also removed, its nonsense to assign > xpm/xbm color > > > values to the faces. > > > As i understand, this is used for the magic map command. This must be > > > reworked for the png only > > > set, so i drop it too. > > > > Do you have a better suggestion for what to do? Its easy to > say what is > > currently there is not ideal, but often harder to come up with > a good solution. > > > > For png, if magic map is to be supported in the same form, > that information is > > needed. The server otherwise has no way of knowing what color > the different > > items are (and since as far as the server is concerned, the > images are just a > > bunch of bits which it does not understand, so it can't really > look at the > > images and generate what color it should be). > > > > Since the color/face data already exists, it makes keeping and > using it the > > easiest solution. > > > > Now magic mapping could of course get reworked to do something > else, like send > > the actual faces for all the spaces, and the client can then > scale it down or > > the like (which many other games do for the larger view). This > would consume > > much more bandwidth (at minimum, twice as much of only 1 > face/square is sent), > > and may be much more useful (if all faces on a space are sent) > or less useful > > (if bottom space (typically terrain/floor/wall) is sent, or > somewhere between > > depending on what all gets sent. > > > > > > > > > > Michael > > > > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From smurf at CSUA.Berkeley.EDU Wed Jun 20 01:40:28 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] client 'configure' gives problems In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Wed, Jun 20, 2001 at 04:08:18PM +1000 References: Message-ID: <20010619234028.C55137@CSUA.Berkeley.EDU> On Wed, Jun 20, 2001 at 04:08:18PM +1000, dnh wrote: > Things are getting quite wierd in regards to joining and leaving servers > (via savebeds), If I log on and off a few servers I get this error. > > Got error on read (error 0) > gtk_main exited, returning from event_loop The first two are normal I believe. The read error is from the server closing the socket connection.. > Fatal signal: Segmentation Fault (SDL Parachute Deployed) This is happening in reset_image_data. A corrupt SDL surface seems to be sneaking into the surfaces array every once in a while and causes SDL_FreeSurface to core. Dunny why yet. -Scott From dnh at hawthorn.csse.monash.edu.au Wed Jun 20 03:51:02 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] new release: CFJavaEditor 0.971 In-Reply-To: Message-ID: On Wed, 20 Jun 2001, Michael Toennies wrote: > Type information is a absolut unique identifier. > To advance it, we also talked about to make a second byte > which is then the under type typ. > > like type x = weapon. x,1 = swords, x,2 = axes... > > This is absolut enough information for the client. Fair enough > Also, the color information submited with the magic map command is more > than worse. You will not have different colors... magic map is normally > build up by 13 or 16 colors ors so. Seems a relict from 16 colors days. > > And, it its the xbm/xpm color system. Indeed that is probably because it is. > Really, this is another discussion which blocks the game and make > much work in the future, only to safe yet some time. Nobody is stopping you, I certainly am not. I know personally I don't have copius amounts of time floating about and I lack the skills to do it anyway. If you find something wrong and you want to fix it, go for it. I don't see why we are wrong to express concern about the REMOVAL of a feature because someone else thinks it isn't efficient. Would anyone be happy id I decided I don't like any maps and deleted them all? would you mind it if I decided I didn't like your client and deleted it? I some how doubt it, if you want to work in a team project Mich, you might want to consider other members positions. We are all happy to see new and exciting things, and really glad when someone finally fixes that stupid bug here etc etc. but when you start declaring that something is old and crappy, but not providing a solution bar just removing it... obviously people are going to question why. I don't use magic map very often, probably because I know every map already, but I don't like the idea of things just simply being removed. You are complaining about creating work, would you like a list of current bugs which no one has fixed? *Monks wielding weapons *Priest switching gods to gain all godly artifacts *Speed problems concerning n^x spells calculations *Server handling of entering and exiting... I would consider alot of these more important than removing magic map blah blah blah. I think you get my point. Anyway, I never really liked the way magic mapping's interface was handled, nor how it looked. Is anyone prepared to rework it? I am happy to discuss how we can improve it so if anyone is interested gimme a bell =). The new ISO set is looking very nice indeed, can anyone write out some sort of way to install it all simply in debian. I really need some sort of java .deb package and I was wondering which ones I should get.. mids? food for thought dnh > I had removed the visiblity and magicmap command from the iso arches and > i will not use it anymore. If no one build here a better magic map spell, > i hack in a short type to color transformation in the server. > > I had remove it, when one miss it (what will not happens so fast) he can > build > something better. > > > > > > > Hmm i tend to agree with mark here, while it may be silly to put face > > colour in there when we aready have the images. It seems both wasteful and > > very time consuming to create a new method. I don't really have a better > > suggestion for how to do it, though I would like to point out. There are > > some cases where certain tiles have been given strange colours to make > > sure if people use magic map it stands out. I can think of one classic > > example where there is a river, and they only way to get across is by dim > > dooring on the right angle. To help the player the correct path is a > > different colour on magic map. Now how else could map makers store this > > sort of information? > > Using a different water arch. > > > > dnh > > > > On Tue, 19 Jun 2001, Mark Wedel wrote: > > > > > Michael Toennies wrote: > > > > > > > Also, as i add i copy&paste a false name, so i make a > > yoyodyme folder in CVS > > > > main tree. > > > > Can one remove it? Mark, Tanners? > > > > > > Since the CVS repository is hosted on sourceforge, everyone > > basically has the > > > same power to create/destroy. > > > > > > > The face file should be also removed, its nonsense to assign > > xpm/xbm color > > > > values to the faces. > > > > As i understand, this is used for the magic map command. This must be > > > > reworked for the png only > > > > set, so i drop it too. > > > > > > Do you have a better suggestion for what to do? Its easy to > > say what is > > > currently there is not ideal, but often harder to come up with > > a good solution. > > > > > > For png, if magic map is to be supported in the same form, > > that information is > > > needed. The server otherwise has no way of knowing what color > > the different > > > items are (and since as far as the server is concerned, the > > images are just a > > > bunch of bits which it does not understand, so it can't really > > look at the > > > images and generate what color it should be). > > > > > > Since the color/face data already exists, it makes keeping and > > using it the > > > easiest solution. > > > > > > Now magic mapping could of course get reworked to do something > > else, like send > > > the actual faces for all the spaces, and the client can then > > scale it down or > > > the like (which many other games do for the larger view). This > > would consume > > > much more bandwidth (at minimum, twice as much of only 1 > > face/square is sent), > > > and may be much more useful (if all faces on a space are sent) > > or less useful > > > (if bottom space (typically terrain/floor/wall) is sent, or > > somewhere between > > > depending on what all gets sent. > > > > > > > > > > > > > > Michael > > > > > > > > _______________________________________________ > > > > crossfire-devel mailing list > > > > crossfire-devel@lists.real-time.com > > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From bugs at real-time.com Wed Jun 20 14:41:45 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] [Bug 374] New - Jump skill bug Message-ID: <200106201941.f5KJfjX15294@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=374 *** shadow/374 Wed Jun 20 14:41:45 2001 --- shadow/374.tmp.15291 Wed Jun 20 14:41:45 2001 *************** *** 0 **** --- 1,25 ---- + +============================================================================+ + | Jump skill bug | + +----------------------------------------------------------------------------+ + | Bug #: 374 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: All | + | Severity: normal OS/Version: All | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: cpeirce@enderthethird.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + A low level character of mine (lev10) recently got a hold of a jump skill + scroll... anyway, i learned that without actually KILLING anything, or causing + any noticable damage, my char could get experience by jumping into things, + which is considered an attack and SHOULD cause damage... + this was on the MiDS + good be a fluke or a mistake... + At the time I was using the DX Client, but their is no way it is the clients + doing (obviously) + Have fun! ;-) \ No newline at end of file From michael.toennies at nord-com.net Wed Jun 20 18:14:20 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] area spells Message-ID: When i stay near a single skull who is attacking me, i often notice he is floading the areas which the same spell a few times. So i had often 3-6 flame object under my feet with a (it looks so) normal spell cast round. In fact, it seems there is some redundant casting. From joel at mamia.prninfo.com Wed Jun 20 21:41:59 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] Special Floors Message-ID: <200106210241.WAA16933@mamia.prninfo.com> If a normal monster kills you in the arena(not an avatar),do you die a normal death or do you get teleported to the floor's destination? If this does not already exist,it would be a nice feature. Such as the player gets challenged to a fight by a NPC(not a fight to the death). Or if you just want the player to get captured. Joel Southall From mwedel at scruz.net Wed Jun 20 22:52:08 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] area spells References: Message-ID: <3B316F68.88AD38EF@scruz.net> Michael Toennies wrote: > > When i stay near a single skull who is attacking me, > i often notice he is floading the areas which the same spell > a few times. So i had often 3-6 flame object under my feet with > a (it looks so) normal spell cast round. > > In fact, it seems there is some redundant casting. That is 'normal'. The monster logic certainly is not very intelligent. They will repeatedly cast the same spell. In some circumstances, this is a good thing. In the case you describe, each flame object does some amount of damage, so having got hit by 6 of them will do more damage than just getting hit by one. In other cases, this may make less since. If the character is already paralyzed, probably better to hit them with a lightning bolt or fireball and not another paralyze. The spells do not currently merge. There is some debate on how much good it will really do to let them merge (let them in this case means that all the spell parameters match up). The main question is how many spells can actually merge in that situation. Because in the case of the multilple spells, they will be in different phases of the duration (so for example, if you cast burning hands, wait a tick and cast another such that it is effectively one space behind the other, nothing in that will really be able to merge even though the effects are overlapping, and this is because the duration of the lead is a little shorter than the one behind.) Similarly, things like damage, direction its moving, and other things may very well be different. From dnh at hawthorn.csse.monash.edu.au Wed Jun 20 23:19:17 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] area spells In-Reply-To: Message-ID: I don't follow this? You mean the skull is casting the same thing a few times? On a similar note, I noticed last night if you over cast with holy word and get the message "you fumble the spell" it acts as a counter spell. Clearing any holy word in the same area as if I had cast a holy word. What this means is if you hit holy word 5 times, you get x damage, when you hit it 6-7 you get x/4 or so. Basically holy word keeps coming out after you cast and the second you get a fumble spell it terminates them all, thus rapid casting = much less damage than casting a few and regenerating. This IMHO is very broken. On a similar sort of bug, if you use skill literacy on a book of a higher level than you could in theory read (so it doesn't actually identify) then you read that book (even though you shouldn't be able to) you ALWAYS succeed. I haven't been able to do massive testing with this one, but the 3 or 4 I managed to test all proved positive. Another one which I have already metioned, Monks are using weapons with a scroll of melee weapons and retaining mediation. What I would like to see is adding the removal of mediation skill if one of these scrolls is read (if it is there) and adding a warning message.. "by reading this scroll you will no longer be at peace, your karma will be lost" or something. This can then be applied to Sorcerors, we can give sorcerors meditation or melee weapons, it is for the user to decide =). I have heard of this jump bug before, answer seems obvious just make jump do call the normal attack code if it hits a monster, or just stop if it hits a monster. Is anyone around who can either a) help me fix these serious bugs, or b) fix them themselves? The list is etting suffiecently long that I would agree to a 1.0.1 release including the new SDL client properly tested (which I am currently doing). Mark? dnh On Thu, 21 Jun 2001, Michael Toennies wrote: > When i stay near a single skull who is attacking me, > i often notice he is floading the areas which the same spell > a few times. So i had often 3-6 flame object under my feet with > a (it looks so) normal spell cast round. > > In fact, it seems there is some redundant casting. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed Jun 20 23:24:25 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:22 2005 Subject: [CF-Devel] Special Floors In-Reply-To: <200106210241.WAA16933@mamia.prninfo.com> Message-ID: In an arena, no final damage can be done. Ie regardless of the caster/s type when hp = 0 or lower the player is teleported out and not killed. A monster arena is perfectly possible, the only problem with it is that after killing the monster you don't gain any exp (perhaps the map maker could give some reward bonus.. artifacts, notes, money..) the real issue is that the player has no 'risk' to doing these maps, and so as long as they can keep playing, they can keep gaining money with no risk of death. While this may be fairly inconsiquential (how much money do players need? there is so much around I would be surprised if players had to resort to this to gain money.. and if they did something is wrong). I believe AV might have suggested a player vs monster arena and I would be happy to see one implemented. I know in the circus in caterham has a monster arena in which you pay a small amount of money to fight various monsters, this map could be reworked to take advantage of AV's arena tiles. dnh On Wed, 20 Jun 2001, Joel South wrote: > > If a normal monster kills you in the arena(not an avatar),do you die > a normal death or do you get teleported to the floor's destination? If > this does not already exist,it would be a nice feature. Such as the player > gets challenged to a fight by a NPC(not a fight to the death). Or if you > just want the player to get captured. > > Joel Southall > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Wed Jun 20 23:28:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:23 2005 Subject: Magicmap, was Re: [CF-Devel] new release: CFJavaEditor 0.971 References: Message-ID: <3B3177EA.FF8CB81C@scruz.net> Michael Toennies wrote: > > Type information is a absolut unique identifier. > To advance it, we also talked about to make a second byte > which is then the under type typ. > > like type x = weapon. x,1 = swords, x,2 = axes... > > This is absolut enough information for the client. One may question if it is in fact too much information for the client (I'm not necessarily saying it is, but such a system certainly conveys a lot more information to the client). Also note that such a change for the archetypes and code isn't near the top of my things to do right now. I do agree that some for like that could be used. I remember that heroes of might and magic would let you cast similar spells, and on the overall map, it would tell you what type of things are where. > > Also, the color information submited with the magic map command is more > than worse. You will not have different colors... magic map is normally > build up by 13 or 16 colors ors so. Seems a relict from 16 colors days. There is no debate about that. But there are a lot of things in the server that are 'old', but they work fine. Certainly something that works but is not ideal is better than nothing at all (or a quick hack). It seems like it would be a lot simpler to just update your editor to collect this information than do anything else. Or of course the alternate solution which will probably be used for a while then is to just not use the editor to collect the archs, but instead use the scripts in crossfire that actually do work and do all this stuff. could magic map be improved? It sure could be. But we should figure out what it should be improved to and how the implementation works out. > > Using a different water arch. Under your system, that only works if that other arch has a different type/subtype. To me, that is not a good approach - it requires rebuilding archetypes for somethign that should purely be an object change. Also, with a type/subtype setup, the client still needs to know what to do with the information. So if you add a new archetype, that doesn't really do any good unless client knows what to do with that new subtype. This makes adding such attributes much more difficult, as basically a client update is needed for it to be usuable. But as said, we really need to figure out what do to. My personal preference would be to basically make it a extended map type command (were we send the faces), but only send faces for non items/non monsters, and include special tags to note these other facts (tag for monster, treasure, and some other number of types). But once again, this conveys different informatoin - you get a very pretty map (client would presumably scale the images down), but you don't get any information on the monsters other than they are there. For example, with color information right now, you can narrow down monster types based on colors (not a lot of yellow/orange monsters, so if that currently shows on a magic map, you can pretty much know its a beholder/dread). OTOH, sending the exact information is a lot more than currently given. OTOH, if thats what is needed to make magic mapping usuable, that may not be too unreasonable. Note that there can be same big bandwidth issues if many of the images have not been sent to the client. Yes, if the player plans on doing the map, he will need to download those at some point, but casting this on a decent sized maps shortly after the player starts could results in a whole lot of images needing to get downloaded. From crossfire at suckfuell.net Thu Jun 21 00:59:00 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] Special Floors In-Reply-To: Message-ID: In Mopoon's Cave (Lake Country, mountains in the east) there is an area for training how to fight dragons. How about changing this ground so that you can't die while training the technique there? It doesn't hurt when you don't get any exp for killing those dragons, since it was just for training the battle tactics. And you could make other "training grounds" where newbies can try if they kill bigger monsters before they try and die on the spot. > I believe AV might have suggested a player vs monster arena and I would be > happy to see one implemented. I know in the circus in caterham has a > monster arena in which you pay a small amount of money to fight various > monsters, this map could be reworked to take advantage of AV's arena > tiles. Bye Jochen -- E-Mail: Jochen Suckfuell From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 01:07:00 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] Special Floors In-Reply-To: Message-ID: Well if someone wants to do this, i don't have a big problem with it.. I certainly don't feel like doing it myself. dnh On Thu, 21 Jun 2001, Jochen Suckfuell wrote: > In Mopoon's Cave (Lake Country, mountains in the east) there is an area for > training how to fight dragons. > > How about changing this ground so that you can't die while training the > technique there? > > It doesn't hurt when you don't get any exp for killing those dragons, since it > was just for training the battle tactics. > > And you could make other "training grounds" where newbies can try if they kill > bigger monsters before they try and die on the spot. > > > I believe AV might have suggested a player vs monster arena and I would be > > happy to see one implemented. I know in the circus in caterham has a > > monster arena in which you pay a small amount of money to fight various > > monsters, this map could be reworked to take advantage of AV's arena > > tiles. > > Bye > Jochen > > -- > E-Mail: Jochen Suckfuell > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 03:05:18 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars Message-ID: I just lost 52 levels of wisdom in roughly 54 seconds. How you ask? I was stuck down a corridor in a random map fighting a high angel, I prayed for more grace.. and instead watched as I went down to level 30 and became a valriel follower... yay. I then recalled and prayed to gorokh, down to level 12.. I started on 64. Now I basically resign that character because I can't be bothered playing for 3 weeks to try and get back all those lost points + prayers (vitriol). This IMHO is not fun. I ask myself why do we have this massive loss for switching gods? perhaps we could make it only loss a max of 10 levels? Right now I am about as inclined to play crossfire as I am to smash my head repeatedly against a large solid concrete wall. Until this bug is either a) changed or b) agreed to be left alone my position will not change. *deep sigh* dnh From crossfire at suckfuell.net Thu Jun 21 03:16:16 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: I suggest to leave the exp penalty as is, but also paralyze the player so that he doesn't pray more than once on the wrong altar. This also reduces the chance for changing the gods in a short time. On 21-Jun-2001 dnh wrote: > I just lost 52 levels of wisdom in roughly 54 seconds. How you ask? I was > stuck down a corridor in a random map fighting a high angel, I prayed for > more grace.. and instead watched as I went down to level 30 and became a > valriel follower... yay. I then recalled and prayed to gorokh, down to > level 12.. I started on 64. Bye Jochen -- E-Mail: Jochen Suckfuell From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 05:04:41 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: > I suggest to leave the exp penalty as is, but also paralyze the player so > that he doesn't pray more than once on the wrong altar. This also reduces the > chance for changing the gods in a short time. Hmm so then instead of losing all the grace to the altar I would just die to the high angel? =). No actually this idea has merit, i think i will implement it and see how it works. dnh From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 05:13:44 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: Interestingly it seems the code should move the player in the opposite direction from where he/she came. move_player(pl,absdir(pl->facing + 4)); /* back him off the way he came. */ Why did I not get this affect? The more I think about this more I think that I have been a victim of extreme bad luck. dnh On Thu, 21 Jun 2001, Jochen Suckfuell wrote: > I suggest to leave the exp penalty as is, but also paralyze the player so > that he doesn't pray more than once on the wrong altar. This also reduces the > chance for changing the gods in a short time. > > On 21-Jun-2001 dnh wrote: > > I just lost 52 levels of wisdom in roughly 54 seconds. How you ask? I was > > stuck down a corridor in a random map fighting a high angel, I prayed for > > more grace.. and instead watched as I went down to level 30 and became a > > valriel follower... yay. I then recalled and prayed to gorokh, down to > > level 12.. I started on 64. > > Bye > Jochen > > -- > E-Mail: Jochen Suckfuell > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Thu Jun 21 10:55:23 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: I longer prefer to change the way, yu can change gods. The way we handle this stuff comes from nethack. Well, nethack is a different game as our MMORPG. We can't quick reload. So, i prefer this: - no exp lose/ god changing on normal god altar - you must enter the church/temple of the god with special altar - if you pray on altar of different god you lose hp or something This will give also the fine option, to hide temples of special gods with high power, so you must find them fist in a quest. I never like this "god avenue" we have in scorn. > > Interestingly it seems the code should move the player in the opposite > direction from where he/she came. > > move_player(pl,absdir(pl->facing + 4)); /* back him off the way he came. > */ > > Why did I not get this affect? > > The more I think about this more I think that I have been a victim of > extreme bad luck. > > dnh > > > On Thu, 21 Jun 2001, Jochen Suckfuell wrote: > > > I suggest to leave the exp penalty as is, but also paralyze the > player so > > that he doesn't pray more than once on the wrong altar. This > also reduces the > > chance for changing the gods in a short time. > > > > On 21-Jun-2001 dnh wrote: > > > I just lost 52 levels of wisdom in roughly 54 seconds. How > you ask? I was > > > stuck down a corridor in a random map fighting a high angel, > I prayed for > > > more grace.. and instead watched as I went down to level 30 > and became a > > > valriel follower... yay. I then recalled and prayed to gorokh, down to > > > level 12.. I started on 64. > > > > Bye > > Jochen > > > > -- > > E-Mail: Jochen Suckfuell > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 12:12:07 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: Hey this sounds like a cool idea. Rewarded with a new god... cool. Actually I really wouldn't mind a complete rework of the gods starting with the names and what they are.. and finished with a new set from scratch. I feel alot of the concepts on which gods are based are now far out dated (can anyone say ruggilli?). I like the idea of circular god strengths and weaknesses (see magic the gathering) but I would be happy to see any number of new suggestions. Well this is certainly a massive project, I have already tried to repair the gods once (and I think they are okay right now), but because god worship is such a critical point in crossfire there are far to many exploits (can anyone say random maps). Basically alot of stuff needs to be reviewed and that takes alot of time and most of us don't have that. My ears are open.. dnh On Thu, 21 Jun 2001, Michael Toennies wrote: > I longer prefer to change the way, yu can change gods. > The way we handle this stuff comes from nethack. > Well, nethack is a different game as our MMORPG. > We can't quick reload. > > So, i prefer this: > > - no exp lose/ god changing on normal god altar > - you must enter the church/temple of the god with special altar > - if you pray on altar of different god you lose hp or something > > This will give also the fine option, to hide temples of special gods > with high power, so you must find them fist in a quest. > > I never like this "god avenue" we have in scorn. > > > > > Interestingly it seems the code should move the player in the opposite > > direction from where he/she came. > > > > move_player(pl,absdir(pl->facing + 4)); /* back him off the way he came. > > */ > > > > Why did I not get this affect? > > > > The more I think about this more I think that I have been a victim of > > extreme bad luck. > > > > dnh > > > > > > On Thu, 21 Jun 2001, Jochen Suckfuell wrote: > > > > > I suggest to leave the exp penalty as is, but also paralyze the > > player so > > > that he doesn't pray more than once on the wrong altar. This > > also reduces the > > > chance for changing the gods in a short time. > > > > > > On 21-Jun-2001 dnh wrote: > > > > I just lost 52 levels of wisdom in roughly 54 seconds. How > > you ask? I was > > > > stuck down a corridor in a random map fighting a high angel, > > I prayed for > > > > more grace.. and instead watched as I went down to level 30 > > and became a > > > > valriel follower... yay. I then recalled and prayed to gorokh, down to > > > > level 12.. I started on 64. > > > > > > Bye > > > Jochen > > > > > > -- > > > E-Mail: Jochen Suckfuell > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From bugs at real-time.com Thu Jun 21 12:25:11 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] [Bug 375] New - Monk Bug Message-ID: <200106211725.f5LHPBc07808@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=375 *** shadow/375 Thu Jun 21 12:25:11 2001 --- shadow/375.tmp.7805 Thu Jun 21 12:25:11 2001 *************** *** 0 **** --- 1,21 ---- + +============================================================================+ + | Monk Bug | + +----------------------------------------------------------------------------+ + | Bug #: 375 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: All | + | Severity: normal OS/Version: All | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: cpeirce@enderthethird.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + (Just thought that it should at least be added to Bugzilla after this long + without it being added... Would be a good habit) + + With a scroll of melee weapons (or whatever it's called, i forget ;-) ), a monk + is able to use weapons, and retain the core skill he starts with: meditation. \ No newline at end of file From mwedel at scruznet.com Thu Jun 21 14:24:57 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: On Thu, 21 Jun 2001, dnh wrote: > Interestingly it seems the code should move the player in the opposite > direction from where he/she came. > > move_player(pl,absdir(pl->facing + 4)); /* back him off the way he came. > */ > > Why did I not get this affect? It reverses the direction you are currently facing. This may not be direction you approached the altar from. Consider the case below: | |---- A |---- | Area to the left is a big room, and the altar is where the A is, and the passage is single width. When you first come to the altar, the code above would work fine. But suppose the case is now: | M|---- A |---- | With M being the monster you are attacking in melee. Reverse the direction does no good, as it just puts you into a wall Probably the easiest fix is to require something more than just praying to be a following. Maybe you need to do something like 'use_skill praying become_follower' or the like. Or the idea of only some altars doing automatic conversions (as MT suggest) is completely reasonable. It should be hard to come up with some flag that does that. Altars found in dungeons could still assist in getting grace and other benefits, but would not change your religion (praying over one may still have bad effects, like reducign grace). I'm not sure making conversion from one religion to another for free is a good thing. I could then see characters saying 'hmm. About to go on the dragon quest - let me follow the god that gives me really good fire protection. Ok, done with that, now time for undead, so let me worship the undead destroying god', etc. Making the altars harder to get to may not make it quite so bad, but do realize that experienced players will quickly learn where these altars are, and they will probably end up on web pages or other spoiler information, so effectively everyone will know where they are. This is one reason for the row of gods in the start town. The other is that gods are very important, and before when the altars showed up randomly, it could be a real pain to find the altar that you really want. Now adding in advanced temples could be interesting. You've gained some levels, and to progress your learning, you need to visit the high temple of sorig at the mountain tops. The actual effect of this could be mean several things. Each altar could have a level, and this transfers to what power of benefits you may get from that altar (so for the ones in scorn, praying over them is not going to get you much in the way of special benefits). This level could also be used to determine the maximum preist level spells you can cast - so maybe you can cast up to level 5 from the temples in scorn, but the high temple of sorig lets you cast up to level 15 (praying on a lower level altar does not reset this value lower, but to be able to cast these high level spells means you need to make at least one journey to the higher level temple). Of course, this is a lot of work - new maps would need to be done, changes to altar and praying code, etc. From mwedel at scruznet.com Thu Jun 21 14:30:47 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] major bug In-Reply-To: Message-ID: I haven't looked at this, but have some thoughts for anyone that may. The biggest problem here is that while the monk should not be able to learn melee weapons, there are other potential races/classes that may not start with that skill that should be able to learn it. And being able to differentiate that (other than putting in a check specific for the monk) is difficult. Now if there is no other class that starts without melee weapons but can learn it, then the simple solution is to remove the scrolls of melee weapon. I would guess this same bug may apply to all the class/race combinations that do not start with melee weapon skill. But I'm really not all that familar with race/class code. So I could be completely wrong on this. On Sat, 16 Jun 2001, dnh wrote: > Monks can wield weapons! > > They just need a scroll of melee weapons! > > - Havoc. > - cloak of Gaea +4 * (worn) 7.3 > - girdle of damage * (worn) 2.5 > - ring of War * (worn) 0.0 > - gauntlets of Sorig +4 * (worn) 2.3 > - bracers +4 * (worn) 2.2 > - Midnight Robe +5 * (worn) 5 > - amulet of Free Action * (worn) 0.5 > - Flame Tongue of Mostrai +5 * (wielde 22 > - full helmet of Might +4 * (worn) 10.6 > - holy shield +4 * (worn) 24.3 > - ring of Strife * (worn) 0.0 > > This is the inv of a monk... > > this bug needs to be fixed NOW! > > dnh > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From yann.chachkoff at MailAndNews.com Thu Jun 21 15:15:29 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] Scripting notes/questions Message-ID: <3B3C0CDB@MailAndNews.com> >===== Original Message From Mark Wedel ===== > Really meant to send this to the dev list, and not the cvs list. > >----- Forwarded Message ----- >From: crossfire-cvs-admin@lists.sourceforge.net >To: >Subject: RE: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.34,1.35 > > > A few questions on the scripts below (now I haven't looked at the code >a lot, so these questions may be able to get answered easily). But just >bringing this in a more forward form may also help others develope scripts. > > In the case of the weapon - it would seem that if your lucky, >it may be mulitple +10 bonuses and thus could be a very good weapon? >Now I do notice there is equal chance for the weapon to get worse - I'm >just saying theoretical here. Yes, that's 100% true. That's why it is a somewhat "chaotic" item. That is not really a problem - the weapon can loose bonuses very quickly, so it is somewhat risky to use it, even if it has got lots of +10 bonuses. > > Also, does the actual setting function do sanity checking on values? >For example, if your weapon does dam 5, and you attack and it happens >to take the first one and does dam -5, will the code say 'negative values >for damage are not valid', or would it set the damage to -5, which >would basically ammount to healing? I didn't included such checking. That's why the weapon is "chaotic" - You can sometimes "heal" your opponent instead of hitting it ! Now, you can of course check the damage value by yourself in the script - You just need to test the damage value with an if statement like (if (< (get-damage weapon) 10) ...) > >For the ring, I notce several lines like: >> + (set-wis (who-am-I) (- (get-dex (who-am-I)) 1)) > > Is that intentional that it is doing a get_dex and then a set_wis on >that value (if so, why it is doing that could perhaps be explained). > That was not intentional at first. You may replace the get-dex statements by corresponding get-wis, get-int, ... I didn't noticed it but since it doesn't hurt, no one sent me a bug report about it until now... > Third, what I would really like to see an example of (if it doesn't exist >already) is a npc character that actually has state. > >Right now, the npc's handling matches a specific message with a specific >word. I imagine the scriptfire stuff can do that also. > > But what I would like to see is something like: > >npc: I have a tale to tell. Do you want to here it? >player: yes >npc: blah blah blah. Should I continue? >player: yes >npc: more blah blah blah > > IMO, this is one of the things that is lacking in the current >message handling. Talking with npc's can be very difficult, because >it doesn't have any state, so you need the precise keyword. In the >above example, more complex language can also be done - maybe after >the npc says something, there are 3 followup questions the character >could ask, but if the player doesn't use any of the proper keywords, >the npc can then return with either some clue that helps the player >carry the conversation on, or continues on with a default thread and >the player misses the two other branches of the conversation unless >they return. > > Also, if not already done, I think having some small number of >variables that the script can set/read which are only used for scripts >could be useful (maybe 3 ints and 3 string pointers?) To do state >above, you need such a variable, and re-using some 'unused' variable >otherwise in the object structure seems like a bad idea from past >experience). Perhaps in fact, all the scripting related stuff should >be in its own structure which the object structure includes (sort of >like what is done with the stats structure) - this just addes some >cleanliness and compartmentilization. It also means that if we are >paranoid about space, that could in fact be a pointer, and only alloc >after the first referance to a script comes from the load file (since >a lot of objects probably won't contain scripts, this could add up to >some savings). Yeah, I like that idea of structures. I'll implement that now. For the loading/saving of states, you currently have to use the force archetype. I admit that it is not a clean way to do it, but I didn't included local vars until now to limit memory consumption (I'll not tell you who said me that it would consume too much memory - I didn't wanted to polemicate about this). Another addition I am currently testing: Implementing spells with scripts (using cast metamagical of xxx, where xxx is a name identifying the script executed). Chachkoff Y. ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. ------------------------------------------------------------ From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 21:36:23 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] altars In-Reply-To: Message-ID: Yes. I really like this idea. We move some temples out of scorn (to far away) and we give them the flag convert_player_religion. We make these altars very rare (for example mostrai could be a lost relic from a by gone era of dwarves living just east of navar). Indeed we could even make the temple of the firegods final altar, a special god or something the possibilities are much more interesting. I would certainly like to see this, cause I really hate how easy it is to kill yourself on an altar. mids, can you conduct a poll? dnh On Thu, 21 Jun 2001, Mark Wedel wrote: > On Thu, 21 Jun 2001, dnh wrote: > > > Interestingly it seems the code should move the player in the opposite > > direction from where he/she came. > > > > move_player(pl,absdir(pl->facing + 4)); /* back him off the way he came. > > */ > > > > Why did I not get this affect? > > It reverses the direction you are currently facing. This may not be direction > you approached the altar from. > > Consider the case below: > > > | > |---- > A > |---- > | > > Area to the left is a big room, and the altar is where the A is, > and the passage is single width. > > When you first come to the altar, the code above would work fine. > But suppose the case is now: > > | > M|---- > A > |---- > | > > With M being the monster you are attacking in melee. Reverse the direction > does no good, as it just puts you into a wall > > Probably the easiest fix is to require something more than just praying > to be a following. Maybe you need to do something like > 'use_skill praying become_follower' > > or the like. > > Or the idea of only some altars doing automatic conversions (as MT suggest) > is completely reasonable. It should be hard to come up with some flag > that does that. Altars found in dungeons could still assist in getting > grace and other benefits, but would not change your religion (praying > over one may still have bad effects, like reducign grace). > > I'm not sure making conversion from one religion to another for free is > a good thing. I could then see characters saying 'hmm. About to go > on the dragon quest - let me follow the god that gives me really good > fire protection. Ok, done with that, now time for undead, so let me > worship the undead destroying god', etc. Making the altars harder to get to > may not make it quite so bad, but do realize that experienced players will > quickly learn where these altars are, and they will probably end up on > web pages or other spoiler information, so effectively everyone will know > where they are. > > This is one reason for the row of gods in the start town. The other is > that gods are very important, and before when the altars showed up randomly, > it could be a real pain to find the altar that you really want. > > Now adding in advanced temples could be interesting. You've gained some > levels, and to progress your learning, you need to visit the high temple > of sorig at the mountain tops. > > The actual effect of this could be mean several things. Each altar > could have a level, and this transfers to what power of benefits you > may get from that altar (so for the ones in scorn, praying over them is > not going to get you much in the way of special benefits). This level > could also be used to determine the maximum preist level spells you can > cast - so maybe you can cast up to level 5 from the temples in scorn, > but the high temple of sorig lets you cast up to level 15 (praying > on a lower level altar does not reset this value lower, but to be > able to cast these high level spells means you need to make at least > one journey to the higher level temple). > > Of course, this is a lot of work - new maps would need to be done, > changes to altar and praying code, etc. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Thu Jun 21 21:39:28 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:23 2005 Subject: [CF-Devel] major bug In-Reply-To: Message-ID: Well the only other class that can't use weapons is the sorceror. And melee scrolls don't affect race, so you don't have to worry about fireborn (and beholder). Basically currently only monk has meditation, the simple solution would be. If a player reads a scoll of melee weapons, and they have meditation make sure meditation is removed or fail to learn the scroll. This is assuming the scroll doesn't affect race (ie if a fireborn monk read it, it would fail regardless of whether the player had meditation). dnh On Thu, 21 Jun 2001, Mark Wedel wrote: > > I haven't looked at this, but have some thoughts for anyone that may. > > The biggest problem here is that while the monk should not be able to > learn melee weapons, there are other potential races/classes that may not > start with that skill that should be able to learn it. > > And being able to differentiate that (other than putting in a check > specific for the monk) is difficult. > > Now if there is no other class that starts without melee weapons but > can learn it, then the simple solution is to remove the scrolls of > melee weapon. > > I would guess this same bug may apply to all the class/race combinations > that do not start with melee weapon skill. > > But I'm really not all that familar with race/class code. So I > could be completely wrong on this. > > > > On Sat, 16 Jun 2001, dnh wrote: > > > Monks can wield weapons! > > > > They just need a scroll of melee weapons! > > > > - Havoc. > > - cloak of Gaea +4 * (worn) 7.3 > > - girdle of damage * (worn) 2.5 > > - ring of War * (worn) 0.0 > > - gauntlets of Sorig +4 * (worn) 2.3 > > - bracers +4 * (worn) 2.2 > > - Midnight Robe +5 * (worn) 5 > > - amulet of Free Action * (worn) 0.5 > > - Flame Tongue of Mostrai +5 * (wielde 22 > > - full helmet of Might +4 * (worn) 10.6 > > - holy shield +4 * (worn) 24.3 > > - ring of Strife * (worn) 0.0 > > > > This is the inv of a monk... > > > > this bug needs to be fixed NOW! > > > > dnh > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Thu Jun 21 22:56:59 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:24 2005 Subject: [CF-Devel] major bug References: Message-ID: <3B32C20B.5C8C8CAA@scruz.net> dnh wrote: > > Well the only other class that can't use weapons is the sorceror. And > melee scrolls don't affect race, so you don't have to worry about > fireborn (and beholder). Basically currently only monk has meditation, the > simple solution would be. If a player reads a scoll of melee weapons, and > they have meditation make sure meditation is removed or fail to learn the > scroll. This is assuming the scroll doesn't affect race (ie if a fireborn > monk read it, it would fail regardless of whether the player had > meditation). Ok. I think I understand this a little better. The monk/race does in fact have the can_use_weapon attribute, it just doesn't have a skill to use a weapon. Am I right in assuming that it is impossible for any other race/class combo to get the meditation skill (through scroll or other means?) If so, then it would just mean that the monk reads the melee weapon scrolls (which would lose the meditation skill), and then learn the meditation skill right back again. And while your simple solution works, this strikes me as having the same potential problem with praying - a monk character accidentally reads melee weapons, and loses his meditation ability with no way to get it back. But putting a check in when learning melee weapon to not let them learn the skill they have meditation works, presuming they are the only situation where this arises (ie, no one else has meditation, or if they do, they already have melee weapons. This should be pretty easy to do - check out the learn_skill function DB. but it would probably be more interesting to revamp all of this. As others have been suggested, add guilds which is where characters can learn these new skills or other abilities (you could have incremental abilities, like upon attaining some level, you get a bonus ability of 15 sp if you go to the guild at .... - basically do the same thing with guilds as suggested with altars - many guilds for each class, but higher level guilds (which are also harder to get to) might teach the more advanced skills Guilds could charge admission, and use the typical ways so that you only need to pay once (marker objects). etc. But like the altar/god thread, this is a bit of work, but I think it could add more flavor to the game, and also allow for better balancing (if it is discovered the class XYZ starts falling too far behind in power compared to other classes at some level, that guild could teach some special ability that helps balance this - give out resistances, bonus sp/dam/grace, etc. You could only get this bonus once of course) From mwedel at scruz.net Thu Jun 21 23:14:41 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:24 2005 Subject: [CF-Devel] Scripting notes/questions References: <3B3C0CDB@MailAndNews.com> Message-ID: <3B32C631.A0C063BF@scruz.net> Yann Chachkoff wrote: > > Also, does the actual setting function do sanity checking on values? > >For example, if your weapon does dam 5, and you attack and it happens > >to take the first one and does dam -5, will the code say 'negative values > >for damage are not valid', or would it set the damage to -5, which > >would basically ammount to healing? > I didn't included such checking. That's why the weapon is "chaotic" - You can > sometimes "heal" your opponent instead of hitting it ! Now, you can of course > check the damage value by yourself in the script - You just need to test the > damage value with an if statement like (if (< (get-damage weapon) 10) ...) Ok. I'm more curious because if the script doesn't do something right, it could very well set values beyond legal limits (negative damage, while healing enemies, could very well have some other strange effects since the attack code basically assumes that damage done will always be positive). To be honest, I don't really know if this would work or not. Thats an example. Another would be setting the resistance of an item to above 100 in some field, overflowing allowed values, etc. I'm not sure how much of this should be the script writers responsibility and how much should be in the code itself, but at least if checking is done in the code, it is probably easier to find out where these strange values came from - looking at an object and finding it has resist_fire 110 could be very difficult to know how that happened, especially if it was a script in another object that modified that one to that value. If the player has been playing a while before they notice it, it could have been any of potentially dozens of scripts. > > Is that intentional that it is doing a get_dex and then a set_wis on > >that value (if so, why it is doing that could perhaps be explained). > > > That was not intentional at first. You may replace the get-dex statements by > corresponding get-wis, get-int, ... I didn't noticed it but since it doesn't > hurt, no one sent me a bug report about it until now... I was more curious because as a demonstration of using the script, doing that seemed pretty non intuitive, and I was more curious if there was something special going on there. For demonstration scripts, keeping them clear cut and not doing anything really strange is probably a good idea. > Yeah, I like that idea of structures. I'll implement that now. For the > loading/saving of states, you currently have to use the force archetype. I > admit that it is not a clean way to do it, but I didn't included local vars > until now to limit memory consumption (I'll not tell you who said me that it > would consume too much memory - I didn't wanted to polemicate about this). Until I saw the actual code, I was not aware of how the scripting was being implemented (a pointer in the object structure for each possible event). Given the number of events, adding 6 state variables to that memory consumption is pretty small in comparison. Probably making a script structure that is a pointer and only allocated as needed is the best way to go. > > Another addition I am currently testing: Implementing spells with scripts > (using cast metamagical of xxx, where xxx is a name identifying the script > executed). I'm curious what the desired result of this. I realize that probably most everything in the game could be done via scripts, with only the framework in C. But the script code is almost certainly slower than C, and if we go overboard into putting too much in scheme, we will probably find ourselves with more performance problems than we have right now, and then reverse again and start putting more stuff in C again. And when we already have working code in C (which already has performance issues), I really wonder if going to guile is the right thing. My other concern related to this is that most of the developers probably know C much better the guile (and this in fact came up when you announced your implementation idea). The more that gets implemented in guile probalby means the fewer people that will actually be able to debug and fix the problem. I have another idea to redo the spells, but that redos much more than just casting. In simple terms, everything is controlled via the archetypes (so the spellist.h and spells.h largely go away). The archetypes would contain spell level, sp costs, chance for it being in a wand/rod/scroll (as well as typical number of charges and cost for that), etc. Spell code would also get generalized, so things like ball spells would all use the same code, and the arch would determine how big an explosion, etc. From michael.toennies at nord-com.net Thu Jun 21 23:10:56 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:24 2005 Subject: [CF-Devel] major bug In-Reply-To: <3B32C20B.5C8C8CAA@scruz.net> Message-ID: Hm, why not removing the scrolls and make this stuff part of quests /npcs? So, we can control this better and we avoid this boring "i run through shops and search for the scroll i had find tons with other char but never with these one". > dnh wrote: > > > > Well the only other class that can't use weapons is the sorceror. And > > melee scrolls don't affect race, so you don't have to worry about > > fireborn (and beholder). Basically currently only monk has > meditation, the > > simple solution would be. If a player reads a scoll of melee > weapons, and > > they have meditation make sure meditation is removed or fail to > learn the > > scroll. This is assuming the scroll doesn't affect race (ie if > a fireborn > > monk read it, it would fail regardless of whether the player had > > meditation). > > Ok. I think I understand this a little better. > > The monk/race does in fact have the can_use_weapon attribute, it > just doesn't > have a skill to use a weapon. > > Am I right in assuming that it is impossible for any other > race/class combo to > get the meditation skill (through scroll or other means?) If so, > then it would > just mean that the monk reads the melee weapon scrolls (which > would lose the > meditation skill), and then learn the meditation skill right back again. > > And while your simple solution works, this strikes me as having the same > potential problem with praying - a monk character accidentally reads melee > weapons, and loses his meditation ability with no way to get it back. > > But putting a check in when learning melee weapon to not let > them learn the > skill they have meditation works, presuming they are the only > situation where > this arises (ie, no one else has meditation, or if they do, they > already have > melee weapons. > > This should be pretty easy to do - check out the learn_skill function DB. > > but it would probably be more interesting to revamp all of this. > As others > have been suggested, add guilds which is where characters can > learn these new > skills or other abilities (you could have incremental abilities, like upon > attaining some level, you get a bonus ability of 15 sp if you go > to the guild at > .... - basically do the same thing with guilds as suggested with > altars - many > guilds for each class, but higher level guilds (which are also > harder to get to) > might teach the more advanced skills > > Guilds could charge admission, and use the typical ways so that > you only need > to pay once (marker objects). etc. But like the altar/god > thread, this is a > bit of work, but I think it could add more flavor to the game, > and also allow > for better balancing (if it is discovered the class XYZ starts > falling too far > behind in power compared to other classes at some level, that > guild could teach > some special ability that helps balance this - give out resistances, bonus > sp/dam/grace, etc. You could only get this bonus once of course) > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Fri Jun 22 00:43:51 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:24 2005 Subject: [CF-Devel] major bug In-Reply-To: <3B32C20B.5C8C8CAA@scruz.net> Message-ID: Cool On Thu, 21 Jun 2001, Mark Wedel wrote: > dnh wrote: > > > > Well the only other class that can't use weapons is the sorceror. And > > melee scrolls don't affect race, so you don't have to worry about > > fireborn (and beholder). Basically currently only monk has meditation, the > > simple solution would be. If a player reads a scoll of melee weapons, and > > they have meditation make sure meditation is removed or fail to learn the > > scroll. This is assuming the scroll doesn't affect race (ie if a fireborn > > monk read it, it would fail regardless of whether the player had > > meditation). > > Ok. I think I understand this a little better. > > The monk/race does in fact have the can_use_weapon attribute, it just doesn't > have a skill to use a weapon. Yeah that is what it would appear to be. > Am I right in assuming that it is impossible for any other race/class combo to > get the meditation skill (through scroll or other means?) If so, then it would > just mean that the monk reads the melee weapon scrolls (which would lose the > meditation skill), and then learn the meditation skill right back again. > > And while your simple solution works, this strikes me as having the same > potential problem with praying - a monk character accidentally reads melee > weapons, and loses his meditation ability with no way to get it back. Yes, well my simple fix to that would be to provide meditation scrolls ;). > But putting a check in when learning melee weapon to not let them learn the > skill they have meditation works, presuming they are the only situation where > this arises (ie, no one else has meditation, or if they do, they already have > melee weapons. > > This should be pretty easy to do - check out the learn_skill function DB. Okay I had alook, all we have to do is run another case.. case 3: new_draw_info(NDI_UNIQUE, 0,op,"You have a skill which denies the possession of such skills"); return; or something (I haven't done cases.. nor do I know what NDI_UNIQUE is) alternatively i suppose you could just say.. you already possess the knowledge inside this scroll.. > but it would probably be more interesting to revamp all of this. As others > have been suggested, add guilds which is where characters can learn these new > skills or other abilities (you could have incremental abilities, like upon > attaining some level, you get a bonus ability of 15 sp if you go to the guild at > .... - basically do the same thing with guilds as suggested with altars - many > guilds for each class, but higher level guilds (which are also harder to get to) > might teach the more advanced skills This is my prefered option but I don't think I can do much.. I have trouble following most of this code.. let alone writting my own. > Guilds could charge admission, and use the typical ways so that you only need > to pay once (marker objects). etc. But like the altar/god thread, this is a > bit of work, but I think it could add more flavor to the game, and also allow > for better balancing (if it is discovered the class XYZ starts falling too far > behind in power compared to other classes at some level, that guild could teach > some special ability that helps balance this - give out resistances, bonus > sp/dam/grace, etc. You could only get this bonus once of course) again I like it, but I can't do it. dnh _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From bugs at real-time.com Mon Jun 25 02:10:03 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:24 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200106250710.f5P7A3w22906@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 http://bugzilla.real-time.com/show_bug.cgi?id=369 From michael.toennies at nord-com.net Tue Jun 26 17:52:52 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:24 2005 Subject: [CF-Devel] sever warnings under VC6++/win32 Message-ID: when i compile the server under VC6++, i got many warnings. Most are missing casting, but some should be interesting for possible side effect. In fact ,we should remove them step for step in the future. Sadly, my VC gives german error messages out, but they should be understandable. her some hint Konvertierung = converting Konflikt = conflict :) Gr??enkonflikt im Argument. Konvertierung vorgenommen = size conflict in argument. auto converted. Verkuerzung von = shortend from (implizit cast, which he don't like) info.c init.c item.c F:\PROJECTS\crossfire\socket\item.c(239) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\item.c(320) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\item.c(422) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\item.c(497) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\item.c(541) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\item.c(545) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\item.c(549) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\item.c(553) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\item.c(557) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\item.c(762) : warning C4018: '==' : Konflikt zwischen signed und unsigned loop.c F:\PROJECTS\crossfire\socket\item.c(226) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(243) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(65) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(65) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(65) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(307) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(324) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(65) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(377) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(406) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(426) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(65) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(484) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(501) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\item.c(65) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\loop.c(387) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\loop.c(429) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\loop.c(430) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\loop.c(431) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\loop.c(452) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\loop.c(453) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\loop.c(454) : warning C4018: '==' : Konflikt zw ischen signed und unsigned lowlevel.c metaserver.c request.c F:\PROJECTS\crossfire\socket\request.c(331) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\request.c(622) : warning C4244: '=' : Konvertierung von 'short ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\request.c(629) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\request.c(643) : warning C4244: 'function' : Konvertierung von 'short ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\request.c(914) : warning C4244: '=' : Konvertierung von 'unsigned short ' in 'unsigned char ', moeglicher Datenverlust F:\PROJECTS\crossfire\socket\request.c(946) : warning C4018: '>' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\socket\request.c(1072) : warning C4305: 'function' : Verkuerzung von 'const int ' in 'char ' F:\PROJECTS\crossfire\socket\request.c(1073) : warning C4305: 'function' : Verkuerzung von 'const int ' in 'char ' F:\PROJECTS\crossfire\socket\request.c(1146) : warning C4018: '>' : Konflikt zwischen signed und unsigned sounds.c F:\PROJECTS\crossfire\socket\request.c(328) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(617) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(618) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(643) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(648) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(650) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(677) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(1092) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(1094) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(1104) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(1106) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(1116) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\request.c(1118) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\sounds.c(35) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\sounds.c(36) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\sounds.c(37) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\socket\sounds.c(38) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen Kompilierung l?uft... alchemy.c F:\PROJECTS\crossfire\server\alchemy.c(86) : warning C4244: '+=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\alchemy.c(91) : warning C4244: '+=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\alchemy.c(136) : warning C4244: '*=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\alchemy.c(138) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\alchemy.c(269) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust apply.c F:\PROJECTS\crossfire\server\alchemy.c(416) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\server\apply.c(628) : warning C4244: '+=' : Konvertierung von 'double ' in 'long ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\apply.c(1117) : warning C4244: '=' : Konvertierung von 'const double ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\apply.c(1140) : warning C4244: '=' : Konvertierung von 'short ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\apply.c(1981) : warning C4033: 'manual_apply' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\apply.c(1986) : warning C4033: 'manual_apply' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\apply.c(2811) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\apply.c(2811) : warning C4018: '!=' : Konflikt zwischen signed und unsigned attack.c F:\PROJECTS\crossfire\server\apply.c(2165) : warning C4715: 'manual_apply' : Nicht alle Steuerelementpfade geben einen Wert zur?ck F:\PROJECTS\crossfire\server\apply.c(2895) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\server\attack.c(415) : warning C4033: 'attack_ob_simple' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\attack.c(1028) : warning C4033: 'kill_object' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\attack.c(1036) : warning C4033: 'kill_object' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\attack.c(1049) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\attack.c(1051) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\attack.c(1017) : warning C4101: 'simple_attack' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\attack.c(1015) : warning C4101: 'attacknum' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\attack.c(1015) : warning C4101: 'ndam' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\attack.c(1018) : warning C4101: 'hitter_tag' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\attack.c(1018) : warning C4101: 'op_tag' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\attack.c(1252) : warning C4101: 'buf' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\attack.c(1564) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\attack.c(1596) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\attack.c(1601) : warning C4244: '+=' : Konvertierung von 'float ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\attack.c(1604) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust ban.c F:\PROJECTS\crossfire\server\attack.c(597) : warning C4715: 'attack_ob_simple' : Nicht alle Steuerelementpfade geben einen Wert zur?ck F:\PROJECTS\crossfire\server\attack.c(1239) : warning C4715: 'kill_object' : Nicht alle Steuerelementpfade geben einen Wert zur?ck c_chat.c c_misc.c c_move.c c_new.c c_object.c F:\PROJECTS\crossfire\server\c_object.c(476) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\c_object.c(541) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\c_object.c(681) : warning C4018: '==' : Konflikt zwischen signed und unsigned c_party.c c_range.c F:\PROJECTS\crossfire\server\c_range.c(113) : warning C4018: '!=' : Konflikt zwischen signed und unsigned c_wiz.c commands.c F:\PROJECTS\crossfire\server\commands.c(62) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' disease.c F:\PROJECTS\crossfire\server\disease.c(428) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\disease.c(489) : warning C4244: 'function' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\disease.c(491) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust egoitem.c F:\PROJECTS\crossfire\server\disease.c(489) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\server\egoitem.c(34) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust encounter.c gods.c F:\PROJECTS\crossfire\server\gods.c(56) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\gods.c(153) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\gods.c(684) : warning C4244: 'initializing' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\gods.c(686) : warning C4244: 'initializing' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\gods.c(839) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust hiscore.c F:\PROJECTS\crossfire\server\hiscore.c(352) : warning C4018: '>' : Konflikt zwischen signed und unsigned init.c login.c F:\PROJECTS\crossfire\server\login.c(794) : warning C4113: 'int (__cdecl *)()' weicht in der Parameterliste von 'int (__cdecl *)(const void *,const void *)' ab main.c monster.c F:\PROJECTS\crossfire\server\monster.c(141) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\monster.c(525) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\monster.c(978) : warning C4244: 'function' : Konvertierung von 'short ' in 'unsigned char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\monster.c(1355) : warning C4033: 'talk_to_npc' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\monster.c(1686) : warning C4018: '==' : Konflikt zwischen signed und unsigned move.c F:\PROJECTS\crossfire\server\monster.c(978) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\server\monster.c(1382) : warning C4715: 'talk_to_npc' : Nicht alle Steuerelementpfade geben einen Wert zur?ck pets.c player.c F:\PROJECTS\crossfire\server\player.c(990) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\player.c(1362) : warning C4244: '=' : Konvertierung von 'short ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\player.c(1513) : warning C4018: '<' : Konflikt zwischen signed und unsigned resurrection.c rune.c F:\PROJECTS\crossfire\server\rune.c(103) : warning C4018: '<' : Konflikt zwischen signed und unsigned shop.c F:\PROJECTS\crossfire\server\shop.c(69) : warning C4244: 'return' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\shop.c(70) : warning C4244: 'return' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\shop.c(171) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\shop.c(183) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\shop.c(185) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\shop.c(399) : warning C4018: '>' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\shop.c(676) : warning C4113: 'int (__cdecl *)()' weicht in der Parameterliste von 'int (__cdecl *)(const void *,const void *)' ab skill_util.c .\include\skillist.h(36) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(59) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(59) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(59) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(60) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(60) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(60) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(61) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(61) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(61) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(61) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(62) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(62) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(62) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(63) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(63) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(63) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(63) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(64) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(64) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(64) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(64) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(64) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(65) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(65) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(65) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(65) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skill_util.c(315) : warning C4244: '=' : Konvertierung von 'long ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\skill_util.c(606) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\skill_util.c(1216) : warning C4018: '>=' : Konflikt zwischen signed und unsigned skills.c F:\PROJECTS\crossfire\server\skills.c(1441) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\skills.c(1442) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\skills.c(1537) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\skills.c(1545) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\skills.c(1546) : warning C4244: '=' : Konvertierung von 'const double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\skills.c(1586) : warning C4305: '*=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\skills.c(1590) : warning C4305: '*=' : Verkuerzung von 'const double ' in 'float ' spell_effect.c F:\PROJECTS\crossfire\server\spell_effect.c(481) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_effect.c(557) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_effect.c(674) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(1196) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(1197) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_effect.c(1218) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\spell_effect.c(1222) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\server\spell_effect.c(1704) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(2086) : warning C4244: '*=' : Konvertierung von 'const double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(2692) : warning C4244: '-=' : Konvertierung von 'double ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(2698) : warning C4244: '+=' : Konvertierung von 'double ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(3504) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(3506) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_effect.c(3687) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_effect.c(3690) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' spell_util.c F:\PROJECTS\crossfire\server\spell_util.c(342) : warning C4244: '-=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_util.c(872) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_util.c(873) : warning C4244: '=' : Konvertierung von 'const double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\spell_util.c(1329) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_util.c(1366) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_util.c(1439) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_util.c(1789) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\spell_util.c(2117) : warning C4244: '*=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust swamp.c F:\PROJECTS\crossfire\server\swamp.c(19) : warning C4244: '-=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\swamp.c(44) : warning C4244: '-=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\swamp.c(53) : warning C4244: '-=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust swap.c time.c F:\PROJECTS\crossfire\server\time.c(50) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(52) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(64) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(66) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(522) : warning C4244: '=' : Konvertierung von 'short ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\time.c(852) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(854) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(874) : warning C4244: '=' : Konvertierung von 'const double ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\time.c(945) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\server\time.c(946) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust Kompilierung l?uft... script.c F:\PROJECTS\crossfire\server\script.c(252) : warning C4013: 'guile_init_spell_functions' undefiniert; Annahme: extern mit Rueckgabetyp int F:\PROJECTS\crossfire\server\script.c(265) : warning C4101: 'buf' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\script.c(299) : warning C4101: 'buf' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\script.c(333) : warning C4101: 'buf' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\script.c(562) : warning C4033: 'Script_setWeight' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(567) : warning C4033: 'Script_setWeight' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(644) : warning C4033: 'Script_setQuantity' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(649) : warning C4033: 'Script_setQuantity' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(881) : warning C4033: 'Script_setSpeed' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(886) : warning C4033: 'Script_setSpeed' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(888) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(905) : warning C4033: 'Script_setLastSP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(910) : warning C4033: 'Script_setLastSP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(925) : warning C4033: 'Script_setLastGP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(930) : warning C4033: 'Script_setLastGP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(967) : warning C4033: 'Script_setDamage' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(972) : warning C4033: 'Script_setDamage' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1032) : warning C4013: 'kill_object' undefiniert; Annahme: extern mit Rueckgabetyp int F:\PROJECTS\crossfire\server\script.c(1230) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1231) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1373) : warning C4101: 'buf' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\script.c(1399) : warning C4101: 'buf' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\server\script.c(1675) : warning C4033: 'Script_setAC' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1680) : warning C4033: 'Script_setAC' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1682) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1749) : warning C4033: 'Script_setHP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1754) : warning C4033: 'Script_setHP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1756) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1767) : warning C4033: 'Script_setSP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1772) : warning C4033: 'Script_setSP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1774) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1785) : warning C4033: 'Script_setFP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1790) : warning C4033: 'Script_setFP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1792) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1803) : warning C4033: 'Script_setGP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1808) : warning C4033: 'Script_setGP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1810) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1821) : warning C4033: 'Script_setMaxHP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1826) : warning C4033: 'Script_setMaxHP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1828) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1839) : warning C4033: 'Script_setMaxSP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1844) : warning C4033: 'Script_setMaxSP' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1846) : warning C4244: '=' : Konvertierung von 'long ' in 'short ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1858) : warning C4033: 'Script_setCha' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1863) : warning C4033: 'Script_setCha' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1865) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1868) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1881) : warning C4033: 'Script_setStr' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1886) : warning C4033: 'Script_setStr' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1888) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1891) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1904) : warning C4033: 'Script_setDex' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1909) : warning C4033: 'Script_setDex' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1911) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1914) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1927) : warning C4033: 'Script_setInt' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1932) : warning C4033: 'Script_setInt' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1934) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1937) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1950) : warning C4033: 'Script_setWis' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1955) : warning C4033: 'Script_setWis' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1957) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1960) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1973) : warning C4033: 'Script_setPow' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1978) : warning C4033: 'Script_setPow' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(1980) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1983) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(1996) : warning C4033: 'Script_setCon' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(2001) : warning C4033: 'Script_setCon' muss einen Wert zurueckgeben F:\PROJECTS\crossfire\server\script.c(2003) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust F:\PROJECTS\crossfire\server\script.c(2006) : warning C4244: '=' : Konvertierung von 'long ' in 'char ', moeglicher Datenverlust script_spells.c script_types.c win32.c expand2x.c Generieren von Code... F:\PROJECTS\crossfire\server\script.c(499) : warning C4716: 'Script_setCursed' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(504) : warning C4716: 'Script_activateRune' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(509) : warning C4716: 'Script_checkTrigger' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(522) : warning C4716: 'Script_setUnaggressive' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(554) : warning C4716: 'Script_setGod' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(570) : warning C4716: 'Script_setWeight' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(594) : warning C4715: 'Script_teleport' : Nicht alle Steuerelementpfade geben einen Wert zur?ck F:\PROJECTS\crossfire\server\script.c(604) : warning C4716: 'Script_pickUp' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(636) : warning C4716: 'Script_getMap' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(652) : warning C4716: 'Script_setQuantity' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(668) : warning C4716: 'Script_insertObjectInside' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(696) : warning C4716: 'Script_drop' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(704) : warning C4716: 'Script_take' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(724) : warning C4716: 'Script_setInvisible' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(734) : warning C4716: 'Script_setXP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(743) : warning C4716: 'Script_setReturnValue' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(754) : warning C4716: 'Script_setDirection' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(804) : warning C4716: 'Script_setScriptDeath' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(811) : warning C4716: 'Script_setScriptLoad' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(818) : warning C4716: 'Script_setScriptApply' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(825) : warning C4716: 'Script_setScriptSay' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(832) : warning C4716: 'Script_setScriptTrigger' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(846) : warning C4716: 'Script_setScriptTime' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(853) : warning C4716: 'Script_setScriptAttack' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(860) : warning C4716: 'Script_setScriptDrop' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(867) : warning C4716: 'Script_setScriptThrow' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(874) : warning C4716: 'Script_setScriptStop' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(889) : warning C4716: 'Script_setSpeed' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(913) : warning C4716: 'Script_setLastSP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(933) : warning C4716: 'Script_setLastGP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(938) : warning C4716: 'Script_fixObject' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(947) : warning C4716: 'Script_setFace' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(952) : warning C4716: 'Script_setAttackType' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(975) : warning C4716: 'Script_setDamage' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(983) : warning C4716: 'Script_getDamage' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(998) : warning C4716: 'Script_setBeenApplied' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1013) : warning C4716: 'Script_setIdentified' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1044) : warning C4716: 'Script_killObject' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1090) : warning C4716: 'Script_castAbility' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1100) : warning C4716: 'Script_castSpell' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1108) : warning C4716: 'Script_forgetSpell' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1116) : warning C4716: 'Script_acquireSpell' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1313) : warning C4716: 'Script_removeObject' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1365) : warning C4716: 'Script_crossfireSay' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1391) : warning C4716: 'Script_crossfireWrite' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1414) : warning C4716: 'Script_crossfireMessage' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1638) : warning C4716: 'Script_setPosition' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1665) : warning C4716: 'Script_setTitle' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1683) : warning C4716: 'Script_setAC' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1757) : warning C4716: 'Script_setHP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1775) : warning C4716: 'Script_setSP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1793) : warning C4716: 'Script_setFP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1811) : warning C4716: 'Script_setGP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1829) : warning C4716: 'Script_setMaxHP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1847) : warning C4716: 'Script_setMaxSP' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1871) : warning C4716: 'Script_setCha' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1894) : warning C4716: 'Script_setStr' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1917) : warning C4716: 'Script_setDex' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1940) : warning C4716: 'Script_setInt' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1963) : warning C4716: 'Script_setWis' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(1986) : warning C4716: 'Script_setPow' : Mu? einen Wert zur?ckgeben F:\PROJECTS\crossfire\server\script.c(2009) : warning C4716: 'Script_setCon' : Mu? einen Wert zur?ckgeben Kompilierung l?uft... decor.c door.c exit.c floor.c maze_gen.c monster.c F:\PROJECTS\crossfire\random_maps\monster.c(106) : warning C4244: '=' : Konvertierung von 'double ' in 'unsigned long ', moeglicher Datenverlust random_map.c reader.c rogue_layout.c room_gen_onion.c F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(169) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(174) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(177) : warning C4244: '-=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(178) : warning C4244: '-=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(184) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(185) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(228) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(233) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(236) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(237) : warning C4244: '-=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(238) : warning C4244: '-=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(244) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(245) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(251) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(329) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(330) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(331) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(336) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(337) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(344) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(345) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(351) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(352) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(404) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(409) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(411) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(414) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(415) : warning C4244: '-=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(416) : warning C4244: '-=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(422) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(423) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(428) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_onion.c(430) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust room_gen_spiral.c F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(77) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(78) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(98) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(102) : warning C4244: 'initializing' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(117) : warning C4244: 'function' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(117) : warning C4244: 'function' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(119) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(120) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\random_maps\room_gen_spiral.c(122) : warning C4305: '+=' : Verkuerzung von 'const double ' in 'float ' snake.c special.c square_spiral.c style.c treasure.c F:\PROJECTS\crossfire\random_maps\style.c(130) : warning C4700: Lokale Variable 'save' wurde ohne Initialisierung verwendet wall.c Kompilierung l?uft... anim.c F:\PROJECTS\crossfire\common\anim.c(135) : warning C4113: 'int (__cdecl *)()' weicht in der Parameterliste von 'int (__cdecl *)(const void *,const void *)' ab arch.c F:\PROJECTS\crossfire\common\arch.c(55) : warning C4101: 'index' : Unreferenzierte lokale Variable F:\PROJECTS\crossfire\common\arch.c(104) : warning C4013: 'item_matched_string' undefiniert; Annahme: extern mit Rueckgabetyp int F:\PROJECTS\crossfire\common\arch.c(335) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' button.c F:\PROJECTS\crossfire\common\button.c(49) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(134) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(182) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(244) : warning C4018: '<=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(248) : warning C4018: '>=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(302) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\button.c(512) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(529) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\button.c(668) : warning C4018: '!=' : Konflikt zwischen signed und unsigned exp.c F:\PROJECTS\crossfire\common\exp.c(40) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(43) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(44) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(45) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(46) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(57) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(59) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(60) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(61) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(62) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(63) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(64) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(65) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(66) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(67) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(69) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(70) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\exp.c(71) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' friend.c F:\PROJECTS\crossfire\common\friend.c(90) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\friend.c(123) : warning C4018: '!=' : Konflikt zwischen signed und unsigned glue.c holy.c image.c F:\PROJECTS\crossfire\common\image.c(250) : warning C4113: 'int (__cdecl *)()' weicht in der Parameterliste von 'int (__cdecl *)(const void *,const void *)' ab F:\PROJECTS\crossfire\common\image.c(320) : warning C4113: 'int (__cdecl *)()' weicht in der Parameterliste von 'int (__cdecl *)(const void *,const void *)' ab info.c init.c item.c links.c living.c F:\PROJECTS\crossfire\common\living.c(67) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(67) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(67) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(67) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(68) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(69) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(69) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(69) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(69) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(78) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(79) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(80) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(80) : warning C4305: 'initializing' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(899) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(962) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(963) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1085) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1170) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1174) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1223) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1232) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1244) : warning C4244: '=' : Konvertierung von 'int ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1245) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1248) : warning C4244: '+=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1253) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(1257) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1258) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1259) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1260) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1261) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1262) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1263) : warning C4244: '*=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1264) : warning C4305: '=' : Verkuerzung von 'const double ' in 'float ' F:\PROJECTS\crossfire\common\living.c(1313) : warning C4244: 'return' : Konvertierung von 'double ' in 'unsigned int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1315) : warning C4244: 'return' : Konvertierung von 'double ' in 'unsigned int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1321) : warning C4244: 'return' : Konvertierung von 'double ' in 'unsigned int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1323) : warning C4244: 'return' : Konvertierung von 'double ' in 'unsigned int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1440) : warning C4244: 'function' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\living.c(1475) : warning C4018: '>=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\living.c(1490) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\living.c(1530) : warning C4018: '>' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\living.c(1607) : warning C4018: '>' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\living.c(1624) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust loader.c F:\PROJECTS\crossfire\common\living.c(411) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen F:\PROJECTS\crossfire\common\living.c(424) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen loader.l(360) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust loader.l(361) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust loader.l(365) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust loader.l(366) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust logger.c los.c F:\PROJECTS\crossfire\common\los.c(139) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\los.c(256) : warning C4244: '=' : Konvertierung von 'short ' in 'unsigned char ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\los.c(327) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\los.c(435) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\los.c(452) : warning C4018: '!=' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\los.c(506) : warning C4018: '!=' : Konflikt zwischen signed und unsigned ltostr.c map.c F:\PROJECTS\crossfire\common\map.c(730) : warning C4244: '=' : Konvertierung von 'short ' in 'unsigned char ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\map.c(1419) : warning C4244: '=' : Konvertierung von 'double ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\map.c(1422) : warning C4018: '<=' : Konflikt zwischen signed und unsigned object.c F:\PROJECTS\crossfire\common\object.c(298) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\object.c(631) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\object.c(1651) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\object.c(1692) : warning C4018: '>' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\object.c(1702) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\object.c(1722) : warning C4018: '<' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\object.c(1896) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\object.c(1900) : warning C4244: '=' : Konvertierung von 'double ' in 'float ', moeglicher Datenverlust player.c porting.c re-cmp.c F:\PROJECTS\crossfire\common\re-cmp.c(176) : warning C4018: '>' : Konflikt zwischen signed und unsigned readable.c F:\PROJECTS\crossfire\common\readable.c(1440) : warning C4244: '=' : Konvertierung von 'float ' in 'int ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\readable.c(1520) : warning C4018: '==' : Konflikt zwischen signed und unsigned F:\PROJECTS\crossfire\common\readable.c(1910) : warning C4018: '==' : Konflikt zwischen signed und unsigned recipe.c shstr.c sqrt.c time.c treasure.c F:\PROJECTS\crossfire\common\treasure.c(1478) : warning C4244: '=' : Konvertierung von 'float ' in 'long ', moeglicher Datenverlust F:\PROJECTS\crossfire\common\treasure.c(542) : warning C4761: Gr??enkonflikt im Argument. Konvertierung vorgenommen Linker-Vorgang l?uft... 1 Datei(en) kopiert crossfire32.exe - 0 Fehler, 509 Warnung(en) From michael.toennies at nord-com.net Wed Jun 27 00:56:18 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:25 2005 Subject: [CF-Devel] CF SDL client 0.1 Message-ID: Hi Here is the first release of the iso SDL client 0.1 . http://mids.student.utwente.nl/~michtoen/sdl_client/cfclientsdl.zip and the data to setup a iso server http://mids.student.utwente.nl/~michtoen/sdl_client/isoserverdata.zip To setup a iso server: 1.) just setup a NORMAL cvs server. 2.) copy all data in the isoserverdata.zip over the same named stuff in share folder 3.) done. You don't need to change server code or special compiling Note, that there is still a crossfire.xbm/crossfire.xpm, but with png files inside. So, don't login to this modified server with xbm/xpm client... Or your client has some bad seconds. I had done the win32 implementation, the linux/max/BeOS one should do someone else who has access to this OS. I use native SDL: - SDL 1.2 lib - SDL image lib - SDL mixer lib I included them for win32 in sdl_win32 folder. You has to download for a different OS the libs. At the moment, the client can connect to a server, input with name/paswd, going around with num pad keys, apply with SPACE, and with the 'v' key you can fire a sound for sound lib testing. Input is odd yet - no cursor and perhaps not the right keyboard layout. You can close the client by hit ESC. When it don't work, try to hit RETURN first. If you login, the map will shown and a not finished text windows. The client shows iso map yet. For every OS, there is one native module. win32.c/win32.h for win9x, linux.c/linux.h for linux. There is the low level socket stuff in and some other functions. For linux, making a native version should be easy. I use a very basic socket implementation, this should be usable for all other OS. The client is REAL fast. Frames per second for my P500 with Voodoo 2000: mode fps ------------------------------------------------------ 800x600 16bpp fullscreen 90-100 800x600 16bpp windowed on 16bpp 50-55 800x600 16bpp windowed on 32bpp 50-55 800x600 32bpp windowed on 32bpp 50-30 800x600 32bpp fullscreen 80-90 (when i remember right) Don't try mixed modes windowed, this will destroy performance. Also, a bad setup for he client (loading and storing bitmap data in the false mode) will destroy performance on a high level. I had about 20 false stored map tiles one time, and my performance dropped down to 6 fps ! Ok, i need now one who does the linux convert. Should be a small work. I have many sounds/pictures i can use from dx client, so we don't need a widget lib. I tested the useful libs, and most are not useful for us, to slow or simply to powerful. 2 Libs adding full window system power to SDL, thats like you use gnome or kde yet. And we use only 2-3% of all there functions, so its a big big overhead. Another problem are fonts. I do a flirt with true type fonts, but we need 2 other libs to include them. They are slow. The libs don't work 100% on mac and BeOS. The fonts are 99% copyright by others. And so on. Perhaps one can write her something native... As libs, they are overpowered for the few text parts we have. The font routine i implement will be very powerful. Because the routine can change the attached palette for every blitted character, we can now include text like msg @match * Hi, welcome in &Scorn @match scorn .... endmsg The text will be normal color, the trigger word Scorn will shown in a special color. The '&' will trigger this. The '&' will then not shown, of course. I don't include it yet, but its easy to do. 10 minutes work. Ok, i had included so many useful interfaces like possible, this is only a 3 day work. :) Oh yes: no key repeat yes nor real game timing. So don't wonder. Michael From yann.chachkoff at MailAndNews.com Wed Jun 27 02:36:21 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:25 2005 Subject: [CF-Devel] sever warnings under VC6++/win32 Message-ID: <3B405D33@MailAndNews.com> I can only respond about the warnings for script.c - Someone already underlined that problem and correction is under way. Chachkoff Y. ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. ------------------------------------------------------------ From joel at prninfo.com Thu Jun 28 16:43:51 2001 From: joel at prninfo.com (Joel South) Date: Thu Jan 13 18:01:25 2005 Subject: [CF-Devel] altars In-Reply-To: from "dnh" at Jun 22, 2001 12:36:23 PM Message-ID: <200106282143.RAA07912@mamia.prninfo.com> Perhaps the dungeons in the temple of gorokh and the temple of valriel could have a high temple at their ends. The altars here would be for higher level players,and they would get a reward for reaching this place,maybe more sp,hp,resistances,spells,a good weapon,etc. From dnh at hawthorn.csse.monash.edu.au Thu Jun 28 16:52:23 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:25 2005 Subject: [CF-Devel] altars In-Reply-To: <200106282143.RAA07912@mamia.prninfo.com> Message-ID: This is a nice idea, and I wouldn't imagine to hard to do (except the special altar) dnh On Thu, 28 Jun 2001, Joel South wrote: > Perhaps the dungeons in the temple of gorokh and the temple of valriel > could have a high temple at their ends. The altars here would be for > higher level players,and they would get a reward for reaching this > place,maybe more sp,hp,resistances,spells,a good weapon,etc. > > From bugs at real-time.com Fri Jun 29 01:00:05 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:25 2005 Subject: [CF-Devel] [Bug 375] Changed - Monk Bug Message-ID: <200106290600.f5T605P07737@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=375 *** shadow/375 Thu Jun 21 12:25:11 2001 --- shadow/375.tmp.7732 Fri Jun 29 01:00:05 2001 *************** *** 2,9 **** | Monk Bug | +----------------------------------------------------------------------------+ | Bug #: 375 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: All | | Severity: normal OS/Version: All | | Priority: P2 Component: server | +----------------------------------------------------------------------------+ --- 2,9 ---- | Monk Bug | +----------------------------------------------------------------------------+ | Bug #: 375 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: All | | Severity: normal OS/Version: All | | Priority: P2 Component: server | +----------------------------------------------------------------------------+ *************** *** 19,21 **** --- 19,26 ---- With a scroll of melee weapons (or whatever it's called, i forget ;-) ), a monk is able to use weapons, and retain the core skill he starts with: meditation. + + ------- Additional Comments From mwedel@scruz.net 2001-06-29 01:00 ------- + Fixed in CVS - MSW 2001-06-28 + server/skill_util.c: Remove the unused LINKED_SKILL code. Prevent + characters that have meditation skill from learning melee weapon skill. From olle at viksten.com Fri Jun 1 02:28:38 2001 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] goblin king In-Reply-To: <20010531141957.A15576@crystal> References: <20010531141957.A15576@crystal> Message-ID: <01060109283800.04635@pingu> torsdagen den 31 maj 2001 20:19 wrote H. S. Teoh: > You've gone *way* too far :-) > The goblin king lives in the random dungeon in the hole just outside > Scorn, on the mountains to the northeast (between Euthville and Scorn), > just next to Barad-Dur. I just ran around on a killing spree in there and returned with the head, put it down and obviously became a knight. But what does that mean? I didn't see a change in anything, no stat change, no new title, no .... Olle Viksten From peterm at tonks.EECS.Berkeley.EDU Fri Jun 1 02:42:27 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] goblin king In-Reply-To: Your message of "Fri, 01 Jun 2001 09:28:38 +0200." <01060109283800.04635@pingu> Message-ID: <200106010742.f517gRq08198@tonks.EECS.Berkeley.EDU> Well, do you think you'll get a mark on your forehead which says "Knight"? In Britain, when you become a Knight, some people start to call you 'Sir'. Same thing in crossfire. Also, you'll find that your knightship will get you in and out of certain rooms in the castle and that you'll be able to advance in the quests, and you'll be able to go in and out of the city without using the password or a pass. PeterM > torsdagen den 31 maj 2001 20:19 wrote H. S. Teoh: > > > You've gone *way* too far :-) > > The goblin king lives in the random dungeon in the hole just outside > > Scorn, on the mountains to the northeast (between Euthville and Scorn), > > just next to Barad-Dur. > > I just ran around on a killing spree in there and returned with the head, put > > it down and obviously became a knight. But what does that mean? I didn't see > a change in anything, no stat change, no new title, no .... > > Olle Viksten > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From trevj at mail.mainetoday.com Fri Jun 1 06:45:00 2001 From: trevj at mail.mainetoday.com (Trevor Jennings) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] How do you pray on an alter? Message-ID: <200106011134.HAA00321@mail.mainetoday.com> Hey, thanks for those tips!! There's actually 2 of us playing at the moment and neither of us could figure out how the heck to do the praying bit. So again, thanks for the help! Have to try that out tonight... Cheers, - Trevor >On Thursday 31 May 2001 09:20, you wrote: >> Hello, >> >> I know this is a very newbie question so I apologise for that. I was >> wondering how the heck do you pray at an altar? I've read the survival >> guide and manual and it mentions about what can be done with the different >> 'cults' and you pray to a god for special powers etc....but I'll be darned >> if I can figure out just HOW do you actually go about joining. Is it the >> 'use_skill praying' command? > >In addition to the advice given elsewhere, it also wasn't immediately >obvious to me but you have to be standing "on" the altar, not next to it, >when you do the praying bit... > >-- >"Given the pace of technology, I propose we leave math to the machines >and go play outside." - Calvin >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list |Trevor Jennings |Programmer/System Administrator |MaineToday.com - Division of Blethen Maine Newspapers |Email: trevj@portland.com |ICQ: 656540 Phone: (207) 822 4070 From trevj at mail.mainetoday.com Fri Jun 1 06:47:47 2001 From: trevj at mail.mainetoday.com (Trevor Jennings) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] Update for USA east coast server! Message-ID: <200106011137.HAA00354@mail.mainetoday.com> Hi again, Not sure whether anyone would remember, but quite awhile ago I setup a CF server here on the east coast. Anyway it had been quite some time since this had been updated, but I'm pleased to announce that the server on IP 24.93.158.219 is now up and running with the latest version 1.0. Sometime here I'll add this to the meta server section :) Cheers, - Trevor From scott at campy.tymnet.com Sun Jun 3 23:08:55 2001 From: scott at campy.tymnet.com (Scott Wedel) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] goblin king Message-ID: <200106040408.WAA06020@moots.tymnet.com> > >Well, do you think you'll get a mark on your forehead which says >"Knight"? > And why not? I think it should stamp "Knight" on his forehead and he should lose a charisma point for being so butt ugly. And then he is sent on a quest for the "Lotion of Cleaniness" to remove it from his forehead and regain his charisma point. I think the original question indicates the game should do a better job of having a ceremony making the character into a knight which includes a speech stating the major advantages. Now that the game has been released, there are more new people playing and their questions should be viewed as QA testers. On this topic, maybe the newbie dungeon needs an additional room to explain religions and praying. Maybe it should have a null temple which allows the character to learn how to pray but it isn't to an actual god so the player remains unattached to any religion. It seems questions on praying come up fairly frequently so it must not be that obvious how to do. sdw >In Britain, when you become a Knight, some people start to call you >'Sir'. Same thing in crossfire. Also, you'll find that >your knightship will get you in and out of certain rooms in the castle >and that you'll be able to advance in the quests, and >you'll be able to go in and out of the city without using >the password or a pass. > >PeterM > >> torsdagen den 31 maj 2001 20:19 wrote H. S. Teoh: >> >> > You've gone *way* too far :-) >> > The goblin king lives in the random dungeon in the hole just outside >> > Scorn, on the mountains to the northeast (between Euthville and Scorn), >> > just next to Barad-Dur. >> >> I just ran around on a killing spree in there and returned with the head, put >> >> it down and obviously became a knight. But what does that mean? I didn't see >> a change in anything, no stat change, no new title, no .... >> >> Olle Viksten >> _______________________________________________ >> crossfire-list mailing list >> crossfire-list@lists.real-time.com >> https://mailman.real-time.com/mailman/listinfo/crossfire-list >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list From lembark at wrkhors.com Sun Jun 3 23:28:16 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] goblin king References: <200106040408.WAA06020@moots.tymnet.com> Message-ID: <3B1B0E60.5C7D36B7@wrkhors.com> > I think the original question indicates the game should do a better > job of having a ceremony making the character into a knight which > includes a speech stating the major advantages. That or at least a scroll describing them on the floor. > On this topic, maybe the newbie dungeon needs an additional room > to explain religions and praying. Maybe it should have a null temple > which allows the character to learn how to pray but it isn't to an > actual god so the player remains unattached to any religion. It seems > questions on praying come up fairly frequently so it must not be that > obvious how to do. That or use some sort of "temporary" attachment to a god (e.g., you step off the altar and it goes away). This would allow praying to 1-2 gods to get a feel of what the auras do for you. -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 lembark@wrkhors.com 800-762-1582 From peterm at tonks.EECS.Berkeley.EDU Thu Jun 7 20:33:46 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] crossfire.csua back up now Message-ID: <200106080133.f581Xks29103@tonks.EECS.Berkeley.EDU> Hello, The hardware problem on crossfire.csua got fixed and now the server is back up. PeterM From highway at cstone.net Fri Jun 8 12:49:09 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] Raffle 3 Message-ID: <3B211015.9022D60@cstone.net> Okay, so raffle 1 is cake, and raffle 2 is cake too if we can get two people to do it. But how in the heck do you get past the opening area in raffle 3? I kill all the acid and wild pyromaniacs (though, admittedly, the pyros do most of my job for me) but can't get anything else to open up. SeanMike From andi.vogl at gmx.net Sat Jun 9 08:37:03 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] Raffle 3 In-Reply-To: <3B211015.9022D60@cstone.net> Message-ID: > Okay, so raffle 1 is cake, and raffle 2 is cake too if we can get two > people to do it. > > But how in the heck do you get past the opening area in raffle 3? I > kill all the acid and wild pyromaniacs (though, admittedly, the pyros do > most of my job for me) but can't get anything else to open up. > > SeanMike From draugr at cloud9.net Sun Jun 10 18:46:10 2001 From: draugr at cloud9.net (John Draugr) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] Visual C++ free? Message-ID: <003001c0f207$86b86c20$0a00a8c0@soznet> Hi, Does anyone know where I can get a free C++ compiler that will compile the W32 version of Crossfire server? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010610/f1d8e7cc/attachment.htm From yann.chachkoff at mailandnews.com Mon Jun 11 07:20:15 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] Visual C++ free? In-Reply-To: <003001c0f207$86b86c20$0a00a8c0@soznet> References: <003001c0f207$86b86c20$0a00a8c0@soznet> Message-ID: <01061108201500.01558@Terminus.magellan.fpms.ac.be> Le Dimanche 10 Juin 2001 19:46, vous avez ?crit : > Hi, > Does anyone know where I can get a free C++ compiler that will compile > the W32 version of Crossfire server? You may try Borland C++ 5 compiler, which is freely available on their site, but you'll probably have to manually configure the server compilation. Crossfire was also known to be compilable under the CygWin32 environment with GCC, but I don't know if it is still true. Chachkoff Y. From peterm at tonks.EECS.Berkeley.EDU Thu Jun 14 21:17:43 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] Beholder-crash problem at CSUA fixed. Message-ID: <200106150217.f5F2HhC21419@tonks.EECS.Berkeley.EDU> Have fun. PeterM From highway at cstone.net Fri Jun 15 15:02:13 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] list of servers Message-ID: <3B2A69C5.BD32CD82@cstone.net> Anyone else getting a "connection refused" when logging in to play Crossfire with the gtk client? I can play on my local server, and hand type in a server, but the list is not there... SeanMike From egbert at ehinzen.de Sun Jun 17 15:47:57 2001 From: egbert at ehinzen.de (Egbert Hinzen) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 Message-ID: Hi! First my thanks to all who helped to make a great game! After not-looking at CF for years, I saw you finally call it "1.0.0" now. Maybe that was a little too optimistic... Questions ========= 1.) How can I use the new sound system? Looking at the client's README it should be done automatically... (I use Linux 2.4.5 with ALSA sounddrivers 0.5.11) 'cfsndserv' is compiles without problems but doesn't play sounds... BTW: The old system runs without any problems. 2.) How can I build the 1.0.0-documentation? There was no way to build handbook (ps) or spoiler (ps or html) using the Makefiles. (Yes, I installed all needed programs including the arch-files not needed for new users 8-)). BTW: I also found *no* place where I could download them. 8-( 3.) Everytime I start the (GtK-)client it starts my (dial-up)-internet- connection (also offering my localhost). That's nice, but there should be the possiblity just to use my localhost. I tried "-server localhost", but that changed nothing. 4.) Do you have plans to add localization to CF? If so, I'll offer my help to make a German translation... Thanks again for a great game! -- Egbert Hinzen From mwedel at scruz.net Sun Jun 17 17:54:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 References: Message-ID: <3B2D352E.F10A910E@scruz.net> Egbert Hinzen wrote: > > Hi! > > First my thanks to all who helped to make a great game! > > After not-looking at CF for years, I saw you finally call it "1.0.0" now. > Maybe that was a little too optimistic... > > Questions > ========= > 1.) How can I use the new sound system? > Looking at the client's README it should be done automatically... > (I use Linux 2.4.5 with ALSA sounddrivers 0.5.11) > 'cfsndserv' is compiles without problems but doesn't play sounds... > BTW: The old system runs without any problems. Can't really help. I don't use ALSA, so this is not a problem I can really investigate/fix. I got it to the point where it at least compiles with ALSA, but that was on a remote system where it is hard to verify that there is actual sound output. > > 2.) How can I build the 1.0.0-documentation? > There was no way to build handbook (ps) or spoiler (ps or html) > using the Makefiles. > (Yes, I installed all needed programs including the arch-files > not needed for new users 8-)). > BTW: I also found *no* place where I could download them. 8-( cd doc; make spoiler.ps; make handbook.ps Yes, not very well documented. The latex file are probably basically unsupported at this point (I don't think/know that any of the developers know latex very well, and I don't think anyone really wants to learn). There are also the html docs, which of course are not as good for printing, but if those are broken, someone may be more willing to look at the problem and fix it. > > 3.) Everytime I start the (GtK-)client it starts my (dial-up)-internet- > connection (also offering my localhost). That's nice, but there should > be the possiblity just to use my localhost. > I tried "-server localhost", but that changed nothing. That has been fixed for future releases (you can turn off the client trying to contact the metaserver). the logic of trying to contact the metaserver is not spelled out that well, but basically, if the server supplied matches the compiled in default server, it tries to contact the metaserver. You can likely fix this by doing -server 127.0.0.1 (which amounts to localhost, but string name is different). Also, if your system actually has a real name beyond localhost, you can use that. > > 4.) Do you have plans to add localization to CF? > If so, I'll offer my help to make a German translation... I don't think there are any plans. This gets a little trickier in that a lot of the messages/names come from objects, not code. Done properly, localization should purely be a client issue (ie, connecting to an american server, I should be able to tell my client I want german as my language). This also gets a bit harder. But probably the bigger reason this won't get done anytime really soon is that for most people, this is not a high priority issue or something they want to spend time on. From egbert at ehinzen.de Mon Jun 18 05:28:58 2001 From: egbert at ehinzen.de (Egbert Hinzen) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 In-Reply-To: <3B2D352E.F10A910E@scruz.net> Message-ID: On Sun, 17 Jun 2001, Mark Wedel wrote: > Egbert Hinzen wrote: > > 2.) How can I build the 1.0.0-documentation? > > There was no way to build handbook (ps) or spoiler (ps or html) > > using the Makefiles. > > (Yes, I installed all needed programs including the arch-files > > not needed for new users 8-)). > > BTW: I also found *no* place where I could download them. 8-( > > cd doc; make spoiler.ps; make handbook.ps Sorry, but you misunderstood my question. I tried this, but the compiling died with lots of errors. Can you build theese files? They would be useful on the download servers and in the CVS... Thanks before! > You can likely fix this by doing -server 127.0.0.1 (which amounts to localhost, > but string name is different). Also, if your system actually has a real name > beyond localhost, you can use that. Running. Thanks. > > 4.) Do you have plans to add localization to CF? > > Done properly, localization should purely be a client issue (ie, connecting to > an american server, I should be able to tell my client I want german as my > language). This also gets a bit harder. Using GNU's gettext this wouldn't be such a big problem... We've done it with freeciv (an server/client civilization clone) and it runs well... > But probably the bigger reason this won't get done anytime really soon is that > for most people, this is not a high priority issue or something they want to > spend time on. Nothing can be said against that... -- Egbert Hinzen -- ICQ 45698606 -- PGP Public Keys at www.ehinzen.de From mwedel at scruz.net Wed Jun 20 00:07:21 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 References: Message-ID: <3B302F89.EDE179BA@scruz.net> Egbert Hinzen wrote: > Sorry, but you misunderstood my question. I tried this, but the compiling > died with lots of errors. > > Can you build theese files? They would be useful on the download servers > and in the CVS... > > Thanks before! After some minor tweaks, the spoiler.ps built without problems (the cupid.111.xpm file was using too many colors and confused the xpm->ps parser) and my tetex installation did not allocate enough memory (I've added a note to doc/README about this, since it is likely a common problem) The handbook does not build - it doesn't look the equip.tex file that gets generated. It may make more sense to just write one up by hand than try to have one get generated by the system (as I notice the file as listed has things like Elf player_force lines. The playbook itself is probably out of date, since it has never been updated for the split beween classes and races. So the equip.tex contains the races, and of course many do not have any inherent equipment which may be a problem. And there is probably no mention about the differing classes. > > Done properly, localization should purely be a client issue (ie, connecting to > > an american server, I should be able to tell my client I want german as my > > language). This also gets a bit harder. > > Using GNU's gettext this wouldn't be such a big problem... > We've done it with freeciv (an server/client civilization clone) and it > runs well... The harder part I think will be all the archetypes, since they have embedded names/text in it (maps have a similar problem). I don't know how this can really dealt with reasonably well - either that portion remains in English (to localize all the objects/maps to each language would probably be a lot of work), or external references are needed (ie, messages don't contain text, but rather point to some message number, which of course gets harder to do). From michael.toennies at nord-com.net Wed Jun 20 00:28:24 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 In-Reply-To: <3B302F89.EDE179BA@scruz.net> Message-ID: We can do a simple thing: Include a special language tag to the text outputing commands in the arch files. like name_german or name_french. Also: msg_german/endmsg_german. On collect time, the collect tool generate for the server then the right name cmd. The other language parts will be in arch but not be in archtypes file which the server use. With this, you can collect -german of collect -french and get a native language version of the arches. I mean, for what reason have we a scripted object system when not for this? Its of course some work - so if one want do it, he should start and tell me, i include then the collect syntax in the editor. Btw, the CFJavaEditor can eat html as online help, so writing a help there will usable for web and editor. Michael > > Egbert Hinzen wrote: > > > Sorry, but you misunderstood my question. I tried this, but the > compiling > > died with lots of errors. > > > > Can you build theese files? They would be useful on the download servers > > and in the CVS... > > > > Thanks before! > > After some minor tweaks, the spoiler.ps built without problems (the > cupid.111.xpm file was using too many colors and confused the > xpm->ps parser) > and my tetex installation did not allocate enough > memory (I've added a note to doc/README about this, since it is > likely a common > problem) > > The handbook does not build - it doesn't look the equip.tex file > that gets > generated. It may make more sense to just write one up by hand > than try to have > one get generated by the system (as I notice the file as listed > has things like > Elf player_force lines. > > The playbook itself is probably out of date, since it has never > been updated > for the split beween classes and races. So the equip.tex > contains the races, > and of course many do not have any inherent equipment which may > be a problem. > And there is probably no mention about the differing classes. > > > > > > Done properly, localization should purely be a client issue > (ie, connecting to > > > an american server, I should be able to tell my client I want > german as my > > > language). This also gets a bit harder. > > > > Using GNU's gettext this wouldn't be such a big problem... > > We've done it with freeciv (an server/client civilization clone) and it > > runs well... > > The harder part I think will be all the archetypes, since they > have embedded > names/text in it (maps have a similar problem). I don't know how this can > really dealt with reasonably well - either that portion remains > in English (to > localize all the objects/maps to each language would probably be > a lot of work), > or external references are needed (ie, messages don't contain > text, but rather > point to some message number, which of course gets harder to do). > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From jajcus at bnet.pl Wed Jun 20 04:04:41 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 In-Reply-To: ; from michael.toennies@nord-com.net on Wed, Jun 20, 2001 at 07:28:24AM +0200 References: <3B302F89.EDE179BA@scruz.net> Message-ID: <20010620110440.A2410@nic.gliwice.sdi.tpnet.pl> On Wed, Jun 20, 2001 at 07:28:24AM +0200, Michael Toennies wrote: > We can do a simple thing: > Include a special language tag to the text outputing commands > in the arch files. > > like name_german or name_french. > Also: msg_german/endmsg_german. I would rather see it like this: name(de_DE) or name(fr_FR) Using not standard language identifiers can be confusig, and can lead to some problems i future. Please note, that different languages use different encodings, and using standard tags locale functins can help us. For the archs and other files using localization IMHO UTF-8 should be used, as this is the only standard encoding readable by humans and able to encode any character. Greets, Jacek From scott at campy.tymnet.com Wed Jun 20 04:33:21 2001 From: scott at campy.tymnet.com (Scott Wedel) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 Message-ID: <200106200933.DAA03974@moots.tymnet.com> To be realistic, language localization is never going to happen for the maps. That would require a lot of work and the great majority of the language used is very easy for someone to learn. The game could be in greek and it wouldn't take long to learn the greek words for "hit", "miss", "sword" and so on. The part of the game that could benefit from localization are things like magic mouths which speak in paragraphs and the adventurer is supposed to respond with key words to be told more. Some of those require a modest amount of language skills and the capability to use localization in specific cases would be helpful. For instance, newbie dungeon would be a perfect candidate for language localization. The effort needed to localize those messages including the trigger words is not beyond the scope of an enthusiastic person if the capability existed in the program. From elodiesierra at yahoo.fr Wed Jun 20 05:10:22 2001 From: elodiesierra at yahoo.fr (elodie sierra) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] i must study cross-fire and i need help:) Message-ID: <3B30768D.27784A55@yahoo.fr> hello:) i'm a student in technologies for education (in geneva).I have a little work :i must study some games to see how they are technicaly advanced (in comparison whith learning environnements)... And i must study Cross-fire...:) Could you help me by answering me to some questions below ? 1) what must we do to go from a map to another map:(in general) 2)in a map,for exemple the first map (i have just seen this map:))...we can go in the houses and others buildings...does it exit a third level ,ie once we are in the house can we go to a basement (with "apply below")... 3)can we go from a house to another house ; does it exit some undergroung passage...?:) i need to know this because i have to draw a diagram of the structure of cross-fire...:) thank you very much (it would help me a lot!:)) sorry for my english (i speak french:)) elodie sierra From leaf at real-time.com Wed Jun 20 18:33:28 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 In-Reply-To: <3B302F89.EDE179BA@scruz.net> Message-ID: I have an HTML version of the playbook that I was working on to checkin to CVS It contains the data for the race/class split, along with a few other tidbits of information I have collected and added over the years. Right now, all the graphics are broken and need to be updated with the new png (or iso?) set. HTML code for Chapters 1 through 7 (except for the tables) has been thoroughly cleaned up. The Appendixes still need work... In case anyone is interested. Online version: http://crossfire.real-time.com/hbk/handbook.html Winzip: http://crossfire.real-time.com/hbk/hbk.zip http://crossfire.real-time.com/hbk.tar.gz On Tue, 19 Jun 2001, Mark Wedel wrote: > The playbook itself is probably out of date, since it has never been updated > for the split beween classes and races. So the equip.tex contains the races, > and of course many do not have any inherent equipment which may be a problem. > And there is probably no mention about the differing classes. From egbert at ehinzen.de Wed Jun 20 20:11:55 2001 From: egbert at ehinzen.de (Egbert Hinzen) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 In-Reply-To: <20010620110440.A2410@nic.gliwice.sdi.tpnet.pl> Message-ID: On Wed, 20 Jun 2001, Jacek Konieczny wrote: > Using not standard language identifiers can be confusig, and can lead to > some problems i future. Please note, that different languages use > different encodings, and using standard tags locale functins can help > us. For the archs and other files using localization IMHO UTF-8 should > be used, as this is the only standard encoding readable by humans and > able to encode any character. New versions of gettext are able to work with different ISO files without problems (if the original uses US-English standards. -- Egbert Hinzen -- ICQ 45698606 -- PGP Public Keys at www.ehinzen.de From mwedel at scruz.net Wed Jun 20 23:38:33 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 References: <3B302F89.EDE179BA@scruz.net> <20010620110440.A2410@nic.gliwice.sdi.tpnet.pl> Message-ID: <3B317A49.8173D8D9@scruz.net> To me, the problem is more that client and server may (and probably do) cross language and country borders. So while that server in germany may be 'speaking' german, that may not be all that useful for the players in france, belgium, sweden, and other nearby countries that have different native languages. This is why IMO it is better for the client (and thus the server) to be able to support all the languages at the same time. So in the above case, if I'm in france, I could play on that german server and say 'I want all the stuff in french', and if I'm in sweden, I can say 'I want the language to be swedish'. The problem with this is keeping it up to date (ignoring the technical issue of the server supporting multiple languages). IF someone creates a new object or map, it is unlikely that they will know all the potential languages to be supported, so will only do it in one. This then means that other people have to do the localization (and in fact, probably many more depending on how many languages are supported), and if the person doing the French localiziation leaves, then that information will likely get out of date. One big question I have is: How important is localization? Is this just one of those wishlist things, or is this something that people see as being fairly important for whatever reason? From quinet at gamers.org Thu Jun 21 07:25:23 2001 From: quinet at gamers.org (Raphael Quinet) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Questions about CF 1.0.0 References: <3B302F89.EDE179BA@scruz.net> <20010620110440.A2410@nic.gliwice.sdi.tpnet.pl> <3B317A49.8173D8D9@scruz.net> Message-ID: <3B31E7B3.8080207@gamers.org> On Wed, 20 Jun 2001, Mark Wedel wrote: > This is why IMO it is better for the client (and thus the server) to > be able to support all the languages at the same time. So in the > above case, if I'm in france, I could play on that german server and > say 'I want all the stuff in french', and if I'm in sweden, I can > say 'I want the language to be swedish'. Agreed. Hmmm... But who will provide the code that translates the messages sent from one player to another, if they come from different countries? :-) > The problem with this is keeping it up to date (ignoring the > technical issue of the server supporting multiple languages). > > IF someone creates a new object or map, it is unlikely that they > will know all the potential languages to be supported, so will only > do it in one. This then means that other people have to do the > localization (and in fact, probably many more depending on how many > languages are supported), and if the person doing the French > localiziation leaves, then that information will likely get out of > date. This is not a very big problem. If the information gets out of date because a translator has left, then: 1 - the problem will be detected because gettext will complain about the untranslated string or fuzzy matches 2 - the users will see the problem when they get an untranslated message 3 - one of these users will submit a patch and maybe take over the position left open by the previous maintainer. Look for example at the following page. It gives the translation status for various parts of the GIMP 1.2: http://sven.gimp.org/1.2/i18n.html There are almost 5000 strings to be translated. Most of the common languages (German, French, Spanish, Italian, Japanese, Russian, etc.) are up-to-date. Sometimes a translator leaves or is too busy for a while, so the corresponding language gets out of sync for a couple of weeks, but it does not take long before someone else steps in and provides the missing translations. > One big question I have is: How important is localization? Is this > just one of those wishlist things, or is this something that people > see as being fairly important for whatever reason? Well, I expect that most native English speakers will think that the localization issues are not very important. ;-) But people who are less familiar with the English language (and are probably not playing the game for the moment) would probably have a different opinion. Although there is no way to measure this directly, I think that the number of users of the GIMP has been multiplied by at least 3 or 4 since it is available in several languages. Some initial effort was needed to prepare all strings for localization (the GIMP had its own set of problems with the external plug-ins, Script-Fu and Perl-Fu that were not supported natively by gettext) but once that was done, it did not take long before dozens of volunteers started to contribute their translations in various languages. -Raphael From andi.vogl at gmx.net Thu Jun 21 10:54:50 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Q's about CF 1.0.0 (language localization) In-Reply-To: <3B31E7B3.8080207@gamers.org> Message-ID: Raphael Q. wrote: > On Wed, 20 Jun 2001, Mark Wedel wrote: > > [...] IMO it is better for the client (and thus the server) to > > be able to support all the languages at the same time. > > > > The problem with this is keeping it up to date (ignoring the > > technical issue of the server supporting multiple languages). > > This is not a very big problem. [...] > Look for example at the following page. It gives the > translation status for various parts of the GIMP 1.2: > http://sven.gimp.org/1.2/i18n.html You can't compare GIMP with CF in this case. - GIMP has a lot more active developers - Even with 5000 strings, GIMP has less text than CF - CF is a multiplayer game, hence if you can't speak english you cannot communicate. And that would suck anyways. > > One big question I have is: How important is localization? [...] > > Well, I expect that most native English speakers will think that the > localization issues are not very important. ;-) But people who are > less familiar with the English language (and are probably not playing > the game for the moment) would probably have a different opinion. I'm german, but I wouldn't work on a german (map-)localization even if it existed. People who are interested in Multiplayer Online RPG Games have to learn english anyways, so why bother? What fun is a MORPG when you can't communicate with anyone? And while playing, I wouldn't turn on the german localization either. Because then the NPCs would talk german and the players english - What a mess in my brain! :) Just my thoughs... Andreas V. From highway at cstone.net Wed Jun 27 14:37:27 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Is there no end? Message-ID: <3B3A35F7.B60455B1@cstone.net> To the top of Valriel's Church? I decided to see what was at the end of the random maps at the top of Valriel's Church. There doesn't seem to be an end... Just wave after wave after wave of high angels, arch angels, retributioners, and XP...since my warrior worships Valriel and sucks with spells, I just kept gaining physique XP. I'm not complaining about that (particularly not since I'm level 93 now) but is there anything I'm *looking* for up there? :) Somewhat related, where can I find a Holy Avenger? SeanMike From peterm at tonks.EECS.Berkeley.EDU Wed Jun 27 14:55:13 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Is there no end? In-Reply-To: Your message of "Wed, 27 Jun 2001 15:37:27 EDT." <3B3A35F7.B60455B1@cstone.net> Message-ID: <200106271955.f5RJtDw22031@tonks.EECS.Berkeley.EDU> No, there's nothing at the top. It probably ends, eventually, at a depth of about 99, but with a whimper not a bang. There simply won't be any way to go up. PeterM > To the top of Valriel's Church? > > I decided to see what was at the end of the random maps at the top of > Valriel's Church. There doesn't seem to be an end... > > Just wave after wave after wave of high angels, arch angels, > retributioners, and XP...since my warrior worships Valriel and sucks > with spells, I just kept gaining physique XP. I'm not complaining about > that (particularly not since I'm level 93 now) but is there anything I'm > *looking* for up there? :) > > Somewhat related, where can I find a Holy Avenger? > > SeanMike > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From Kimmo.Hoikka at Digia.com Wed Jun 27 15:25:00 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Is there no end? References: <3B3A35F7.B60455B1@cstone.net> Message-ID: <3B3A411C.A9390995@Digia.com> the random maps in valriels tower and gorokhs temple have no end, they are just plain hack&slash areas to obtain exp and stuff Sean Michael Whipkey wrote: > To the top of Valriel's Church? > > I decided to see what was at the end of the random maps at the top of > Valriel's Church. There doesn't seem to be an end... > > Just wave after wave after wave of high angels, arch angels, > retributioners, and XP...since my warrior worships Valriel and sucks > with spells, I just kept gaining physique XP. I'm not complaining about > that (particularly not since I'm level 93 now) but is there anything I'm > *looking* for up there? :) > > Somewhat related, where can I find a Holy Avenger? > > SeanMike > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From egbert at ehinzen.de Thu Jun 28 20:19:09 2001 From: egbert at ehinzen.de (Egbert Hinzen) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] Installation of arch.tar Message-ID: Where should this tar be extracted? TIA -- Egbert Hinzen -- ICQ 45698606 -- PGP Public Keys at www.ehinzen.de From laneholc at earthlink.net Sat Jun 30 23:29:17 2001 From: laneholc at earthlink.net (Lane Holcombe) Date: Thu Jan 13 18:04:00 2005 Subject: [CF List] That name is already in use. Message-ID: <01063023291701.08346@server.unix.home> I just discovered crossfire in my FreeBSD ports directory so I installed it but when I try to run it I get the same response for each character I try to create: "That name is already in use." The FAQ seems to skip over this problem. Please help. This looks like a really cool game.