Re: [crossfire] A funny thing happened on the way to the new maps

[Otto J. Makela]

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 0100 01001011 * * * * * * */
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Mark Wedel]

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 

Re: [crossfire] A funny thing happened on the way to the new maps

[Robert Brockway]

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: rob...@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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Mark Wedel]

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:

NAMEUSED  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 

Re: [crossfire] A funny thing happened on the way to the new maps

[Robert Brockway]

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:

NAMEUSED  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: rob...@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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Mark Wedel]

 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:


NAMEUSED  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.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Robert Brockway]

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: rob...@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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Matthew Giassa]

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:   matt...@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


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Robert Brockway]

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: rob...@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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Kevin Zheng]

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
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Matthew Giassa]

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:   matt...@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


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] A funny thing happened on the way to the new maps

[Robert Brockway]

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: rob...@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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire