Naero

This error is occurrent because your Pokemon's caught date, which needs to be cross-compared with the date you started the task to ascertain whether it's eligible for points or not, has yet to be registered in the database; because of that, the value is not yet in the notation needed in order for the string-manipulator's function to properly parse it and thus it's misformatted. As you discoveredly know, relogging resolves this, as it will force-save it into the database; this also needs to be done every time a new Duskull is captured to expedite its saved caught data, as it takes the server a plodding rate of time to save it in the database. Unfortunately, there is no fix I can make on my end, as scripts themselves lack the capacity to force-save it, but I will add another explanatory clause to the script to advise the user to log out if it evaluates that the caught data has yet to be saved.

I've already submitted a fix for this a while ago, but it has not effectuated yet due to the lack of a reboot since then. I have recently overhauled the back-end framework of this system to register and allocate memory more efficiently, but the script deadlocks at that point due to an oversightful typo I've added in the script; effective next reboot, however, that should no longer be an issue.

________________________________________________________________________________________________________________________________________________ I will preface this thread by underscoring the fact that we cannot case-specifically return any lost items or Pokemon, nor can we reset cooldown times if you're penalized by one due to a rollback; any posts made asking for that only serve to pollute the forums and will be deleted as such. I can not make any promise that any absolute resolution will be made for the entire issue anytime soon, but I can promise that sifting through this thread will make you more informed on rollbacks and how to potentially elude the often-inevitable event. With a glaring trend of reports for rollback-reverted items, a cascade needs to be made on this entire plight—both to help users stay on their toes to possibly stave off rollbacks, and to inform those rollback-plagued users who are turning here for a solution. ⋯⋯⋯⋯⋯⋯⋯⋯⋯ Rollbacks occur whenever the server was unable to successfully save newly gained progress—in which case, the data in the database remains changeless, as that newly gained progress—while temp-held by the server for your log-in session—never registered in the database. This mostly commonly occurs in the wake of a server crash wherein data was gained after Point A (the last saving point), but the server crashed intervened with Point B (a would-be saving point, had the server not crashed before it). Additional but much more uncommon causal scenarios can be when your computer logs you out abruptly, such as during a sudden shut-down; in those cases, progress may also end up unsaved, as it did not give your game client ample time to query the database to save it before your computer force-ended the client. Due to how onerously taxing it would be for the server to insta-save all data—especially for the more data-rich characters of data—the systematically scheduled saving points of some data need to be regulated more strictly; as that opens up a broad window for Pokemon data, which are among the larger-scale data types for the server to save, nature dictates that those are the most commonly lost. These saving-point intervals aren't bound to be deregulated due to those reasons, but we do hope to minimize the frequency of server crashes in order to forestall more rollback cases moving into the future. ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯ As long as it is possible for the server to crash, which is perpetuated as new, potentially deadlock-inducing server-coding is added, the game will never be absolutely devoid of potential rollbacks; it will be a minefield wherein the mines are irremovable, but it is possible to tread through it when regardful of precautionary measures. Relogging. This is usually is the ticket to staving off most rollback cases. By relogging, you effectively force-save the data, as your client tells the database to save your data to ensure that it's retained by the time you log back in. Because the client needs a little time to processually communicate with the database to save it, you are advised not to "force-end" your client—be it through terminating it via the task-manager prematurely, insta-shutting off your computer, and so on. Due to varying data-type integers used, different forms of data take discrepant amounts of times to save. While account-side data, items, quest variables, and so on all fold into a pecking order, they all tend to insta-save within a few minutes; it's Pokemon data, on the other hand, that takes longer to save (5-20 minutes) and thus runs the biggest risk of a rollback loss. Since all Pokemon-specific data is lumped together and saved synchronously, I would advise relogging when any of the following data changes happen to your Pokemon: Capturing it. This is obviously the most primal, as your Pokemon's existence will be lost if no Pokemon-data saves occur before a server crash. Equipping an item to it. This is also critical but more overlooked, since it can cause Held Item losses. Since item data consists of only a few points, the server manages to insta-save the fact that it was removed from your inventory, but the item will then embed itself into the Pokemon data of the holder; that means that if Pokemon data fails to save after the item is removed, there is a good chance that the item will be lost, because it will revert your backpack's state to a point whereafter the item was already removed from it. Evolving it. This may be a more negligible contingency for Pokemon that evolve on a level-up basis; but when an evolutionary item is expended in accomplishing the evolution, there is more at risk than a simple retrogression. Due to the reasons precedingly explained, item data saves at a much more systematically frequent rate than Pokemon; resultantly, you could see yourself losing both the evolutionary item and the evolution it induced if you item-evolve a Pokemon before a Pokemon-data saving point. Expending an item on it or paying for a service. Whenever you use an expendable item on your Pokemon—be it a healing item, TM, evolutionary item, vitamins, and so forth—you risk losing the aftereffect of the item's usage and the item itself, as items will embed themselves into the Pokemon's data while it's possible for item data (the usage of the item) to save before it—in addition to money expended, such as on a move-tutor. Whether it is worth relogging to preserve the aftervalue of more mundane items, such as a potion, is your call; but if you're more frugal, you may want to habituate relogging after such changes to ensure that the more invaluable expenditures don't end up rewardless in a rollback. Trading. When trading for a new Pokemon, it may also be a considerable amount of time from Point A (trade-acquiring the Pokemon) to Point B (a Pokemon-data saving point); as such, it's a broad window of time for the server to crash and intervene with saving it. If it's a money-for-Pokemon trade, it is especially urgent to log out, as the server will be faster to save the fact that money is lost than it will be to save the Pokemon's new account-holder. ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯ Due to the varying saving-point intervals, it is possible to lose data while the entire control flow of obtaining it ends up disordered; for example, if the only method of obtaining an item was through a one-off NPC and a server crashed thereupon purchasing it, the server may have registered the fact that you've used up your one chance to buy it while failing to save the item, thereby deadlocking you from obtaining the item. I've devised similar NPC-oriented solutions for this in the past, such as Professor Oak giving you a new starter Pokemon if your starter Pokemon rolled back, and I will try to be amenable to adding more fallbacks for similar predicaments as they come to my knowledge. The exact data you lost will be irrecoverable, as we have no means of systematically authenticating that the item was obtained and lost via a rollback before manually returning it; but through systemic means, we can mitigate the damage of rollbacks and clear up progressional deadlocks caused by it. Before making such a suggestion, however, the following questions must be addressed: is an essential source of obtaining the data gone (such as an NPC disappearing)? Is it possible for scripts to discern that it was lost due to a rollback? Is the data indispensable? For some questions, only scripters can give a definitive yes, but it is food for thought before raising up a suggestion to obtain it.

Hello, and apologies for the inconvenience. As it is impossible to authenticate that the item was ever obtained, we are unable to return lost items. We always have our crosshairs on fixing the underlying causes of the server crash to obviate these rollback occurrencies, but it is a growing pain that we can not always stave off before an absolute fix is in-place. Rather than levying extra compensatory work on the staff, however, we prefer to look into systemic fixes; in this case, we need continuity to the obtainability of these items, which was only obtainable as a one-off item upon trading from the NPC. As of now, however, you can rebuy the Macho Brace for 20k from the same Machop-trader once every 18 days. If there are any other irreplaceable items—once-obtainable items from an NPC that are not obtainable from any other non-luck-based challenge—I would like to look into to apply a similar solution. For now, I would advise taking the following steps to prevent such items from being lost on the coattail of a server crash: 1. As soon as you obtain any keep-worthy assets, I would advise immediately logging out; this will force-save the item, as it will forcibly register it in the database to ensure that the client reloads it when you relog. 2. Whenever you any holdable item to your Pokemon, log out immediately; otherwise, if a rollback occurs before Pokemon data saves, your item will be lost. As soon as you equip an item to your Pokemon, it embeds itself as apart of the "Pokemon data." Due to the multitudinous scope of Pokemon data that needs to be saved—its thousands of experience points, stats, equipped Held Items, and so forth—the server is set to save Pokemon data at longer intervals (10-20 minutes) than item data in order to counter-regulate the otherwise-excessive amount of queries that are sent to the database; the action of equipping the item to the Pokemon, however, only requires a few data points to be registered and thus can be successfully insta-saved by the server. Therefore, if a Held Item was recently equipped to your Pokemon before the Pokemon data saved, your Pokemon data will be reverted to the last state the server saved it at; that means that the Held Item will down in the same ship, as it (hypothetically) wouldn't have been saved as apart of the Pokemon data during the previous saving point.

This is being looked into as we speak; thank you for reporting. I will need to examine the scriptwork in the most up-to-date map files to pinpoint the issue; I'll need to await Nikola to be around before I can do so. I have only made one change to the area recently, and since it should have had no impact on the control flow of the quest, I assume changes were made elsewhere that have engendered this issue.

Re: SS ann dale.. Not solved. <t>By the juncture I marked it as resolved, I've already made the fix and funneled it over to be uploaded to the server. It will require a server reboot to effectuate it in-game, however, which has not yet occurred but is bound to coincide with the current downtime; by then, it should be uploaded in-game and no longer an issue.</t>

@drvirus Thank you for your suggestion. Regardless of disagreements on its practicality, you have volunteered interesting outlooks and well-thought-out viewpoints, which is all we can ask users to contribute when posting suggestions. Regardless of its (im)plausibility, it does raise interesting concerns for the economy which can segue into other solutions if needed, which I would be interested in discussing. Now onto addressing your issue: the biggest issue is that your suggestion is geared towards changing how the current system operates when the current system isn't even causative of it; rather, it exists mainly because we are working with a sample-size of the long-term economy as we speak. I will explain more on that later, but I will start by addressing why this issue isn't glaring enough that we need to make drastic changes to the landscape of the economy, which your suggestion would do. It appears that the underlying concern is the growing disparity between rich and poor players; how problematic is it when we contextualize it? PRO's economy is incomparable to real-world economies, which changes the entire complexion of the issue; unlike real-world economies, you do not need money for livelihood. All expenditures made with Pokemoney serve nothing more than to buy resources with one's self-worth, not because the failure to obtain those resources would have grave ramifications as they would in a real-world economy—indigent inability to afford food, shelter, and so on. It's always possible for there to be a colossal gap between the rich and poor classes in any economy, but whether or not it's an issue in PRO's economy depends on how that disparity was formed to begin with. The economy in the game you are likely referring to indeed had the gap, but that in itself was not an economic issue; it was merely an aftereffect of an inequitable economic system, and the causal factors of it served their own, discrete issue—whether or not there was parity of opportunityp and resources in achieving the same wealth. In that game, the socioeconomic differences were centered around the pay-to-win potentiality of the game; donators gained a tremendous advantage over non-donators, simply because they had means of obtaining enviable resources (UC shinies, etc.) that not everyone had the monetary resources to donate for, and it thus became a bigger determinant to wealth than a player's gameplay efforts did. We've taken counter-regulatory measures against that issue by not making any economic assets available as much as aesthetics and cosmetics—resources that serve only to enhance the appearance and elegance of the user without making any splash in the economy. Broad rich-poor gaps may exist, and while there will never be equality for the wealth, there will be equality for the opportunities to obtain that wealth. Everyone is is put into an equitable to obtain the consummate Pokemon that are highly coveted as long as they put forth the effort and have the luck in hunting that Pokemon. To make landscape-shaping changes to the economy would be totalitarianistic on the staff's part, and that is oftentimes what causes inequities and undermines the players' role in jumping into the economy to begin with. As for your suggestion to remedy that supposed problem: even if there was a necessity from it (will explain why below), it would only be a short-term solution at best; such stopgap solutions are not wise or prudent to change the landscape of the economy over—especially when it poses imbalance to other aspects of the economy, such as the diminishing of shiny-Pokemon values. Pokemon may be high-cost on-paper at this time and thus more unaffordable to newer players, but those prices are dynamic and changeful enough that it wouldn't be imprudent to try to create a system to stimulate change when it's inevident that the exact change is even going in a bad direction. If anything, time will only make those covetable Pokemon more affordable. With all the money sinkholes that exist with the variety of purchaseables and services (transportation systme, per se) and limited moneymaking methods in comparison, the economy is in a disinflationary position; as such, the total amount of Pokemoney in circulation will (theoretically) remain fairly steady. Pokemon on the other hand? They will accumulate in the economy overtime and will only cease to circulate if they're locked in an inactive/banned account or released, and all the ideal Pokemon will increasingly accumulate in the economy's circulation. As Pokemoney will not be pumped into the economy at the same rate, you can theorize that the amount of Pokemon in supply will eventually outbalance the demand with Pokemoney, which will make them more easily affordable as there are more Pokemon to buy. Bottom line is that the issue you're addressing can very well be solved over time through economics dynamics, more money sinkholes, and more stimulated allocation of Pokemon with the advent of the Auction House, and it would do more harm than good to try to make radical changes in the economic system when the issue itself is negligible enough—remember how it differs from a real-world economy—that chances do not need to be taken to immediately fix it.

Recently, I have amended the digway outlets to require you to interact with the inceptive script on the rear-end side of the tunnel before you have access to the front-end tunnel. Previously, badges of the immediately successive town were required to access the digway; however, as my digways restrictions were intended to force the player to explore the cave at least once before this shortcut was usable, I decided to liberalize the requirement by changing it from badges to interacting with the exitway first—especially to allow players to use the digway if needed before they obtain the previously required badges. Nonetheless, the exitway-script problem—the one cited by leotosi, specifically, wherein one can not use it to access the frontal end—is indeed a bug, it has been brought to my attention, and it has been fixed accordingly earlier today; it is merely pending a reboot of the server before it can effectuate. Thank you for reporting nonetheless. :)

I can confirm that it has been deliberately disabled for now, as duplicatively exploited items were sold to it and an immediate stopgap fix was needed to prevent them from further commercializing those exploited items. While the item exploitation is a discrete issue from this script and assuredly should be fixed by now, the staff has also collectively agreed that the Item Maniac in itself needs to be re-examined and refined with its item and price selections--especially for consistency purposes with other junk-buyers--before it can be made serviceable again.

1. Due to how your account-session ID is encrypted to PayPal when clicking on the donation link in-game, it registers in the game database which account clicked on the donation link from the coin shop; it then ties the session ID to the PayPal transaction (you can see it in the URL; it has hashed whenever PayPal is accessed from an externally linked 'donate' button) to that account, and it then designates that account as the recipient of the coins once the transaction is complete. This is a common protocol used for most websites that are interlinked with PayPal, and it's the authenticator used to verify which account is making the transaction when making the donation from an external link. 2. Currently the coins-per-purchase rate is not scalable; this may be amended in the future, but you can currently only donate $5 for 100 coins at once. You are allowed to make multiple, discrete donations to obtain more coins, however.

Put into perspective the current rate in which inappropriate nicknames must be moderated, and then contextualize how players are able to pluralize the nickname creations with Pokemon, due to how many more Pokemon exist than accounts; one can envision tenfold the amount of moderation needed for the latter. Inappropriateness is obviously a risk we're needfully taking with accounts, as it is the only visibly unique identifier to accounts; but in the case of Pokemon nicknames, the essentiality of that feature is outbalanced by the moderational concerns that would stem from it. The only negotiable compromises for the vault to be opened for user-custom Pokemon-nicknaming is to either impose lofty enough requirements, such as requiring that the player must be deep enough in the game wherein most wouldn't risk venturing into bannable territory for such a stunt, or--more plausible--if the nicknames were only client-sided--in other words, only displayable to the owner.

Hello, I'm not going to sugarcoat problems that we as staff may have when interacting with players; we are not infallible or even tenable when it pertains to our public behavior, and anyone who thinks we are is blurring fundamental differences between a professional and volunteer-driven staff. As this is the first experience on staff for a volunteer game for many of our current staff members, many are only getting their feet wet in the delicate realm of player-staff interactions and thus it can be a growing pain on both sides as they find the poise for interactions—especially in a new, upsurgent community that is more high-interaction. With that being said, using caustic generalities, which may be the takeaway of some in this topic, will not help. It only makes it seem as if your goal is to take jabs at the staff more so than to make amends; whether that correctly reflects your intentions or not, many are inclined to have that takeaway at face value, and thus it is always advisable to emphasize one's post on constructive criticism more so than personalizing an issue to help make ends meet. We value the staff-community relations, which can oftentimes be the X-Factor in one's decision to stay with this game or not—particularly when it pertains to first-impression attitudes towards the project. What players do not see behind the scenes as much is the initiatives the administrators, among other staff members, make in attempting to correct the staff's behavior. Without specifically giving us pointers as to where the issue is with a staff member's behavior, however, we are as good off as taking a shot in the dark with what direction to go in rectifying it. If this topic ends up locked, it will be done so not because it vilifies the staff but because it is coming across as a potentially toxic minefield that not everyone will tread through carefully. If the goal of this topic is inclined towards constructive criticism for the staff, I would be interested to help veer it into that direction; otherwise, if that constructive-criticism purpose is clouded by a more vitriolic theme in this topic, no one will be better off from it.

Currently, the scripts yield no chance of a shiny counterpart of the starter-Pokemon selectees to spawn. In order to disicentivize starter-farming, we need to omit external variables, such as this, that would encourage starter-farming for players to create new accounts repeatedly until the luck lands in their favor—at too early of a stage in this. Starter Pokemon are obtainable via other sources later in the games (as huntable spawns, Mystery Egg eventualities, etc.); in those mediums, there will still be a chance of obtaining their shiny counterpart, thereby giving an alternative avenue to obtain them. Due to the aforementioned reasons, however, it would do too much of a disservice to make starter-Pokemon scripts potentially reward Shiny Pokemon, as they are far from an indispensable medium for shiny Pokemon while also doing a disservice in the account-farming it would promote.

This was actually initially intended, as I wanted to preclude any potential experience exploitation for rebattling Jackson while he has no cooldown time; that has been the set-up for most quest-compulsory NPCs, as we wanted to interbalance the need to allow players to rebattle them instantly to complete their quests seamlessly while also curtailing experience abuse, and the no-experience parameter for battles has been an agent for that. However, we have methodized a compromise a few months ago for gym-leaders wherein experience was yielded for the initial battle but nullified for any subsequent ones; that has been nothing more than an afterthought for quest NPCs, and it is one I will apply here. Effective next reboot, Jackson and Giovanni will both reward experience for the initial battle, while any follow-up battles—contingent that you have lost the first one—will not include any experience payouts. Thank you for reporting.

In the expectantly large-scale playerbase, it's important to contextualize that due to the bevy of hunters that'll inevitably hunt for the statistically optimal competitive Pokemon, the ideally competitive Pokemon will be accumulated in the economy over time and thus they will be made obtainable for those who tap into the marketplace as well. Even if one is not willing to commit to the huntfest needed to obtain the the competitive Pokemon, they will be still be made eventually as marketplace hurdles will serve as a different avenue to obtaining them--for the Pokemon of a designated level range, IV permutation, Nature, and so on. As others alluded to, however, the main differentiator between a battle-simulator and an MMO complexion is the fact that assets must be obtained through PvE (Player vs. Environment) hurdles--be it through hunting or expending the money needed to buy the enviable Pokemon--as the PvE aspect is an intricate part of any game that puts chief emphasis on the virtual world for players to progress. I do agree that it is an onerous tedium to hunt for and obtain all the cream-of-the-crop Pokemon for the PvP culture; but MMOs entail that you not only use Pokemon effectively but also invest the effort needed to obtain them in order to succeed, and it is a growing pain that all players are subjected to and one that should be left as rewardful to those who make the effort to obtain the Pokemon needed in whichever standardly avenue possible.

Hello, and thank you for raising up this discussion. I've intended to re-examine this myself, as this has been considered an almost haphazardly selected resource and is reasonably untenable in that viewpoint. With the anticipative release of the game within horizontal eyeshot, the window is closing for a sensible time to change in, especially in regards to all the aftereffects of changing it once Espeon has been (hypothetically) rewarded to players already post-release; therefore, there is no better time to re-examine it than now. Yes, I have selected Espeon mainly for lore-related reasons—that is, as a nod to the protagonistic Eevee in the manga. As the framework of the script's storyline was inspired by a Team Rocket subplot of the anime, I've intended to underscore that very element of the questwork by rewarding the centerpiece of it in the Espeon. One would espouse, however, that economic factors, such as the theoretical erosion of Espeon's price, should outbalance, if not work hand-in-hand, with the value of lore-related elements infused in the quest; as such, I would agree that it would not be worthwhile to reward it in an already-evolved form in Espeon, and now is the time to refine any economic imbalance wherever we can before we actually move into the formational development of the economy post-release. Effective next reboot, an Eevee will now be rewarded via the Rocket Hideout quest rather than one of its evolutionary branches. It will also be rewarded as a level-5 Eevee, rather than the level-26 form it was initially in, as the level-26 value served no purpose aside from storyline-related purposes (namely, being on the exact level that you battled the Eevee before obtaining it), and that assuredly is a trivial detail compared to how appreciable it'd be to players to start with a low-leveled Eevee. Thank you for the feedback, and if you have any follow-up suggestions on the recent update (see: previous paragraph), now is the time to raise them up—optimally before the release, as all already-implemented resources will become much more rigid when endless continuity comes into play.

For those that spontaneously spring to mind: Zelda (because there's universality to how befitting of a pet name it is for any species!), Venus, Scarlet, Ember, Helen, Marlene, and Mittens—all of which I can think of off-hand, based on my own history of custodianship over cats in addition to cat names I recently saw that are fresh in my memory bank.

Effectuating next reboot, this will have been fixed. Thank you for reporting!

As character customization is too multiplex for the gender of the account's registrant to be registered anywhere within the database upon initialization, it's indiscernible to scripts as to whether its interactor is male or female; as such, many have assumptively opted to "male," while there really should be no gender inflection at all in the scripts. :P I've amended the script to inflect the referent based on their username rather than a gender-specific inflection; in this case, it would be on the phraseological handle of "Now, Dragonair, kill Frosliss!" instead. :P Thank you for reporting, and I would encourage any testers to report any gender-specific referents in scripts, as I would advise all scripters (including myself) to start dishabituating that.

Due to a causally different reasons, we have wanted to re-open S.S. Anne for post-quest access; we've planned to instigate continuity in it as the housing site for expansive questwork in it. While that has not been materialized yet, as we have situated most major content-oriented work on the back-burner while we're focalizing bug-fixing already-existent content, I would not oppose re-opening the S.S. Anne for post-quest NPC-training; as such, I will edit the entryway scriptwork to allow you entry into it. Do note, however, that in order to curtail inordinate amounts of experience earned from the bevy of NPCs in the S.S. Anne, a one-week cooldown time will be imposed for most NPCs. Hopefully that should not be too harsh, however, as the cooldown time may have already elapsed to many by the time they feel they need to turn all stones for preparatory training for the Elite Four. :) For a storyline overlay, however, you will only be able to board the ship for an hour before it "departs" again; by the time it departs, you will automatically vacate the ship, so sweep through the NPCs in a timely manner. ;)

While I have not immediately mulled over the rest of the suggestions, I've already added in an NPC-trader to trade you Bellsprout (effective next reboot), as I believe it is essential for players to have ultra-advantageous Pokemon obtainable early on for their first gyms. The NPC is Madeline in Viridian City, who will give a level-5 Bellsprout in return for Pidgey—with a slightly unorthodox stipulation; you will need to hunt for a Pidgey with at least two 15-IV stats, specifically for Pidgey's Attack and Speed statistics. If my math is not formulaically wrong (16/32^2 * 1/6^2), the odds of capturing a Pidgey with at least two 15-IV stats with particularity to the specific stats calculate to 0.00694%—1/144, in fractional notation, so it should hopefully serve as a reasonable challenge without treading into "overkill" territory in relation to the reward. As I've espoused the philosophy that players should not feel the need to dictate long-term decisions, such as starter-Pokemon selections, based on short-term decisions in an advantageous lineup merely for the first-few gyms, I've been meaning to facilitate pre-Brock training myself; as such, I'm hoping this nPC will take Brock out of the equation for the parameters used to select starter Pokemon in Kanto—especially due to the ubiquity of Charmander-selectors. Thanks for the suggestions!

To retouch on this, for whoever it may concern, I should announce that Pokeballs are now buyable in Celadon City's departemnt store—on floor 2, wherein I've scripted a multi-category seller for Pokeballs, Potions, ailment-curing supplements, and a miscellany of other commodities. Thank you for raising it up. :)

Not to lord over anyone, but I would implore that everyone embedding pictures in their posts—especially multi-pictorial posts—to habituate inserting their pictures within spoilers; see the syntactic exemplification below. [spoiler][u]image-url[/u][/spoiler] Spoiler-concealing pictures is generally an advisable practice among the forums, as it will minimize the amount of immediate content loaded on the page and will thus quicken how fast the page loads and be more navigation-friendly to readers; but as this topic is naturally one of the biggest hotbeds for post-embedded pictures, it's the one I would like to stress the principle for more. The OP has been instructionally edited to adopt this advice. Thank you in advance. :)

All have been correctively revised. Thank you for reporting. :) Regarding the Pokemon Center error: it has existed not because we have been acceptant of the imperfection, but rather it is because it is a sweeping issue with the Pokemon Centers that is best approached collectively (fixing all at once); to this point, no one has, as a widespread issue of this is of a bigger magnitude than most single-map typos. The Pokemon Center template itself had the dialogic oversight, and it carried over into each Pokemon Center script it was applied to. Professionalism has no caveats when striving for perfection, and it's therefore reasonably assumable that we want to fix any identifiable error that is (appreciably) reported; it is just that response times can vary depending on the magnitude of the fix and the availability of departmental personnel to fix it.

Taking value control over commodities, such as Pokemon Eggs in PRO's own iteration of a daycaring system, that are initially arbitrary in their value (when considering the proportionality of price and workload thereof) is a surefire complexion to spawn dissent and disagreement down the road once the system finds traction among the playerbase. While any attempt of complete deporalization of the opinions is impossible, forming a consensus is always instrumental to finding a much better balance of the prices. While we are nearing the cusp of the anticipated game's full release and also in the incipient development of a release-concurrent overhaul to the daycare system, there is no better time to sort out the quandary of price selections than now; that especially holds true because the pricing will need more rigidity post-release, when there will inevitably be less wiggle room—that is, as far as the consumership's reaction goes to such price changes—with frequently redoing prices. Each regional subset of Pokemon eggs is subdivided in the survey below; your voting to that will lend to me a metrical perspective to your opinions on them. https://kwiksurveys.com/s/9kHAq0JC It is infeasible for me to ask for feedback on the exact pricing, as that's also indivisible to one's opinions on how rewardful the Pokemon prices are in relation to the workload for earning points, but giving me a perspective on what you feel of the Pokemon's egg values will at least give me pointers as to what direction to go in with price increases or decreases and the general pecking order of the eggs' values—the next-best and most situationally feasible feedback for balancing out the prices. Thank you in advance to any respondents. :)