trollson

On the other hand, if the value of the creature (in experience and drops) increased as it grew older, maybe fighers would hold off attacking the younger versions of their own accord?

zero'ing current attributes and having a gradual recovery would work well. It would be difficult to speed up, and make characters take a time out (provided they have food!). Zeroing nexuses could be problematic, since characters may end up wearing items they do not have the (current) nexus to use.

Multiple levels of 'underworld' -- if you die in one, you decend to the next level down. Throw in a few demons prowling around to spice things up... There could even be things on the lower levels which are worth trying to get to. Though you could easily discourage players if it was too hard to get out of Heck.

Probably not hard, but a fair amount of work. There would need to be 3D models for each life-stage of each creature (at a minimum young, adult, old), so thats 3 times the number of animal models currently in the game.

This would introduce a big parsing headache. Consider for example the PM: /Lord Vermor Castle Should this send "Castle" to "Lord Vermor", "Vermor Castle" to "Lord", or an empty PM to "Lord Vermor Castle"? The client has no way to know, and the server would have to search for all possible combinations (which could be ambiguous). It would be pretty trivial to replace underscore ('_') with a space in the name displayed above a character -- but could lead to confusion if people try to use the name verbatim in PMs. On a side note - it would have been nice to reserve name prefixes like "Lord", "Sir", "King" etc as titles which could be earned in-game. So if you saw "King Kong" then you would know he was an important character, and not just some monkey

Thats elcoholics

If they are on the same IP it will be the MAC of the NAT device thats seen externally, so that wouldn't help. MAC addresses can be set on some devices (firewall routes, VMWare, probably on linux?). Can't think of a solution to this with an open source client -- the only thing you can control/define is the protocol.

Could we have some different models for peasants and townsfolk, rather than just reusing the character models? Some peasent girls in dresses, serving in taverns or carrying baskets. Town guards in surcoats with the town coat of arms emblazened. Beggars in rags. Rich fat merchants. Blacksmith in leather apron. ...etc... Or increase the number of body types and clothe types available to characters to give more variety throughout.

This game isn't just about fighting, so for balance we really need animations for the other activities. It may add atmosphere to see what other characters around you are doing, rather than just a lot of folk standing or sitting around. It would help spot bagjumpers lurking in the mines for instance. It is suspicious (and somewhat threatening) to see a character standing around near a bag party. If we knew that they were actually mining or doing something it would ease tensions. A sleeping animation for no-activity and AFK would be nice to see as well. If we could then step over sleepers it would avoid some blocking problems. Mining and harvesting should be conductable standing or sitting (though crouching is a good compromise). Maybe a high and low target animation? As Placid says, the character can turn to face the deposite, there wouldn't be as much pick-ax-in-the-face as you might expect. Though the mining range would probably be decreased to fit the animations, which may cause conjestion at the ore-face. Would you have to put away your weapons to harvest (veg, fruit, flowers)? If the animation for these used hand actions to gather the crop, then still having a sword in hand would just look like eco-vandalism!

Non-alchololic during daylight, but then... Whisky, without the 'e', single malts only, and no ice! Real Ale and Beer - those that don't need to be chilled to disguise lack of or foul taste. Lager only if its from Europe. Cold cider on hot days (exception to the daylight rule). Sake with Japanese food, warmed to body temperature is a very pleasant way to get drunk. Put some Zatoichi or Lone Wolf and Cub DVD on for atmosphere. Red wine, never touch white. Frozen Black Irish - ice, vanilla ice cream, kahlua, baileys, vodka (?), blended together.

Ah, if the server had a published API and loadable modules for items (dlload() etc) then this would be easy ...though Entropy would be swamped by every c-hack gamer

Yes, to summoning. The experience would be being earned through application of the summong skill, through the summoner's control of the summoned, so should go there.

If you have summoned creatures, and you click to attack a target, give the summoned the precedent to attack rather than the character. Assuming that if you have summoned creatures, you want to use them (and there isn't much use for them other than to attack, apart from annoy people outside of storage). If the summoner is now controlling the summoned, maybe its worth revisiting the suggestion that they get some portion of any experience earned by their critters -- experience for application rather than purely repetition, reduce the experience for the actual summoning (except for very minor creatures).

I see the same negative-shadows since I u/g to Nvidia kernel/gl on gentoo. Only seem to see it in Portland in the rain. Very pronounced.

Has anyone solved this issue already? My new set up now has my Linux box, with a dual head nvidia driving two monitors -- a 17" and a 15" LCD, as seperate servers (:0.0 and :0.1 respectively). I don't want to use Xinimera, I am happy with two seperate displays. I would like to run EL in full screen on the 15" (1024x768), while I work on the main 17". However, EL in fullscreen mode captures the mouse, and I cannot get to the main desktop without first reverting to a windowed mode. I have tried binding an applet 'dualmouse' (from the dual monitor article on the Gentoo Wiki) to a key combination (<CTRL><ALT>z). This allows the mouse to jump between displays from the keyboard, and works as expected under normal circumstances. But, sadly, this doesn't appear to work when EL is running full screen mode! Configuration: Gentoo Linux 2.6.12, dual Athlon MP 1900+, 1GB. Nvidia GeForce FX 5700, 256MB, Displays 17" (1280x1024-32), 15" (1024x768-32). Gnome desktop, metacity.

Windowed mode -- thats what I have set up now. EL running in "1024x768" (actually slightly less in windowed mode) on the 15", leaving the larger 17" for all other applications. Works well enough. Also disabled sound in el.ini to let me play my own music

Melee weapons come in a huge variety of forms and variations, with a broad cross-over in names, such as mace, morning star, and flail being used interchangable in some contexts. That WOW had this is really irrelevant -- real life had it first, and that is a far richer background to pluck ideas from. Not that this will be implemented though. Could this be done as a monster invasion? Though it would be good to see some various human (dwarf, elf, etc) models used in the role (pirate, bandits, soldiers bearing a coat-of-arms etc).

Blender Video Tutorials (other tutorials linked from there) Working with Blender will take some time to master, but its free, and a very valuable skill to have

Download 'blender' and have a play, maybe you will find a hidden talent ;-)

Well, if a 3D model is made for a Scorpion, there is little work in having monster and creature (giant and small) versions.

I'm not pro/con on this yet, but some thoughts anyway... I don't think that it would stop the parties, since these involve a lot of activities other than muleing. Keep the pack animals capacity to reasonable limits, say upto 1000. Characters can reach these limits by themselves. Loading and unloading the mule will take time, and go via the character's carrying capacity. Mules should not just add to the characters cap. Mules are fair game targets, for monsters and animals (no MM for them!), and for other players (as with summoned creatures). If they die, what they were carrying goes into their deathbag. If their former owner recovers the bag, there is still the problem of getting it all back to storage!

On precedent: I'm pretty sure Giant Scorpions were around in the early D&D Monster Manual et al (c.1980) -- just about "Giant Anything" was there (and just about any monster suggestion since!). My copy is packed away so I cannot check, but I'll make a point of getting a PDF copy for reference. Before that, I vaguely recall seeing a hero fight a giant scorpion in a 60s movie, but no idea which or what so cannot be adamant.

Pack animals are interesting idea, but it would probably be better to introduce actual mules and donkeys, or else we'll just look like asses...

Should the new continent come with a seperate storage? Soon you will go to explore new lands , encounter new creatures and new NPCs , to bravely go where no character has gone before... ...and still pop into the local store and pick up that special item you depositied back in Desert Pines? Doesn't this seem just a bit too convenient? The new continent should come with a new storage. Goods you deposite in Seridia should not be present in the Irrilion storage. You should start afresh there, with your wits, skills, and what you can carry. Sure, you can carry stuff from Seridia to Irrilion, but I would hope that the journey is not as simple as hopping on the local boat from Lakeside to Portland! Some of you may dislike this because it is inconvenient :shame: Exploring and exploiting new lands should not be easy, and this would give some characters a chance to act as proper traders, transporting items and commodities found only on one continent. Addendum: For those with a dislike of manual labour, there could be an export option added to the storage interface, to transfer goods between continents. Such an option would incur a shipping charge (prices by weight), and/or a 1 game day delay to represent transport.

The server must know which summons belong to which character, and since the summoned creatures can attack it shouldn't be much of a problem to iterate through them and have them attach the named target, if in range, or move towards them. To have them queue up to attach the named target maybe more work, as the command would have to be saved, and the targetting repeated -- probably as part of the summoned movement routine (they already tend to follow their summoner, so there must be specifc coding for them). A problem with the '#attack <name>' command is that mister 'no-one' is going to be impervious, while mister 'Rabbit' will feel victimised... What if when the summoner selects to attack a target (using the 'flaming fist' icon), this sets the target for the summoned? I originally thought this was what happened when I was summoning rats and hunting rabbits