Page 4 of 10 FirstFirst 12345678910 LastLast
Results 61 to 80 of 191

Thread: Player warning: Crowd Limiting System coming up

  1. #61


    Originally posted by Bonk
    Well I hope the beta testers for 14.7 are better than the ones for 14.6.

    I'll believe it when I see it.
    Bonk! Are you the same Bonk that used to do the "Can I have your stuff..." on the DAoC Vault boards? I thought you really liked AO. Are you burning out on AO a bit?

    I was always a big fan of your witty, sharp posting style. You and I started with DAoC and then moved to AO at about the same time, if you are the same guy. AND we are both DUNE fans.

    Good on ya!
    Ozor: lvl 2(x) - MA - Clanner - RK2
    Qranx: lvl 2(x) - Adv. - Clanner - RK2
    Seclorum: lvl 12 - Agent - OT - RK2

    I'm drunk as hell!

  2. #62

    /me *Bonks* Bonk

    Simple solution Bonk, patch the test server to your comp and apply your (unproven) incredible testing talent to repair faulty beta code.



  3. #63
    This is all great, I like option C the best, but when will the beta notifications go out so I know when I'll be able to test. Also, will the crowd limitations be tested in Notum Wars beta? Obviously this issue was discovered while beta testing. You should let beta test the options you offered starting with Option C.

  4. #64
    I do have to admit that I am very intregued by this...and I hope it works well I do hope though it won't totally ruin alot of nice RP elements though where many large groups of players like to congregate together, and can just imagine how this might effect Newlands where it seems the majority of Rubi-ka congregates to find a team.

    I am also wondering about something else...since about 14.0 I have found that the grid is totally un-usable due to it causing drops. My system isn't the problem, and it seems that the grid is now loading textures and information from peoples armours etc like it would if you were in a town. Chatting to a few other players on slow connections like myself (yes I know I have a slow connection but theres nothing I can do about that for another 5 years+ thanks to useless telecoms, but I try to make up for it by having a twinked up machine instead) it would seem there are a few with this same problem. It's not the texture loading which I personally find the problem, its the amount of data that this is of char/prof/armours etc much data, so little a modem.

    Nice to know you're trying to improve things this way
    Major "Nyadach" Prabel
    Neutral and proud of it!

  5. #65


    The limit on PvP 10vs10 I like that idea .. but the limiting when just passing through a non PvP zone? like if I wanna go shopping in trade so I try to grid into trade but hey to many people are there so I have to go somewhere else? That is where most people meet to go play and I don't see the point of limiting in non PvP zones.. so what I get a little what has been refered to as LAG .. I still get to the shop non the less.. I see the need for it in PvP zone but not in normal non-PvP zones.. this will just becoming annoying like the 14.6 bug reseting the agg/def bar.. it's nothing major but very annoying.

    I have a suggestion for the problem it's along the same lines as one other post I read.. instead of limiting the # of people in an area.. why not lower the polygons in crowded areas or let those that have low end comps be able to lower the graphics setting as such.. cause I only have a 1ghz computer with a vodoo 5 video card.. and the only place I have problems is newland and omni-trade.. for the obvious reason. but your suggesting that if I'm in trade and wanna gather a team and they are in entertain they might not even be able to enter the zone to team with me? that is the way I'm reading it so correct me if I'm wrong.

    ON another note about the testers for 14.6 I was one of the testers and we did report every bug that is currently being fixed.. don't go shooting your mouth of about the testers when you obviously don't have a clue what your talking about.
    Last edited by Davitger; Nov 8th, 2002 at 00:02:21.

  6. #66

    A small suggestion

    I've played in many MMOGs, including a lot of DAoC, which has serious problems when big PvP battles break out, as well as flight sims like Air Warrior, which had similar problems.

    DISPLAY LIMITS: The flight sims solved the problem by only displaying the X closest friends and enemies. In Air Warrior, X=12 to 16, in other flight sims it was different, but the end result was the same. This had the benefit of preventing long-range sharpshooting (agents will be sad), but the disadvantage of benefiting fast-movers who blitzed past, shooting on the run. Overall, though, it was a solution that worked pretty well for 300mph airplanes, so it shouldn't be too bad with 20mph humans.

    ATTACKER LIMITS: If you prefer to limit the number of characters physically present, as opposed to just limiting the graphic display of same, things do get messy, and people will be unhappy. In this case, my suggestion is that you apply the limit to each side that does NOT own nearby territory. This means attackers cannot "flood the zone" and prevent a defense.

    A DEFENSIVE BIAS: I would be perfectly comfortable with allowing any number of defenders within "their" territory (i.e., within a certain distance of the mine). If a guild wants to "camp" their own mine to help defend it, more power to them! Attackers who find framerates too low will quickly learn to hunt elsewhere, or try again later. Just as a party goes to a wildnerness "camp," only to find another group is there and they must move on, similarly mine attackers will find some mines "unattackable" at that time and will move on.

    LEARNING FROM DAoC: This view is partly because of what I've observed in DAoC. Territory there was very hard to defend 24x7 (keeps especially), and 24x7-based attack tactics were making relics similarly difficult to defend. As a result, in patch after patch Mythic had to beef up defenses by making keep doors stronger, guards stronger, give players XP incentives to be around their keep, etc., etc. You have a chance to benefit from that sad spectacle by defusing the problem at the start in AO.

    Hope these ideas help you deal with a messy problem.

    - Anupa's Guiding Spirit

  7. #67
    lol this is such a bad idea that it makes my stomach hurt. i thought i read that the towers will have thier own defences? If so and it is a powerful guild with many defense posts they can just send in a small number of defense players limiting the attacking force as well. The attacking force would not only have to fight the players but the tower defences. That means no matter how big your guild is you wont be able to defeat the towers if the defending guild only sends a couple well picked players in at each time? People dont like getting steamrolled? Well if i remeber it correctly i read that the towers would be hard to defeat but easy to defend and if thats the case i dont see how you can overtake one unless you have a big force that can just run in and smash stuff. Also no reason to have massively large high lvl guilds then cause you might end up not having a chance to participate
    - lvl 200 neutral agent -

  8. #68

    Exclamation Giving up? I think so

    Firstly I _am_ a software developer both win32 DX and Linux/BSD.

    Only 5 years or so as a professional but I have a fair idea of how things work.

    I can understand the bandwidth choke from system mem to card mem, but the solution these is simple, reduce texture rez when the play area fills up (mipmap then disgard parent).

    Too many different meshes? simplify! Design some generic ones (the existing one should be generic inside breed anyway) and use the textures to differentiate (the UVW mapping in this game is so simple that this would be easy to do)

    Thrashing from disk to mem when you zone? then don't zone like that, zone like this:

    1. Client issues move order
    2. Server initiates zone, removes player from playfield
    3. Server issues rez manager command to client: load new playfield + all meshes in area (switching to more generic meshes/lower rez textures if overcrowded)
    4. Client thrashes (Screen still blank, or maybe playing a pretty and simple animation)
    5. Server prepair to add player to new playfield but doesn't do it yet.
    6. Client issues "all done" order
    7. Server adds player to playfield

    True, It'll take longer to zone, but what would you prefer? the proposed "zone full" message? The server could even wait for a team to be ready before zoning them, if turning up together was considered important (like the Q3A level loading waits for all players to be up and ready)

    One thing about the rez manager, I understand that IDE blocking can really screw up framerate when loading stuff, but why-oh-why doesn't AO cache properly? I have 1GB of ram, and _still_ the HDD thrashes after zoning.

    People were asking how Luclin does in in EQ? well the caching works, and you need lots of RAM.

    I still this that a proper non-blocking trickle loader is the only proper way to do this (the console can do this, but they don't have to contend with IDE)

    Rather than limiting the battles please implement generic fallback meshes/textures (use vertex shading to get the general colour rather than textures, most people are wearing black/white/red/blue anyway) then trickle the textures from mem to GFX card as you get the oppertunity, and cache everything you can in mem before you log.

    Please if anyone in FC thinks I haven't thought this through I'd love to hear their thoughts. I don't want to argue or be akward, I'd just love to hear their side.
    Last edited by SM; Nov 8th, 2002 at 00:58:17.

  9. #69

    Re: Giving up? I think so

    Originally posted by SM
    Rather than limiting the battles please implement generic fallback meshes/textures (use vertex shading to get the general colour rather than textures, most people are wearing black/white/red/blue anyway) then trickle the textures from mem to GFX card as you get the oppertunity, and cache everything you can in mem before you log.

    Please if anyone in FC thinks I haven't thought this through I'd love to hear their thoughts. I don't want to argue or be akward, I'd just love to hear their side.
    I can agree with that

    In the words of the SWG guy from their boards.

    We want the game to have a descent frame-rate no matter what you are doing, I don't care if you all turn into a bunch of little green stick figures, you won't have low framerate!


  10. #70
    I noticed alot of people mentioned Tir and I'm assume these limits will be placed on cities. Now my questions are...

    "You are stopped from zoning in or teleporting (i.e summoned by an engineer) in if you are in a legal playfield already. You will simply be told "no-can-do" and remain in your old place."

    What happens to the people in shops and other building in cities when the city reaches its limit?
    Are they stuck in that building/shop until the until the city is no longer at its limit?

    This in reference to Land Control areas but I think it would apply to cities to. "As defenders move in, and the sum of characters is above the legal limit - attackers will actually be moved out. (And vice versa.)"

    Are Omni and Neutrals removed from Tir so that Clans can more easily access the city it controls when the city is at its limit? (Omnit for Omnis cities, Neutral for neutral cities)

  11. #71

    a small suggestion - continued

    I'm not interested in getting into flame wars, so I won't try to defend or argue a point.

    However, I did neglect to mention a couple more points about attacker limits and defensive bias.

    SIEGES & HUMAN WAVES: In a defensive bias situation, attackers with good tactics still have options. If they place the tower under siege (i.e., prevent more defenders from getting to it), then they can use superior numbers to send in wave after wave of attackers. Each wave wears down the defenders, causing more and more casualties until the attack succeeds. Costly, but effective, as the Chinese proved in the Korean War.

    LOGOUT-LOGIN PREVENTIONS: One extremely nasty defensive tactic that should be prohibited is defenders logging out right around the tower. Now that many players have "alts" at level 200, a guild could have dozens and dozens of level-200 alts logged out right around the tower, ready to log-in at the first sign of trouble and defend the tower. This trick has already been used to great effect in DAoC, making most relics uncapturable in prime time (when plenty of those top-level alts can be mustered). It's not uncommon for an attack of 200-300 people see a couple hundred (yikes!) defenders material inside their fort within minutes of the attack starting, as people log-in on their alts, which were logged out inside the fort.

    The needed prohibition is that players in a guild which owns a tower cannot log out within X distance of that tower. If you can't prohibit this absolutely, then when they do log-out, their logout position can be reset to their last insurance terminal location.

    - Anupa's guiding spirit

  12. #72

    Re: Giving up? I think so

    Originally posted by SM
    1. Client issues move order
    2. Server initiates zone, removes player from playfield
    3. Server issues rez manager command to client: load new playfield + all meshes in area (switching to more generic meshes/lower rez textures if overcrowded)
    4. Client thrashes (Screen still blank, or maybe playing a pretty and simple animation)
    5. Server prepair to add player to new playfield but doesn't do it yet.
    6. Client issues "all done" order
    7. Server adds player to playfield
    Wouldn't help very much with the streaming of ressource in zone.
    The client doesn't knows in advance the list of all of the dynels (ie dynamic object, like players) for the whole zone.
    Only the dynel infos for the immediate surrounding of the player are sent, otherwise it would probably take too much bandwidth, and would pose a security problem where one could, for instance, write a small prog capturing the network packets and displaying the complete mission map with all the mobs and the pickup item.

    I do think that the streaming from disk takes a lot of time. But I wonder if they use a separate thread to manage the ressource streaming... If not, then the whole game is bound to the randomness of disk accesses, and probably sometime need to wait longer than usual. If that was done by a separate thread with a lower priority, the engine could continue to update and render the game, even whle waiting for some particularly long loading to be done... Althought most probably the ressource manager thread would have a hard time getting some cpu time.

    Just some thoughts... I don't pretend to teach the devs their job. It's just that the game seems to have to wait sometimes for a data to be loaded for long times (with lots of HS thrashing - I get it a lot because the partition where I have AO need a defrag), and seems to be completly blocked until the data has been loaded.

  13. #73
    if rendering is such a problem in close quarters why not have colors fade as numbers of players increase.

    in the case of battle, omni could be one color and clans could be another.

    it could be a setting for low end computers to use if need be.

    sounds logical but maybe theres something wrong with that?

  14. #74
    hmm defenders already have a advantage with all their towers... If its 40 attackers vs 40defenders with attack and buff towers well i dont see the LC goin down u know

    still seems like a good idea if implemented well
    Kalashnakof [Over 170 LvLs Served]
    The Few, The Proud, The Unendowed
    The Troxy Soldiers of Pax Romana
    [!]AR/RE 80/40 from 66/33
    [!]Nophex drop off Notum Trainie
    [!]Still waiting for AirStrike MK1-10...

  15. #75

    rambling on

    I have read over the article very carefully and I think it is important enough to deserve comment. It appears that the limiting system will only be applied in areas where crowding could be used as a PVP exploit. Given the explaination of tower based PvP in other articles, there will not be unbalanced level issues in these areas, so many of the issues brought up in previous posts are moot. I read with distaste the posts that say basicly, if you don't like what FC is doing, go play something else. I like this game and pay to play it. I would like to see it run better on my machine. I would like to see, that when I choose to join a large group of people in a cooperative endevour, that it would be an enjoyable experience. I am not comfortable with my enjoyment coming at the expense of others whose money is just as good as mine. I am in favor of some stopgap method of relieving some of the pressure on the various servers and clients, but I am very leery of a system where players are removed from play. Not from the game mind you, but from play. If I am not where I want to be in the game, where I have been, where I was assisting my comrades, I will be very unhappy. I don't mind getting killed in game, or losing at anything, I do resent however, not being able to play. Reducing the number of players at a given PvP location to reduce system stress and give everyone still in play a fair shot is very seductive, but I wonder how decisions will be made as to who goes and who stays. If I have many defenders available, but few useable, will I be disadvantaged? Will org size become another stat that will be defined down to a very narrow range and any deviance from that range be pointless? I find this crowd limiting solution very troubling in a massivlely multiplayer game. Other proposed solutions are just as troubling though, I for one want to know at a glance what type of armor my opponent is wearing, to choose the best counter for it, limiting resolution will deny me that. Reducing framerate is equally unacceptable because I like playing a game of near realtime flow, not a turn based system. All in all I think I understand the motivation to make the play for all involved as smooth and as enjoyable as possible, but when a few are sacrificed for the many, I seriously doubt the method. The final question I must pose is this: In a virtual world, where the creators are paid by the inhabitants, who makes the rules? Who is the final arbiter?

  16. #76


    I like this number limit idea. I think it is the only workable solution. The real key going to be the algorithm that decides who gets booted out of the battle. I think someone on both sides of the conflict should have the ability to pick and boot someone from their side. (highest org officer, maybe) That will take care of campers.

    As for Neutrals, you're Neutral. You've chosen no side. You shouldn't have a place in a Clan/Omni battle.

    As for people who are mad 'cause they are told the play field is busy with a war at the moment. Hmm. Would you rather it not be at the limit and you walk into a battle? Would you rather wander past a hostile tower that starts picking off your team members? How is being told, 'You really don't want to go there, right now.' any worse?

    I think this is a good plan Funcom and I hope you can pull it off. I look forward to Notum Wars. I also hope you keep working on the texture issue.


  17. #77

    Re: Re: Giving up? I think so

    Originally posted by MORB

    Wouldn't help very much with the streaming of ressource in zone.
    The client doesn't knows in advance the list of all of the dynels (ie dynamic object, like players) for the whole zone.
    Only the dynel infos for the immediate surrounding of the player are sent,
    All True, however the terrain objects that the player would "see" can be loaded before arrival (stopping post-whompa building popping) minimising the post-zone thrash. If the meshes are done properly you should need 1 mesh for each breed (not each body type) regardless of wether they are wearing cloaks or not and a few extra meshes for helmets/weapons/tank armour. Have a few generic textures in memory (use vertex shaders to colour the armour) or just straight vertex colour. Then monitor free CPU and trickle in "important" textures and meshes from disk to mem and from mem to GFX card as and when you can.

    On a system with a reasonable (or unreasonable) amount of memory there should be nor resource based reason why there cant be hundreds of meshes wandering about (or sliding about a-la Quake2)

    AO does look pretty, I'll give it that, but do you really want to maintain pretty at the expense of gameplay?

  18. #78

    There are still other things that you can do.

    I have to say that the solution is the lesser of 2 evils. Notum wars probly will suck if this issue was left unchecked.

    There are other avenues that could help make this problem less of a blatent issue, but they would require planning and crap like that. indeed im writing the post because of the problems you descriped (i keep crashing so now im here at the forums to rant).

    I'm sure that my couple hours a day are spent doing the same thing that most other do. I log on, hang out in omni-ent and chat with people or shop, I head to nlc to find a team, and we all go to bs to do a mission, and then if the ocassion arizes, we all head off to camalot to ***** and complain about the lag. All punctuated with a crash here and there.

    One problem is definately the congestion. There are zones that no doubt developers spent many many hours developing that are practically deserted and some that are over crowded and causing problems.

    I think that one of the reasons that this congestion occurs is because traveling in the game is just too damn convienent. the other is the lack of anything more proffitable to do.

    Amendment #1 that I would suggest would be to try and devide the player base over the entire world. You have to turn the players from the deeply beaten paths. When an experienced player starts a new character, he pretty much goes to places pre-ordained by the playerbase experiences. This would not be so bad except for the fact that there are places where the people tend to pile up for many levels (like 20k, omni-ent, newland, tir). Where they sit around looking for a team to do a mission as quickly as possible, do as little thinking as possible, and level up as quick as possible, with the smallest possible risk. And then they'res the dayly mess of camalot, where the player base has piled up the worst. This is my phase 1 of what I'm trying to convey to help the situation. Make it more profitable to travel and try and force the people at different levels to be in different places in order to accomplish their goals. This would mean designing certain area's of a game for a certain level range.

    But before you would do that you would have to consider this.
    No one is going to agree with me on this one but:

    when I outline my tipical game session that I share with so many of the same faces every time, I realize that the 3-4 places i usually go are very very far away, but they can be reached in less than a minute. The greatest danger in traveling in this game is crashing. I don't know why moving around this big world needs to be so damn easy. They wompas and grid are convienent but they make things just too efficient. You can get a yalm at lvl 20 or less and fly the entire world with no real danger. Why? These things are nifty but they serve to flame the lazy mission frenzy and ultimately the player pile up.

    Try these 3 things

    1. Limit the whompa network, you can go almost anywhere at any level right now. Make them less convenient
    2. Limit your ability to use the grid like 12 hours or so or make it cost a bunch of money to use it.
    3. Yalms......just get rid of them or have them time limited and will vanish in 2 hours.

    If you decided to limit the transportation, you could easily control where the people should be at what level and spread them out. Make it impossible for a level 2-50 to get to camalot, he would surely perish by some nasty mob because he couldnt wompa around or fly there with no danger.

    Also if I'm down in DAV doing something profitable besides bird watching and site seeing and I recieve a "come to camalot clanners have the box room!" theres no damn way I could make it there in time. (of course to keep people from just piling up in camalot, you'd have to make other big similar places for people to hang out at, make them choose which area they are gonna try and defend against the other side/loot they want the most)

    Well thats my solution for lag reduction.
    *limit transportation
    *design playfields to be more accomidating at certain levels to try and get the players seperated out.

    Now this combined with your idea of limiting the amount of players in a zone I think would help alot. Even though its a lot of work I think that idea is something to strive for.

    There is one small flaw with these things and that is the leveling out of the player base at a higher level, I guess the solution to that would be to make many places for high levels to hang out at.

    those are my ideas, now wheres my paycheck


  19. #79


    AO's texture loading and handling definitely needs some work - given the kind of systems people have, it's a little surprising that there's such an extreme slowdown. That it's also unprecedented can probably attributed to the sheer number (and detail?) of textures AO has to load on the fly. Either that or sloppy programming.

    Regarding the limiting system:

    Tactically, it puts the attackers in a problem. - it's already been discussed how the defenders can just swamp the area with numbers until the attackers start having people forcibly removed.

    Forcible removal: *Gulps* Bad idea. BAD IDEA! Instead, try setting a maximum number of attackers and a maximum number of defenders. Don't allow more than that in to begin with. Of course, this raises the horrible prospect of attacks not getting off the ground because the attacker slots have been used up inadvertantly - or even deliberately (by defender alts). As I said: Bad idea.

    Who gets the boot: The currently laid out system does not go into which characters would get the unceremonious "To compensate for the inadequacies of the engine, you have been removed from the fight" message. Will it be the level 1Sapiens or the level 200 Omega? Will there be quotas on profession, time in the zone, distance from a certain point or something else?

    NonCombatants: Personally, I'd rather take the risk of a trigger-happy clan scumbag shooting at me than not be able to get to a mission because of a war going on in the area. Getting killed means I didn't fly high enough or make the best use of cover. Getting stopped by a text message just makes me want to scream. Oh, and cancel.

    Any discussion on player limiting is, at the moment, a slightly moot point. What we need to see before we make our decision...ahh rephrase that. What the designers need to see before the designers make their decision is how the improved engine handles the current setup.

    THEN you can consider covering for the engine by restricting people's movement. But to do so beforehand is to do so without knowing one of the most important variables in the situation. And thus a bad idea.

    NB: That last comment assumes the optimisations wil deliver a substantial preformance increase. If they don't, then now would be a good time to 'fess up.

  20. #80


    Originally posted by eyedee
    This is a fact ppl, So you put up a whole german dimension. why cant you put up a european server?

    Isn't Germany in Europe? Or is it Africa?

Page 4 of 10 FirstFirst 12345678910 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts