Llywar

It actually does look like Gentoo has been mirroring the data files unmodified. I'll go ahead and stick with that - I suspect they don't care since we aren't modifying them, and we're only using them with stock clients (built from source, but only patched to make the build system work). If they have any objection I'll happily take down the mirroring at their request. So, I was able to get the data files packaged without much fuss using your URL. Now the only issue is that the client won't build. I'll need to give that more attention. First error: x86_64-pc-linux-gnu-gcc -march=native -Wall -Wdeclaration-after-statement -O0 -ggdb -pipe -DLINUX -DELC -Dassume-digests -Dbinpkg-logs -Dbuildpkg -Dcgroup -Dconfig-protect-if-modified -Ddistlocks -Debuild-locks -Dfixlafiles -Dipc-sandbox -Dmerge-sync -Dmultilib-strict -Dnetwork-sandbox -Dnews -Dparallel-fetch -Dpreserve-libs -Dprotect-owned -Dsandbox -Dsfperms -Dsign -Dsplitdebug -Dstrict -Dunknown-features-warn -Dunmerge-logs -Dunmerge-orphans -Duserfetch -Duserpriv -Dusersandbox -Dusersync -Dxattr -D_7ZIP_ST -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -I/usr/include/minizip -fno-strict-aliasing -DDATA_DIR="/usr/share/games/eternal-lands/" -DLINUX -DELC -DCLUSTER_INSIDES -DCUSTOM_LOOK -DCUSTOM_UPDATE -DFUZZY_PATHS -DNEW_SOUND -DPNG_SCREENSHOT -DTEXT_ALIASES -DUSE_INLINE -DBANDWIDTH_SAVINGS -DANIMATION_SCALING -DFSAA -DNEW_NEW_CHAR_WINDOW -DNEW_TEXTURES -DFASTER_MAP_LOAD -DFASTER_STARTUP -DMIDDLE_MOUSE_PASTE -DNEW_EYES -D_7ZIP_ST -MT '2d_objects.o' -MD -MP -MF '.deps/2d_objects.o.pp' -c 2d_objects.c -o 2d_objects.o <command-line>:0:7: warning: missing whitespace after the macro name [enabled by default] (... many repeats of this warning ...) <command-line>:0:9: error: expected ‘;’, ‘,’ or ‘)’ before ‘-’ token Gotta say - has to be the first time I've seen that one on a command-line.

Are those data files legally hosted? The only issue holding up distributing this on Gentoo is the fact that I couldn't find a legally-hosted file containing the data files (maps, artwork, etc) in a form other than the installer. Previously they had been hosted as zip files on the el website. I doubt I'll have any issues building the client once I have them. There is no need for Gentoo to redistribute the artwork as long as it is legally hosted in a zip file, tarball, etc. Gentoo separates the installation scripts from the files to install, so we don't need to redistribute the original files to package them. As far as I can tell, the license itself only gives permission to redistribute the client, not the artwork, and the latter is the problem here.

This is obviously going to be lower priority than dealing with 1.9.2 bugs/etc, but tinderbox testing at Gentoo has uncovered some underlinking issues with the linux client. The ld linker isn't bothered by underlinking, although it can lead to subtle errors when non-linked libraries change ABI and --as-needed is used. Obviously this won't impact static binaries. The gentoo bug can be found at: http://bugs.gentoo.org/show_bug.cgi?id=369315 The EL build output with errors on underlinking can be found at: http://bugs.gentoo.org/attachment.cgi?id=275159 The fix is somewhat straightforward - edit the Makefile to include the libraries containing the functions. While there are a bunch of errors I suspect it will only be a few libraries. What is doing to be more complex is that some of those functions could be provided by more than one library (such as xlib vs xcb), and EL doesn't use autotools or a similar mechanism to work this out. Essentially EL is "cheating" by letting SDL (or whatever is brining those in) figure that out and leveraging the underlying functions. I don't have a ton of time at the moment, but if I get a chance I'll see what I can do in terms of patches and send any I make your way.

The file is obviously in master, but the v1.9.2 tag snapshot is missing elloggingwrapper.h, which is problematic if you're trying to build that exact version. I'm preparing the distfile snapshot for gentoo, and the goal is obviously to stay as close to upstream as possible. However, I can just take a snapshot of master as it appears at some random time and use that instead. If you wanted a particular commit to be used just let me know (and ideally update the tags accordingly). I'll go ahead and wait a little before packaging something up, but I don't users to be stuck without a working client for an extended period of time...

(Thinking about the item shop of EL) Check the definitions: By that definition, the EL shop does not distribute "Products" and neither does EL in general. Basically you can't use the market to distribute another android app market.

OK, I've committed this change. Thanks. Not sure if it makes a difference, but a Gentoo dev sent me the following alternative patch for the same problem. Half of it is identical to what is now in CVS, but the second half modifies the call to png_destroy_write_struct. If CVS builds as-is with libpng 1.5 I'll avoid applying a Gentoo-specific patch, but I figured I'd post this in case there is something worth looking at: Index: elc/misc.c =================================================================== --- elc.orig/misc.c +++ elc/misc.c @@ -311,7 +311,7 @@ int IMG_SavePNG_RW (SDL_Surface *face, S } /* Set error handling. */ - if (setjmp(png_ptr->jmpbuf)) + if (setjmp(png_jmpbuf(png_ptr))) { /* If we get here, we had a problem reading the file */ IMG_SetError("Error writing the PNG file"); @@ -360,10 +360,7 @@ done: if (row_pointers != NULL) free (row_pointers); - if (info_ptr != NULL && info_ptr->palette != NULL) - free (info_ptr->palette); - - png_destroy_write_struct (&png_ptr, (png_infopp)NULL); + png_destroy_write_struct (&png_ptr, &info_ptr); return result; }

I've been working on ditching MM, and was shocked when I ended up having to pay around 15k for an MM cloak. The prices have risen dramatically over the last few years. Now, it isn't that big deal since 15k isn't much for a decent-level player who doesn't break them left and right. However, I'm a bit concerned about the impact this has on newbies. MM Cloaks are one of the first items a newbie will tend to save up for - or at least they used to be. They used to be around 5k, maybe 7k in later years. That is a LOT of gc for somebody who can't even carry the ingreds for 2 iron bars. Until they have MM most of the game world is inaccessible to them. Now, dangerous maps are part of the game dynamic, but I think that we're currently out of balance. EL really needs to help newbies to get started if it wants to grow. If the concern is that we want MMs to have a higher price for experienced players, perhaps the solution is a one-time quest accessible to newbies to get them a cloak. Perhaps the quest might even cost a few k in gc equivalent. Of course, the simplest solution is just upping the drop rate so that the price drops overall, or capping their price via an npc. I just remember back to my newbie days when remembering to wear an MM cloak and being careful not to break it was part of the game mechanic. Now it just seems to be that newbies need to confine themselves to 3 maps in the day, and 4 at night.

I took MM as well as a newbie, and in the end it worked out just fine since the removal stones came along. However, in general it isn't really good for newbies to just take perks left and right - there is no guarantee that an MM stone won't cost 400k when they eventually get around to buying one. Perks should be very carefully considered. I still think that an MM cape should be cheaper. It shouldn't be so cheap as to be a trivial thing, but there is a big difference between a 7k cape and a 15k cape. I don't consider 15k a trivial sum and I'm in the 80s OA and have been playing for years.

Well, 15k probably represents at least an hour or two of work for most mid-level chars - maybe a few hours if you aren't working hard at it. For a casual player that can be a week of real world time. For a newbie it could be much longer. Keep in mind that EL shouldn't be designed for an 8hr/day*7d/wk player. That is, unless you want to limit it to these kinds of players. Arguably the success of many other games is their appeal to much more casual gamers. When I was a newbie an MM cloak cost maybe 6-7k, and it still represented a serious sacrifice to buy one. I don't know that gc/hr rates for newbies have gone up much such that 100% inflation makes sense.

Not a bad idea, but I have to wonder if it would still be worth buying with the ingredients that would be involved. Tailoring is an expensive skill. That really just depends on what ingredients are actually involved. An MM cape for newbies shouldn't cost 100gc - but it probably shouldn't cost 10k either. Something more in-line with the fast regen cape is probably appropriate. Yes, that does mean that it can't require the same kind of ingredient chain that goes into the other cloaks/shirts/pants/etc. It really does need to be simple. Perhaps this might even be a practical item that lower-level tailors could make. Maybe it might even be something a newbie could work towards making for themselves?

Good point - if an MM cloak isn't worth buying for 15k, then it isn't worth keeping for 15k either. Indeed, I could see people signing up alts left and right just to run the quest. Obviously changing the drop rate is still a fix. Perhaps there are other ways to change the newbie dynamic as well.

One Magic Removal Stone up for auction. Buy it now for 700k. Starting bid 600k. Increment bids by multiples of 5k. I'll take bids by forum private message or posts here only. Auction closes on May 31st at 23:59:59 UTC (forum time). I may not be online then but I'll take the maximum bid with the earliest timestamp before that time. If you do buy-it-now I'll make every effort to rush the item to you as soon as you want it.

buy-it-now price reached - sold! thanks for your interest!

Llywar - 2k silver - 5k gc total.

While there is a thread already started pertaining to this topic it is several years old, so I figured I'd start a fresh thread. Does EL/Ent/etc have a stance on including unofficial maps in distributions? I have a request to include the Bloodsucker maps in the Gentoo distro. If I add them, they wouldn't appear by default - users would have to set a "USE flag" to have them installed. However, this would allow users to want unofficial maps to always have the latest and greatest and the distro would manage the file collisions so that they end up with a more consistent experience. This would also ensure that users aren't accidentally messing up their .elm's/etc when trying to save their maps during an upgrade. The way it would work is that the official maps would be installed by default, but if a user wants alternate maps the official maps (bmps) would not be installed, and another package would contain the alternate maps. The alternate packages would display a notice at installation time clearly stating that the maps are unofficial, and EL staff/mods/etc are not to be pestered about problems that come up (you get to keep the pieces...), etc. In general Gentoo tries to play nice with upstream, so I figured I'd look for an opinion here. I doubt anybody would even notice the impact of the addition around here - since only those who go looking for the maps would get them, and these people likely already have them.

250 Yarrow 750 Mullein 5001 Lilacs 6k for all - game or forum pm (negotiable)

Gentoo is running into the glext.h problem in the testing branch now (due to using a newer version of mesa). Since the package depends on a package that provides a modern version of glext.h anyway, I am just patching package.h for gentoo users. I figure that this is a lot cleaner than moving them to the bleeding-edge CVS version which you might not appreciate...

Gentoo is trying to move to building packages with --as-needed by default (simplifies library upgrades when sonames change, and also improves launch times). However, eternal lands does not build with --as-needed. With this flag the linker is sensitive to the command-line order of libraries - they must follow the objects they are needed for, otherwise the linker just discards them and you get unresolved symbols. A quick fix is to edit the Makefile to replace: @$(LINK) $(CFLAGS) $(LDFLAGS) -o $(EXE) $(OBJS) with: @$(LINK) $(CFLAGS) -o $(EXE) $(OBJS) $(LDFLAGS) More ideally, the libraries should be put in a separate variable so that LDFLAGS can still be used for anything that must go earlier on the command line. Gentoo is already patching this now, but it would be nice to have this fixed upstream. I understand other distros are starting to use --as-needed as well.

One problem with IRL trading is that it gives people more incentive to camp spawns/resources/etc. Right now a player with nothing better to do can kill yetis or harvest silver or whatever night and day, and end up will millions of gc. Eventually they'll get board with this since they can only spend it so fast (and if they're spending it to level other skills then that is less time they can spend camping the spawn or whatever). If you allow gc for $$$ then some people will just camp on lucrative resources almost 24x7 - and then contention will become an issue. You start to run into farmers and other semi-professional gamers. You could take steps to make things more inconvenient for them (depletable resourceds / etc), but this also makes the game more inconvenient for regular players. The farmers will ALWAYS have more time/incentive to get around these limits. As others have pointed out, enforcement is almost impossible. You can force "balanced" trade, but what is a balanced trade? I (like many others) like to give cheap drop books to guildies to free. Somebody gave books to me which really helped me, and I pass on the favor. And "balanced" trades can only do so much - I can trade somebody 100 S2Es for 600gc and they can trade them back for 750gc, and that ends up giving me 15k gc for free - unless you fix the prices of items exactly (or very close to it), then people can transfer cash with just moderate hassle. Frankly, I hate the idea of price fixing - one of the things I really like about EL is that it is fairly close to a free economy. I think Ent feels the same way.

When walking South from the Melinis South Gate running the current CVS I got a segfault in textures.c. The problem would repeat every time I reloaded the client. Launching the v1.8 client worked fine and allowed me to navigate past this point. The CVS client worked fine after that. Here is a backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f5c68068740 (LWP 22428)] 0x00000000004b0555 in load_texture (file_name=0x15f9c84 "./3dobjects/trees/treehousebark.bmp", tex=0x0, alpha=52 '4') at textures.c:1181 1181 textures.c: No such file or directory. in textures.c (gdb) bt #0 0x00000000004b0555 in load_texture (file_name=0x15f9c84 "./3dobjects/trees/treehousebark.bmp", tex=0x0, alpha=52 '4') at textures.c:1181 #1 0x00000000004b0d0e in load_bmp8_color_key (tex_cache_entry=0x15f9c80, alpha=0) at textures.c:1585 #2 0x00000000004b10a1 in get_texture_id (i=174) at textures.c:1438 #3 0x0000000000411855 in draw_3d_object_detail (object_id=0x540aad0, material_index=<value optimized out>, use_lightning=1, use_textures=<value optimized out>, use_extra_textures=<value optimized out>) at textures.h:236 #4 0x0000000000411af8 in draw_3d_objects (object_type=<value optimized out>) at 3d_objects.c:397 #5 0x0000000000412193 in display_objects () at 3d_objects.c:691 #6 0x0000000000457b20 in display_game_handler (win=0x20b9bb0) at gamewin.c:1195 #7 0x000000000044b236 in draw_window (win=0x20b9bb0) at elwindows.c:1266 #8 0x000000000044b47d in display_windows (level=1) at elwindows.c:80 #9 0x0000000000440686 in draw_scene () at draw_scene.c:144 #10 0x000000000047522d in start_rendering () at main.c:205 #11 0x00000000004752bb in main (argc=1, argv=0x7fff700a1138) at main.c:344 I am using gzipped textures, but I tried uncompressing treehousebark.bmp and that didn't fix the problem. It looks like it managed to load hte 173 previous textures just fine, so not sure what is going on there. If there are any particular variables you'd like me to dump if I run into the bug again let me know. This is on gentoo amd64.

That would be the problem - reordering the code fixes the segfault. The problem occurs consistently for me at Melinis [224.86].

I'll bid 2.1gc each for the silver.

Current when harvesting high-level items the cooldown after an event is considerable - you might have to wait 10+ seconds before clicking on a harvestable item in order to resume harvesting. If the goal is to deter afk harvesting the main point of the event should be to force a re-click. The additional wait is harmful only to those who are not afk, since the afk harvester will be past the cooldown before they even notice that harvesting has stopped. If mini-events removed the harvest cooldown when they were triggered then it would at least take a little of the pain out of high-level items for non-afk players. On the other hand, if a goal is to cut down harvesting of items that are way about character harvesting level then this might be undesirable. I'm not sure this should be a goal, however - it is VERY hard to get your harvest levels up so I'm not sure it should be the same as other skills where you are basically prevented from going much above level.

in game name? Same as the forum: Llywar Just let me know who to PM to pick up.

I just wanted to comment on limited harvesting resources since that topic has come up. I think that something like this could work, but the implementation would be tricky. If the resource is limited per-character then a person with 50 alts isn't impacted much. If the resource is limited globally then people who are in more Western timezones are going to be stuck trying to find the pickings left over by those who wake up earlier (unless the recycle rate is very high). People who only connect occassionally might spend all their online time just finding a resource, with very little time left to actually exploit it (similar to the issues with trying to find empty spawns on a busy day). This is certainly not a reason to not implement limited resources at all, but it is a concern that would need to be balanced.