From robert at timetraveller.org Fri Apr 1 21:20:26 2016 From: robert at timetraveller.org (Robert Brockway) Date: Sat, 2 Apr 2016 12:20:26 +1000 (AEST) Subject: [crossfire] A funny thing happened on the way to the new maps Message-ID: Hi all. I'm a long time CF player who has mostly lurked. I've played on and off since 94 or so. I did some map work ages ago but never submitted any. Anyway recently I've been focussing on doing work on CF. Since I'm not great at C I have been playing mostly with plugins and maps. Anyway I've been having fun building a new world over the last few months. I modified the 'land' utility a little and have played a lot with different land forms. My modified version is called 'bigland' and allows for the creation of quite large land forms. I've written a script which calls bigland and records the parameters used in a file so they can be reproduced later. I've created a new world running on my server which is 1000x1000 maps. I started small but gradually made bigger and bigger land forms. There are reasons I went and built a world this big that I can go in to later. That's really just an intro... Since finalising the world I wanted I've been adding cities, roads, dungeons, etc. I built one city and then decided it was too close to the portal from the old world so I turned it into a ruined city. I put a few monsters in the ruined city - giant rats, some undead and others. For the most part they stay in the city but they may harass travellers on the road that passes by the ruined city. I also put in mice :) I had wondered whether monsters would move between tiles on a world map. I have my answer now :) The mice are spreading like a plague on my new world map - passing well beyond the original one or two maps I placed them on. They are even activiting new maps which surprised me a bit. They are definitely spreading to maps that none of our characters have visited recently. At this stage they have only been going for about 12 hours but have already filled 30-40 maps. Of course I could restart CF to clear the problem but I've decided to leave it for a while to see what happens :) I suppose eventually number of active objects will cause problems but this is only a private server with two active players and regular backups so we're all good. Anyway you will be hearing more of me as I'll be submitting my work. I suspect few players will want a full 1000x1000 map world as it stands since it takes up roughly 100GB storage. I was thinking that a lot of space could be saved if the game tried to open a compressed map if it did not find an uncompressed map at the location specified when it tried to open a map. Using xz (or similar) compression on maps would be a huge storage saver and would not be very cpu expensive. I'll tell you know how my mouse plague turns out :p Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC, Freenode and Snoonet) Web: http://www.pracops.com I tried to change the world but they had a no-return policy From matthew at giassa.net Fri Apr 1 21:51:30 2016 From: matthew at giassa.net (Matthew Giassa) Date: Fri, 1 Apr 2016 19:51:30 -0700 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: Message-ID: <56FF33B2.5010803@giassa.net> If you have multiple types of mice (ie: altruistic, aggressive, tribalism-oriented, etc), you could have a pretty entertaining simulation play out. ============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matthew at giassa.net website: www.giassa.net On 04/01/16 19:20, Robert Brockway wrote: > Hi all. I'm a long time CF player who has mostly lurked. I've played > on and off since 94 or so. I did some map work ages ago but never > submitted any. > > Anyway recently I've been focussing on doing work on CF. Since I'm not > great at C I have been playing mostly with plugins and maps. > > Anyway I've been having fun building a new world over the last few > months. I modified the 'land' utility a little and have played a lot > with different land forms. My modified version is called 'bigland' and > allows for the creation of quite large land forms. I've written a > script which calls bigland and records the parameters used in a file so > they can be reproduced later. > > I've created a new world running on my server which is 1000x1000 maps. > I started small but gradually made bigger and bigger land forms. There > are reasons I went and built a world this big that I can go in to later. > > That's really just an intro... > > Since finalising the world I wanted I've been adding cities, roads, > dungeons, etc. I built one city and then decided it was too close to > the portal from the old world so I turned it into a ruined city. I put > a few monsters in the ruined city - giant rats, some undead and others. > For the most part they stay in the city but they may harass travellers > on the road that passes by the ruined city. > > I also put in mice :) I had wondered whether monsters would move > between tiles on a world map. I have my answer now :) The mice are > spreading like a plague on my new world map - passing well beyond the > original one or two maps I placed them on. They are even activiting new > maps which surprised me a bit. They are definitely spreading to maps > that none of our characters have visited recently. > > At this stage they have only been going for about 12 hours but have > already filled 30-40 maps. > > Of course I could restart CF to clear the problem but I've decided to > leave it for a while to see what happens :) I suppose eventually number > of active objects will cause problems but this is only a private server > with two active players and regular backups so we're all good. > > Anyway you will be hearing more of me as I'll be submitting my work. I > suspect few players will want a full 1000x1000 map world as it stands > since it takes up roughly 100GB storage. > > I was thinking that a lot of space could be saved if the game tried to > open a compressed map if it did not find an uncompressed map at the > location specified when it tried to open a map. Using xz (or similar) > compression on maps would be a huge storage saver and would not be very > cpu expensive. > > I'll tell you know how my mouse plague turns out :p > > Cheers, > > Rob > From kevinz5000 at gmail.com Fri Apr 1 23:34:35 2016 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 1 Apr 2016 21:34:35 -0700 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: Message-ID: <56FF4BDB.60702@gmail.com> On 04/01/2016 19:20, Robert Brockway wrote: > Anyway I've been having fun building a new world over the last few > months. I modified the 'land' utility a little and have played a lot > with different land forms. My modified version is called 'bigland' and > allows for the creation of quite large land forms. I've written a > script which calls bigland and records the parameters used in a file so > they can be reproduced later. > > I've created a new world running on my server which is 1000x1000 maps. > I started small but gradually made bigger and bigger land forms. There > are reasons I went and built a world this big that I can go in to later. Sounds interesting. Any chance your server is online so I can take a look at your new maps? I'd love to hear more about your 'interesting' game dynamics with a big world (and lots of mice). -- Kevin Zheng kevinz5000 at gmail.com | kevinz at berkeley.edu | PGP: 0xC22E1090 From robert at timetraveller.org Sat Apr 2 00:16:44 2016 From: robert at timetraveller.org (Robert Brockway) Date: Sat, 2 Apr 2016 15:16:44 +1000 (AEST) Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: <56FF4BDB.60702@gmail.com> References: <56FF4BDB.60702@gmail.com> Message-ID: On Fri, 1 Apr 2016, Kevin Zheng wrote: > Sounds interesting. Any chance your server is online so I can take a > look at your new maps? I'd love to hear more about your 'interesting' > game dynamics with a big world (and lots of mice). I am looking at opening it up. I was considering relocating it to a Linode but the 100GB storage is significant. That's one of the reasons I'm thinking that compressed maps would be great - since they are all text anyway they compress really well. The server is currently at my house. I'll probably open it up as a trial but not sure how well it will perform as I'm on DSL. I think Matthew Giassa's idea of using mice with different characteristics would be fantastic. The world is divided in to several continents so I may reserve one for experimentation :) As we speak the mouse plague is steadily heading south along the road towards a major city. Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC, Freenode and Snoonet) Web: http://www.pracops.com I tried to change the world but they had a no-return policy From matthew at giassa.net Sat Apr 2 08:31:23 2016 From: matthew at giassa.net (Matthew Giassa) Date: Sat, 2 Apr 2016 06:31:23 -0700 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: <56FF4BDB.60702@gmail.com> Message-ID: <56FFC9AB.7050906@giassa.net> It would be pretty cool. Reminds me of the AliceBot experiment (http://blogs.discovermagazine.com/80beats/2011/05/05/nice-robots-finish-first-simulation-shows-how-altruism-can-evolve/). Altruistic mice help anyone, regardless. Aggressive mice attack anyone. Tribalism-oriented mice attack only mice of other "tribes". Then you could have variations (sneaky mice pretend to be non-aggressive, then become aggressive after a random number of turns, then eventually regress to non-aggressive again), variations in the "viewing distance" (ie: range before monster sees another and becomes aggressive), purely defensive altruistic, etc. You would need a reward mechanism for attacking other mice (victorious mouse gains an attribute). Then you could just reset certain maps to play around with initial conditions, like a Monte Carlo simulation. You could release a bunch of magical cats to clean up the mice population, then they disappear. Or, you could release pigeons to eat the mice, followed by lizards, snakes, gorillas, to make it really interesting. 100GB? All you need is a few people like me running the equivalent of a private OC3 to effectively saturate the pipe and rack up a hefty bill by setting the "pre-cache all maps on launch" option in the client. DreamHost does some good private server services, but it's about $150.00 USD per month. Please keep us up-to-date on this. Sounds comical AND academic. Cheers! ============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matthew at giassa.net website: www.giassa.net On 04/01/16 22:16, Robert Brockway wrote: > On Fri, 1 Apr 2016, Kevin Zheng wrote: > >> Sounds interesting. Any chance your server is online so I can take a >> look at your new maps? I'd love to hear more about your 'interesting' >> game dynamics with a big world (and lots of mice). > > I am looking at opening it up. I was considering relocating it to a > Linode but the 100GB storage is significant. That's one of the reasons > I'm thinking that compressed maps would be great - since they are all > text anyway they compress really well. > > The server is currently at my house. I'll probably open it up as a > trial but not sure how well it will perform as I'm on DSL. > > I think Matthew Giassa's idea of using mice with different > characteristics would be fantastic. The world is divided in to several > continents so I may reserve one for experimentation :) > > As we speak the mouse plague is steadily heading south along the road > towards a major city. > > Cheers, > > Rob > From robert at timetraveller.org Sat Apr 2 11:50:29 2016 From: robert at timetraveller.org (Robert Brockway) Date: Sun, 3 Apr 2016 02:50:29 +1000 (AEST) Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: <56FFC9AB.7050906@giassa.net> References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> Message-ID: I hope no one minds me inline replying. I'm oldskool :p On Sat, 2 Apr 2016, Matthew Giassa wrote: > It would be pretty cool. Reminds me of the AliceBot experiment > (http://blogs.discovermagazine.com/80beats/2011/05/05/nice-robots-finish-first-simulation-shows-how-altruism-can-evolve/). > > Altruistic mice help anyone, regardless. Aggressive mice attack anyone. > Tribalism-oriented mice attack only mice of other "tribes". Then you could > have variations (sneaky mice pretend to be non-aggressive, then become > aggressive after a random number of turns, then eventually regress to > non-aggressive again), variations in the "viewing distance" (ie: range before > monster sees another and becomes aggressive), purely defensive altruistic, > etc. What your suggesting there would require additional coding in the game wouldn't it? Actually I've always liked the idea of having the potential for monsters to fight each other. Just because they are against the player doesn't mean skeletons and orcs should always get on. > You would need a reward mechanism for attacking other mice (victorious mouse > gains an attribute). Then you could just reset certain maps to play around > with initial conditions, like a Monte Carlo simulation. You could release a > bunch of magical cats to clean up the mice population, then they disappear. > Or, you could release pigeons to eat the mice, followed by lizards, snakes, > gorillas, to make it really interesting. That's starting to sound like a ecology simulator - they are fun too :) > 100GB? All you need is a few people like me running the equivalent of a > private OC3 to effectively saturate the pipe and rack up a hefty bill by > setting the "pre-cache all maps on launch" option in the client. > DreamHost does some good private server services, but it's about $150.00 USD > per month. I know you can pre-cache all images. Is it really possible to pre-cache all maps? > Please keep us up-to-date on this. Sounds comical AND academic. It's been fun so far. I've learnt a few things: * The mice on tile maps spread out to other maps and the population grew at high rate initially. * Population growth rate slowed after 12-15 hours. I believe only mice with a free adjacent space were able to reproduce. Eventually this was effectively only mice at the periphery (wave front) of the mouse expansion as all other mice were adjacent to mice, very high mountains or ocean. * The mice will eventually fill up any terrain they can walk to but they will not cross bridges. * This does cause the server to slow. Noticable slowness observed with 100,000-200,000 mice in the game. * Monsters created on a tile map that have moved to a different tile map do not disappear if the original tile map is reset. I restarted crossfire with temp maps removed as my daughter wanted to play and it was really slow with all the mice. One of her characters may have a corrupt character file after she logged in with the vast number of mice in play. The character seems to be fine however the logs get many examples of the error below when the character logs in: 16/04/02 17:24:28 [EE] Multiple skills with the same subtype? praying, karate 16/04/02 17:24:28 [EE] Multiple skills with the same subtype? praying, thaumaturgy 16/04/02 17:24:28 [EE] Multiple skills with the same subtype? literacy, sorcery 16/04/02 17:24:28 [EE] Multiple skills with the same subtype? climbing, bargaining 16/04/02 17:24:28 [EE] Multiple skills with the same subtype? use magic item, evocation The source says this is a warning, but a warning of what I wonder :) The character hasn't been played much lately and I have a backup from a couple of days ago that I may restore if it is having issues and I can't fix it any other way. Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC, Freenode and Snoonet) Web: http://www.pracops.com I tried to change the world but they had a no-return policy From mwedel at sonic.net Sat Apr 2 15:04:51 2016 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Apr 2016 13:04:51 -0700 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> Message-ID: <570025E3.5040705@sonic.net> I presume the 1000x1000 maps are 50 (or some other size) spaces/side? Or is each map 1000x1000, but you have some smaller set of maps being tiled together? With map tiling, things can move to adjacent maps even if players don't move to them. The game doesn't really distinguish between objects, and just as you wouldn't want an arrow to stop at a map edge, same goes true for monsters. What should eventually happen is that maps with no players on them will get swapped out. However, what probably also happens is that maps that are still in memory are touching the other maps, keeping them active, so this never happens (at least in the case of mice which keep multiplying). One could have a monster that just wanders and moves to a new map, but it would eventually get swapped out if nothing else is keeping the map it is on active. As far as compression goes, at one time, the server did support map (or really, all file) compression. However, the typical size of an entire installation was small enough on current hard drives, there really wasn't much point to it (even 100 GB isn't that big for modern systems). Also, some newer filesystems (ZFS for example) support compression, eg: NAME USED RATIO export/home/crossfire 18.0G 2.09x (that is all my crossfire stuff - sources, binaries, etc, so size is reduced by 50+%) Also, I'm not aware (though may have missed it) of client side map caching. But even if that did exist, at least as far as the protocol goes, transmission of map data is much more efficient in the protocol that the method used in the map client itself. In the protocol, its probably around 6 bytes/map object (with some additional overhead to note the space, darkness, and a few other attributes). Where as in the map file, a pretty minimal object is something like: name grass x 5 y 5 end Which is going to be 20 bytes. From robert at timetraveller.org Sat Apr 2 23:49:10 2016 From: robert at timetraveller.org (Robert Brockway) Date: Sun, 3 Apr 2016 14:49:10 +1000 (AEST) Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: <570025E3.5040705@sonic.net> References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> <570025E3.5040705@sonic.net> Message-ID: On Sat, 2 Apr 2016, Mark Wedel wrote: > > I presume the 1000x1000 maps are 50 (or some other size) spaces/side? Or is > each map 1000x1000, but you have some smaller set of maps being tiled > together? Yes I'm using 1000x1000 maps, with each map being 50x50. While I'd been reading C and Python code I'd come to suspect there were implicit assumptions that the world tile maps would be 50x50. Yes this could be fixed but I found it easier just to stick to the existing standard. It's worth noting that the name of the new world is Quadra and I've layed the tiles out in a directory tree to avoid the issues of having too many files in a single directory. So the map tile for maps 117,117 on my new world is: /worlds/quadra/117/117/tile I've written a script which take the tiles generated by 'land' or 'bigland' and sets the tile paths correctly. I have special plans for the edge maps which are worth their own post some other time. > With map tiling, things can move to adjacent maps even if players don't move > to them. The game doesn't really distinguish between objects, and just as > you wouldn't want an arrow to stop at a map edge, same goes true for > monsters. That's great. I think that has some potential to make really interesting tiled maps. > What should eventually happen is that maps with no players on them will get > swapped out. However, what probably also happens is that maps that are still > in memory are touching the other maps, keeping them active, so this never > happens (at least in the case of mice which keep multiplying). One could > have a monster that just wanders and moves to a new map, but it would > eventually get swapped out if nothing else is keeping the map it is on > active. Great thanks. > As far as compression goes, at one time, the server did support map (or > really, all file) compression. However, the typical size of an entire Any chance it could be put it back in, even as an optional component enabled in the config? > installation was small enough on current hard drives, there really wasn't > much point to it (even 100 GB isn't that big for modern systems). Also, some I am looking at hosting my server in Linode or a similar service but I find the cost of 100GB hosted is more than I want to pay on going to run a game server. I could cut the world down to 500x500 maps and add the rest back when the cost of storage drops but I'm hoping not to have to do that. > newer filesystems (ZFS for example) support compression, eg: > > NAME USED RATIO > export/home/crossfire 18.0G 2.09x FreeBSD? Few will be using ZFS on Linux I think and I'm not trusting my data to Btrfs just yet :) There seems to be a FUSE option for on-the-fly compression but there are concenrs about stability. Other than that I think Linux users have few options for on-the-fly compression but happy to hear about options I may have missed. If we applied the map compression in the application it would work on any OS that the game runs on. I compressed a few random tiles from my new world and got compression rations ranging from 6:1 to 10:1. Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC, Freenode and Snoonet) Web: http://www.pracops.com I tried to change the world but they had a no-return policy From mwedel at sonic.net Sun Apr 3 00:37:52 2016 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Apr 2016 22:37:52 -0700 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> <570025E3.5040705@sonic.net> Message-ID: <5700AC30.9090508@sonic.net> On 04/ 2/16 09:49 PM, Robert Brockway wrote: > On Sat, 2 Apr 2016, Mark Wedel wrote: > >> >> I presume the 1000x1000 maps are 50 (or some other size) spaces/side? Or is >> each map 1000x1000, but you have some smaller set of maps being tiled together? > > Yes I'm using 1000x1000 maps, with each map being 50x50. While I'd been reading > C and Python code I'd come to suspect there were implicit assumptions that the > world tile maps would be 50x50. Yes this could be fixed but I found it easier > just to stick to the existing standard. I would hope that there are not any such assumptions (the relevant sections of code could just look at the maps and see how big they are), but that of course doesn't mean that such things don't exist. Certainly the generic tiling logic doesn't have any size assumptions, because I believe there are some other maps (non world) which are tiled, and those probably are not 50x50. I suppose doing a 'grep 50 ...' would see if anything hard codes in the value of 50. As cpu power and memory increases, some assumptions made when things were done may no longer be true. each map being a 100x100 tile (while having 4 times the number of objects) would probably be fine on current hardware, in both cpu and memory standpoint (going way back, I remember when 16 MB of memory was a good amount of memory0 > > It's worth noting that the name of the new world is Quadra and I've layed the > tiles out in a directory tree to avoid the issues of having too many files in a > single directory. So the map tile for maps 117,117 on my new world is: > > /worlds/quadra/117/117/tile > > I've written a script which take the tiles generated by 'land' or 'bigland' and > sets the tile paths correctly. I have special plans for the edge maps which are > worth their own post some other time. Yes, 1,000,000 files in one directory (depending on filesystem) may not work well. >> As far as compression goes, at one time, the server did support map (or >> really, all file) compression. However, the typical size of an entire > > Any chance it could be put it back in, even as an optional component enabled in > the config? I don't remember the details (I'm not the one that removed it), but it was a config file option. One of the main issues is that to open such files, a popen (instead of fopen) was necessary, so this littered the code with checks based on if the file was compressed, it had to record if the file was compressed (so when it saved it, it saved it as compressed), and also dealt with the potential of of many different compression methods (compress, gzip, bzip, now xzip, etc). It was removed to make the code cleaner, which is a good thing, and at the time, the given size of maps (and other data) wasn't large enough to be a concern. Also, at the time, it allowed all files to be compressed (archetypes, player files, etc). Certainly allowing it only on map files would be limit the number of places that code would be needed. Other assumptions could be made, like if compress is set in configure, then assume all map files to be opened will be compressed, and all map files saved will be compressed (thus, do not need to record at time of reading if the file was compressed and what it was compressed with). > >> installation was small enough on current hard drives, there really wasn't much >> point to it (even 100 GB isn't that big for modern systems). Also, some > > I am looking at hosting my server in Linode or a similar service but I find the > cost of 100GB hosted is more than I want to pay on going to run a game server. > > I could cut the world down to 500x500 maps and add the rest back when the cost > of storage drops but I'm hoping not to have to do that. Fair point, but you are sort of an edge case on this, which is to say, a feature really only one person would probably use. > >> newer filesystems (ZFS for example) support compression, eg: >> >> NAME USED RATIO >> export/home/crossfire 18.0G 2.09x > > FreeBSD? Few will be using ZFS on Linux I think and I'm not trusting my data to > Btrfs just yet :) There seems to be a FUSE option for on-the-fly compression > but there are concenrs about stability. Other than that I think Linux users > have few options for on-the-fly compression but happy to hear about options I > may have missed. ZFS on Solaris. I've not looked at the state of other filesystems on linux - I would have thought that there would be other transparent compression methods for linux, but could be wrong. > > If we applied the map compression in the application it would work on any OS > that the game runs on. I think there was some added complication to that compression logic when the server was ported to windows, but may be misrembering. But as noted above, this wasn't a widely used feature, which was why it was removed (I don't recall anyone at the time caring it was removed). > > I compressed a few random tiles from my new world and got compression rations > ranging from 6:1 to 10:1. Yes, the map files would be highly compressible - being plain text, and even more so, generally using a few words very often. That 2x compression was for all the crossfire data, some of which is not very compressible at all (png images) and some that compresses some but not as well as that (eg, binary files) Back to the mega map, one thing that was thought of back in the past was to unify the scale. That is, instead of having buildings/caves/whatever you enter, everything is just on the world map (there may be stairs to different levels). Thus, you would just wander from one shop to another without ever transitioning maps, enter a cave, etc. On the existing bigworld map (30x30 maps, or 1500x1500 spaces), the scale isn't there to do it. Scorn itself might be 500x500 spaces. But on a megaworld map (50,000 x 50,000 spaces), that wouldn't be an issue. However, there probably isn't any easy way to make those changes without a fair amount of manual effort. While tools could be written to put the buildings into appropriate mega-world maps, spaces and alignment probably don't work out, eg, if you had four buildings in scorn right now like: 12 34 Building 1 might be 20x20, building 2 is 40x40. Building 3 is 30x30, and building 4 is 40x40. So while those could all be put on the megaworld map (say use a spacing of 40 for each building), then build 1 may now have odd games with it, or alignment to the road, etc. Plus, it would make it take longer to move between buildings in the town if they are 200 spaces apart (probably want to reduce tick time a bit) From robert at timetraveller.org Sun Apr 3 01:27:53 2016 From: robert at timetraveller.org (Robert Brockway) Date: Sun, 3 Apr 2016 16:27:53 +1000 (AEST) Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: <5700AC30.9090508@sonic.net> References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> <570025E3.5040705@sonic.net> <5700AC30.9090508@sonic.net> Message-ID: On Sat, 2 Apr 2016, Mark Wedel wrote: > I would hope that there are not any such assumptions (the relevant sections > of code could just look at the maps and see how big they are), but that of It was several months ago that I had a look at a lot of that code. I thought I saw potential issues in a few places but I could be wrong. In any case I decided to stick to 50x50 and avoid any potential issues. > One of the main issues is that to open such files, a popen (instead of > fopen) was necessary, so this littered the code with checks based on if the > file was compressed, it had to record if the file was compressed (so when it > saved it, it saved it as compressed), and also dealt with the potential of of > many different compression methods (compress, gzip, bzip, now xzip, etc). It > was removed to make the code cleaner, which is a good thing, and at the time, > the given size of maps (and other data) wasn't large enough to be a concern. > > Also, at the time, it allowed all files to be compressed (archetypes, player > files, etc). Certainly allowing it only on map files would be limit the > number of places that code would be needed. Other assumptions could be made, > like if compress is set in configure, then assume all map files to be opened > will be compressed, and all map files saved will be compressed (thus, do not > need to record at time of reading if the file was compressed and what it was > compressed with). What I was thinking about was quite a bit simpler. Try to open the uncompressed map file as normal. If that fails try to open the same file in the same directory with extension .xz compressed with the xz algorithm (or subsitute another similar compression algorithm to taste) while keeping all temp files uncompressed. The editor would need to know about that too of course. > Fair point, but you are sort of an edge case on this, which is to say, a > feature really only one person would probably use. If 1000x1000 maps became standard in the game (or at least a supported ad-on) it could be common. I wonder if it is possible to do it with a plugin using Mapload or Mapenter: http://wiki.cross-fire.org/dokuwiki/doku.php/server_plugin?s[]=events#hooking_to_global_events If so the uncompressed map could be cleaned up by Mapunload or Mapreset. > ZFS on Solaris. I've not looked at the state of other filesystems on linux > - I would have thought that there would be other transparent compression > methods for linux, but could be wrong. Linux is trailing FreeBSD and Solaris in that regard. BTRFS is the filesystem of the future (and always will be ;) ). > Back to the mega map, one thing that was thought of back in the past was to > unify the scale. When I was considering what to do with my new world a few months ago I went through the archives and found a discussion on this topic. I felt there were some good argument against having buildings at the same scale as the bigworld map. In particular there was a concern about the ability of characters to see the buildings properly. This seemed like a strong argument to me. I like the flexibility that the current 2 scale approach allows. Cheers, Rob -- Email: robert at timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC, Freenode and Snoonet) Web: http://www.pracops.com I tried to change the world but they had a no-return policy From mwedel at sonic.net Mon Apr 4 00:57:54 2016 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Apr 2016 22:57:54 -0700 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> <570025E3.5040705@sonic.net> <5700AC30.9090508@sonic.net> Message-ID: <57020262.4040305@sonic.net> On 04/ 2/16 11:27 PM, Robert Brockway wrote: >> One of the main issues is that to open such files, a popen (instead of fopen) >> was necessary, so this littered the code with checks based on if the file was >> compressed, it had to record if the file was compressed (so when it saved it, >> it saved it as compressed), and also dealt with the potential of of many >> different compression methods (compress, gzip, bzip, now xzip, etc). It was >> removed to make the code cleaner, which is a good thing, and at the time, the >> given size of maps (and other data) wasn't large enough to be a concern. >> >> Also, at the time, it allowed all files to be compressed (archetypes, player >> files, etc). Certainly allowing it only on map files would be limit the >> number of places that code would be needed. Other assumptions could be made, >> like if compress is set in configure, then assume all map files to be opened >> will be compressed, and all map files saved will be compressed (thus, do not >> need to record at time of reading if the file was compressed and what it was >> compressed with). > > What I was thinking about was quite a bit simpler. Try to open the uncompressed > map file as normal. If that fails try to open the same file in the same > directory with extension .xz compressed with the xz algorithm (or subsitute > another similar compression algorithm to taste) while keeping all temp files > uncompressed. That is more or less what the old code did - however, there was the potential of several possible compression method used, so it would have to try .xz, .gz, .Z, etc. With availability of compression libraries, if this was to be redone, that logic might be different - instead of calling popen, if the server found a .xz suffix, it runs it through the xz decoder. However, it still has to record that the file was in fact compressed when it read it in, so it needs to write it out compressed. Doing it with a library is certainly better - I have to imagine the overhead of running an external program to do the compression could not have been great. > > The editor would need to know about that too of course. That might have been another reason the old compression logic was removed - possibly the java editor did not support it. Back with the old C editor, it used the same function to read the maps as the the server, so if the compression was supported, crossedit would also support it. That certainly does not exist now. > >> Fair point, but you are sort of an edge case on this, which is to say, a >> feature really only one person would probably use. > > If 1000x1000 maps became standard in the game (or at least a supported ad-on) it > could be common. True, for certain cases (eg, those where the cost of 100 GB of storage is significant because of hosting costs). Or I guess if someone is running all on an SSD, it may not be particularly large, so chewing up 100 GB of it with map data may not be ideal. > > I wonder if it is possible to do it with a plugin using Mapload or Mapenter: > > http://wiki.cross-fire.org/dokuwiki/doku.php/server_plugin?s[]=events#hooking_to_global_events > > > If so the uncompressed map could be cleaned up by Mapunload or Mapreset. Maybe - it is possible that these could be done outside, eg, before the map is loaded, it decompresses the map file so that the uncompressed map file exists. However, I'm not exactly sure the timing of those functions - for MapLoad, it would have to be done before any work on loading the map is done, and I suspect (though could be wrong and am too lazy to look at the code now), that event may be generated after the map is loaded but before anything is done with it (thus scripts could make certain changes to the map or do other special initialization). Likewise, the MapUnload may be done before the map is unloaded, so global events could do certain cleanup. However, I would expect performance to be worse in this case, even if possible, as basically it would have to call an external program to decompress the map into a new file, and then the server reads in that file. That triples the I/O - now granted, it probably all remains in the file cache, but certainly less efficient than just decompressing it as it is read in. >> Back to the mega map, one thing that was thought of back in the past was to >> unify the scale. > > When I was considering what to do with my new world a few months ago I went > through the archives and found a discussion on this topic. I felt there were > some good argument against having buildings at the same scale as the bigworld > map. In particular there was a concern about the ability of characters to see > the buildings properly. This seemed like a strong argument to me. It would certainly make relations of buildings harder. However, in some ways, it would also make buildings easier to find - on such a huge world, it would be pretty easy to miss a castle in the now much larger forest, etc. On a single scale, you'd probably find the castle wall - may have to circle around to find the entrance, etc. However, such a change would be pretty massive, simply because many maps in town generate monsters - one could pretty quickly find those wandering the town, perhaps also multiplying to a large degree. Another bigger issue would likely be map resets - even if no one enters the church in town, they may wander close enough so it doesn't reset as often as it should From om at iki.fi Wed Apr 6 04:53:07 2016 From: om at iki.fi (Otto J. Makela) Date: Wed, 6 Apr 2016 12:53:07 +0300 Subject: [crossfire] A funny thing happened on the way to the new maps In-Reply-To: References: <56FF4BDB.60702@gmail.com> <56FFC9AB.7050906@giassa.net> Message-ID: <5704DC83.4020706@iki.fi> On 2016-04-02 19:50, Robert Brockway wrote: > Actually I've always liked the idea of having the potential for > monsters to fight each other. Just because they are against the > player doesn't mean skeletons and orcs should always get on. This of course already happens when you charm monsters (and some other magicks or skills, I believe?) to be your friends. In addition to mice, I could easily see pestilences of giant locusts or battalions of army ants. -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */ From leaf at real-time.com Mon Apr 18 15:37:09 2016 From: leaf at real-time.com (Rick Tanner) Date: Mon, 18 Apr 2016 15:37:09 -0500 Subject: [crossfire] Web forum offline Message-ID: <57154575.8050600@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The web forum at forum.metalforge.net is offline for the time being. There was hardware failure so I am going to move/migrate to a Virtual Server and recover from backups - but that is going to take a few days (or longer..) because of my current work load. -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlcVRXQACgkQhHyvgBp+vH4iRwCfVII8r8KfQElG0p6gCJ7X323N jhoAoItX6TkcVyzGsWzT+gjUW0eLzDhr =DijM -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sat Apr 23 14:37:41 2016 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 23 Apr 2016 21:37:41 +0200 Subject: [crossfire] Web forum offline In-Reply-To: <57154575.8050600@real-time.com> References: <57154575.8050600@real-time.com> Message-ID: <201604232137.45291.nicolas.weeger@laposte.net> Thanks for the hosting and management of the various Crossfire sites :) Nicolas Le lundi 18 avril 2016 22:37:09, Rick Tanner a ?crit : > The web forum at forum.metalforge.net is offline for the time being. > > There was hardware failure so I am going to move/migrate to a Virtual > Server and recover from backups - but that is going to take a few days > (or longer..) because of my current work load. > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From john at jfloren.net Fri Apr 29 13:48:29 2016 From: john at jfloren.net (John Floren) Date: Fri, 29 Apr 2016 12:48:29 -0600 Subject: [crossfire] building very old versions Message-ID: Hi! I have some very fond memories of installing Crossfire from a Redhat 6.2 disk way back in the day; I seem to remember the game being monochrome, with much simpler maps, but still very fun. I was hoping someone might have some tips on what revisions I should check out in the svn repo (I'm not very familiar with svn, I'm more of a git person) and how exactly one would build the older versions. Thanks! John From rick at tanners.org Fri Apr 29 14:15:37 2016 From: rick at tanners.org (Rick Tanner) Date: Fri, 29 Apr 2016 14:15:37 -0500 Subject: [crossfire] building very old versions In-Reply-To: References: Message-ID: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> Sounds like you are looking for source code that was in place before Crossfire started to use revision control (originally cvs from 1999 to 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM days. Looking back at my collected archive or releases, I don't have anything before 0.97.0 -- it was before I became involved with the project. http://crossfire.real-time.com/download/archive/ The origins of Crossfire source code may be lost? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From john at jfloren.net Fri Apr 29 14:27:27 2016 From: john at jfloren.net (John Floren) Date: Fri, 29 Apr 2016 13:27:27 -0600 Subject: [crossfire] building very old versions In-Reply-To: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> References: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> Message-ID: Near as I can guess, Redhat 6.2 (released April 2000) would be just about situated to have shipped the CVS code from 1999... "svn log" shows me checkins going back that far. Maybe the best thing to do is install 6.2 in a VM and just grab the packages... or maybe install a similarly-aged Debian / Slackware, to reduce my RPM frustrations :) I might try that tonight, will report back if successful john On Fri, Apr 29, 2016 at 1:15 PM, Rick Tanner wrote: > > Sounds like you are looking for source code that was in place before > Crossfire started to use revision control (originally cvs from 1999 to > 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM > days. > > Looking back at my collected archive or releases, I don't have anything > before 0.97.0 -- it was before I became involved with the project. > > http://crossfire.real-time.com/download/archive/ > > The origins of Crossfire source code may be lost? > > > > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From drnlmuller+crossfire at gmail.com Fri Apr 29 15:29:13 2016 From: drnlmuller+crossfire at gmail.com (Neil Muller) Date: Fri, 29 Apr 2016 22:29:13 +0200 Subject: [crossfire] building very old versions In-Reply-To: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> References: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> Message-ID: On 29 April 2016 at 21:15, Rick Tanner wrote: > > Sounds like you are looking for source code that was in place before > Crossfire started to use revision control (originally cvs from 1999 to > 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM > days. > > Looking back at my collected archive or releases, I don't have anything > before 0.97.0 -- it was before I became involved with the project. > > http://crossfire.real-time.com/download/archive/ > You can dig up crossfire 0.95 out of the debian archive - http://archive.debian.org/debian/dists/Debian-2.1/main/source/games/ - which is a bit before the start of the sourceforge CVS history. I'm under the impression that crossfire made it into the FreeBSD releases before it got picked up by most of the Linux distributions, so it may be possible to pull older versions out of those archives if one is so inclined. -- Neil Muller drnlmuller at gmail.com I've got a gmail account. Why haven't I become cool? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwedel at sonic.net Fri Apr 29 15:47:19 2016 From: mwedel at sonic.net (mwedel) Date: Fri, 29 Apr 2016 22:47:19 +0200 Subject: [crossfire] building very old versions Message-ID: <9tb85b2veuflaivh8d8s3uno.1461962839132@email.android.com> I have all the versions (well, at least going back to the 0.89s I think) on my computer and can dig them up at some point. Note that even XPM mode were color, though for quite a while that existed side by side with the XBM mode which were two color. A question would be what exactly are you looking for in those old versions? The retro graphics, old maps, old gameplay, etc? The old versions did not have a separate client, though I would expect that the old server should compile without much difficulty. ?I can't recall anything too platform specific. ?The biggest problem might be deprecated function calls in the various libraries.?? ? -------- Original message --------From: Neil Muller Date: 4/29/2016 22:29 (GMT+01:00) To: Crossfire Discussion Mailing List Subject: Re: [crossfire] building very old versions On 29 April 2016 at 21:15, Rick Tanner wrote: > > Sounds like you are looking for source code that was in place before > Crossfire started to use revision control (originally cvs from 1999 to > 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM > days. > > Looking back at my collected archive or releases, I don't have anything > before 0.97.0 -- it was before I became involved with the project. > > http://crossfire.real-time.com/download/archive/ > You can dig up crossfire 0.95 out of the debian archive - http://archive.debian.org/debian/dists/Debian-2.1/main/source/games/?- which is a bit before the start of the sourceforge CVS history. I'm under the impression that crossfire made it into the FreeBSD releases before it got picked up by most of the Linux distributions, so it may be possible to pull older versions out of those archives if one is so inclined. -- Neil Muller drnlmuller at gmail.com I've got a gmail account. Why haven't I become cool? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at jfloren.net Fri Apr 29 15:54:17 2016 From: john at jfloren.net (John Floren) Date: Fri, 29 Apr 2016 14:54:17 -0600 Subject: [crossfire] building very old versions In-Reply-To: <9tb85b2veuflaivh8d8s3uno.1461962839132@email.android.com> References: <9tb85b2veuflaivh8d8s3uno.1461962839132@email.android.com> Message-ID: Yes, I do remember that I only ran one command to start the game... As for what I'm looking for, I liked the old maps (when I tried playing later, found the new maps kinda sprawling), the old graphics, and the old gameplay... It's all probably nostalgia but I liked it better when there were fewer classes and just generally fewer options :) On Fri, Apr 29, 2016 at 2:47 PM, mwedel wrote: > I have all the versions (well, at least going back to the 0.89s I think) on > my computer and can dig them up at some point. > > Note that even XPM mode were color, though for quite a while that existed > side by side with the XBM mode which were two color. > > A question would be what exactly are you looking for in those old versions? > The retro graphics, old maps, old gameplay, etc? > > The old versions did not have a separate client, though I would expect that > the old server should compile without much difficulty. I can't recall > anything too platform specific. The biggest problem might be deprecated > function calls in the various libraries. > > > -------- Original message -------- > From: Neil Muller > Date: 4/29/2016 22:29 (GMT+01:00) > To: Crossfire Discussion Mailing List > Subject: Re: [crossfire] building very old versions > > > > On 29 April 2016 at 21:15, Rick Tanner wrote: >> >> Sounds like you are looking for source code that was in place before >> Crossfire started to use revision control (originally cvs from 1999 to >> 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM >> days. >> >> Looking back at my collected archive or releases, I don't have anything >> before 0.97.0 -- it was before I became involved with the project. >> >> http://crossfire.real-time.com/download/archive/ >> > > You can dig up crossfire 0.95 out of the debian archive - > http://archive.debian.org/debian/dists/Debian-2.1/main/source/games/ - which > is a bit before the start of the sourceforge CVS history. > > I'm under the impression that crossfire made it into the FreeBSD releases > before it got picked up by most of the Linux distributions, so it may be > possible to pull older versions out of those archives if one is so inclined. > > -- > Neil Muller > drnlmuller at gmail.com > > I've got a gmail account. Why haven't I become cool? > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From matthew at giassa.net Sat Apr 30 07:55:24 2016 From: matthew at giassa.net (Matthew Giassa) Date: Sat, 30 Apr 2016 05:55:24 -0700 Subject: [crossfire] building very old versions In-Reply-To: References: <9tb85b2veuflaivh8d8s3uno.1461962839132@email.android.com> Message-ID: <5724AB3C.3040604@giassa.net> When you end up pulling up the old archives, could I please be CC'ed on it as well? I recall playing CF on my old Slackware3 box years back, and while it was color, it was very different. Thanks! ============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matthew at giassa.net website: www.giassa.net On 04/29/16 13:54, John Floren wrote: > Yes, I do remember that I only ran one command to start the game... > > As for what I'm looking for, I liked the old maps (when I tried > playing later, found the new maps kinda sprawling), the old graphics, > and the old gameplay... It's all probably nostalgia but I liked it > better when there were fewer classes and just generally fewer options > :) > > On Fri, Apr 29, 2016 at 2:47 PM, mwedel wrote: >> I have all the versions (well, at least going back to the 0.89s I think) on >> my computer and can dig them up at some point. >> >> Note that even XPM mode were color, though for quite a while that existed >> side by side with the XBM mode which were two color. >> >> A question would be what exactly are you looking for in those old versions? >> The retro graphics, old maps, old gameplay, etc? >> >> The old versions did not have a separate client, though I would expect that >> the old server should compile without much difficulty. I can't recall >> anything too platform specific. The biggest problem might be deprecated >> function calls in the various libraries. >> >> >> -------- Original message -------- >> From: Neil Muller >> Date: 4/29/2016 22:29 (GMT+01:00) >> To: Crossfire Discussion Mailing List >> Subject: Re: [crossfire] building very old versions >> >> >> >> On 29 April 2016 at 21:15, Rick Tanner wrote: >>> >>> Sounds like you are looking for source code that was in place before >>> Crossfire started to use revision control (originally cvs from 1999 to >>> 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM >>> days. >>> >>> Looking back at my collected archive or releases, I don't have anything >>> before 0.97.0 -- it was before I became involved with the project. >>> >>> http://crossfire.real-time.com/download/archive/ >>> >> >> You can dig up crossfire 0.95 out of the debian archive - >> http://archive.debian.org/debian/dists/Debian-2.1/main/source/games/ - which >> is a bit before the start of the sourceforge CVS history. >> >> I'm under the impression that crossfire made it into the FreeBSD releases >> before it got picked up by most of the Linux distributions, so it may be >> possible to pull older versions out of those archives if one is so inclined. >> >> -- >> Neil Muller >> drnlmuller at gmail.com >> >> I've got a gmail account. Why haven't I become cool? >> >> _______________________________________________ >> crossfire mailing list >> crossfire at metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire >> > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From john at jfloren.net Sat Apr 30 11:59:42 2016 From: john at jfloren.net (John Floren) Date: Sat, 30 Apr 2016 10:59:42 -0600 Subject: [crossfire] building very old versions In-Reply-To: References: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> Message-ID: I got the client and server building from these with very little hacking. I had to prevent it from building crossedit, which was having some issues with includes. Here's it running (the window is X-forwarded from my Linux box): http://i.imgur.com/n9PNRgG.png Are there any copyright/licensing issues with me just bundling up these slightly modified versions and sticking them up to download somewhere? john On Fri, Apr 29, 2016 at 2:29 PM, Neil Muller wrote: > > > On 29 April 2016 at 21:15, Rick Tanner wrote: >> >> Sounds like you are looking for source code that was in place before >> Crossfire started to use revision control (originally cvs from 1999 to >> 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM >> days. >> >> Looking back at my collected archive or releases, I don't have anything >> before 0.97.0 -- it was before I became involved with the project. >> >> http://crossfire.real-time.com/download/archive/ >> > > You can dig up crossfire 0.95 out of the debian archive - > http://archive.debian.org/debian/dists/Debian-2.1/main/source/games/ - which > is a bit before the start of the sourceforge CVS history. > > I'm under the impression that crossfire made it into the FreeBSD releases > before it got picked up by most of the Linux distributions, so it may be > possible to pull older versions out of those archives if one is so inclined. > > -- > Neil Muller > drnlmuller at gmail.com > > I've got a gmail account. Why haven't I become cool? > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From matthew at giassa.net Sat Apr 30 12:17:43 2016 From: matthew at giassa.net (Matthew Giassa) Date: Sat, 30 Apr 2016 10:17:43 -0700 Subject: [crossfire] building very old versions In-Reply-To: References: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> Message-ID: <5724E8B7.2080509@giassa.net> Wow, that brings me back. ============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matthew at giassa.net website: www.giassa.net On 04/30/16 09:59, John Floren wrote: > I got the client and server building from these with very little > hacking. I had to prevent it from building crossedit, which was having > some issues with includes. > > Here's it running (the window is X-forwarded from my Linux box): > http://i.imgur.com/n9PNRgG.png > > Are there any copyright/licensing issues with me just bundling up > these slightly modified versions and sticking them up to download > somewhere? > > john > > On Fri, Apr 29, 2016 at 2:29 PM, Neil Muller > wrote: >> >> >> On 29 April 2016 at 21:15, Rick Tanner wrote: >>> >>> Sounds like you are looking for source code that was in place before >>> Crossfire started to use revision control (originally cvs from 1999 to >>> 2006, now svn.) So, it is not possible to cvs/svn revert back to the XPM >>> days. >>> >>> Looking back at my collected archive or releases, I don't have anything >>> before 0.97.0 -- it was before I became involved with the project. >>> >>> http://crossfire.real-time.com/download/archive/ >>> >> >> You can dig up crossfire 0.95 out of the debian archive - >> http://archive.debian.org/debian/dists/Debian-2.1/main/source/games/ - which >> is a bit before the start of the sourceforge CVS history. >> >> I'm under the impression that crossfire made it into the FreeBSD releases >> before it got picked up by most of the Linux distributions, so it may be >> possible to pull older versions out of those archives if one is so inclined. >> >> -- >> Neil Muller >> drnlmuller at gmail.com >> >> I've got a gmail account. Why haven't I become cool? >> >> _______________________________________________ >> crossfire mailing list >> crossfire at metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire >> > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From leaf at real-time.com Sat Apr 30 13:20:30 2016 From: leaf at real-time.com (Rick Tanner) Date: Sat, 30 Apr 2016 13:20:30 -0500 Subject: [crossfire] building very old versions In-Reply-To: References: <30a0b58a-8ef6-be8b-698f-61683409743d@tanners.org> Message-ID: <39208ee8-321a-0bec-ad16-16c139886bfa@real-time.com> > Here's it running (the window is X-forwarded from my Linux box): > http://i.imgur.com/n9PNRgG.png Nicely done! Oh the memories! > Are there any copyright/licensing issues with me just bundling up > these slightly modified versions and sticking them up to download > somewhere? As far as I know, no issues with copyright or licensing for you to do that. You may be asked for a diff of the changes you made though. ;-)