trollson

165019[/snapback] Actually, nothing I said contradicts that. In fact it implements it quite well.

If there was a larger set of skills, then maybe players could choose which to learn (spending pickpoints, and/or research). Then give an experience bonus for having fewer skills active? But maybe thats another game...

Just been browsing the scamming and market forums... Would it solve a lot of issues to implement an eBay-like service linked to EL? Either through commands, or through a seperate web service (or both). Implementation: elBay login as EL character (if a seperate web service). Items put up for auction moved from the character's storage to a holding area. Similarly, bids are taken (in gold) from bidder's storage to holding area. Losing bids can be returned from holding to normal storage. Transactions resolved at end-of-auction. Observations: Don't need anything like the eBay "feedback score", since all transactions can be guarenteed. Dutch auctions useful for selling bulk quantities. Could impose a small "2.5%" tax on transactions, to take money out of the economy. There must be space in character's normal storage to complete a transaction (otherwise what?). Only storable items can be auctioned off. Pros: Goods and gold must exist for an auction to be placed, and are then 'locked' until auction is over. Quality of goods is authenticated by the EL server; no passing off lesser items. Get a record of the value of goods. Player's don't have to be logged to catch an auction. Cons: Can't barter (gold only payments). But still use face-to-face for bartering. Not very role-playing-ish? Extensions: No reserve prices, system bids minimum automatically, taking unwanted goods out of the game. Update 2006-06-05 as a result of cross reference Implement as a bot ("elBay") within range of storage, and using storage trading (1) (requires special permission). Bidders must have some credit (in gc) with elBay, and must be able to cover 10% of any bid they make. If they do not honor a winning bid within some period (1 RL week) they lose this deposit. No reserve prices; the system (the game) always makes a low bid for any item (cf. NPC purchase prices). Any items bought by the system are removed from the game. Bids are of the form "5 gc each for 50 Thingies" (ie, 250gc total, 25gc deposit), see details below. (1) Store trading was not available when this posting was originally made. The following explaination of auctioning multiple items is paraphrased from eBay:

I assume that Vaea wants the character to be an absolute pacifist? No reason in game terms, but may be due to role-play intentions. Though as described, there isn't any game mechanism to enable or enforce this (closest would be a negative perk to always only defend and disengage).

If the auction was purely through a web interface then there would be a break in the flow of the game for those in full screen. However, an initial implementation could be done through the chat screen (cf. some bot implementations such as MadameYes). Actual implementation would not be as hard as you may think, but would require changes to the EL server to support additional queries (limited to being from trusted sources). Recognising game items should be trivial, since this would only be dealing with game items, it could use their item ID numbers (I am assuming that this is how it works?). There are no "unique" items in game at the moment (are there?), which would require special handling (and probably these would not be storable anyway). Data wise, each player would have a second storage structure, accessible only through the auction service. When they place something up for auction, the quantity of the item is transfered from their normal storage to the auction storage, and an auction record created. When a player bids, their maximum bid in gold is transfered similarly (and is transfered back if they are outbid). When an auction ends, the service would deduct the quantities of item from the seller's auction store, and credit the buyers' normal storage, while doing similar with the buyers' gold to the seller. Unspend bid money is also returned. An auction item would need to record: Seller Character ID. Item Type ID. Quantity. Deadline. Current bid per item. List of winning Bids. where a Bid consists of: Buyer Character ID. Quantity desired. Timestamp. Maximum bid per item. where the list of winning bids is sorted by maximum bid (secondary ordering by time stamp), and truncated where the sum of the quantities equals or exceeds those on offer. The lowest maximum bid then defines the current bit per item in the auction record. Each character would have to have a list of their current auctions (as seller) and bids, for reverse lookup. It would also be interesting to keep a track of the final prices for the various commodities over time... (lunch time over... back to work...)

Missed a couple of pages since this thread started, but has anybody suggested letting the monster pickup the deathbag? If the main objection is newby MM-ers wandering around picking over the remains of failed fighters, then having the beasties carry off the goods would prevent this -- unless the looters choose to take on the critters. For the more intelligent monsters, this would be realistic. For animals, well, it could represent the critter dragging the corpse (and kit) to its lair (a bunny with a horde of gold, now there's a thought...). Death should be inconvenient after all...

Vaea, lets see if a scenario can illustrate what you are looking for. What do you want your character to do when attacked? Abolutely nothing, stand and wait to die? Not currently an option, since the character will respond automatically. Defend and hope to flee? Implemented by holding the "Home" key when attacked, but if the attacker is the aggressor there isn't anything to stop it from re-enaging you. Either way, you will get defence experience, and some attack. Something else?

Maybe that would be the right place. However, it would have to interact with the EL server directly (and securely!) to manage transactions. If auctions could be managed through this interface, then user accounts would have to map to EL character accounts.

Yes, sorry. I wasn't replying to you persay, but to the comment about the historical precedent for auctions (which sparked my curiosity). I was busy at the time, and didn't property explain the context. I don't know what the server implementation is like, but I wouldn't have thought that this would be a huge problem data-wise. Only one additional storage structure would be needed per character, regardless of the number of auctions they are active in (buyer or seller). The purpose of that structure is only to "lock" the assets. A web-frontend to show the current auctions (grouped as per the storage interface?) would be a must, but needn't be interactive (at first), if an in-game command system is used (NPC "Auctioneer" to represent the interface?). This would proved a trusted market area, free from scamming, which I think (IMHO) would be a big advantage. It does not stop any aspect of personal face-to-face (avatar-to-avatar) trading, which would still be necessary for non-storable items. What aspects are out of character with the game? It isn't role-playing directly, but it is a real-world activity which did exist in medieval times (in some form or another). Its consequences on the EL economy would be interesting...

Quick search (unvalidated): History of Auctions

The longest books in history?... Not sure whether 1RP == 1 page is quite the right relationship!

Modify that slightly and it could be a useful concept: If there was a concept of rival/feuding/enemy guilds, then allow guild members to attach members of those enemy guilds. This could open up the concept of limited-PK maps. Non-guild members should not be involved though -- Players need to have the choice as to whether they get involved in these feuding organsations. For a guild master to declare a feud against another guild, a casus belli must exist between them. Otherwise things get arbitary and chaotic. Probably the only factor in-game would be to count guild-vs-guild kills.

I was thinking the other evening about quest/scenario implementation. If there where enough scenarios, it should be possible to have them as one-use/first-come only, assuming a clause for lapsed scenarios: When a stage in the scenario is fulfilled, cancel the "trigger" for fulfilling that stage. If a stage is not completed before some time-out (say, 2 weeks rl), fail the quest and re-instate the previous stages. When reinstating previous stages, allow alternate locatations and triggers. The key here is that only one character can be undertaking a quest at any time. If the quests where minor enough, they could be semi-randomly assembled from stock pieces. ...depending on how quests are described to the server of course...

I like the idea of monoliths, extending the repertoire of map objects in the world. Runic inscriptions would be another feature in there own right; texture which could be applied to the monoliths or other 'stoney' surfaces (cave paintings as well?). Anything after that should be driven in the usual way (?) for quests or interaction with the world (which, IMHO, there is too little of). Character aquires "runic scroll", uses scroll on runic inscriptions, event(s) happens... This of course depends on the appropriate scenario being scripted on the server (the right scroll, the right runes...). I would like to see more interaction with objects in the world. For example, "using" layed out food in Inns and homes should feed the character.

Yes! Thanks, I should have remembered that <_< This approach would be in how characters are rendered rather than in-game configuration of clothing (fashions in EL?). If the base colours chosen for a character on creation are part of the animation information passed to the clients, then armour graphics could contain panels which use these colours, rather than fixed colour. I don't know whether this is feasible with the current or Cal3D (sp?) models?

Not quite that simple :-) (puts on language lawyer hat...) The C standard (and inherited by C++) defines the following integer types (refering to data type sizes): char: == 8 bits. short: >= 16 bits, >= char. int: >= 16 bits, >= short. long: >=32 bits, >= int. long long: >= 64 bits, >= long. unsigned type: == type. The minimum sizes are defined in the requirements for <limits.h>, and the relative sizes by the type conversion requirements (an int must fit within a long). On most 32-bit architectures, int and long are 32 bits, long long may be 64 bits. If writing for portability though, you cannot assume that a type has a particular size (except for char). This is particulary significant since the 64 bit platforms are increasing in number. ...and then there are the endian issues... (Currently dealing with cross platform software...)

How about splitting out specialist weapon skills, additive to the base attack/defense level? There could be specialist skills either for each individual weapon type (including special weapons, "Flaming Tongue of Zog" swords etc), or for weapon classes (all Swords, all Axes). An for unarmed combat of course Specialist skills would have to be enabled by (and/or): Reading rare books. Spending pick points to activate (probably the best option). Requiring high human nexus. (I think that spending pick points alone would be sufficient. Weapon usage already requires human nexus, so that is covered, and the book option doesn't really fit with their existing application) An implimentation would be: Attack level is the sum of the base attack level plus the specialist level for the weapon, if available. If using a weapon without the specialist skill, xp goes to base attack. If using a weapon with the appropriate specialist skill, xp goes to specialist skill. To balance the increased effective attack levels of higher characters, a similar specialisation for defense would be needed. I believe that the effective A/D values would tend towards double their current values for fully developed characters. Client skill list could indent specialist skills appropriates: Attack 10 12345/23456 + Iron Sword 5 1234/ 2345 + Wooden Hammer 3 123/ 234 Defense 10 12345/23456 + Steel Shield 8 2345/ 3456 So, this character armed with an Iron Sword and Steel Shield would have an effective A/D of 15/18. In fact, specialist skills could be extended to other "professions" as a general approach (and to balance out the fighter-centric-ness). Personally, I have nothing against low-level characters being able to use high grade equipment (assuming they have the nexus). How they aquired these expensive items is their good fortune -- for example, inheritance is quite valid (the young son-and-heir of a rich noble wouldn't start with just a tunic would they?!). And letting players buy ($£) items to equip characters should be a source of revenue for EL.

When you create your character, you can choose a certain costume. It seems a shame that this individualism is lost when people put on armour. It is a common image in medieval/fantasy scenes to have people wearing a tunic over their armour, bearing their CoA for instance. Couldn't the graphics be changed so that the colour scheme of your original outfit is reflected in an overtunic? (I forget the correct term for these garbs). This wouldn't require different items types, since its a mod applied when the item is worn.

The problem with using custom font bitmaps is that this method is limited wrt I18N. The font set has already been increased to include some accented characters for other western languages -- but what happens when the community demands support for cyrillic, greek, japanese, or (the biggy) chinese? If I18N support is desired, then EL will have to switch to ttf/freetype and UTF-8 encoding. The colour codes (and other display directives) would be moved to an appropriate block of unicode values reserved for custom use. Font configuration is an issue -- for pre-installated fonts I was refering to OS default fonts (well defined for Windows, maybe detectable or pre-req for linux?). But in anycase defining virtual fonts are the way to go (which would be defined in data files as per java). Is I18N support an intended feature for EL? Should there be a developement thread for it? (I18N is far more that just providing textual translations!)

There is a shortage of [L]GPL compliant unicode fonts. However, you could take a tip from Java's handling; form "virtual" fonts by mapping character ranges and styles to different physical fonts. This does save space, since, for example, western font variants (italic, gothic, etc) may not map to asian character sets (chinese doesn't have an italic form), so an "italic U0002000B" would map to a regular form glyph. As per Java, final configuration can be left upto the installation, using fonts available on the system, rather than necessarily supplying the TTFs. Just checked -- "Code 2000" is shareware, so not suitable. Need to look for UNICODE LGPL projects...

Try linking with the realtime library (librt, -lrt).

Has anyone tried using TTF rendering directly in OpenGL instead of bit mapped fonts? A quick search shows that there are TTF (or freetype) libraries for this. If so, then there are free unicode fonts with large character sets (eg, Code2000). Though this would entail some reinterpretation of the colour defining char values...

That could be how a tracking/hunting skill could be implemented -- increase the range at which one can initiate combat with a creature. There would probably be some pay off between creature "level" and increased range -- can sneak up on a rabbit fairly easily, but a wolf takes greater ability.

2c: The honorific for a female Knight is Dame in the British system. There is also a *rare* hereditory knighthood, for which the prefix is 'Knight'. The next 'rank' up from Knight is Baronet (hereditory), which still uses the same prefix (Sir, Dame). Addendum: Also, AFAIK you are a Knight of a particular Order (Knight of the Garter etc), which would permit some interesting RPG groupings...

Just to get back to the original code snippet: Dir[dc].Names[Dir[dc].nf][i]=temp[i++]; Simplified: f[i] = g[i++]; This is a classic example of undefined behaviour. While the expression 'i++' evaluates to the prior value of 'i', the incrementation of 'i' can occur anywhere between the previous and next sequence points. Therefore, the value of 'i' used on the rhs is undefined. It may produce the desired behaviour under certain sets of conditions (compiler, version, optimisations), but there is no guarentee that it will always do so. Reference: ISO C standard, sections 6.5 (P2), 6.5.2.4 (P2). Reference: Reasonable article on sequence points. Update (observation): My installation of EL (gentoo linux) suffers from the 'missing letters' problem in a lot of the text (not all text windows, just the major ones inc. chat). The symptoms of this are any character in the first column of the font bitmap is rendered as a blank space, and some other characters have slight errors (pixels missing). According to disussion on these forums, a work around is to compile without optimisation. This behaviour is exactly as one would expect from code containing undefined behaviour like this... Particularly since this lookes like an obtuse integer error. Currently I just run a console with 'tail -f .elc/chat.txt' to get around the chat side...