0ctane

Missed this thread for a few days. In the new client version (for the next update) the preferences will be much more easily accessible. I am moving the settings to: $HOME/Library/Application Support/Eternal Lands This way, people will not need to know linux terminal commands to access hidden folders and change these settings.

No, I have been playing this gave for over a year and have never heard of a negative perk. If you want to take Hellspawn to get your charm level up, go ahead. If this charm sugestion is implemented, nothing would be stopping you from getting those 42 pps to put into charm too. Of course, you already have the ability to put those 42 pps into p/c to be a stronger fighter, right? And prevously, I did mention that these calculations were based on not getting neg-perks just to simplify things. While alchemy itself does not require a nexus, in order to get the ingredients for many alchemy mixtures, you need to have inorganic nexuses to harvest the stuff. Like I said, unless you somehow can afford to buy all the ingredients. This theoretical total charm player would have to harvest a lot of lilacs to buy enough ingredients to eventually alch and mage up to level 100. Or with their 4p/4c they could kill a lot of rabbits.

Keep it simple. Or at least subdue that animation. Or make it not infinitely loop.

Sorry, but this makes no sense. People who create PvP characters are specifically choosing their attributes to boost their PK ability. While, as I mentioned, others have already suggested NPC actions/reactions for the charm attribute, nothing has come of this. Also, others have already suggested a possible role in summoning. I personally do not see much of a role for a player attribute in summoning. I think those who have suggested it in the past have felt that "charm" was more akin to putting a spell on something ... or like a skill rather than a player attribute. People "charm" snakes, but that is a skill. Again, I am trying to propose something that AFAIK has not been suggested. Yes. And if the calculation used 2% * charm, then it would be very unlikely for anyone to become invulnerable or too "pretty" (sorry Hardcore). Yes, there are players with an OA 100, but no one ever puts all their pickpoints in one attribute. And if someone did decide to entirely stack charm for 100 levels, they could only harvest up to coal, only summon up to rat, only alch a few things for lack of being able to havrvest ingredients, only manu up to leather gloves, only potion small mana and health, and craft nothing. Sure they can do any spells for which they would have to buy nearly every ingredient. Yes, this is an extreme case. My point though is that you would be severely limited as to what other exp gaining skills you pursued in order to achieve "invulnerability" to PvP. And if someone did pursue this path, more power to them IMNSHO. [edit]fixed alch statement

I thought about using (in my suggestion) the difference in charm between players multiplied by some factor. That way players of equal charm would be able to "see through" the opponent's guise. I would rather not start out at 50%, just because too many fights would be avoided. Well, yeah, you could. (technically 64 points since you start at 4) Assuming you take no negative perks, you would still have to get to level 64 at a minimum before you are invulnerable to PK. This would also mean that no nexus were picked (unlikely since harvesting minerals and ore is too important for getting spell ingredients) and no phys/coord were chosen (unlikely since these are needed for EMU) and no phys/will (for health points). But yeah, 2% is probably a bit more reasonable. Then if someone really wants to be invulnerable, they can sink 96 pickpoints into vitality or instinct. First, non-PK maps stop everyone from attacking one another. Second, a lot of the current high level characters would take a significantly long time to raise their charm such that this suggestion would be of any use. I know I have ~1million exp to go before my next pickpoint. Yes, you are quite charming Hardcore.

Wow. I am surprised at how well received was my charm cross attribute suggestion. I just thought of an interesting side on the suggestion... beginning PKers could even boost their charm to avoid undesirable high-level PK encounters. Also, my little calculation should probably be fixed. Two people with the same charm should have no additional chance to avoid combat. Therefore, avoidance = (charmA - charmB)*4%. This would make pickpoint selection much more interesting for both PKers and non-PKers. After all, two pretty girls should be able to fight one another. BTW, I was PKed just "playing through" TD once (on wine quest), but I had the forethought to place all my items into storage first. Some bully in full plate, serpent sword, and over 120MP slaughtered my lowly character. Was I surprised? No. Was I upset? Yes. But, I knew what I was getting into by entering the map. Now, I wait for a Peace Day.

What? No props to me? Ingrate.... More seriously, great idea.

Here is an alternate idea that uses an existing, unused game element: your charm level increases your chance of avoiding a fight. So when Mr. Brickhouse PKer (with p/c of 30/30 and charm of 4) tries to attack you (let's say charm of 10), he gets the message, "You reconsider attacking X". Then that PKer cannot attack you for a certain amount of time. Could make the calculation as "reconsider chance" = 3% x charm. Charm could be something like your ability to pursuade. You would have to get a very high charm (34) to avoid all combat. Of course, this would not work on monsters (MM perk for that). [edit] typos

Whitestone, lake at [618,53]. All three rocks in the water partly float. Whitestone, hole in ground next to cliff at [536,38].

That is due to the fire being lit in that location afaik. At least, from what I've observed that seems to be true. If that is the case, then its not a map bug... but again I'm not 100% sure. Regardless, I think this should be fixed. Also, it happens in the Portland General Store, but there is no fire in the fireplace.

Crystal cavern 17,39 the walls do not extend all the way down into the water pool. Still get "Too many sounds." in portland storage (and probably a few other buildings there, but I did not check all). From what I have been told, this is a map problem that has been around for a while. Also, does anyone else have their inventory "Drop All" and "Load" bleed into the inventory boxes?

Have a crack at it. =)

Or a top-down version of EL for psp. That would reduce the processor load quite a bit. But yeah, it would have to be a homebrew hack since I do not think Entropy wants to pay Sony for development fees.

I think this is a gross generalization.... and true.

Exit from EVTR to Irsis (yes I know that map is not done yet) I just see blackness extending into space. The terrain abruptly stops and does not look too professional. EVTR 24,77 and 77,114 gap between rockface and water. In Red Witch cave, an apple and wood log/board are floating near 59,71. Clicking on compass gives "You are in [59,71]" EVTR 49,31 the shadows of objects are well below the ground surface. Same effect noticed in Sedicolis where sand level reaches thigh-height (over near sulfur). I think this has something to do with walking on a height-field.

yay!can you reproduce the problem in other maps, especially C1 (where the music setup would have been more thoroughly tested)? ... oh, and with -DDEBUG you can trigger rain and thunder manually from memory, ctrl+shift+t for thunder, and ctrl+shift+home for start/stop rain (it starts a counter, though, so you'll have to wait 2-3 sec from the keystroke) yay indeed! Some OS X users have been wondering where the sound and music were. Well, thanks for the DEBUG suggestion. The key combinations are correct, and this will save a lot of time for me. However, the banners are throwing a bunch of errors which is making reading the error_log a pain. I reproduced the music problem on C1 by taking the boat from WS to DP. It looks like the docks at both these places have different music. Also DP->PL by land, but not PL->DP by land. WS<->PL has no problems (I have made this trip many times). Does anyone else have their music cutout in these situations? If not, then I guess it is an OS X issue (but not endian since I use a i386 Mac). [edit] Happens PL->DP by land sometimes too. Also noticed, in PL there is a music free zone around the sapphire cave, which might be why WS<->PL does not have an issue. Anyhow.... [edit2] Yup, I edited the map6nf.pll to put a gap at the North DP exit. Music did not fail. Need to learn OpenAL now.... This is getting a bit off topic though. If no one else has an issue, I will have to look into it on my own. I do not have this problem. Tested it while raining and dry. There is a delay and skip before music is turned off, but it does turn off fine. Music turns on fine too and did not effect sound effects. I did not test all your other combinations though.

This scaling looks pretty cool. Can you update your patch on berlios so I can try applying it to the OS X client?

Well, for a VERY long time things were working great. I managed to have sound effects and music running (after a self compile of OpenAL via SubVersion). So, kudos to all of you. Eventually music died when in Palon Vertas. Got "stream_music error: Invalid Operation Last message repeated 2 times" in my error log. Now I need to wait for some rain to determine if it killed sound effects too. Looks like line 632 in sound.c posted the error. The error check then kills music, but it looks like sound effects should be fine. "I COMMAND RAIN!!!!" *0ctane twiddles thumbs and wonders if there is a weather forecast channel* [edit] reproduced the error, but sound effects still work. =) I think the problem might be from trying to stop and start the same music score. The exit from Sedoculis to PV plays the same music as in PV. I noticed some gittering right before music stopped and the error appeared. I need to change the *.pll file to be sure. [edit] problem is the same for both a different *.ogg and when I try the Kusamura exit from PV. Must be some oddity with PV map.

While sound seems to be working for me now (more testing needed) I am getting an error when turning sound off: Error initializing sound: Invalid Enum Value I find this a little odd since it happens when turning sound off but no errors posted when turning it on. I know OS X has some OpenAL issues, but is anyone else seeing this error? BTW, I am using NO_MUSIC flag right now if it makes a difference. [edit 2] I get "Too Many Sounds" at portland storage and portland mayor's house still. Can we get that fixed?

As always, my services for making this work on Macs are available.

Just an update/notice on progress and some other stuff. The sound routines are going through rewrites, so audio is still up in the air. Hopefully the new code by d00hg will be cleaner and allow me to fix our OSX specific problems. Actually, I did trace down the error of persistent rain sound, but no point in fixing code that someone else is overhauling. A game update is soon approaching, and I should be able to quickly get an OSX client out to everyone (unless I am out of town). I have made the game modular using frameworks, so it will be a lot easier to distribute minor OSX updates/fixes between the major game updates. This means you will not have to download 33MB files everytime I fix something. Now, I want to (and so should everyone) thank the early OSX testers: Atlantis, Nibynool, jamincollins, and gizz. I am probably forgetting a few people, but these folks were brave enough to test the early client versions. Thanks to everyone who has helped track bugs. Learner informed me of a OSX specific bug. The code problem, as it turns out, was powerpc related (I was not causing it since my MacBook is i386).

He never said EL programming in the post, but that linked site does mention it. If you want to recruit real EL programmers, you might want to list your accomplishments on your homepage. I am surprised that the tag was even approved. BTW, your site is shameful. Use a spell-checker. Get a host that does not throw pop-ups. Advertising?

I had the same problem at my university. I will likely have to do the whole proxy port thing (or just not play EL while at work). You can also try the test server at port 2001 to really check if it is just port 2001 that is blocked. 2001 still works for me, but that does not do much good for leveling and what-not. I figure the net admins were a little concerned about traffic going to france over port 2000. If the game server was in the US somewhere, I doubt there would have been much of an issue. Never can tell.... ID-10-T geeks and all.

I do not know all the guild politics in the game, but here is my take. (1) The PK guilds have trained themselves to beat the crap out of anyone, while Manu/Alch guilds have not. This means that, yes, while the PK guilds might fight eachother on this map, they have a distinct advantage in getting a guildmember into that mine. (2) PKers can only carry as many s2e as you (probably less due to armor), so they either take the "harvest" of s2e from your corpse and go back to storage (or sell it back to you) or the db bag disappears. Even if they leave the db alone, I am guessing that no one will be able to run fast enough from the underworld back to retrieve it. Or they grab your swords and give them to their guildie harvesting the hydrogenium in (1). The PKers then control the hydrogenium market and make the best armor/weapons for themselves further tightening their grasp on the resource. Oh, the drama. (3) Lag. Lag lag lag lag lag. Let's say that you have 10-20 people (PKers) camping the mine entrance. Guild X decides to make a coordinated assault requiring 40+ guildies to get a few of their best harvesters in there. I hope you all have good network connections. I am sure/hope the novelty of camping this spot will decline, but it sounds like massive concerted assaults might be required. Yeah, how about air and earth essences? Or maybe fox scarves or something else that has no purpose currently. BTW, I thought MrMind was quiting. Too bad RICH cannot manufacture Rostos, right.

I think we are going to run into a problem since a separate group is also modifying the sound code. See this thread.