Naero

Hello. This issue has been rectified; please see this expositional announcement for more details. Apologies for the inconveniences.

This issue has been rectified; please see this expositional announcement for more details. Apologies for the inconveniences.

Hello, and I hope you are all enjoying this event as it's ongoing. :Grin: It's only duly that I announce that in response to an epidemic of lag and various bandwidth-logjamming issues caused by the Challenger Rick script, it has been revamped in favor of optimizing performance and ultimately staving off the amount of Summer Points that were lost. While much of this revamp boiled back-end optimization of the script, I also had to re-methodize the script to use different, server-friendlier functions; this ushers in new limitations as to what Pokemon you can submit and when, as expounded on below. Initially, Rick would accept any Mudkip or Torchic obtained after the juncture the first task was started and use the Pokemon-unique ID to discern whether or not it's already been submitted; in an ideal world, that method is perfectly workable to allow players to maximize their Summer Points payouts without resubmitting the same Pokemon, but in its practical application, it was far too taxing on the server. Too many potential Summer Points were dissipated due to NPCs freezing from bandwidth logjams wherein the Pokemon-unique ID was successfully registered yet it would not proceedingly execute the coding that rewards Summer Points, so many Mudkip and Torchic ended up rewardless as such. The paradigm has been reworked to only accept one Pokemon per task period; this means that if you obtained multiple Torchic/Mudkip between your last task's completion and the current one's completion, you can only reap Summer Points for one of them since the next task will stipulate that you must capture the next Pokemon after the previous task is complete. The obvious downside to that is that if you're lucky enough to obtain multiple Mudkip/Torchic during the task duration, it'll be limitedly rewardful since only one will be accepted; as such, it'd be advisable to submit a Mudkip or Torchic as soon as you obtain it. Apologies for any prior inconveniences caused—including those affected by the spasmodic lag spikes—and any points that have been lost. Unfortunately, we can not reimburse Summer Points that were squandered from NPC freezes. We would like for them to be compensable if feasible, but therein lies the problem; it isn't, because even through the greatest power of deductive reasoning, we lack the tools to ascertain whether or not you were deprived of points and what Pokemon lost them. We hope you will all continue to enjoy the event. :Grin:

'Vulcan' is the dialectical spelling of 'volcano' in the entire domain; in this case, the spelling is just a consistency of an overarching motif to the island, which indeed refers to 'volcano.' In any case, this is certainly deliberate and thus there is no dialogic error here. There is no bug here—simply because it is not intended to be a battle NPC to begin with. Its operative function is to teeter between giving and removing your Pokemoney depending on your current Pokemoney count. I understand where the confusion stems from, however; it is common for any auto-approaching NPCs to be battle-NPCs, but that isn't inseparable from battle NPCs. It is primarily employed to ensure impassability for battle NPCs, but there are other, less common cases where we want NPCs to auto-approach players; that is the case here, since it wants to ensure that potentially penniless players have at least a modicum of money (specifically 1k) to use when entering the island. That is indeed the issue, and it has been amended accordingly. Thank you for all the reports, and we hope you continue to enjoy the event. :)

This has been amended; please refer to this rundown for more details. Thank you for the report.

Hello. Whenever Pokemon-unique data—namely caught-date registrations and Pokemon IDs, for the operative examples here—is checked for in the script, there is a chance that it may be null; this is because it takes at least several minutes to save upon procuring that Pokemon. The saving-time gap is ample enough that it's possible that the data hasn't yet been database-registered and made manipulable by the juncture you've spoken to the NPC. As advised, you need to relog to force-save the data if it hasn't already been saved automatically. Unfortunately, the issue can not be amended to insta-save Pokemon data upon capturing them—that frequency of saving would be far too bandwidth-expensive considering the unwieldy amount of Pokemon data that needs to be saved simultaneously—but as a user-friendly duck-tape fix, I've added in a dialogic clause that advises users to relog if the data discernedly isn't saved. Thank you for the report, and enjoy the event. :)

A Pokemon's PvP prowess isn't the only fulcrum of its market value; collectibility also can be, and these clone counterparts were added to cater to that psychographic of the market. The market may be predominantly PvP-driven, but it is more than possible--as attested to with this bevy of Pokemon--for a Pokemon to flourish on the marketplace if it has the rarity, distinction and aesthetic appeal to be a coveted asset in one's collection. In any case, you are seeing an inflated picture as to the Pokemon's price while the craze is still fresh for them and while they are under-accumulated in the market. Prisoner-of-the-moment enthusiasts will vie for these Pokemon earlier on and go at steeper prices because of it to pursue these Pokemon while there's a paucity of them, but that's only a short-term phenomenon; in the grand scheme of it, their prices will dwindle as more accumulate in the market supply of them and as te early-bird craze dies down--an inevitable downswing that'll make it more prudential to wait until later to buy them, as opposed to when prices are peaking out for them now. Time will still favor their value as they slowly decumulate from circulation over the long haul; but as it pertains to this week, this is the highest-prices they'll be for a while. By next week, they'll be abundant enough that their own stats will become a bigger factor in their value since there'll be too many that better stats will be needed for them to stand out of the pack.

As the eponymous creator of this NPC, I can confirm the exactitudes of its cooldown times--12 days standardly, and 7 days for members. Since boss NPCs tend to be the more rewardful hotbeds out of all battleable NPCs in the game, it's tenable enough as to why they have the sizable cooldown times that they do; it is a restrictor needed to ensure that players can not reap these covetable rewards from them seamlessly--baby-stage Pokemon in this case, as this boss NPC encompasses some of the better fertile grounds for these Pokemon than many other sources. Could the cooldown time be scrapped in the event that you lose? Possibly, and I most likely would have elected to do so if this was a compulsory NPC for the storyline, but that isn't the case here; rather, it is simply a hurdle for procuring access to egg-move tutors, which is an auxiliary pool of moves more than it is any indispensable feature for the game. Moreover, since this reward is coveted mainly by PvPers--a psychographic that subsumes some of the more Xs & Os-minded battlers in the game--I did not consider it that much of a stretch to steepen up the challenges of winning with an extensive cooldown time, since many of these aspirants are the exact type of players who know how to construct a team to easily counter-strategize against my lineup. I wish you luck in the next battle, but there currently is no strong reason to shorten up the cooldown time at this time, I am afraid.

I will preface this guide by stressing that it's designed strictly towards highlighting the benefits of an application client for IRC and instructional pointers for the setu-up thereof; for a more overarching guide to IRC's usage, please refer to Alex's in-depth one. While IRC is deemedly optimal for our official chat—much of which you can chalk up to how ergonomic it is for its own department of staff as they utilize an array of moderational tools to ensure that the chat comports itself with PRO's intended atmosphere—its drawbacks have been considered too glaring to make it the most popular external chat. As an obsolete and developmentally stagnant chatting program, it has simply lagged behind the popularity of more visually appealing, modernistically developed chats—a la Discord—that more have naturally gravitated to. Indeed, IRC also is not as intuitive by modern standards; much of that can be ascribed to the fact that it is limited on its GUI functions and requires textual commands to be sent to the chat—potentially essential commands that most of the newer IRC-users will not know off-hand. It shouldn't disabuse the consensus that IRC is still the optimum of channel control for a PRO-official chat that we haven't found with any other chatting program, but it does chasten the usership and ultimately mar how enjoyable the go-to external channel is for many avid community members. That is at least the impression left by the web-client—the most readily accessible client used for IRC and thus the one used predominantly for it. Most of IRC's issues are client-side; as such, many of them can be alleviated—if not completely expunged—by different clients. It is no secret to the more experienced bevy of IRC-users that application clients are available to greatly enhance their experience, but many recede away from after short-lived stays before discovering this fact—stays that might not even be as short-lived as they are if the benefits of application clients were more well-known from the outset. You can subsume computational clients in two sweeping categories: web- and application-based ones. As nominally suggested, web-clients are hosted on a web-server and use that to connect their users to an IRC-server, whereas application clients are downloaded to the user's OS directly and is accessed therein. In order to fully know the differences between application- and web-based clients, it starts with knowing how to differentiate the client from the server itself in the transactional model to know its roles. You can analogize the clients and servers to the roles of clients (customers, colloquially speaking) and the services they use in a business model; the clients are the individuals who are looking to initialize the connection with the server (the front-end personnel of the service, analogically speaking), just as you use IRC clients to establish a connection with the server. Web- and application-based clients can be seen as different vehicles for connecting to the client, and it's analogous enough to using a public-transport system (a la a bus) or your own car; web-clients (the bus) are public services that are mostly in the hands of the public (the website) and are limitedly customizable as such, whereas cars (application clients) afford you much more wiggle room to enjoy the ride to the server. In the very computational application of this, however, it is affinitive enough to the transactional model between the game's own client and servers; the client accesses and utilizes your computer's resources on your own end of the connection, initializes the connection to the server, and it decides how to react when the server sends packets to it. Laymen, however, will be most interested in how it controls their computer's resources—the visual presentation it provides, the customizability, and so forth. If you are adamant enough that you won't use IRC for the long haul or with regularity, there is the web-client's biggest advantage—that you won't spend more time setting up an application than you liekly will in using the chat on-average. Otherwise, it's in your best interest to use an application client; I will highlight why. Firstly, while the modernistic motif of clients in general are sorely missed by many in IRC, this issue resonates much more commonly with web-clients than it does with application clients. Development has mostly stagnated with web-clients, but application clients have made strides—and assuredly will continue to do so—with their development. As already explained but bears relevant repeating, clients control all the resources on your computer's end that serve as a happy substitute for much of what web-clients miss; this includes the following: More visual customizability that IRC's web-clients that your computer can be retentive of where IRC web-clients are not. Chat-logging (on your client's side). Customizability over notification systems. A much more intuitive GUI and customizability thereof to denecessitate the glut of text-based commands that you may use. Auto-performing of commands—especially useful for authenticating your nickname automatically as opposed to manually typing in the command. Better performance since it won't share the same RAM that's allotted to your web-browser, thereby easening up your habits of keeping your username parked into the chat. Because of IRC's developer-friendly protocol, there are a multitude of IRC clients available; I will highlight the more popular ones and give instructional pointers for them below. For now, I will cover what the guides will omit as it pertains to PRO's own IRC. /server irc.atomicedge.org - to connect to the RR of the IRC network. If prompted, use 6667 as the standard-protocol port or 6697 as the SSL one. Once you are connected to the server, you may be prompted to join channels depending on your client; input #pro (general channel) or #pro-support (strictly used for player support) if so, or use /join #pro,#pro-support if you are not immediately prompted to join a channel. Here are the more prevalent clients and all the instructional information needed to set them up. -ChatZilla -HexChat -mIRC

Hello. :) Systemically, this bug has been fixed and should no longer be recurrent; however, it is not designed to retroactively fix anyone who is currently deadlocked by it, so you will need a manual, individualized fix. Let us know when you are online, and one of us Content Scripters will try to extricate you if available at the juncture—be it by posting here or contacting us in IRC. Apologies for any inconveniences caused meanwhile. We hope to have it rectified in your case ASAP.

Thank you for the report, [ref]nightjay[/ref]. The issue has been fixed accordingly. :)

Hello, [ref]Mushrambo[/ref], and thank you for the report. This is just an inflectional mistake in the dialogue; it is because we were foresightless to the eventual framework of the HM02 quest at the juncture of dialogizing this NPC and thus chose the gender irrespective to the eventual NPC added. I have corrected all inflections in the script. Thank you again for the report. :)

Hello all. Due to a notational error on the script's end, it misregistered the notation of the string used to ascertain whether or not the PC has been visited; as such, some Transmat Station lobbies have mistakingly recognized the computer as having been software-installed when it hasn't been. I've already made the systemic fix on the script's end; but since I'm unable to retroactive the fix for those who are already quest-deadlocked, manual fixes will need to be done. For anyone who is currently bug-roadblocked by this quest, please contact me in IRC; I'll then rectify them individually, as we'll need to be online in-game simultaneously to do so. Apologies for any inconveniences meanwhile.

Hello, and thank you for reporting. This control-flow disorder was caused whenever you captured the aggressive Poochyena—the first Pokemon you're able to reap in Hoenn. Because the script was mistakenly coded to evaluate your Pokemon-party count before proffering the starter Pokemon, Poochyena's capture would preclude you from claiming it; that has been fixed now, as I have amended the scripts to check for a variable to properly discern whether or not any starter Pokemon has been claimed under your possessorship. If you have yet to claim a Pokemon, simply interact with one of the table-set Pokeballs, and it'll allow you to select one. Apologies for any inconveniences this caused.

Hello. Thank you for reporting this. This was a systemic error on my part that misperformed the string-manipulation functions needed to check whether or not you had already uploaded the software to PCs; it has been fixed now, which should stave off this control-flow disorder from recurring for any future quest-goers. Meanwhile, I have provided an individualized fix on your account; this will ensure that Wally rightfully appears for you. Please let me know if any issues persist thereafter. Apologies for any inconveniences that were engendered by this, and enjoy the game. :Grin:

Hello. While it is infeasible for us to provide any individualized fixes for those affected by this, I have amended a systemic fix that should hopefully ensure that 5 minutes truly do elapse before you're declared as flunking the quiz; let me know if the issue recurs otherwise. Thank you for the report, and apologies for any inconveniences this caused meanwhile.

Hello.Are you still roadblocked by this issue? From perusing over the logic-coding, it should execute the battle function; why it's failed to do so is where the dysfunctionality can be chalked up to. Due to a glaring bandwidth shortage on the servers caused by a flurry of long-awaited Hoenn-anticipators, the server has been short-supplied on the bandwidth needed to accomplish certain tasks; that includes parsing through NPC scripts, which is taxing enough that the scripts will fail to execute altogether—hence the NPC-deadlocking issues wherein players freeze upon interacting with them. While your problem is instead the battle's inability to execute, you can chalk up affinity to the aforementioned one, since I'm theorizing that the bandwidth paucity has chastened the script enough to the point where it froze when it was unable to proceedingly execute it. I would simply try to rechallenge him again when you're next-online, and let us know how it shakes out. We're hoping that the problem is mitigated as soon possible—part of which will be with time, as the server activity normalizes after the initial Hoenn-release bout—and if you're a Red-centric player, you may see notice results even sooner due to the fact that we just switched over to a hopefully more competent physical host for that server.

Lounging around during the more motionless hours at my workplace at my oft-sedentary job.

Not completely true, mind you; while there may be asynchronies between the positional data of a player on the client and where it's registered server-side, they are resynchronized by repositioning the player in the area. The client transmits packets to the server to tell it where the player has moved, and it registers the player on each tile successively; therefore, it would check the tile within eyeshot of the NPC and trigger that battle before it decides to register any subsequent movements. In this case, the NPC's trajectory was mistakingly registered in such a way that it scanned players past the ledge. Since that NPC shouldn't be reachable until one has spatial access to that area, I have amended the trajectory so that the battle can no longer be triggered if you're past the ledge—which should effectuate next reboot. Thank you for the report. :Grin:

Hello. According to your quest-variable and item data, you are flagged as having completed the S.S. Anne Quest and have procured its reward in HM01 - Cut, respectively indicatedly; as such, I will presume this issue as resolved unless anything to the contrary is brought to my attention. Enjoy the game.

Thank you for the report. This issue will be fixed effective next reboot, and apologies for any inconveniences it caused to anyone prior.

Hello. I have fixed this issue in particular; but if there are any others that need revamping, feel free to PM me the list. Due to poor hierarchalization in the previous scripts, these control-flow defects are still existent with many predating move-tutors, but it's a template we have refined for any additional move-tutors moving into the future.

Hello. Thank you for the report, but I can assure there is no dysfunctionality here; these moves are intended on the Pokemon and have been brainstormed beforehand among the staff. By default, NPC- and wild-Pokemon movesets are delimited by the last-four moves that they have met the level-up quanta for; any moveset that deviates away from that parameter is a product of deliberation rather than a bug. In order to maximize the challenges for these more salient brackets of NPCs, we wanted to cull their most viable moves—which settling on their highest-level moves would be simplistic in doing—and thus our administrators and developers have manually edited the movesets within the server. Topic locked, as it is a user-end misunderstanding.

Hello. This disconnectivity occurs when the route-reflector server—irc.bitsjoint.net—is unable to stabilize your connection. The route-reflector address is used as the centerpoint in determining which server you will join out of multiple leafs to help localize your connection and ensure that no server is inundated with users when connecting; however, since it is an extra layer in the protocol, it is also harder to establish connections on it—especially due to bandwidth shortages on your network's part. If you are unable to access it, I'd advise using one of these links to directly connect to one of the leaf servers: https://kiwiirc.com/client/lambda.atomicedge.org/pro https://kiwiirc.com/client/zeta.bitsjoint.net/pro https://kiwiirc.com/client/delta.bitsjoint.net/pro I will also update the global thread accordingly for future accessibility-readiness.

Are you referring to its seen-data entry? If so, this typifies the contingencies I added this fallback fix for: interacting with the computer in Professor Oak's lab. I scripted it to recover the seen-data entries of all overworld Legendary Pokemon that are no longer encounterable—be it due to a rollback or the freeze you're referring to—and it should check to ensure that the NPC has disappeared before proceedingly recovering your Pokedex registry. Please let us know if there are any further difficulties.