Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Stein

Members
  • Posts

    1208
  • Joined

  • Last visited

    Never

Posts posted by Stein

  1. The drama continues, I've locked it with a bit of a warning and request towards them to be a little more mature over this. But I don't see it happening.

    [http://www.eclipseorigins.com/community/index.php?/topic/135573-need-gms-to-take-action/](http://www.eclipseorigins.com/community/index.php?/topic/135573-need-gms-to-take-action/)

    There's a lovely PM going on. Maybe I'm a little lenient on this. But with some luck we can resolve it rather than add fuel to the fire. I invited the lot of you to it.
  2. I'm locking this, I've seen enough from your side and your supposedly innocent team members trying to flame other people their work, and directly putting them down. While I can not endorse their behaviour neither can I endorse yours. I'm also not going to stand for having this out in the open just to attract more drama to this whole ordeal, **if there's an issue with other members we do like to be informed**, but **calling them out on the forums is NOT the way to do this**.

    If you have concrete evidence that it is their doing, and you can back this up by facts we can take action against them and I'd like to see this in my inbox, not the forums.. Until then, we've only seen wrongdoings from your team members using their name, flaming their game and purposefully causing drama on the shoutbox. The odds are not in your favor here.

    And as a general note: you can not simply get a random keylogger through skype without accepting it yourself. You either may need to look into your staff members, or start logging changes on your server and their IP Addresses for security reasons.
  3. That actually seems fairly interesting, and would promote the use of the event system quite a bit. I rarely see people using this to its fullest, they tend to just use it in conversations rather than elaborate scenes.
  4. NPCs themselves do not have shop triggers on them. The way we usually work around it is either a shop attribute on the map itself in front of the NPC, or triggering a shop window through an event conversation.
  5. It's not an ini file, it's a bit of code strewn across a few locations (Player().Steps is a good thing to start looking for) that you'll need to adjust, as well as a lot of sprite-related subs that currently divide the sheet width by 4, you'll need to change this to 3.
  6. > If range is a legend it was done in error. I thought we already had a set of rules for the site, do we need to redo them?

    There used to be some, but I think they got lost somewhere during the transfer and were never rewritten or put back. Most of us seem to use whatever we remember of them for guidelines however.

    > anyone have any ideas on a system to award ranks?

    As Matt said, the current system works except for the fact we may have to make clear to people how exactly the Legend and Veteran ranks work and when they would receive them.
  7. Cutting it down entirely would cause trouble honestly. I say we take parts of his.. rant and explain why things have happened and try to set more things in stone here for the leadership (and us other admins) to enforce and govern by. Possibly set up proper rules and regulations for what makes someone deserve rank X and Y, and what rules are being enforced since, as I've said before we're all basically going by our own judgement.
  8. Not everyone with a red name has full administrative privileges, let's make this clear as well. The only people that really do are JC and Amish, I for example am in a group that's simply colored red, but is not the actual larger ''administrator'' group. So yes, most red names you'd see are basically just elevated moderators. :)

    As for how Ranqe got to be a Legend, christ if I know. It may have been an accident but I honestly never checked since I figured it would have had a reason.
  9. That works but still leaves a desync issue in rare occassions and players will be unable to attack the NPCs properly (first hit, since the location is handled on two locations it may not always match up) although we'd need to see this done in practice to see the full extent of such a possibility. I don't think it would happen often enough to worry about it, but it never hurts to bear this in mind. (Also with the randomized movement timers mentioned below and people joining later, or longer movement timers this WILL cause issues, so possibly resetting the movement timer back to default for everyone might be nessecary when someone joins a map)

    Another issue is that if the steps are done for every NPC on every (active!!!) map without variable speed between each execution in said Byte array you'll get a crapload of new numbers to regenerate every time and the Random() function isn't exactly kind on resources so using it a couple hundred times in a row may not be a great idea. I'd add a random delay to each movement frame (ranging from between say 200ms and 5 seconds so they move at seemingly random intervals) to avoid having to regenerate a lot of arrays at the same time. Using such a method we can cut down the byte array size to around 50 or so as well because we'd have more space to recalculate them.

    This will not fix the speed for NPCs in combat though, but we may be able to patch that up a little if we have more space for processing each individual in-combat NPC as well.

    TL;DR: A great concept in theory Carim, but it leaves a few vulnerable situations. For example when a player joins a map mid-timer, they will always be off by X amount of time on each NPC.
×
×
  • Create New...