Jump to content
Eternal Lands Official Forums

trollson

Members
  • Content count

    1259
  • Joined

  • Last visited

About trollson

  • Rank
    Puma
  • Birthday 04/14/1966

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Hampshire, UK
  • Interests
    40 yrs RPG & Wargames,
    Former Senior Scientist (MOD, 1990-2000),
    Scientific Software (25 yrs).
  1. My EL Character Will Soon be 10 Years Old

    Ohh congrats on the success Mr Mind! I seriously look forward to reading your paper.
  2. Link to topic discussing map interactions in my sig.
  3. Translate NPCs

    To acquire a complete decrypted set of strings somebody would have to play through the quest, at which point they can just publish a quest walk-through as already happens. But even if you had a decrypted string table - what information does it give you? You don't know the context in which the string would appear in the game - where? from whom? or in what situation? Variable or non-translatable elements (or proper names[1]) wouldn't appear in the strings in the string table - but be included in the server message as substitution tokens (cf. printf format string). A separate encryption seed would be used for each string. I'd use a RNG which generates an uncorrelated bit stream, and XOR the stream with the string to encrypt and decrypt. This is a low cost operation (negligible compared to the other operations that the client has to do). The encrypted string is then a series of uncorrelated bits, which does not contain any information other than its length (which can be obscurated by padding). [1] Proper names sent as substitution tokens could still be translated separately using another translation map - in fact, if this was intended, then in-game names (of items, NPCs, places, etc) could be sent as an index rather than a string.
  4. Translate NPCs

    As bad or worse as storing the info in plain text (ignoring the update problem which was one argument against client side texts). The client is open source, so everyone can get the source code. From there, it's very easy to modify the code so that it gives you the seeds If your client has received the seed to decrypt the string, then you can legitimately see the decoded text anyway. The string table would be part of the downloadable game content, to permit updates and new translations. Since it is periodically updated anyway, the encryption seeds would only have a valid lifetime of that release of the string table. You need to decide what weight you give to data security, verses supporting an international player community.
  5. Translate NPCs

    Encrypt your client-side string table. Instead of the server sending the string, it sends the string id, decrypt key or seed, and field text for insertion.
  6. Chain Armors

    ...except that statement has it the wrong way around, as I explained later in that thread.
  7. Harvest level and mini-events

    Why not just let 'experience' harvests be mini-event free? Initially thought that would be interesting (even the absolute harvest limit). However, if I was a farmer I'd just build ten characters in place of one, and cycle through them (still only needing one logged in at a time...). An MMORPG really needs to be designed from scratch to avoid the problem of farmers -- and that mainly means no character advancement through grind (in wealth or experience) which the farmers can exploit.
  8. Sigil price adjustments

    Why not just modify the price for any sigil by how many the character already has? Say that it becomes more difficult to "teach" a sigil as you learn more. This could also give a reason to have a "unlearn" option. Although, I think that Entropy was intending to replace the sigil magic system with separate spells. That would be a shame, as the sigil could be developed to give a very flexible and imaginative system...
  9. 1v1 arena to the death

    Most relevant previous discussion I recall would be the "Duel feature implementation" topic. For the system to support duelling, I would favour reusing the "trade" window. This would allow the players to accept a duel, as well as placing a stake on the outcome (which would be removed to a "safe place" if the challenge is accepted). Of course, fleeing would count as losing the fight.
  10. More realism - rotting items

    Most items, if stored correctly, will last longer than we would care to account for; and I would presume that the storage company know how to do this. Flowers etc intended for alchemical use could be dried and stored for a long time. It is only some food stuffs that would be subject to decay (especially raw meat), and it would be simpler to make these non-storable. However, who is to say that the apple you deposited on C1 is the same apple to withdraw on C2? You could assume that storage worked more like a bank, since there are no unique items. On the other hand, if this was implemented, it would have to be based on player-time, not game time, to allow for occasional players. Each storage slot as a time-stamp for last-access, and when accessed the time difference is used in a half-life calculation and applied to the quantity in storage, before any transaction. Apply this as a binomial random number rather than a flat percentage avoids a no-risk situation from frequent access.
  11. Depletable Resources Poll

    Depleteable resources are good iff implemented fairly. I've voted "yes", but implementation needs careful thought. Consider using a "depletion level" rather than fixed quotas for each resource. Each resource site has a "depletion level" and "timestamp". The "depletion level" adds to the difficulty of harvesting that resource, so harvest yields per hour decrease as the depletion gets worse, but never actually run out. Storing a "timestamp" allows the resource to be restocked when harvest attempts are made, rather than having a background task update unvisited resources. Illustrated through the fine art of pseudo code: on harvest attempt: if current time > timestamp decrease depletion level (current time - timestamp) if depletion level decreased timestamp = current time + offset endif endif make harvest attempt (skill level vs resource level+depletion level) if harvest successful increase depletion level endif end harvest attempt You can then choose how the depletion level gets increased/decreases (I'd suggest an exponential decay as the decrease, with a half-life dependant on the resource type). The time "offset" is an optimisation to avoid calling decrease depletion too often. With this approach, for any group of harvesters around a single resource there is a point at which the rate of depletion is balanced by the rate of recovery. For a single low level harvester, this could be a profitable level, but for a crowd around the lupines it would unprofitable. (This implementation costs two integers per resource.)
  12. Useless Books

    Firstly option: Books which can be bought from an NPC could be sold to that NPC to remove them from the game. Though this releases more gold into the economy. Second option: Books could be used as optional ingredients to related recipes, which, say, increase the change of producing an enhanced item. This would use up surplus books, raise their market price, and consequently reducing the number of new characters who read the book. There would be a marginal increase in the number of enhanced items, which would depend on modified applied for each book added to the recipe. Whether you want to separate books which can be bought, from books which can be added to a recipe would be a balancing decision. Buying books to increase your chance of making an enhanced item would then be another gold sink to balance those being sold back to the NPCs. Not every item has an enhanced (or mod'able) form, but I've always thought that they should (mod'able leather pants!)...
  13. Augmented armor

    That option was discussed when Augmented Armour was being designed, and rejected. Augmented Armour occupies a particular niche of cheap-and-disposable, strong-but-short-lived.
  14. Summoning

    The summoning skill went into the creation of the stones, not the use of them, so no experience from "stoned" creatures! Conversely, directly summoning creatures, if their actions gave summoning experience, would mean summon-and-use could be a better source of experience than making stones. I guess that a perception bonus would apply for "stoned" creatures, though I think there should be some test-of-will if you use a stone to summon a creature that is too powerful for you to control...
  15. Summoning

    Quick tuppence of thoughts: Let summoned creatures increase your perception range - you are aware of what your creatures can see - useful now we have limited perception and ranging. Limitations still apply however. Let experience earned by your summoned creatures go to your Summoning skill - previously suggested and rejected, but I still think its a viable option.
×