User talk:Aichon: Difference between revisions
Line 147: | Line 147: | ||
Too bad, I really hoped to optimize this whole thing... Then again: the danger reports ''are'' updated regularly these days, even more with BB4, and that was always one of the goals :) Maybe I'll go on a little wiki-patrol later today and just list a ton of stuff that can be deleted or otherwise archived to clean the whole wiki a bit out. {{User:Peralta/Signature}} 12:54, 19 June 2013 (BST) | Too bad, I really hoped to optimize this whole thing... Then again: the danger reports ''are'' updated regularly these days, even more with BB4, and that was always one of the goals :) Maybe I'll go on a little wiki-patrol later today and just list a ton of stuff that can be deleted or otherwise archived to clean the whole wiki a bit out. {{User:Peralta/Signature}} 12:54, 19 June 2013 (BST) | ||
:If you want to optimize these pages you could make the core templates use non-wikicode code, here's a list [[wikipedia:m:Help:HTML_in_wikitext | :If you want to optimize these pages you could make the core templates use non-wikicode code, here's a list [[wikipedia:m:Help:HTML_in_wikitext|m:Help:HTML_in_wikitext]], it'll reduce the work done when the parser runs. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 22:12, 19 June 2013 (BST) |
Revision as of 21:13, 19 June 2013
Announcement: I'm no longer active. My talk page is still your best bet to get in touch. —Aichon— 04:39, 15 December 2018 (UTC)
- New conversations should be started at the bottom using a level two header (e.g.
==Header==
). Or with the + - I like to keep conversations wherever they start, but if a conversation ends up here, I will keep it here.
- I will format comments for stylistic reasons, delete comments for whatever reason, and generally do anything else within reason.
Well met
Thank you very much for your input. I shall reply on [1] asap,for there is an entirely good reason for that exact specific edit.
please,if maybe you could either reply here or write on the Groups topic I've started on the talk page.
If you'd have the pleasure means and time in guiding me on my way of putting up a new group's page;I've been reading the guides here but they haven't been that helpful.
Also,I've noticed you have a character with the BB4.I did play a zombie character at first but due to the fact it has been revived while living the life of a zombie -haha,I let it be;was wondering if there might be any group I could join this zombie character of mine to the BB4 playing it completely independent of my survivor's char.
Thank you so much for stopping by and having your input.Hope in hearing from you soon.
Edit: have read almost anything there was to read on your page and some of the things that caught my attention where the 'image stamps' saying things like 'supports humor' and so on! Thus,pleased in meeting,well met. —The preceding unsigned comment was added by Concerned'Citizen (talk • contribs) 01:42, 5 June 2013.
- Regarding groups, what information are you looking for, exactly? I understand that you're trying to make one, but I'll need to know where to start if I'm to offer any advice or answer any questions. I've made a few group pages over the years (e.g. Soldiers of Crossman, Big Bash 3, and Big Bash 4 are all ones I made), so I at least have a little experience in this area. ;)
- As for BB4, yup, you could say that I'm involved with it. If you'd like to join BB4, you are VERY welcome to do so. We welcome all zombies, new or old, and we'll even help feed your zombie so that he can earn some levels and skills. BB4 only lasts for a few months before it goes away (it's been three years since the last Big Bash), so I definitely would recommend joining it while it's around, since they don't happen often. Also, it's worth pointing out that BB4 is an event and that entire groups come to it as well, so we actually have The Nurglings joining BB4 as a group. If you like BB4 and like what you see of The Nurglings, you may want to look into joining them, since they're a newer zombie group that's making a name for themselves.
- Otherwise, the traditional recommendations for zombies groups are the three remaining hordes: the Militant Order of Barhah, The Ridleybank Resistance Front, and the Feral Undead. The MOB tends to be very structured and focused on strike teams and efficiency (one of my other characters is in the MOB), the RRF is a bit more flexible and has everything from death cultists to strike teams and ferals, and FU tends to be more of a free-for-all with minimal leadership. All three of them are great groups, and you should go with whichever idea appeals to you the most, with MOB being super structured, FU being open-ended, and RRF being a bit more in-between.
- There are a number of smaller groups as well, but I have less experience with them, I'm afraid. You may want to check the Groups page for ones that are recruiting. —Aichon— 02:13, 5 June 2013 (BST)
- Most wonderful in reading.
- This urban dead sure got exciting as of joining the wiki,which I strongly recommend to anyone out there who really wishes to have their game on,so to speak.
- In regards to group would appreciate in being guided regarding : group page creation; how to load art,pictures,images videos; how to create a layout,something of a template with titles linking to new wiki pages opening up-which I've noticed on several wiki-user's pages.
- For starters,would be just fine in being able to have a blank group's page adding group's name,description,purposes/goals and a neat banner on tops,though I don't do them-lacking the software for it as well as not being quite experienced with IT art-work.
- As for groups,best suited for a zombie,in my own opinion,would be something such as the MOB.Where do I sign? :D Well,I should be able to get my zombie on,if he's still alive - haha (which I'm sure he is :D them rascals seem to NEVER die oO)
- almost forgot to sign the article just now,haha :P um,here it goes Concerned'Citizen 04:37, 5 June 2013 (BST)
- If you check the "toolbox" section on the left side of the page, you should see a link for Upload file. If you want to upload images, just click on it and then follow the instructions. I'm afraid we can't upload videos or audio files to this wiki, however. Just images.
- As for a layout, you'll mostly have to do that on your own, or else find someone who is willing to do it for you, since there aren't templates or other resources that you can use. One idea you might try is to find pages that you like and then look at their code to see how they did it (I would not suggest starting with the group pages I created that I linked, since the code for them is rather complex). Regarding the "template with titles linking to new wiki pages", could you point me to an example? I'm afraid I don't quite understand what you mean.
- Anyway, you'll have to figure out how to make your own banner, since I'm not very good with images either, but for making a page, all you need to do is go to the page and then start editing. For instance, you could create a group at Lorem Ipsum by following that link and merely editing the page. You can easily add in the information you've talked about, such as their name, description, goals, etc.. You may also want to look at the {{Groupbox}} template, since many wiki novices use it to get that information onto their group page quickly and easily.
- Finally, for applying to MOB, you'll need to sign up for an account on barhah.com and follow the instructions in this message board topic. You may also want to look over the MOB page here on the wiki, as well as the MOB Locator page. —Aichon— 05:01, 5 June 2013 (BST)
- Much appreciated.
- I've made an account with the Barhah Dot Com since of yesterday after reading around the wiki and wishing to join BB4 as a zombie novice.
- Have not received a confirmation e-mail;though I haven't got to checking my e-mail as of yesterday.
- The wiki and all the information coming my way on reading is keeping my undivided attention here.
- regarding the layout and functionality of links: having a template showing contents; clicking on a title would open up a new page which may contain further data. Hope that I managed to explain this well.
- Example : Template - A B C D E F G ... etc. Clicking on either would open up a new page which could have any data there.
- That would be it.
- Concerned'Citizen
- Just make each of A B C D E F G into links to pages (typically you'll want to make them subpages of your group, like Lorem Ipsum/Members or Lorem Ipsum/Recruitment), then create those pages by simply editing them. That's actually how pretty much anything around here works. People just make links to pages that don't yet exist, click the links, and then make the page there. —Aichon— 08:42, 5 June 2013 (BST)
Suburb Danger Reports
Taking my time.
It sure is a job in reading,searching,updating.
Especially reading.
As for updating the danger levels of suburbs it's clear that survivors could sure use an update on the info.
That is,in case they are interested and watching the wiki,which specifies danger levels.
a little something started to work on
safe - Break-ins rare, max 50 zombies in suburb and no zombie groups above 10. moderately dangerous - Active zombies and break-ins, but no 50+ hostile hordes.
It is fairly outdated,don't you think? Reporting a suburb as 'moderately dangerous' may be too late if you take the above ad literam.
Reason being,several mobs of around 9 zombies may be moving about,just an example; and consider there are 8 cardinal points they may close in to a building.
Let's say that only 4 groups of 9 zombies each will target a building coming from the major cardinal points en route for their target.
In this case,the danger levels of each suburb may always be set as Safe until it'd be too late ...
This here danger report system "" Available 'Danger' statuses:
safe - Break-ins rare, max 50 zombies in suburb and no zombie groups above 10.
moderately dangerous - Active zombies and break-ins, but no 50+ hostile hordes.
dangerous - Zombies inside many resource buildings; OR hostile mobs of 50+.
very dangerous - Most buildings wide open or zombie-infested; OR hostile zombie mobs of 150+.
a ghost town - At least 2/3 of the suburb's buildings either empty of Survivors or Ransacked/Ruined AND max 60 zombies in suburb and no zombie groups above 10. ""
greatly advantages the zombies from any perspective anyone would look at it.
In that case,what play does the concepts of 'balance' and fair play stand? Concerned'Citizen 06:11, 5 June 2013 (BST)
- Talking about your example, if those zombies are all in the suburb, then there would be 72 zombies in the suburb, which would mean it'd be classified as Moderately Dangerous or Dangerous anyway. And if they're coming from out of the suburb, then the suburb is safe until they arrive, which makes sense, since the danger isn't there yet. Seems like it's working to me. ;)
- There is some leeway in the system, as well as some gray areas, but generally speaking, the easiest way to check is to go through the suburb and look for zombies gathered at resource points. If you see 10+ zombies gathering outside of a resource point, then it's probably time to call the suburb Moderately Dangerous. Also, when you're counting zombies that are roaming around, make sure you ignore the ones at revive points, since those are really survivors, not zombies, at least as far as we're concerned.
- And, I don't really see how it provides an advantage to anyone, since it's simple fact reporting. Granted, the system was written back in the day when the game had quite a few more players in it, so the numbers may be larger than what makes sense for the game's current population, but that's a separate topic of discussion (and I believe it's been discussed to death elsewhere), and I am not someone who can change it all by myself. I'm simply the guy policing it at this moment. :P
- Also, having suburbs incorrectly labeled as Safe is actually a disadvantage for zombies, not an advantage, since the worst thing that can happen to a horde is that they arrive expecting a buffet of food, only to find out that the suburb is actually in worse condition than the wiki said and that there's almost no one there to eat. All of the zombie leaders I've talked to over the years prefer that the map be accurate (or red, since it makes them look good), rather than green. —Aichon— 06:49, 5 June 2013 (BST)
- Hmm -nods-. Indeed That is one way of looking at it.
- Though,if we are to take into account that survivors which aren't well organized within groups,even those belonging to groups,may seek the shelter of a Safe suburb rather than venture in a suburb marked red/orange even light orange.
- Te simply put it,it's a matter of psychology. One example would be update and danger reports from which anyone active enough can benefit,of course.
- Another example that can be interpreted in more ways than one is this broadcast "The Eley Way Police Dept in Greentown is having a party" - what would you make of it?
- Concerned'Citizen 06:53, 6 June 2013 (BST)
- I understand the psychology, but that would be a bad strategy on the part of zombies. Specifically, if the zombie's objective is to eat more survivors, they want those survivors to be concentrated in a few areas, not spread out where they're harder to eat. Having more green suburbs will actually cause the survivors to spread out over more suburbs, meaning that there are less survivors to eat in any given suburb, which is the exact opposite of what the zombies want. —Aichon— 16:01, 6 June 2013 (BST)
- In regards to the example broadcast you gave, I would personally never update a building status based on solely that information. Bob Moncrief EBD•W! 18:34, 6 June 2013 (BST)
- From my own personal experience, I find the danger reports to be wrong good idea. Meaning that when it came out I was quite happy to participate in maintaining them too but then I realized that it was mostly used as intel and group boasting tools instead of the real, basic journalistic ideal. Because of that I stopped updating and paying attention to them and I really think my suburb is safer when flagged as red even though it is not true because troublemakers and zombies alike tend to avoid the suburb then.
- As far as psychology is involved, a psychological weapon might unfortunately be this tool greatest use... -- •Eagle of Fire• •[Talk]• 18:15, 9 June 2013 (BST)
- Any zombie strategist worth anything would tell you that information should be public and accurate, the easier it is for the horde to follow you the easier it is to wreck stuff and it's the orgnanized groups that already have the information you need to worry about anyway. Feral/unaffiliated management is all about getting the word out and motivating people who are outside your meta-pool. As such I was always a fan of more active posting on wiki-news so long as it wasn't falsified, and drama over NPoV occasionally helped to stir up more visibility when people followed those pages. In the end it's just another way to keep things interesting and informative without spending AP, which is what really matters anyway since this is a wiki about informing and driving interest around the game.( and in this case the state of things in that game) --Karekmaps 2.0?! 19:24, 9 June 2013 (BST)
- Yes. That's pretty much what I think too. Thing is, this kind of public, readily available info is clearly at the advantage of the zombies rather than the survivors. As a survivor we only get there and see for ourselves, free running is not something difficult to get by. Zombies, on the other hand, have clear advantages from knowing where the next target and/or meal should be - all this at the expense of a luxurious 0 AP. -- •Eagle of Fire• •[Talk]• 00:02, 11 June 2013 (BST)
- In that case, DangerReport updating is a fantastic thing, because without it, the game would be even more unbalanced in favor of survivors. Bob Moncrief EBD•W! 01:00, 11 June 2013 (BST)
- It's really not, both sides benefit massively from it and the 'zomgeveryonewilljoinagainstus' people are basically waving at a straw man. Survivors get less benefit from it only because they have more venues to do it in, such as Radios and easily understood speech. The benfit from wiki updates is really their static nature, which means that ferals and lone rangers can see where the action is and come enjoy themselves and depending on what they see while they're there it can be a great recruiting tool. Most survivors see it as a 'The zombies will overrun us' and forget that without coordinated strike times survivors have a significant advantage and a number of the players that would come from that information are most likely to play in state(Dual Nature is normative play) and having an uptick in feral population is largely a plus. --Karekmaps 2.0?! 08:06, 12 June 2013 (BST)
- Sorry but I've been playing a pro survivor since 2005. What I'm basing myself on this matter is direct observations, evidences and experiences. I actually participated in the past in "edit wars" which, like I said before, were more like lame group boasting attempts to publicity... And they clearly were never in favor of survivors. One group take control of a building and post about it. The other group do the same. Then again. Then again. Indefinitely. But what does the survivors have to gain to know that a building is in ruin or barricaded? Not much at all even in case of a resource building. Zombies, on the other hand, know to move away and hit another target or gather at the same place again. Since there is bigger disadvantage for a fully leveled up survivor to simply keep killing zombies around pointlessly (AP, ammo, the zombies always win in the end whatever you do or try to do) why is it important for survivors to know that block X is in the hands of survivors or zombies? Really, it is not. -- •Eagle of Fire• •[Talk]• 00:15, 13 June 2013 (BST)
- Haven't you primarily been playing with a stationary group? At least for me, as a leader of a mobile survivor group, the danger reports can be incredibly helpful. They let us know where we need to go to work, tell us where the action is happening, and can cut down on the number of suburbs we need to scout to get an accurate sense for the condition on the ground. I know that we frequently use it in the SoC when we're trying to plan out missions, but I'd imagine that The Abandoned really don't have much need for them, since you guys know your area forwards and backwards at all times. Really, I think that's the actual distinction: the danger reports are useful for people who aren't there, regardless of if they are survivors or zombies. After all, stationary zombies in your area won't get any more benefit from the reports than you do, but a traveling horde or a mobile survivor group can use them to direct their activities. Also, as a quick aside, zombies can't know to both "move away and hit another target" or "gather at the same place again" when they see a ruined building, since those two ideas are mutually exclusive. It can only mean one or the other, since zombies don't psychically communicate or something. ;) —Aichon— 14:52, 13 June 2013 (BST)
- Quite true that The Abandoned is a stationary group. However, even then the use for the danger reports are the same if you want to cover lots of ground quickly from one side to the other. Let me tell you something: if the danger reports were actually updated in a timely manner, let's say every single hour at most, they would be very useful because you can then rely on the information. Since it is not the case and the info is unreliable, why rely on it as a survivor? We just get there and see if it is still good. Info on this regards, especially in an active suburb, can change in a matter of minutes. You're the one who have experience of a roaming group so tell me how useful that can be? As a stationary group, I persist and sign in stating that the danger reports are the most useful to me when they are showing false information. Green suburb when under heavy attack and red suburb when all's quiet is the best way to keep my suburb orderly. Which is why I ignore the reports now, because if I were to actually use it I'm sure you can guess what I'd do with them. But that would not be right in any way.
- On your aside, I disagree. It is quite true that zombies can't communicate well in game, so they need to communicate out of the game. For me the most obvious way to do it would be a forum but then you only communicate with your own group. Using the danger reports allow zombies to communicate with each other on a basic level even if they are not part of the same group. How? Well, let's say you are a ferral zombie. You stumble in Yagoton. You open the danger report. You see that Hinks is currently "under attack". What do you do? Wander around aimlessly or head to Hinks to participate in the destruction of the barricades, hoping to get a breach in? Another example: the danger report says the place is ruined and the guy who posted, whom you recognize to be from a competent zombie group, posted only a few hours ago. Will you head there and look at the ruined building or go elsewhere?
- As a survivor, those reports serve little purpose. Either I'm going to get away from the reported building "under attack" because 1) it's common sense 2) it is reported so many more zombies will come in, ruining any chance which were pretty non existential to actually hold the place up... Or either be already dead from the breach. And in the case of a suburb wide zombie attack, the reports are going to be extremely unreliable at best, so again useless.
- I don't know for you but for a play style heavily focused on lack of communication, adding good communication between players kind of become a way more helpful benefit than unreliable sightings... And that's my whole point. -- •Eagle of Fire• •[Talk]• 01:14, 14 June 2013 (BST)
- This mindset is basically why zombies usually win sieges even though all of the math favors survivors when they keep NTs running. Every successful siege I've been a part of on both sides has been won by better communication with the non-meta populace, something zombie groups are historically better at post-Caiger and that there was some parity in during the heyday of the Mall Which Must Not Be Named. It's the same thing that stopped the RRF at Santlerville and froze Big Bash 2 at Giddings for over a month(almost ending it there and/or in defeat if a few of us in the leader role hadn't talked the others into switching tactics and staying just long enough to give them time to work). As a survivor every siege I've participated in in a strategic role has relied heavily on catoring our tactics towards making it easier to keep the non-meta's involved particularly by keeping them alive and reviving them when they die(the best thing a coordinated group can do is repair and revive) where most other groups come in suspicious of everyone, revive only their members, and then blame Zombie Spies and Death Cultists for why they aren't able to establish a footing. It's even worse when they bring that mindset to sieges and approach it like hiding that there's a siege is helping them when any zombie group worth it's salt is groaning, gesturing, and updating through every venue they can find and recruiting idles slowly over time in timed break-ins while obscuring the revival pool(the best thing a survivor group can do in response to this is revive more, track rotters, and do the best to raise the population of idle non-meta barricaders).
- You may not know me from a hole in the ground but I speak from a role of authority when it comes to zombie and survivor strategy. I've walked the walk when it comes to the talk I talk. And as a zombie horde leader in a number of large hordes the one thing I was always more than glad to make use of was the fact that I had a recruiting advantage because most survivor groups were massively paranoid and when I targetted the non-group survivors they stayed dead. It's the biggest thing I spent my time talking the survivor groups I've run/run with into focusing on and I've never seen it fail, this is including against groups like Extinction who use dedicated Zombie Spais, Alts, and Death Cultists all of which failed. You're giving up the momentum in a game of momentum in favor of smaller numbers and secrecy from the people that would help you. --Karekmaps 2.0?! 17:12, 14 June 2013 (BST)
- This mindset is basically why zombies usually win sieges even though all of the math favors survivors when they keep NTs running. Every successful siege I've been a part of on both sides has been won by better communication with the non-meta populace, something zombie groups are historically better at post-Caiger and that there was some parity in during the heyday of the Mall Which Must Not Be Named. It's the same thing that stopped the RRF at Santlerville and froze Big Bash 2 at Giddings for over a month(almost ending it there and/or in defeat if a few of us in the leader role hadn't talked the others into switching tactics and staying just long enough to give them time to work). As a survivor every siege I've participated in in a strategic role has relied heavily on catoring our tactics towards making it easier to keep the non-meta's involved particularly by keeping them alive and reviving them when they die(the best thing a coordinated group can do is repair and revive) where most other groups come in suspicious of everyone, revive only their members, and then blame Zombie Spies and Death Cultists for why they aren't able to establish a footing. It's even worse when they bring that mindset to sieges and approach it like hiding that there's a siege is helping them when any zombie group worth it's salt is groaning, gesturing, and updating through every venue they can find and recruiting idles slowly over time in timed break-ins while obscuring the revival pool(the best thing a survivor group can do in response to this is revive more, track rotters, and do the best to raise the population of idle non-meta barricaders).
- Haven't you primarily been playing with a stationary group? At least for me, as a leader of a mobile survivor group, the danger reports can be incredibly helpful. They let us know where we need to go to work, tell us where the action is happening, and can cut down on the number of suburbs we need to scout to get an accurate sense for the condition on the ground. I know that we frequently use it in the SoC when we're trying to plan out missions, but I'd imagine that The Abandoned really don't have much need for them, since you guys know your area forwards and backwards at all times. Really, I think that's the actual distinction: the danger reports are useful for people who aren't there, regardless of if they are survivors or zombies. After all, stationary zombies in your area won't get any more benefit from the reports than you do, but a traveling horde or a mobile survivor group can use them to direct their activities. Also, as a quick aside, zombies can't know to both "move away and hit another target" or "gather at the same place again" when they see a ruined building, since those two ideas are mutually exclusive. It can only mean one or the other, since zombies don't psychically communicate or something. ;) —Aichon— 14:52, 13 June 2013 (BST)
- Sorry but I've been playing a pro survivor since 2005. What I'm basing myself on this matter is direct observations, evidences and experiences. I actually participated in the past in "edit wars" which, like I said before, were more like lame group boasting attempts to publicity... And they clearly were never in favor of survivors. One group take control of a building and post about it. The other group do the same. Then again. Then again. Indefinitely. But what does the survivors have to gain to know that a building is in ruin or barricaded? Not much at all even in case of a resource building. Zombies, on the other hand, know to move away and hit another target or gather at the same place again. Since there is bigger disadvantage for a fully leveled up survivor to simply keep killing zombies around pointlessly (AP, ammo, the zombies always win in the end whatever you do or try to do) why is it important for survivors to know that block X is in the hands of survivors or zombies? Really, it is not. -- •Eagle of Fire• •[Talk]• 00:15, 13 June 2013 (BST)
- Yes. That's pretty much what I think too. Thing is, this kind of public, readily available info is clearly at the advantage of the zombies rather than the survivors. As a survivor we only get there and see for ourselves, free running is not something difficult to get by. Zombies, on the other hand, have clear advantages from knowing where the next target and/or meal should be - all this at the expense of a luxurious 0 AP. -- •Eagle of Fire• •[Talk]• 00:02, 11 June 2013 (BST)
- Any zombie strategist worth anything would tell you that information should be public and accurate, the easier it is for the horde to follow you the easier it is to wreck stuff and it's the orgnanized groups that already have the information you need to worry about anyway. Feral/unaffiliated management is all about getting the word out and motivating people who are outside your meta-pool. As such I was always a fan of more active posting on wiki-news so long as it wasn't falsified, and drama over NPoV occasionally helped to stir up more visibility when people followed those pages. In the end it's just another way to keep things interesting and informative without spending AP, which is what really matters anyway since this is a wiki about informing and driving interest around the game.( and in this case the state of things in that game) --Karekmaps 2.0?! 19:24, 9 June 2013 (BST)
- Also two other notes as an addendum. The zombies that you should be most worried about don't choose targets based on suburb news, they choose targets based on the easiest path to be able to pull a horde and maintain momentum and the zombies that are left are the ones you want attacking you where you're strong, which would be where you have your active meta-users, instead of where you're weak, where you have your non-meta can't tell you when you lose stuff survivors. While survivors are directing the combat they almost always have the numbers advantage and make the most use of it when they have an instant communications network (forums for larger groupings, chat rooms for smaller). That's math and basic strategic logistics. --Karekmaps 2.0?! 17:16, 14 June 2013 (BST)
- Well, you know what? I completely agree with the vast majority of what you said. I just don't see how it is relevant with the suburb danger reports and this conversation. -- •Eagle of Fire• •[Talk]• 00:25, 15 June 2013 (BST)
- Suburb danger reports, when functioning as in your premise, draw priority of target to your place of strategic strength and when functioning as intended draw over all intention of feral/unaffiliated players who will be likely to be a net benefit when a group prioritizes non-idle functions like repairing and reviving. If a coordinated horde, for whatever unlikely reason, decided to respond to it they will bring ferals along behind them who, when appropriately responded to, will provide a net numerical benefit to survivors non-meta defense. When you strategically consider announcing and telegraphing your movements you'll be better strategically equipped to respond to them getting out there(which they will) and will always benefit. In this context, for many of those reasons, survivors have no real downside and plenty of reasons why it is a good idea. Not the least among them being that they will drive nearby killed survivors towards your area as that's one of the ways they search for active revives, via locations of active groups and news updates on the wiki. --Karekmaps 2.0?! 00:46, 15 June 2013 (BST)
- I had to re-read what you just said plenty of times to really understand what you were trying to say. I wanted to reply right away but without really realizing what bothered me I thought it would only lead to confusion. Then I went to bed and thought about it the whole day until I realized that what really bother me is that you are right... But that "my premise" was to use the danger reports completely at the opposite of how they should be used. And that's what's bothering me and why I'm ignoring them to begin with. 'Cause I don't like acting like a dork. -- •Eagle of Fire• •[Talk]• 01:09, 18 June 2013 (BST)
- Suburb danger reports, when functioning as in your premise, draw priority of target to your place of strategic strength and when functioning as intended draw over all intention of feral/unaffiliated players who will be likely to be a net benefit when a group prioritizes non-idle functions like repairing and reviving. If a coordinated horde, for whatever unlikely reason, decided to respond to it they will bring ferals along behind them who, when appropriately responded to, will provide a net numerical benefit to survivors non-meta defense. When you strategically consider announcing and telegraphing your movements you'll be better strategically equipped to respond to them getting out there(which they will) and will always benefit. In this context, for many of those reasons, survivors have no real downside and plenty of reasons why it is a good idea. Not the least among them being that they will drive nearby killed survivors towards your area as that's one of the ways they search for active revives, via locations of active groups and news updates on the wiki. --Karekmaps 2.0?! 00:46, 15 June 2013 (BST)
- Well, you know what? I completely agree with the vast majority of what you said. I just don't see how it is relevant with the suburb danger reports and this conversation. -- •Eagle of Fire• •[Talk]• 00:25, 15 June 2013 (BST)
- Also two other notes as an addendum. The zombies that you should be most worried about don't choose targets based on suburb news, they choose targets based on the easiest path to be able to pull a horde and maintain momentum and the zombies that are left are the ones you want attacking you where you're strong, which would be where you have your active meta-users, instead of where you're weak, where you have your non-meta can't tell you when you lose stuff survivors. While survivors are directing the combat they almost always have the numbers advantage and make the most use of it when they have an instant communications network (forums for larger groupings, chat rooms for smaller). That's math and basic strategic logistics. --Karekmaps 2.0?! 17:16, 14 June 2013 (BST)
Date format
DD-MM-YYYY being mistaken for MM-DD-YYYY could easily as well happen for YYYY-MM-DD and YYYY-DD-MM. Besides, there is only country in the world stupid enough for not maintaining an orderly format. --Thadeous Oakley Talk 20:51, 5 June 2013 (BST)
- That's not exactly true. There are no known cultures on earth that make use of the YYYY-DD-MM format, whereas YYYY-MM-DD is intuitive, sensible, and in common use in a number of nations and cultures, meaning that ambiguity is essentially as unlikely as it can possibly be in this context, and that the one being mistaken for the other could not happen very easily at all. In contrast, you and I are both aware of how ambiguous DD-MM-YYYY and MM-DD-YYYY can be when dealing with people from around the world, since there are billions of people on one side and hundreds of millions on the other. And while I do agree that the US' MM-DD-YYYY format is "stupid", I'd also fault those who use DD-MM-YYYY for "not maintaining an orderly format", since it doesn't order itself chronologically when lexicographically sorted, which would seem to be an obvious trait that would be desired. Long story short, ISO >>>>> everything else. —Aichon— 21:27, 5 June 2013 (BST)
- May I cut in?
- Scratch this in case you feel that it should be left out for any reasons.
- Well,if there's an automated signature imprinting the exact date and time (such as the above:5 June 2013 (BST)),then either ways the format would become clearer by comparison.
- Even so,I'd have t concur that keeping a standard format may help everyone making things simple,clean and clear for all eventually.
- It may work with having the month alphabetically written. That solves showing dates such as 2012:6:8 or 8:6:2012.
- Also,when in Rome-do as the Romans do.
- Concerned'Citizen 07:27, 6 June 2013 (BST)
- There was some context to this conversation that you're unaware of. We were talking about the Sysop Check page, and since it uses future dates, we can't use auto-generated timestamps like we can with signatures. —Aichon— 15:51, 6 June 2013 (BST)
- As a point of fact the stupidiest(logic wise) date order is actually day, month, year. It's ass backwards when you need to know the year to know the length of days in a month and you need to know the month to know the length of days in a month. Logically it follows that Year, Month, Date is appropriate and forgiving movement of year to the end for common practice reasons(since you're basically supposed to know the year regardless) months limit days and has informational priority. So really it's all about how China and Japan calculate time. Anyone defending anything else is arguing for idiocy and at least middle-endian doesn't completely abandon logic when vocalization makes it the vocal big-endian.(You say November 5th not November 5th, 2013 when talking in the current year). Also, in addendum, the 'more people use it' argument loses ground when you know that India uses both month day and day month with one being the governmental method of practice since they were a colony and the other being the one popular in it's culture and media. --Karekmaps 2.0?! 08:01, 6 June 2013 (BST)
- Additionally now it can sort dates right with the exception of year followed by month Abbrevs but you all should still follow ISO 8601 because it's just right. --Karekmaps 2.0?! 08:42, 6 June 2013 (BST)
Editting User Pages
I was looking around at all the pages that call on the 5000 or so danger report templates, and I noticed that a lot of them were userpages. Since we're experiencing so much lag these days when the danger reports get updated, I was wondering if I could delete or disable the superfluous ones? Putting nowiki tags on them, with a little explanation that we disabled it because of performance issues and because they were unused. Problem is: they still are other peoples' user pages and I'm not sure what the wikipoliticians and wikilawyers would say about this, so any advice? PB&J 14:51, 18 June 2013 (BST)
- The lag isn't from them. The lag is from the Danger Center needing to re-grab all 5000 templates every single time a single one of them changes, since the cache for the page needs to be recreated. Right now, updating a danger report might kick off, say, 5000 updates for the Danger Center and another 10 updates for the other pages mentioning that danger report, giving us a total of 5010 updates to do. Quite obviously, removing the 10 won't have a significant impact on performance. —Aichon— 15:11, 18 June 2013 (BST)
- Quite a lot of the pages I'm talking about are like this one, and call on about 50 everytime a single one of them changes. If we look at the "What links here" of the first one in the topleft corner, Special:WhatLinksHere/User:DangerReport/Palprey_Road_Police_Department, one which is among the lesser used ones and lesser known ones, we see that several of those pages call on dozens of templates, including used, unused and personal test status maps, as well as specific building status maps (in this case the PD Status Map. That could amount to quite a lot of pages, each calling on a couple dozen templates, just for one danger report update, no? PB&J 15:18, 18 June 2013 (BST)
- In this case it would make no difference because it's a by page thing and not a by call thing. --Karekmaps 2.0?! 16:50, 18 June 2013 (BST)
- I still don't really understand? The lag increased when we added the danger center, and it occurs more when updating the danger reports than when you look at the center itself. AFAIK the amount of times a danger report is called upon has a direct influence on that lag, ergo reducing the amount of maps that call upon a danger report should reduce the overall lag. Right? PB&J 16:59, 18 June 2013 (BST)
- What Karek is saying (and what I was typing up before I saw that he had already linked exactly what I was going to say) is that the Danger Center is a gigantic job, whereas the other pages are not. The reason that matters, is because the wiki is configured to process one job in the queue per page load. As such, those smaller pages are not even getting processed at the same time as the Danger Center and are thus in no way contributing to the unresponsiveness that people are suffering. To draw an imperfect analogy, the job queue is like a relay race where every time the baton is passed a page gets loaded for a user. In this race, some runners (jobs) are slower than others. Quite obviously, you can improve the speed of the faster runners all you want, but you'll still be waiting the exact same amount of time for the slower ones to complete their laps and pass the baton. So, more or less, those smaller pages aren't contributing to the problem at all, since the unresponsiveness they create is separate from what people are complaining about and is small enough that most of us have never noticed it at all. —Aichon— 18:39, 18 June 2013 (BST)
Technical gobbledegook-> Yeah, sorta this. Basically everytime you load a page the job queue processes 1 job. Everytime you have a template on a page it loads a function and then on repeat calls of the template it just references the already loaded function. Different templates do have different costs but that's based on the size of the initial template, not so much the number of times it's called(which has a much smaller impact). Everytime you call a unique template the server has to go and make a new database connection and call that template's page content to then queue it up for the preprocessor/job queue. Batch processing it with the job queue means instead of having a half hour of horrific lag(where you have thousands of database connections and nothing can load) you queue up the change and then half multiple hours of much more negligbile lag(where you just double the normal page loads).Super simple version is instead of having 5000 pages load when you edit danger reports it makes it so that for the next 5000 pages loaded you're basically loading 2 pages. --Karekmaps 2.0?! 18:49, 18 June 2013 (BST)- It sounds like you may have accidentally said the opposite of what you meant. Just to double check, as you said above, the queue adds jobs on a per-page basis, which means that the Danger Center is processed as a single job, just as each of those other pages is also processed as a single job (though clearly the Danger Center is a larger job). When a user visits a page, the wiki does the job at the front of the queue before it delivers the page to the user. When a danger report gets updated, each page that transcludes that danger report will receive a corresponding job to update the page. For those smaller pages, because they each have their own job, they get spread out over a number of page loads and cause no noticeable delay. For the Danger Center, it too is done as a single job attached to a single page load, but because it's a much larger job it creates an extremely noticeable delay (i.e. it does the 5000+ db operations you're talking about). I think that's what you meant to say, but please correct me if I'm mistaken. —Aichon— 19:55, 18 June 2013 (BST)
- A lot of this is going to be process descriptive but not exact to how the code runs. It functions like a php include that contains a class with only a single method that's being batch processed. What happens is essentially when you update a template it checks to see how many rows return in the table(see picture below) of transclusions. It then adds those pages(where the template is transcluded) to the jobs queue if there are more than a certain number.
The jobs queue then runs a preprocessor on each of those individual pages. The preprocessor runs through the page content sequentially until it finds text matching what it sees as a template call. It then runs that call through a check against all other held templates/functions already preprocessed, if it returns that none are already stored it queues up a database call to the page(usually a template) being transcluded. It searches for include only tags then for noinclude tags to determine content and then converts the uneliminated text into XML Trees and stores this as a callable variable to be referenced when the same template is called later in the text. That means it only calls the template from the database once per page instead of however many times the template is included in the page.
Once the preprocessor sets limits on the generated text size for the final result and stops converting template content after a certain point. There are a number of reasons for this but the biggest one I can imagine would relate to the topic of this white paper microsoft released a few years back(pages are stored in blobs) about large file vs blob performance. The end result all then gets thrown through the parser when the page is called which converts wikitext like to it's output state.
My understanding is thus that when a page does not hit the rows returned in the 'Pages Included On' check it runs the preprocessor in reverse, thus processing all of the pages then and there making x calls where x is the amount of pages it's included on. When it determines that this would be too much strain for the server based on the limits set it instead queues them up for batch processing so that the calls are processed at a set interval and not all at once. --Karekmaps 2.0?! 03:07, 19 June 2013 (BST)- I love the technical description (honestly, I do), but that's actually tangential to what I was asking. You already explained the details below, and I thought it was well understood that that's what the function of the job queue is, since it's basically just "baking" elements for later use. What I was talking about was specifically the un-struck line you left, since the problem we're having is that it's not being broken up into 5000 jobs, which is what it sounds like you were suggesting is happening. That's why I said you sounded like you were saying the opposite of what you meant. ;) —Aichon— 05:34, 19 June 2013 (BST)
- I was insanely oversimplifying, the default value is 500 operations and each job itself is 500 operations. So with a current job queue of 6 that's roughly 3000 transclusions. Basically it is just the numbers are obscured, additionally Kevan might have changed it but it's unlikely. --Karekmaps 2.0?! 06:16, 19 June 2013 (BST)
- I love the technical description (honestly, I do), but that's actually tangential to what I was asking. You already explained the details below, and I thought it was well understood that that's what the function of the job queue is, since it's basically just "baking" elements for later use. What I was talking about was specifically the un-struck line you left, since the problem we're having is that it's not being broken up into 5000 jobs, which is what it sounds like you were suggesting is happening. That's why I said you sounded like you were saying the opposite of what you meant. ;) —Aichon— 05:34, 19 June 2013 (BST)
- A lot of this is going to be process descriptive but not exact to how the code runs. It functions like a php include that contains a class with only a single method that's being batch processed. What happens is essentially when you update a template it checks to see how many rows return in the table(see picture below) of transclusions. It then adds those pages(where the template is transcluded) to the jobs queue if there are more than a certain number.
- It sounds like you may have accidentally said the opposite of what you meant. Just to double check, as you said above, the queue adds jobs on a per-page basis, which means that the Danger Center is processed as a single job, just as each of those other pages is also processed as a single job (though clearly the Danger Center is a larger job). When a user visits a page, the wiki does the job at the front of the queue before it delivers the page to the user. When a danger report gets updated, each page that transcludes that danger report will receive a corresponding job to update the page. For those smaller pages, because they each have their own job, they get spread out over a number of page loads and cause no noticeable delay. For the Danger Center, it too is done as a single job attached to a single page load, but because it's a much larger job it creates an extremely noticeable delay (i.e. it does the 5000+ db operations you're talking about). I think that's what you meant to say, but please correct me if I'm mistaken. —Aichon— 19:55, 18 June 2013 (BST)
- What Karek is saying (and what I was typing up before I saw that he had already linked exactly what I was going to say) is that the Danger Center is a gigantic job, whereas the other pages are not. The reason that matters, is because the wiki is configured to process one job in the queue per page load. As such, those smaller pages are not even getting processed at the same time as the Danger Center and are thus in no way contributing to the unresponsiveness that people are suffering. To draw an imperfect analogy, the job queue is like a relay race where every time the baton is passed a page gets loaded for a user. In this race, some runners (jobs) are slower than others. Quite obviously, you can improve the speed of the faster runners all you want, but you'll still be waiting the exact same amount of time for the slower ones to complete their laps and pass the baton. So, more or less, those smaller pages aren't contributing to the problem at all, since the unresponsiveness they create is separate from what people are complaining about and is small enough that most of us have never noticed it at all. —Aichon— 18:39, 18 June 2013 (BST)
- I still don't really understand? The lag increased when we added the danger center, and it occurs more when updating the danger reports than when you look at the center itself. AFAIK the amount of times a danger report is called upon has a direct influence on that lag, ergo reducing the amount of maps that call upon a danger report should reduce the overall lag. Right? PB&J 16:59, 18 June 2013 (BST)
- In this case it would make no difference because it's a by page thing and not a by call thing. --Karekmaps 2.0?! 16:50, 18 June 2013 (BST)
- Quite a lot of the pages I'm talking about are like this one, and call on about 50 everytime a single one of them changes. If we look at the "What links here" of the first one in the topleft corner, Special:WhatLinksHere/User:DangerReport/Palprey_Road_Police_Department, one which is among the lesser used ones and lesser known ones, we see that several of those pages call on dozens of templates, including used, unused and personal test status maps, as well as specific building status maps (in this case the PD Status Map. That could amount to quite a lot of pages, each calling on a couple dozen templates, just for one danger report update, no? PB&J 15:18, 18 June 2013 (BST)
- This may help some. The Job Queue, from my understanding, basically functions like the preprocessor for templates so that the stored wiki text can be served faster on significantly large template calls to minimize load time. Templates are thrown into the job queue based on how many pages need to be preprocessed and it converts them into wiki-text/html there. Because job queue processing isn't done through a cron or based on server load it's happenning while other things are being done on the server, so lag will increase be it 1 template call on a page or 10 as it's running the same script either way. As far as impact on performance, because there's no additional complexity to the call(you should only have to queue up the template's content once regardless) it's of neglible impact of processing speed. You get a bigger impact from an increase in unique templates as 0-1 is where you're having to open a new file stream or make a new databse connection(which is likely the cause of the lag). Preprocessor ref. This is also one of many reasons templated signatures suck, they slow down the wiki for everyone, particularly more so the more pages they're on. --Karekmaps 2.0?! 18:43, 18 June 2013 (BST)
Too bad, I really hoped to optimize this whole thing... Then again: the danger reports are updated regularly these days, even more with BB4, and that was always one of the goals :) Maybe I'll go on a little wiki-patrol later today and just list a ton of stuff that can be deleted or otherwise archived to clean the whole wiki a bit out. PB&J 12:54, 19 June 2013 (BST)
- If you want to optimize these pages you could make the core templates use non-wikicode code, here's a list m:Help:HTML_in_wikitext, it'll reduce the work done when the parser runs. --Karekmaps 2.0?! 22:12, 19 June 2013 (BST)