Enola

Members
  • Content Count

    960
  • Joined

  • Last visited

Everything posted by Enola

  1. Personally, I'd prefer the thicker walls, even if they wouldn't be walkable for the time being.
  2. Actually, uniques follow a different code for crowding, which was 10 max, and Rolf changed it to 20 to make it more fair. Don't say he wont change anything. Indeed. Even though it was crowded, 10 people could still attack (which didn't help much, because those who could attack got switched around constantly).
  3. Besides, didn't Rolf mention that when improving something, you only get the chance for it to turn rare if the rare material is used up in the process? Combining materials you cannot seperate anymore seems counterproductive for this one.
  4. People like Buddha already publish their tools for everyone to use (See wplanner and wurm army knife). Of course, a dedicated sections sounds like a good idea for me, but you cannot force everyone to release what they've done. Some people only produce rather "unpretty" tools that need some maintenance user-side to get them to work, which would be unsuitable for release. They'd have to pretty them up and support them, so they'd run for everyone who wants to download them. What if I were to release a highly complicated command line tool that has several things hardcoded (for ease of creation) that only runs on my setup? You could use it, but you really can't. Jealousy might tell you that it's an easy-button, but it isn't. First, there's some work involved to create the tool. Then, there's some work involved to refine it. And lastly, you're highly limited with what you even can achieve. Basically, the most you can do with one of those tools that accesses client data is reading the log files and displaying and calculating some things.
  5. The thing is, the event log is outside the client. It's just a normal text file that's regularly updated. You can easily read it with a text-editor (that's actually what the log files are there for). And tools have been created for Wurm for a long time already, without any problems (as long as they don't mess with the files or the data stream). Combining these two parts is just the next step. I wouldn't consider that "walking the line" as either of those alone already isn't a problem at all. Why should then the combination of them be?
  6. Those people belong to noone. They can go whereever they want to go. Freedom is just split into several servers because that's easier on the hardware and easier to manage. And neither you nor this ominous "CA" can force anyone to leave or stay. It's legimitate and should stay that way. What are you afraid of anyways? At most half a dozen people will even consider moving over there. That wouldn't even put a tiny dent into the graph.
  7. It's a .gif. Those only support 256 colors, thus you get that kind of appearence if you try to save something which shows more colors than the gif can handle. //edit: If it was for me, you should remove the texture scaling of the bars. That's what causes the weird "stretching".
  8. Just because they hide from you, doesn't mean they exist Our alliance is filled with 'em (poor Tealc )
  9. It's always refreshing to see people who can muster up the courage and admit they've been in the wrong.
  10. Schrödinger's gnome.
  11. Even if this gets implemented that people cannot store away loot anymore via merchants, they'll just find another way :/
  12. Not true in the least. Iirc there are 6 or fewer programmers/coders/devs on the forum. depends on the context of this i reckon.. as to actual Wurm Dev's there's 5 iirc. As to actual IRL 'programmers' there's 8-10 in just staff alone and i know at least another 5 players who are coders as well. Make that 6 players. I am a C#, .NET, SQL developer by profession. Make it 7, then. PHP/MySQL, Flash and JavaScript at work; C++, Java and Python as a hobby.
  13. You will have to connect to the servers, if this idea will ever be implemented (which I doubt). For a true singleplayer experience, you'd have to run the server on your own PC and Rolf has stated numerous times that he won't ever give out the server code.
  14. It's a bug and it's known already.
  15. That's meant to stop, or at least impede, macroing. Which is pretty inefficient, as it only changes once per server reboot.
  16. Problem that this entails is what if I have say 2 hatchets, one high ql, one low ql with high coc and I want to use a different hatchet at different times? The client has no way of knowing what I want to do and would always choose a certain tool everytime. I think the suggestion itself is a good one, but perhaps needs a little bit more thought in how it would be executed. Things such as building towers etc could be changed without needing activation, perhaps the order you place items in your inventory is the order they are used in? Would only require a quick search on the inv arraylist to find the appropriate tool and use it? To automate as many things as possible would be best imo. Zcul, if you want any help devising a system that uses what I have suggested, just let me know and I can think what I can come up with Actually, for the decision, we could use the toolbelt. What's in there gets priority.
  17. Can't make it much easier than it is already. That's the thing. Never ever overcomplicate things for the honest user. The macroer won't care how tedious things are. The honest user will, though.
  18. They tried to contain it, but failed. There was just too much of a community behind the bot-writers, so that it was fast to find a solution to virtually any problem.
  19. Personally, I wouldn't base UI elements and usage of it on if it could be macroed or not. You're just kicking the honest players in the teeth with that, not really stopping those who want to macro stuff. The more complicated something is to do regularly, the larger the gap becomes between the honest people and those who cheat. Remember, a machine doesn't ever get tired of navigating a 5 level deep menu. A human does so, very fast. I've written elaborate bots for Ultima Online on a server where it was allowed to do, just for the challenge. There's absolutely nothing short of GM intervention that can stop a macroer at all. Some things do, indeed, take more time, but as I said already, a macro doesn't get tired of it. So please, stop using that rotten excuse to not implement good things that make things more accessible for us honest players.
  20. Well, ever since I got to 70, the skillgain did slow down quite a bit. On the other hand though, it doesn't seem to be all that bad. I'm close to reaching 71 in a bit, and didn't do much more than regularly just clean around our alliance's villages.
  21. Something must've been changed with fatigue, then. I once had a pretty hard improving session two or three years ago, during which I was smithing for a week straight 12 hours a day. And didn't run out of fatigue back then. So clearly something must've been changed for the worse. As to your suggestions, only the question popping up cannot be easily accounted for with a sophisticated enough macro. All the others could be circumvented. And to be honest, I'm not too sure if I'd like that question pop up regularly. As it is now, only a small amount of people have been incapacitated by fatigue. So we should have a look at what happened during that time for some fine tuning of the fatigue system. We don't have to throw it over board completely, if there's just a bug with calculations going on.