trollson

I'd actually like to see that implemented (discussed before).

Quick thoughts on this, while waiting for things to build [3]: Unbalanced Guilds: It has been discussed that players may migrate towards the stronger of the guilds, resulting on one group dominating. There are ways around this: With 3+ sides, the weaker ally against the stronger. The cost of joining a guild depends on its relative strength. So rather than have a permanent state of mutual warfare, the relations shift between allied/peace/war, so long as each WarParty is at war with at least one other [1]. You need to come up with a reasonable metric for "strength". A sum across participants, possibly of PK Points, which can go down as well as up, even with a fixed population. Roleplay Aspect: It would be a shame if this ends up disconnected from the background of the game world. The Warlords (GM 'Bots) should represent something in the game world -- place them in different seats of power (castles, forts, etc) throughout the land, weave them in as personalities. So you have to walk across a few maps to sign up... how lazy are folk now? Camping Out the Warlord: Something to discourage one side from camping out near the GM of another side, and smegging or scaring off new recruits? Make the GM'bots similar to blessed Guardbots, able to move within their "HQ" area and free to attack members of an enemy guild. Unlike Guildmap Guardbots, they are not 'red flagged' of course, so cannot attack anyone. Actually, attacking and killing the GM'bot would be possiblity as it stands, unless they remain pacifist; but who'd follow a Warlord like that? Guild Ranks Can you make some use of guild ranks. While there are limits -- members can never recruit or promote for instance -- some 'promotion' for long-serving participants would be good, though what practical implications could there be? I didn't notice Learner's rank commands -- so ranks are buyable. [1] All rather "1984" ... the goal is not to win the war but to continue it. [2] [3] Started builds around midday. The Solaris/SPARC server & client built hours ago. Windows client build started at the same time, same codebase, and is still going at 1900... This is normal sadly, Windows is incredibly slow if you are building anything complex...

For collecting bones from newbies on Isle Prima, a Merchant NPC might be an interesting approach ("game" owned rather than guild owned).

To encourage newbies on Isle Prima to earn money by collecting and selling bones, it would really require a character to hang around near the beam and announce that they are buying bones. They would also have to explain how to trade etc. This would get newbies familier with making money from trade, and they'd probably sell their bones for 1gc.

Example screen shot (too large to display) I'm curious; I don't see how this will solve the issue shown in the screenshot; the water isn't being extended where land tiles edge the map. Extending land tiles wouldn't give a satisfactory result. Unlike a uniform water area, featureless land would look artificial, and the boundary between extended tile types would be unnatural straight lines. The only way I can think of [1] is to 'steal' the edge of adjacent maps, assuming they are registered correctly onto the global map. This would look good, but involves a lot of changes. [1] Well, there are other ways, but probably not for this project...

I think Florian meant that bags are/can-be visible from a greater range than actors at the same location.

Since you can eat bones while under food cool down, you should always be eating some form of normal food and just supplementing it with bones. Stretches the hard stuff much further. I would have expected that bone-collecting would be a worthwhile pursuit for low level characters; how many bones are left to rot on Isle Prima by newbies? Rather than adding more bones to high level creatures, for the benefit of high level fighters, perhaps more emphasis on getting newbies to collect and sell the bones from little critters -- after all, which would you prefer, rabbit bones or skeleton bones?

This is a good idea, and an interesting one as well. Lunch time musings... If no NPCs exchange platinum (pc) and gold coins (gc) any more, there is no fixed exchange rate [3]. The value of a pc in gc (and visa versa) depends on the "strength" of the EL game economy vs the affluence of the players. If any items traded by NPCs for platinum are also traded for gold by another NPC, this would create a min or max to any exchange rate. This is bad and never ends well (see "Black Wednesday"). Gold coinage can be removed from the game, when necessary, by auctioning off limited sets of Platinum coins [4]. There is no need to sell any other non-RL item in the EL shop other than Platinum coins. Game services (guild maps, bot fees, custom clothes, P2P) could be paid in pc within the game -- but where there is a RL service associated with the in-game purchase, issue a receipt by, at least, email [1]. This lets players without access to RL money/PayPal exchange in-game effort for P2P benefits. Do not offer to buy back pc for RL currency, even for a lesser amount. It would just encourage play-for-profit, and would get messy. Finally, it should be possible to automate the process at some point -- automatically crediting a character account when a payment is made by, say, PayPal [2]... ...so Entropy can just sit back and let the money roll in. Its not a bad business model. [1] Requires an email address to be registered with a character. This has other uses as well, but need not be compulsory. [2] Requires that the PayPal depositor can be associated with a character of course. Multi-play would then have to be permitted for the exchange of pcs at least. [3] I discussed the topic of separate economies for different currencies in the last platinum piece thread. [4] But there are better ways to remove gc from the economy; expensive items only remove gc from rich characters, and only if they are interested in the item. I auto-charge on boat travel etc of a few pennies could raise quite a bit.

As ville-v said, this has been discussed a number of times. In addition to macro'ing, it can be rather inconvenient to have bags opening automatically and blocking your view, especially when there may be more critical things you need to be paying attention to... As for using the bodies instead of bags -- you can select creature & animal bodies ("you can't fight dead entities" etc). There are interesting possiblities for this: You are searching the corpse or skinning the carcass to get the best parts. Could be a skill or attribute test -- the better the result, the better the find [1]. This has been discussed before under "skinning" and "hunting" (search), and could encourage team work if there was an advantage in having a specialist searcher (thief, rogue, hunter, etc). Death/drop bags generated when the corpse vanishes. The value of items in drop bags would be less if the better finds can be recovered from the body of course. Characters don't leave corpses. Maybe they should? You have to hang around as a disembodied entity until you "respawn" in the underworld, after some appropriate time. Makes death a bit less trivial, and means you get to see and hear your killer dance on your grave. But this opens up some new possibilities:"speak with dead" spell could allow characters to speak with recently departed. The dead cannot speak until respawned (all outgoing messages blocked or perhaps redirected to a "I hear dead people" channel). "raise dead" spell, could be cast while the body is still fresh, brings you back to life. Also applies to other entities of course [2]. How would searching a body interact with Rostogol stones? Items are recovered from the deceased's inventory before the death bag is formed (though deathbags would be reduced to compensate). Weakens the effect of the stones. Boobytrap in your rucksack! Carry a trap, if it is recovered by a body search it inflicts damage. If items recovered from the body, and items in death bags are separated, then there is no new state information. All you are adding is a "use corpse" action, and delaying the death bag generation until the body is removed from the game. [1] All "special" finds would have to be recovered from the body. Anything left in a bag afterwards would be mundane items only. [2] Keep raising & killing a monster till you get the special drop? Can be designed to avoid this.

Fine tribute from "Penny Arcade" E. Gary Gygax, the co-creator of Dungeons & Dragons, died aged 69 yesterday, 4 March 2008. Without him we would have no RPG or MMORPGs nowadays. The Registry has a nice thematic summary of the news. In the news: The Registry Associated Press Wikipedia BBC News E. Gary Gygax as he appeared in Futurama, second from right In a curiously twist of fate, the 4 March has been known as "GM's Day" in certain circles for several years (see "Daily Illuminator", Steve Jackson Games). I guess that this will cement that date now. (this may be worthy of being moved to General)

Having the application name *following* the context description (document name or in this case character name) good practice in GUI design, which has been pretty well adopted in the last decade or so. The reason for this arrangement is obvious when you consider what happens when a running application is minimised, or has an entry in the task bar; the window title is used as the label on the task bar entry, which can be truncated when the bar becomes crowded. When application names were ordered first, you'd see a lot of identical entries (eg, "[Word...][Word...][Word...]") and finding the correct one to switch to was a pain. Having the context description first keeps truncated task bar entries distinguishable for longer as the task bar becomes crowded.

Exactly what I've always thought. This would improve gameplay in the long run, even if people would inevitably complain that they like standing in one place and being fed critters. Even underground spawns could covered more than one room. It would be possible for a creature to only respawn if it is out of view of any player character, though this still would still need a wider area as well.

Cut out the middle man and just have "Experience Stones". Actually, "experience stones" would make good prizes for quests & competitions, so don't read this as just an absurdity -- don't presume how they would be obtained either. The economy is experienced based, so it would be interesting to see how much the market would value such items.

The OP is a good idea; though I'd see this as a candidate to be implemented as a 'bot rather than server-side -- no issues of loading the server with unnecessary AI (even running the bot on the server as a separate process has advantages). Some actions may require the client-server protocol to be extended; that leads to clients having permissions on protocol sets. This can be designed quite simply, and would open up a lot of possibilities for different types of client. With an extended segmented protocol, all creatures, monsters, & NPCs could be farmed off to specialised client processes, leaving the server to just get on with administering their interactions.

Gravity is low, you can carry more but you also have to hold onto things; bags are easily dispersed ("float off"), and the time at which they go "poof" becomes random.

Need this be much worse than being AFK outside when there is acid rain? The bigger problem then is balance between characters of different levels & health. Acid rain gives small continual damage. A lightening strike would be rare event but deal a non-trivial amount of damage, which could wipe out a newbie. One option is to do proportional damage. Another is to have alternate forms of damage, with lightening strike affecting attribute values instead of health (far more use could be made of this type of effect, since the game already manages attribute recover).

Very very expensive to perform ray tracing for every actor pair in range, compared to simple distance tests (with perception modifiers). This has to be done server side, and there is a reason why FPS games don't scale to MMO-sizes.

Warning: This post contains content which may be disturbing to those of a non-technical disposition. This post describes a general approach or implementation to allow static map objects to be 'used'. It relates closely to the "Interacting with the Map" thread. Goal I want to be able to make more use of the static objects which litter EL's world. At the moment there is very little interaction between characters and these objects, which serve as just eye candy or obstacles to be walked around. I would like to use a forge to help my Swordsmith, or use a bed when I log off so I can start the next session fresh and healthy. Implementation When a character 'uses' a static map object (clicks on it with the 'use' icon), a field in their character record is updated to record the object selected (map object id) and their location. Think of this as another inventory or equipment slot. When a character performs a task which requires or benefits from the use of a static object of some type, this field is checked for: The selected map object, if any, is of the correct type. That the character is still in the same location. If this test fails, then the selected object field is cleared. If it passes, it is as-if the character was using, say, the forge object as a tool. The selected object field is only updated when a character selects an item, or when it is checked for a task. We don't need the server to keep testing that the character is still in range of the object every time they move for instance. We don't even care if they have moved away and back since selecting it. Applications Static tools: Recipes already require certain tools to be in a character's inventory for the product to be made. They could also require that a static tool be used, which would check the selected object when attempted. There are plenty of examples across the maps -- forges, mills, ovens and stoves, anvils, fountains, etc... Augmenting Items: Having an object selected may modify an effect when it is applied to the character. A shield spell may give a greater bonus if case when the character is "touching" (selected) some defensive object. Magical spell effects may be modified by different "magical" or mundane objects -- this could be quite extensive. Bed Time: Perform a selected object check on login (before the actor is placed and possibly relocated); if the character has selected a bed restore health and mana according to how long the character was logged off, less their equipped emu. Reward players for role playing, and putting their characters to bed, rather than sitting out in the rain all night. Encourages people to frequent Inns. Notes The character selects a specific object, even though tests require an object type . If a character selects the forge at A , but then walks to a different forge at B , a test will fail because it is not the forge they said they where using. When we record the selected object, I've left it vague as to the actual numbers to be recorded. We certainly need the map object id , from which we can obtain the object type and either the object location or character location . Recording object location we allow a character to be within range (1.5m or 3 squares) of the selected object to continue to use it. Recording character location requires the character to stand in exactly the same location -- lower runtime overhead but more restrictive. If we don't also record which map that the selection was made on, we must clear the selected object on a map change. Consider "special events" that could be divined and sought out: "A major conjunction will occur over location A at time T, which improve the chances to make something special at a forge nearby." [1] This approach can coexist with other more direct applications of "use" with a map object. "map id" just identifies the map. Presumably this is just an integer (it need not be more). "object id" is the index of the object within the map. Each map has an array of object records. The record then identifies the 3D model of the object, and its location (amongst other things). "object type" is given by the 3D model of the object, where several different models can have the same "type" . This requires a lookup table to associate object model with object type. From the above I prefer recording just the map and object id of the selected object. From this all other necessary information can be derived when the selection is queried. This approach has a lot of potential applications, of which I have mentioned only a few examples. It would give reasons to visit a more diverse set of locations. [1] This is what I hoped the astrology system would give us.

Whenever this is implemented, one observation or check (since my original reading could be wrong...): On a merchant, you can set a quantity for any item, which related to buy/sell limit. From what I read at the time, it seemed that this was a lower stock limit related to selling; ie, the merchant would only sell the item when their stock was above that level. Now, there may be uses for this, but after over a year of painstaking stock management on Dacia, we never had any use for it. However, what would be *essential* when the merchants start buying goods, is an upper stock limit; ie, they won't buy if their stock exceeds this amount. In fact, it would be difficult to run a business through a merchant if their buying was unlimited! ...and a less tedious way to get stock listings from the merchants, while we are here. ...and a fresh cup of tea please.

The map maker just chooses from a palette of 3D models, in which there can be a few variations on the same object type. This is why I make a distinction between the model and object type in the design -- making the table that maps models to types is a prerequisit of this implementation. Adding to this palette, even just making a copy of an object under a different name, is not the role of the map maker, as this new object has to be included in the distribution. But yes, if there where "forge1" and "forge2" models, they could be placed in different object types; but any map maker could then use either model, and the two would be different throughout the world. Don't forget that there is always scripting to handle special circumstances, which could superceed normal behaviour in a particular instance.

Most of kailomonkey's suggestions are quite valid, but I'll highlight one point which could cause a headache: What we should avoid is adding information to the existing maps; if two forges have different properties, then that information would need to be added somewhere, which is expensive. I am trying to find ways to use map objects only using what information we already have, or global information (for example, a table mapping each 3D object model to an object type). Other that that, some of what kailomoney suggests could be implemented using hotspots, some of which could be (semi-) perminant.

Maybe the same thing when you reset with alot of stuff in inv?(cough)Thats the point -- being overloaded has the same effect as being fully loaded. If this becomes a more regular occurance then more attention should be made to handling this situation. Resets were not intended to be a regular part of the game, but seem to have become one (to the detriment of the game IHMO).

Well, the implementation is about as cheap as you can make it: Record which map object a character uses ("selected object"). API to get the selected object type, if valid. API to clear selected object (optional, but reduces overhead of 2). Then you can start to use the stuff on the maps, and you will find uses for this. The suggested applications are just a few examples, not a definitive list. A test for "selected object is of type..." could be used in many contexts, including scripting. The "Bed Time" isn't meant to compete with other healing effects (though that of course depends on how strongly it is implemented). It as a slight effect, encouraging RP behaviour, and should be trivial to implement if the framework is in place. Lots of slight effects working together can make a richer environment. Can you think of another game reason for the beds in the taverns?... ...no, that would require new animations! I know of the static tools discussions from a couple of years ago, and was wondering if these where ever going to make an appearance. This is why I made this post for a minimum-effort enabling framework. Static tools need not change anything already in the game; reserve them for newer items, or alternate recipes for existing items, if there is a problem with riots. Static tools can also be augmenting items; a recipe could have an optional static tool, which if used increased the characters effective level when making that item -- so its a lot easier to make that sword if you are using a forge or anvil. Deciding what items would benefit from what static tools, and how much, is a design & balance issue. The use of augmenting items during a battle was prompted from "KF forts" thread, which bemoaned that PK areas where only populated near the entrances. Now, this doesn't solve that issue, but does give a means for terrain and features to become relevant in a fight (though it would be more interesting if characters moved while fighting). Hot Spots One thing I didn't mention in the OP, because it requires another component to be implemented, is to combine augment items with transient "hot spots". There would be an interesting game in finding (predicting or detecting) these "hot spots", travelling to their area, and finding an appropriate item to channel their effect. Here, a "hot spot" gives a time and place, and a type of effect. Using a static object in some task, near that location and time gives a proportional chance of channelling the effect. Hot spots may arise from invasions, astrological conjunctions, natural events, etc. If you want make it a race, then the hot spot vanished once somebody successfully channels the effect (uses up its power). ...All purposefully vague to let you map it to different scenarios. 2008-01-22: Hot Spot Implementation Requirements Since hotspot idea could work quite well with using map objects, I'll elaborate a bit on what is needed to implement this. Allocate space for a few (say 5) hot spot records for each map. Each record need only be a few integers long, consisting of: type of hotspot -- only one of each type per map. When checking if a hotspot applies, this is what is checked for. A type of zero (0) is no-hotspot. position (x,y) -- the centre of the hot spot. The effectiveness of a hotspot decreases the further away from its centre you are. time of occurrence -- a time stamp when the hotspot is at maximum effect. The effectiveness of the hotspot decreases as the difference between current time and occurrence time increases. A time stamp of zero (0) can be used to indicate a permanent hotspot. strength -- how this is interpreted may depend on the hotspot's type. That could be as little as 12 bytes per record, or 60 per map for 5 records. API calls are required to set, check, and cancel a hotspot: Set a hotspot either updates an existing hotspot of the same type, or uses an empty record, or fails if all records are used. Check a hotspot returns the effective strength of any hotspot of that type for a position and current time. Cancel a hotspot sets a record with matching type to type=0, unless it is permanent. Cancelling a permanent hotspot should require an explicit call.

0.5 rounding to 1.0 is the conventional rounding rules for nearest integer. 0.5 rounds to 0.0 with simple integer division, as this drops the fraction. However, don't assume that EMU is equivalent to MASS; it has to factor in other encumbering aspects, bulk and fragility for instance. So it is perfectly justifiable to have different rounding rules for EMU and FOOD.

Characters may end the day overloaded, which (AFAIK) just has the same effect as being fully loaded (cf. resets). If there was some effective penalty to being overloaded, then it could be a more interesting risk in the game.