DoubleX

Updates v1.03b(GMT 1000 21-5-2023): - Fixed not updating the enemy mp and tp bars when their mp and tp becomes 0 respectively

I never thought even I could make some music, but I don't know if mine would be too unpleasant to hear, so it takes me some courage to share them here DoubleX - Everyone Turning Against You

Disclaimer: While exceptions and negative emotions are essentially similar, they're still not 100% the same, so there will be minor discrepancies here and there when this article tries to apply wisdom on handling exceptions into handling negative emotions, but I still hope that this article can make its points across to as many of you as I can As programmers, we probably at least have a basic knowledge on what exceptions do in general, so it's unlikely that I've to explain much about that here. However, did we think about applying some wisdom from exceptions in real lives? Since I've had some thought about that, I'm going to share about them in this article, but the gist is this - Exceptions in software are a lot like negative emotions in human, so negative emotions should be addressed responsibly, just like exceptions being supposed to be handled properly. The following 3 approaches show the similarities among exceptions and negative emotions: Letting Exceptions Crash The Software - Letting Negative Emotions Take Over Control Let's use an unrealistically silly example about exceptions first. Let's say that a program has to send some GET requests to get data from some remote servers, and it's totally normal for the requests to fail, possibly because of unstable network connections, overloaded servers, or some other similar reasons, so it's just the norm to throw exceptions in such cases. However, an unbelievably sloppy programmer may just let the exceptions abruptly crash the whole program badly without even telling the users what's going on, when he/she could've just tell them why those requests failed and ask whether they'd like to retry or abort those requests. Needless to say, if a so-called experienced professional frequently handle exceptions in such immature ways without even thinking about them, he/she probably won't last long in the software engineering industries, because he/she'd likely just create disasters after disasters otherwise. Of course, there are really cases where there's indeed nothing for a software engineer to do when some methods throw some nasty exceptions, like StackOverflowException in C#, even though such exceptions shouldn't be that easy to leak out to production to begin with. But the point remains that, letting an exception crash the entire system should at least be a careful and conscious decision(and preferably as the last resort only), rather than out of laziness nor misconceptions. Now let's go on to another childish example, but this time about negative emotions. Let's say a rookie investor just watched an online video about a seemingly legitimate(while actually unqualified) stock market expert "explaining"(when it's actually nothing but nonsense) about how certain stocks will skyrocket to record highs after several days, and that rookie investor trusted this kind of insanity by investing more than 80% of his/her total wealth into that stock. Unfortunately, after several days, those stocks dropped to such lows that the underlying companies may as well be considered bankrupt, so that rookie investor feel extremely angry and unjust about his/her tragic loss, and leave many insulting and vulgar comments on that video, without even thinking about how that fraud really caused him/her to lose so much money in such a short time. What's worse, even that isn't enough for that rookie investor to vent all his/her anger, so he/she feels exceptionally furious whenever he/she perceives anything he/she doesn't like in his/her family, and disproportionally blames his/her sons and daughters for even trivial mistakes that he/she wouldn't normally even notice nor care. Needless to say, if he/she continues to behave this way without thinking about his/her part of the responsibility of this mess(just automatically listening to any apparent authority without critical thinking), his/her family, as well as him/herself, will just suffer deeper and deeper, while he/she'll increasing feel that it's all the others' fault for his/her disarray in his/her life. Of course, there will be times where some adversities will cause even some of the most self-aware and serene people to be completely outraged, like when a guy realizes that his girlfriend had been concealing the fact that she's pregnant for weeks because of another guy, even though there are actually people who can behave friendly(but not being weak) towards their girlfriends and even those guys responsible for such pregnant, all without repressing any negative emotions(like by nonjudgmental and nonviolent expressions of the feelings of hurt and sadness). But the point remains that, letting negative emotions to take over control should be rare and the last resort only(even though it's okay to fail on this sometimes as long as the damages from uncontrolled emotional outbursts are at least partially compensated), rather than out of complete lack of self-awareness nor emotional intelligence. Silently Swallowing Exceptions - Repressing Negative Emotions Those used to handling exceptions should know that exception swallowing is generally a very bad practice and should only be used when there are very solid reasons behind it, otherwise the original exceptions that could be properly handled can easily become something much worse much later - severe errors that seem to come out of thin air, so it'd be very hard to find the root causes behind all this, let alone fixing it. For instance, I still vaguely remember that, when I had a full-time programming job, I've taken over a codebase from someone else, and soon realized that that codebase will occasionally be out of memory without obvious causes. While it's reasonable to suspect that there are memory leaks unknown to me(and it's extremely hard to eradicate every possible memory leak anyway), I'd to spend quite some time to find out that, some of those memory leaks come from silently swallowing(an empty catch that's not even logging anything) a certain exception when using an API of a library as a dependency of that codebase(I unconfidently recall something like only closing connections/streams in the try block but the exception's thrown before reaching that line of code). If that exception were properly handled, I might have noticed those suspected improper use of resources much earlier, thus saving me tons of time when debugging the application. In a very similar sense, those used to exercise self-awareness practices should know that repressing negative emotions(even though strictly speaking there's no such thing as "negative" emotions as every emotion reflects unique messages about one's dominant internal states) is generally a very bad practice and should only be used when there are very solid reasons behind it(like under prolonged critical emergencies constantly requiring difficult yet immediate actions with no room of errors), otherwise the originally manageable negative emotions can easily become something much worse after several years or at most decades - total mental breakdown triggered by seemingly trivial setbacks as the last straw, and sometimes even seasoned professional therapists may fail to understand the accumulated suffering of such patients, regardless of years of attempted consultations and treatments. For instance, while I don't claim to remember every last details, someone I know very well had almost committed suicide more than a decade ago, with the last straw being having no hope to finish his bachelor degree in university(and he really didn't finish it at the end). While I don't think I've thoroughly comprehended the essence behind his depressions at that time(fortunately nowadays he's at most lightly depressed once in a while for a short time), I do know that he almost never asked for help unless absolutely necessary, and he nearly always refused to talk about his hardship to anyone else(now he'll at least try to talk a little bit about that when someone else ask him about that directly). With the fact that he rarely expressed even his positive emotions to the others at that time(but now he can genuinely smile easily), it's reasonable to think that his self-awareness and emotional intelligence were both very low at that time, so repressing negative emotions in front of the others and even himself was all he could do back then. If he didn't try to escape from external challenges as well as not ignoring his internal unhappiness, I don't think he'd have tried to prepare to commit suicide(although I'd still doubt if he could've finished his bachelor degree even with external helps), even though it's lucky that he never did it, and it was all that mattered. Properly Handling Exceptions Thoughtfully - Observing Negative Emotions Nonjudgmentally In short, exceptions that can be handled should be properly handled with thought, because different kinds of exceptions need different kinds of care, and sometimes even the same kind of exceptions can have totally different meanings under different contexts, so it's usually better to think about how to handle a specific exception under a specific context with a case-by-case basis, even though it doesn't mean there's no need to establish exception handling facilities and policies for each software. Mixing Different Exceptions - Lacking Emotional Granularity If you're a Java developer, it'd be a fortune for you to have not worked with a high-level try-catch block that has just a single catch catching Throwable for no reason(ideally such codes should never exist to begin with), without caring whether it's an IOException(which can still be too broad sometimes), NullPointerException(which might be effectively meaningless under some contexts), OutOfMemoryError, StackOverflowError, or some other kinds of errors and exceptions. Because, strictly speaking, it's also a kind of exception swallowing, not by negating the existence of exceptions altogether, but by erasing their specific details necessary to handle them properly. Obviously, it helps avoiding to face the problems head-on, but it won't solve them either, and in fact, it often makes them much worse, sometimes even to the point of being impossible to fix within feasible costs anymore. Similarly, if you only know that you feel bad when you're facing negative emotions, without knowing what kind of the bad feeling it's(like anger, anxiety, guilt, sadness or shame), you can end up with swallowing the details of your unmet internal needs by covering them using the generic word "bad" and nothing more(although it's still better than negating negative emotions altogether), thus pretending to be working hard on improving mindfulness while giving you excuses to evade all those limiting beliefs and psychological pains that have to be faced, in order to have meaningful spiritual advancement and mental growth required to function effectively and efficiently as a healthy being. While increasing emotional granularity demands some courage and knowledge, it's the only way to stop those stagnant negative emotions from eventually evolving into nastier and nastier mental disorders, even though one won't descend into such hell that easily nor quickly in normal cases. Analyzing Exception Stack Trace - Identifying Negative Emotion Roots When investigating the root causes of an exception, it's often helpful to study its stack trace, at least until to the level where some meaningful fix can be done, instead of just covering its symptoms. Of course, sometimes, including rare instances where I've experienced personally, covering the symptoms reflected by an exception is indeed better than trying to fix its root causes, and this can be due to varying special reasons, like the prohibiting cost and technical barrier needed to fix it, with the reasonably assumed lack of serious consequences of just covering its symptoms, or maybe the exception is due to some native bugs of the frameworks or platform used, when it'd be infeasible to find replacement just because of those relatively minor annoyances. The key of this, again, is to really know what you're truly doing, rather than just mechanically sweeping ugly messes under the carpet without long-term thinking, and being at least this responsible and thoughtful will be one of the advantages helping us go a long way as seasoned professional software engineers. Similarly, after giving ourselves some time to just feel those negative emotions without criticism, it's often helpful to ask what triggers those negative emotions, and I might have to use an example to illustrate this. Let's say you and colleagues A and B have the same position in the same company, while they've higher salaries than yours. While you dislike A a lot because of that, you respect B despite of that however. After some brief self-observation, you realize that you dislike A more and more whenever he/she creates even more mess(and you've to clean it up) without contributing much to anybody or anything(and the higher-ups never punished A for anything ever), and you respect B more and more whenever he/she performs even better than he/she already did without making troubles to anyone else, so having the same position with different salaries isn't the full story of your disdain towards A but not B. Instead, it makes sense to have a hypothesis that(which needs to be further verified), you've an implicit golden rule that the rewards received by someone should be proportional to the values that someone brought to the others, and your hatred towards A stems from him/her violating your golden rule without any negative consequences, thus threatening some parts of your subjective value systems that are imbued deep within your brain and heart. With this new insight about yourself, you can choose to either accept that it's okay for your golden rule to slightly fail sometimes, or continue to be angry with A but with the crystal clear awareness of him/her violating your golden rule without having to pay for it, or try to reveal your past pains causing your adoption of this golden rule by digging even deeper about where it came from(which is insanely hard without professional supports), but what's the most important is that, no matter what you choose, it'd be better to admit that it's your conscious choice, and be responsible for it, as well as every consequences on your part. Do note that, in practice, exception stack traces are handled by our minds, meaning that it's a thinking and objective process, while negative emotion roots are handled by our hearts, meaning that it's a feeling and subjective process, so just blindly applying the methodologies of handling exception stack traces into handling negative emotion roots will only make things even worse, and emphasizing the similarities between exception stack traces and negative emotion roots is to use another way to reveal some parts of the essence behind negative emotions, especially for us programmers and former programmers Throwing So Many Exceptions - Being Triggered So Easily While it's totally fine for a method to throw a couple of exceptions, if a method can throw dozens of them, then it's most likely a code smell, because that method probably does too much and/or rethrows too many exceptions coming from even lower level methods, when at least some of those exceptions should be handled by the original method instead. Either way, since exceptions are special kinds of union types(and checked exceptions are special kinds of tagged unions), methods throwing so many exceptions have the same problems of union types having so many different types included, which at least indicate the possibility of low cohesion and/or tight coupling. Similarly, while it's totally fine for us to have a couple of negative emotions once in a while, if we frequently have so many negative emotions simultaneously, then it's most likely a sign for some needs on more personal growth, because we're probably under too much stress and/or have so many past yet unhealed mental sufferings triggered by the current adversities, when it'd be ideal for us to let go of at least some of those stale psychological pains. Either way, since emotions, including negative ones, are the communication media between our conscious and unconscious mind, when we frequently feel so many negative emotions simultaneously, it's natural to suspect that our conscious minds have been ignoring or twisting too many messages from our unconscious minds for far too long, and such self-defeating pattern can indicate the tendency of feeling a false need to strictly control the others rather than ourselves at all times, and being far from always solely responsible for our external behaviors(barring extreme cases like being forcibly drugged by the others). Chaining Exceptions - Stepping Back It seems to me, and possibly seems to you as well, that exception chaining is a best practice when it comes to handling exceptions, but whenever we've to chain exceptions, it means those exceptions can't be handled by places they're thrown, and have to be escalated to a higher level method, by wrapping those original exceptions irrelevant to that higher level method with exceptions meaningful to it, to hope that it can handle those wrapped exceptions, with the original exceptions as their causes. If it still can't handle those wrapped exceptions, the same exception chaining process will be repeated to further escalate those exceptions into an even higher level method, so the whole process will repeat until a high enough level method can handle those exceptions, or the program has to escalate them into the highest level and inform the end users about what really happened, then either ask for user inputs and continue the program safely or ask for user apologies and crash the program nicely. Without wrapping lower level exceptions with higher level exceptions, the higher level methods won't even understand what's going on, let alone doing anything meaningful to it; Without preserving the original lower level exceptions, the higher level methods won't know what causes the exceptions they understand, and sometimes different actions are needed for different causes. The same wisdom can be applied when we're facing some serious negative emotions that can't be just looked away from, but can't be directly dealt with on the level directly triggering those negative emotions either, and this can be illustrated with the following example. When my annual contract of my previous job nearly ended, I feel anxious about both renewing and not renewing the annual contract. On one hand, I liked the workplace, and I'd slightly miss it as well as my colleagues for a while if I just choose not to renew the contract; On the other hand, as I foresee a high probability for the workplace to change from being very nice to being very nasty within months, I'd probably have to change from contributing as much to the workplace as I sustainably can to protecting myself from the workplace as much as my track records won't become too broken, so I'd likely suffer significantly for quite a while if I choose to renew the contract. Because I already had some experience on self-awareness and mindfulness at that time, I realize that this apparent psychological conflict is more than just about the contract itself, so I took a step back and escalated this issue to a higher level. After some inner work, I revealed something noticeably deeper - I don't want to escape from difficult challenges and leave my colleagues behind(I was perceived by most of them as the most helpful colleague there), as I'd feel that doing so is a little bit like betraying at least some of them(now I still think I'm just an unforgivable deserter that deserves to be hated even though no one seems to despise me for that), but I don't want to go back to be someone defending my self interests at the cost of the greater good either, as I'd feel that doing so is going massively backwards when it comes to personal growth(and this will eventually harm my self interests even more even though this backward approach is just temporary). Since I already know that my core principle is to avoid hurting anyone else as much as I can sustainably do so(I suspect that my whole value system's built for this), while choosing either side is going to somehow violate what I care the most, I decided to choose the side that most likely hurt my colleague less - Not renewing the annual contract, in the hopes that the one replacing me will perform much better and help those colleagues much more than I did, thus causing them to at least suffer less. Of course, that doesn't mean my decision is perfect, because maybe I could've taken another step back, and try to have some insights on my past psychological pains causing me to avoiding hurting anyone else even at the cost of harming myself(provided that those harms are totally reversible), or maybe I could've found ways to raise my map of conscious level to joy(540) before starting the renewed contract, so I'd feel incredibly blessed and eternally ecstatic when I know I'm going to face the toughest challenge for me ever, while still sustainably contributing even more to my colleagues and fostering my personal growth. But without taking a step back and escalate the original conflict of whether to renew the contract into a higher level, I might not have understood that the nature of the conflict is actually failing to find any way to withstand my core principle no matter what I do, so I feel hurt and sad about having no means to maintain the integrity of my identity towards myself and possibly some of the others. Therefore, if I just kept struggling on the surface issue alone, no matter what I choose, I'd just be even more guilty and remorseful about what I've done and I'll have to do, all without fathoming why I'd be this ashamed of myself. Summary As seasoned professional programmers, we're good on our thinking sides, otherwise we wouldn't have lasted that long in the software engineering industries, so we'd usually have little problems on aspects primarily using our minds. But as authentic human being rather than objectified machines(although a little bit of systematic dehumanization is still a necessary evil to support the civilization of the mankind) solely for keeping the societies running(when societies are supposed to serve their members rather than the other way around), we'd want to be good on our feeling sides as well, otherwise we'd be more and more alienated and foreign with who we really are and what we really want, so our hearts would bleed and die more and more inside everyday we try to escape from and eliminate our negative emotions. Therefore, by spotting the similarities between exceptions and negative emotions, this article tried to apply some wisdom on handling the former into handling the latter, with the goal of helping me, and perhaps at least some of you, to be good on both our thinking and feeling sides(although most of you are already this good without needing this article at all), and to have little problems on using either our minds and hearts(rather than treating them as polar opposites), thus our lives can become more complete and fulfilling to us and preferably to the others. Even though this article is by no means exhaustive on applying wisdom on handling exceptions to handling negative emotions, at the very least, if we realize that choosing between letting our negative emotions take over control and repressing them is such a false dilemma that will only cause us to be more and more miserable, we're already on a good way to be more self-aware and mindful, just like how understanding exceptions will help us to be better and better programmers. As our emotional intelligence keep increasing, it'd be more natural for us to handle negative emotions wisely, until it'd so intuitive to us that it'd become our second nature, even though it doesn't mean that this will become a piece of cake nor we'll always do it well, just as sometimes we'll make an ugly mess out of exceptions no matter how seasoned and professional we're, and no matter how much we take exceptions seriously, hence it's still okay for us to become a little bit childish once in a while, and it's a part of being human rather than machines

Note This plugin's available for commercial use Purpose Fixes DoubleX RMMV Popularized ATB compatibility issues Games using this plugin None so far Action Sequences Addressed Plugins Video https://www.youtube.com/watch?v=aoBI3DaE3g8 Prerequisites Plugins: 1. DoubleX RMMV Popularized ATB Core Abilities: 1. Nothing special Instructions Place this plugin below all DoubleX RMMV Popularized ATB addons Terms Of Use You shall keep this plugin's Plugin Info part's contents intact You shalln't claim that this plugin's written by anyone other than DoubleX or his aliases None of the above applies to DoubleX or his/her aliases Changelog Download Link DoubleX RMMV Popularized ATB Compatibility

Updates * v1.05a(GMT 0600 26-12-2022): * 1. Compatible With Yanfly Engine Plugins - Battle Artificial * Intelligence Core

Purpose Lets you directly edit various built-in global formulae Video Games using this plugin None so far Parameters Script Calls Plugin Command Prerequisites Terms Of Use Contributors Changelog Download Link Demo Link

Note This script is extremely similar to Yanfly Engine Ace - Battle Engine Add-On: Enemy HP Bars so crediting DoubleX or his alias will violate this script's terms of use. Prerequisites Yanfly Engine Ace - Ace Battle Engine(Created by Yanfly) Script name DoubleX RMVXA Enemy MP/TP Bars Addon to Yanfly Engine Ace - Ace Battle Engine Author DoubleX: - This script Yanfly: - Yanfly Engine Ace - Ace Battle Engine Terms of use Same as that of Yanfly Engine Ace - Ace Battle Engine except that you're not allowed to give DoubleX or his alias credit Introduction Displays the enemy mp or/and tp bars Video https://www.youtube.com/watch?v=C9NAGpaP230 Features Almost no scripting knowledge is needed to use this script(some is needed to edit it) Instructions Open the script editor and put this script into an open slot between the script Yanfly Engine Ace - Ace Battle Engine and Main. Save to take effect. Compatibility Same as that of Yanfly Engine Ace - Ace Battle Engine FAQ None Changelog v1.03b(GMT 1000 21-5-2023): - Fixed not updating the enemy mp and tp bars when their mp and tp becomes 0 respectively v1.03a(GMT 1000 10-10-2022): - Added MP_PERCENTAGE_DECIMAL_DIGHT_NUMBER and TP_PERCENTAGE_DECIMAL_DIGHT_NUMBER v1.02b(GMT 1000 21-5-2016): - Fixed not updating mp/tp bar fill ratio for mp/tp change on battle start - If mmp is 0, the mp bar will be fully filled to show the mmp is 0 v1.02a(GMT 0200 6-4-2015): - Added MP_CRISIS_TEXT_COLOR v1.01e(GMT 0900 14-2-2014): - Fixed the mp and tp bars of the hidden enemies being shown bug - Further increased efficiency and reduced lag v1.01d(GMT 0400 4-10-2014): - Further increased efficiency and reduced lag v1.01c(GMT 0300 4-9-2014): - Updated compatibility with DoubleX RMVXA Percentage Addon to Yanfly Engine Ace - Battle Engine Add-On: Enemy HP Bars v1.01b(GMT 0500 2-9-2014): - Further increased efficiency and reduced size of this script - Reduced lag induced from v1.00b efficiency upgrade v1.01a(GMT 1700 1-9-2014): - Added mp and tp texts x and y offsets relative to respective bars - Added MP_TEXT_COLOR and TP_TEXT_COLOR v1.00b(GMT 1600 1-9-2014): - Fixed undesirable results when text size > bar height - Increased efficiency and reduced size of this script v1.00a(GMT 0500 29-8-2014): - 1st version of this script finished Download Link

Updates v1.03a(GMT 1000 10-10-2022): - Added MP_PERCENTAGE_DECIMAL_DIGHT_NUMBER and TP_PERCENTAGE_DECIMAL_DIGHT_NUMBER

Note This plugin's available for commercial use Purpose Lets you set some states to reverse the ally/foe identification Games using this plugin None so far Notetag Plugin Calls Video https://www.youtube.com/watch?v=NCVMdR7HFls Prerequisites Abilities: 1. Little Javascript coding proficiency to fully utilize this plugin Terms Of Use You shall keep this plugin's Plugin Info part's contents intact You shalln't claim that this plugin's written by anyone other than DoubleX or his aliases None of the above applies to DoubleX or his/her aliases Changelog DoubleX RMMV Confusion Edit

Updates * v1.00e(GMT 1100 9-9-2022): * 1. Fixed infinite loop in targetsForReversedExcludeSelf due to typo

Note This plugin works for both RMMV and RMMZ Purpose Lets you extract texts in events/common events/battle events to txt file Video Games using this plugin None so far Parameters Prerequisites Terms Of Use Contributors Changelog Download Link Demo Link

Note This plugin's available for commercial use Purpose Lets users show the battle turn clock, unit and count in battle Games using this plugin None so far Configurations Plugin Calls Video https://www.youtube.com/watch?v=l9-IX16T9Gg Prerequisites Plugins: 1. DoubleX RMMV Popularized ATB Core Abilities: 1. Little Javascript coding proficiency to fully utilize this plugin Terms Of Use You shall keep this plugin's Plugin Info part's contents intact You shalln't claim that this plugin's written by anyone other than DoubleX or his aliases None of the above applies to DoubleX or his/her aliases Changelog Download Link DoubleX RMMV Popularized ATB Clock DoubleX RMMV Popularized ATB Clock v101a.js

Updates * v1.01a(GMT 1200 25-3-2022): * 1. Added the following parameters: * - turn_clock_bar_x * - turn_clock_bar_y * - turn_clock_bar_width * - turn_clock_bar_height * - turn_clock_bar_back_color * - turn_clock_bar_color1 * - turn_clock_bar_color2

We all know that trust is one of the most important aspects in our lives, yet it doesn’t mean everyone can handle it well, and sometimes some people are so bad on it that many problems in their lives are due to that. As far as I know, the maturity of thinking about trust can at least be categorized into following levels - from the most dysfunctional to the most effective and efficient, even though it’s clearly oversimplified and it’s entirely possible that there are even lower and higher levels than those listed below: Level 1 Some people either always completely trust everything or always completely distrust everything without even assessing what that thing is, and we know that’s it’s so unrealistic and overgeneralized that only very immature people won’t see past that. Fortunately, such naive people are extremely rare, and they won’t remain that uneducated for long. For instance, some people do deeply believe that they can only trust themselves and everyone else is always completely untrustworthy while they know next to nothing about any of the others. Needless to say, their lives will be in deep struggles when everyone is so connected to each other and the demands of a person becomes so complex in the modern world that it's incredibly hard to be totally self-sufficient forever. For those who choose to always completely trust everything, they’ll soon fathom the truth that something really can’t be trusted at all, and either they’ll ascend to Level 2, or go to the other extreme - always completely distrust everything, which will cause their lives to be even more miserable. Anyway, they’ll soon see past the false dilemma between trusting everything and distrusting everything, thus it’s very improbable that they won’t ever ascend to Level 2 in their lives. Level 2 Some people are better in that, they know that not everything can be trusted but there are still something trustworthy. However, they still either completely trust something or completely distrust something, and they’ll quickly judge whether something is trustworthy or not, so it’s still a rather black and white thinking that doesn’t work well in reality, and this inflexibility, albeit not uncommon at all, will soon hit such people so hard that they’ll have to relearn what trust really is sooner or later. For instance, those deeply suffering from confirmation bias without even knowing will likely just use the first impression from someone to decide whether that person can be completely trusted or is completely untrustworthy, and will never reevaluate the decision until the reality teaches those people a tough lesson. Of course, judging someone using the first impression alone is judgmental to the extreme, and the negative consequences are so obvious that it’s even hard for those people themselves to look the other way. For the things they completely trust, quite some of them will turn out to be untrustworthy, so those people will turn from completely trusting them to completely distrusting them, and if there are more and more such things, those people will distrust more and more things in their lives, therefore the whole trend will induce them to descend to Level 1 - always completely distrusting everything. On the bright side, because it’s even harder to remain on Level 1 than ascending from Level 2 to Level 3, when those people ascend back to Level 2 after descending to Level 1, they’ll be forced to let go of the false dilemma between complete trust and complete mistrust towards something, and hence ascend to Level 3. Level 3 Some people realize that trust isn’t either all or nothing, but rather a continuous spectrum, so instead of just thinking whether something is trustworthy or not, they’ll also think about how much it can be trusted, so it’ll take them some time to be familiar with something before evaluating how much it can be trusted. Still, it’s a static thinking that misses the key that how much something can be trusted can change over time under certain conditions(unless such signs are so obvious that it’s impossible for such people to miss them), so they’ll be eventually caught completely off guard, even when there were already so many warning signs that they completely missed(because they never have the habit to actively seek for such signs to begin with), and they’d have long decreased the amount of trust if they noticed those signs. For instance, let’s say an employee has worked in a company for a year, and the track record of that employee suggests that, while that employee isn’t trustworthy enough to take the most crucial and difficult tasks, that employee is trustworthy enough to take some other important tasks that are still somewhat challenging but nowhere as difficult. However, because that employee mentally suffers deeply from suddenly becoming single without knowing what’s going on, that employee can no longer function as effectively and efficiently as before, so some of the latest important tasks, which is very similar than those done well by that employee, suddenly failed badly, even though that employee didn’t even try to hide the personal suffering in the company. As the boss decided that that employee is that trustworthy solely based on the performance of that employee over the last year, without even trying to periodically check for any abnormalities from that employee, that boss missed many obvious signs from that personal suffering and assigned those tasks to that employee anyway, hence causing the totally unexpected failure from that employee. While it’s clear that that employee is also at fault and responsible for not actively informing the boss about the personal suffering and its impact of future performance, the point remains that assuming that the trustworthiness of something is a constant to be found can be very dangerous, so unless those people at this level still didn’t grasp the utter horror of even lower levels, they should figure out the problem of not dynamically adjusting the amount of trust of something over time, and thus ascend to Level 4. Level 4 At this point, some people finally understand that trust is actually dynamic rather than static, so dynamic thinking is needed when thinking about trust, meaning that instead of just using past experience and track record to judge how trustworthy something is right now, they’ll also consistently look for both positive and negative signs at the present moment, therefore they can take these present factors of changes of trustworthiness into account as well. Although it’s already pragmatic enough to think about trust this way and not many has already reached this level, the problem is that it’s just reactive rather than proactive, so while they can quickly adjust the amount of trust towards something after those factors of changes have already manifested, they’re still just passively reacting to these signs instead of actively trying to figure out the essence behind those factors. Let’s say there’s another employee who was prolific and reliable at the start slowly became less and less effective and efficient, and eventually dysfunctional altogether due to prolonged covert workplace bullying hidden from the boss. So the boss, noticing this trend without knowing the root cause behind this issue, could only try to ask that employee about the lengthened performance drop, while gradually assigning less and less challenging and important tasks to that employee, with the benefits given to that employee being smaller and smaller, and had to unwillingly fire that employee at the end, because the boss failed to know the truth that way. Although it’s hard to blame the boss for not knowing what’s really going on with that employee when that employee didn’t even try to report anything, it still shows the issues of just passively reacting to the changes of the amount of trustworthiness, as it could’ve been become more rather than less trustworthy if the underlying conditions of changes were revealed. If the boss tried to proactively investigate what makes the employee appear to be less and less trustworthy besides just asking that employee personally, the boss might have discovered the workplace bullying in secret and kept an originally competent and loyal employee, rather than having to reluctantly fire that employee and possibly repeating the history in the future unknowingly. Level 5 This is where proactive thinking comes in, but people of this level are hard to find as it's hard to keep being on this level, and the paradox is that they don’t consciously emphasize trust anymore, because to them hypothetical thinking is much more flexible and responsive when it comes to constantly reassess the essence of the ever changing conditions behind the factors that increases and decreases the amount of trustworthiness towards something. So instead of thinking about how much something can be trusted at any moment, they think about on what probability that how something will behave under what conditions, and the essence behind the when and why of such correlations and causation hold, so once those underlying conditions change, those people can immediately adjust and correct their hypotheses while reconsidering whether and which previously established contingencies need to be executed(or swiftly come up with a backup plan that didn’t exist beforehand), and when they’ll be executed to what extents. For example, an employee formerly working for a rival company has demonstrated extraordinary competence and willingness to take the most challenging and important tasks in the current company without asking anything extra in return, and that employee can get them done all exceptionally well, so the current boss happily give that employee more and more privilege and recognition within the company, and thus that employee can ascend incredibly quickly there, regardless of the fact that that employee was frequently badmouthing the previous employer, which is the rival company. But as what that employee has shown is far too good to be true and the badmouthing of the rival company from that employee doesn’t match what the boss knows about that company, the boss can’t stop to suspect that that employee, which worked for a rival company, is just acting and up to something even bigger, so on one hand the boss appeared to have complete trust over that employee by giving that employee sole discretion over a new and large project that demands access to valuable company secrets to lower the guard of that employee, but on the other hand privately asked a trustworthy security expert in the current company to silently monitor the activities in that project from that employee behind the scenes. It turns out that that employee being suspected is actually an industrial espionage still working for that rival company, and is assigned to elusively install an undetectable backdoor deep inside the new project using internal software systems that can access the most confidential and sensitive algorithms and data of the current company, so the rival company can later invisibly hack into that backdoor to steal those crucial information while keeping a low profile, and the frequent badmouthing from that employee about that rival company is just a cover-up. Hypothetical Thinking While it’s clear that it’d be overkill and exhausting to use hypothetical thinking over trivial matters as well, when it comes to the key moments of determining the trustworthiness of something vital, hypothetical thinking can still come into handy. Also, do note that thinking about trust and hypothetical thinking don’t have to be mutually exclusive, and in fact they can work well together, even though such unison will never be easy nor cheap. Although there are many factors affecting the trustworthiness of someone, usually the most subjective and unclear one is motivation, which can be broken into at least these following 5 basic building blocks: What does that someone need to get right now? What does that someone need to avoid right now? What does that someone want to get right now? What does that someone want to avoid right now? What is the emotional statuses of that someone right now? Other factors, like whether that someone has the experience, knowledge, information, resources and technique to get something done, while still absolutely necessary to determine the trustworthiness of that someone over that something, are usually much more tangible and visible to the others, so if one can reliably comprehend the basic building blocks constituting the motivation of someone, the other factors should also be of little challenge. As long as one can keep in touch with the factors constituting the trustworthiness of someone, that someone will unlikely to suddenly change from very trustworthy to very untrustworthy without being noticed beforehand, so it’s generally hard to back-stab those with hypothetical thinking as their second nature, at least not with them unprepared. When using hypothetical thinking, one doesn’t just come up with a single hypothesis and call it a day, but should instead explore at least several ones that are reasonably likely to warrant further verification, and act on the currently most probable one, with contingencies designated to handle cases when that hypothesis is proven to be wrong, until it’s proven to be wrong and act on another hypothesis. Do note that besides having to actively and consistently look for signs both supporting and negating the hypotheses, while a hypothesis can be the most probable one right now, after some time with some changes, another hypothesis can become the most probable one later, and sometimes one even needs to generate new hypotheses on the fly, so the whole hypothetical thinking is a constantly dynamic process, and there should be as few unsupported assumptions as possible at any moment. Of course, it’s impossible to be even near perfect, so no matter how experienced, knowledgeable and skillful in practicing hypothetical thinking in real lives, there will always be times where one will be caught completely off guard, so hypothetical thinking isn’t about trying to eliminate uncertainty and the concept of trust altogether, but rather minimize the amount of uncertainty and reliance of trust while accepting that uncertainty is a nature of lives and trust that one can deal with most of the remaining uncertainty most of the time. Because of that, those practicing hypothetical thinking should also be ready to be completely caught off guard, and that means they’ll have to be able to be very flexible, spontaneous and versatile at any time, even though one will have to take very complicated and convoluted paths to get there. Combining everything, those with hypothetical thinking in mind first observe and test someone for a while, then act on a hypothesis based on the initial track record of that someone collected during that period, and those people will continue to look for signs that indicate both the increase and decrease the trustworthiness of that someone. If the hypothesis suggests that some such positive or negative signs will manifest and they mostly do, then the hypothesis is somehow verified and should be kept, otherwise it’s shown to be less and less accurate and should be tweaked somehow, and when there are enough such significant mismatches, the hypothesis will be proven to be dead wrong so those people will have to act on a new hypothesis, and the whole cycle will repeat again and again.

This topic aims to share the basic knowledge on what the default RMMZ TPBS battle flow implementations do in general, but you're still assumed to have at least: 1. Some plugin development proficiency(having written several easy, simple and small battle-related plugins up to 1k LoC scale) 2. Basic knowledge on what the default RMMZ turn based battle flow implementations do in general 3. Basic knowledge on what the default RMMZ TPBS battle flow does in general on the user level(At least you need to know what's going on on the surface when playing it as a player) Simplified Flowchart Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience Battle Start Input Action Slots Thinking In Frames Frame Start Start Phase Turn Phase Action Phase Turn End Phase Battle End Phase Update TPB Input Summary That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ TPBS battle flow implementations, feel free to correct me if there's anything wrong For those wanting to have a solid understanding to the default RMMZ TPBS battle flow implementations, I might open a more advanced topic for that later

This topic aims to share the basic knowledge on what the default RMMZ turn based battle flow implementations do in general, but you're still assumed to have at least: 1. Little javascript coding proficiency(barely okay with writing rudimentary Javascript codes up to 300 LoC scale) 2. Basic knowledge on what the default RMMZ turn based battle flow does on the user level(At least you need to know what's going on on the surface when playing it as a player) Simplified Flowchart Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience Start Battle Input Actions Process Turns Execute Actions Summary That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ turn based battle flow implementations, feel free to correct me if there's anything wrong For those wanting to have a solid understanding to the default RMMZ turn based battle flow implementations, I might open a more advanced topic for that later

Outsourcing business functions is nothing new in the business world, and is actually a very common and well-established practice, although whether it's a wise decision depends on the concrete circumstances. On the other hand, outsourcing core business functions is generally quite dangerous, because you can end up falling into a rather disadvantageous scenario, as demonstrated in the following example. Situation A company has its headquarter in a very well-developed city(so its various expenditures will be much higher), and 3 branches in 3 different other much, much less developed cities(so their various expenditures will be much lower) all being very far away from the headquarter, where each branch runs a core business function outsourced by the headquarter: Branch A runs most of the back end for the core business of the whole company Branch B runs the 24 hour call center and most of the customer support services for the whole company Branch C runs most of the software testing and sales activities for the whole company Of course, each branch is also responsible for expanding the markets in their respective cities, and they're allowed to take a large portion of the profits from those markets by running their own business, in order to motivate and reward them for more effective and efficient market expansion(they'll also take a small portion of the profits from the core business of the headquarter so the branch will still have the incentive to keep the core business running). Back to the headquarter, it runs most of the front end for the core business of the whole company(and takes a large portion of profits from the core business), and is responsible for finding new customers and maintaining existing ones, even though the headquarter will also take a small portion of the profits from the business owned by its branches. This seems to be a decent setup that can significantly lower long-term expenditures and raise overall profits, but actually there's a big problem: The headquarter will likely have less and less control over its branches, which will be more and more powerful due to its own businesses growing over time. Problem So, if you were the head of a branch, and you can frequently pretend to obey the headquarter while actually ignoring its orders, will you focus primarily on the core business of the headquarter, or the business owned by the branch? Needless to say, you'll choose to work on the latter most of the time, and will only work on the former when it delays too much, because you can take a large portion of the profits from the latter but only a small portion of those from the former, and not working on the latter will mainly hurt your branch while not working on the former will mainly hurt the headquarter. As time passes, the branches will become more and more independent from the headquarter, because they'll rely on more and more on their own business and less and less on the core business of the headquarter, whereas the headquarter will become harder and harder to control the branches, because its situation will become more and more dire while those of those branches will become better and better. By the time the business owned by those branches become mature enough for those branches to totally ignore the core business of the headquarter, it's when the headquarter will be forced to submit into those branches, because the headquarter still needs those branches to keep its core business running, and now it's already too late to try to take back control from those branches or migrate those outsourced core business functions from those branches to somewhere else(or just taking them back and let the headquarter run all those functions itself). Normally, the headquarter should be the one controlling its branches but not the other way around, however the control can indeed be reversed if the headquarter does outsource its core business function into its branches, so how to prevent that from happening in the first place? Solution The simplest solution is, of course, never outsourcing core business functions to begin with, but sometimes it has to be done to keep the expenditures low enough by utilizing resources in less developed cities, therefore some other ways have to be found to somehow even out the odds. In the short term, when a branch's just established, the headquarter should find the most trustworthy ones to run its branches in the first place, and they have to be almost absolutely trustworthy for a long time(whether it's because they've such high integrity or the headquarter has their key weaknesses on its hands), to ensure that they won't betray the headquarter so easily even when their self-interests will be more and more inclined to do so. In the medium term, when a branch becomes able to take care of itself, a system should be implemented to mitigate the potential conflicts of interests among the headquarters and its branches, like when a branch starts to ignore the core business function outsourced from the headquarter, the branch should take a larger and larger portion of the profits from the core business of the headquarter and smaller and smaller portion of those from the business owned by that branch, and when it's more important to expand the market assigned by that branch, the opposite adjustment should be made accordingly, so the branch will be more rewarded for focusing on what it should focus on at any moment. In the long term, when a branch starts to intend to become independent, the core business function outsourced to it should also be outsourced to a new branch that is far from being able to stand on its own feet, so the headquarter won't have to totally rely on the former branch(albeit the whole mitigation process can take years), probably even at the hefty cost of having to open a new branch, which would be also responsible for opening yet another market. Of course, even these measures won't last forever, because eventually the headquarter can have so many branches(even when some of them will be sub-branches of other branches) that it won't be able to control anymore, but at least the risk of outsourcing core business function won't be as unmanageable as before, and nearly no company can last forever anyway. Evaluation So far it's all about outsourcing core business functions from the headquarter to its branches, but how about outsourcing them to foreign and popular companies(with excellent reputation) specialized in such functions? It really depends on the functions and the companies planning to have them outsourced, like outsourcing a crucial database to companies running database centers is already quite different from outsourcing a 24 hour call center to respective companies, because different functions have different risks associated to them, and their respective companies can have different reasons to go against your best interests. For instance, while outsourcing a crucial database to a normally good company is usually wise, that company can also be interested by powerful and resourceful hackers(due to its high popularity and excellent reputation), so that company can be more prone to be targeted by sophisticated attacks, therefore although that company should also have quite a good defense against such attacks, once an attack succeeded, the database being outsourced can become totally compromised. Whereas outsourcing a core business function to an unknown company in a foreign country can have some other risks, like asking one such company to write the cross-platform front-end of a mobile app for you, and you can end up being effectively blackmailed by that company, perhaps the app will be stable at the beginning of production but have more and more bugs later on(so you'll have to pay more and more money to ask it to fix the bugs), and perhaps you can even end up having to give it a hefty sum so you can take back the codebase of that front-end and fix all those artificially created bugs yourself(of course you'll also have to hire some new employees to do that). On the other hand, just because outsourcing a core business function can be dangerous, it doesn't mean one should never do so, because sometimes the resource and technical requirements for running that function can be much higher than what a company possesses in the foreseeable future, and this restriction alone shouldn't always mean a company shouldn't even have a try on such function, it's just that outsourcing a core business function, no matter how big and strong a company is, should be a very serious(and perhaps irreversible) decision that can never be taken lightly.

Note This plugin's available for commercial use Purpose Fixes DoubleX RMMV Status Bars compatibility issues Games using this plugin None so far Addressed Plugins Prerequisites Plugins: DoubleX RMMV Status Bars Abilities: 1. Nothing special Terms Of Use Changelog Download Link DoubleX RMMV Status Bars Compatibility

Descriptions The following image briefly outlines the core structure of this whole idea, which is based on the idea of applying purely server-side rendering on games: https://github.com/Double-X/Image-List/blob/master/Future%20MP%20Games%20Architecture.png Note that the client side should have next to no game state or data, nor audio/visual assets, as they're supposed to never leave the server side. The following's the general flow of games using this architecture(all these happen per frame): 1. The players start running the game with the client IO 2. The players setup input configurations(keyboard mapping, mouse sensitivity, mouse acceleration, etc), graphics configurations(resolution, fps, gamma, etc), client configurations(player name, player skin, other preferences not impacting gameplay, etc), and anything that only the players can have information of 3. The players connect to servers 4. The players send all those configurations and settings to the servers(those details will be sent again if players changed them during the game within the same servers) 5. The players makes raw inputs(like keyboard presses, mouse clicks, etc) as they play the game 6. The client IO captures those raw player inputs and sends them to the server IO(but there's never any game data/state synchronization among them) 7. The server IO combines those raw player inputs and the player input configurations for each player to form commands that the game can understand 8. Those game commands generated by all players in the server will update the current game state set 9. The game polls the updated current game state set to form the new camera data for each player 10. The game combines the camera data with the player graphics configurations to generate the rendered graphics markups(with all relevant audio/visual assets used entirely in this step) which are highly compressed and obfuscated and have the least amount of game state information possible 11. The server IO captures the rendered graphics markups and send them to the client IO of each player(and nothing else will ever be sent in this direction) 12. The client IO draws the fully rendered graphics markups(without needing nor knowing any audio/visual asset) on the game screen visible by each player The aforementioned flow can also be represented this way: https://github.com/Double-X/Image-List/blob/master/Future%20MP%20Games%20Architecture%20Flow.png Differences From Cloud Gaming Do note that it's different from cloud gaming in the case of multiplayer(although it's effectively the same in the case of single player), because cloud gaming doesn't demand the games to be specifically designed for that, while this architecture does, and the difference means that: 1. In cloud gaming, different players rent different remote machines, each hosting the traditional client side of the game, which communicates with the traditional server side of the game in the same real server that's distinct from those middlemen devices, meaning that there will be at most 2 round trips per frame(between the client and the remote machine, and between the remote machine and the real server), so if the remote machines isn't physically close to the real server, and the players aren't physically close to the remote machines, the latency can raise to an absurd level 2. This architecture forces games complying with it to be designed differently from the traditional counterparts right from the start, so it can install the client version(having minimal contents) directly into the device for each player, which directly communicates with the server side of the game in the same server(which has almost everything), thus removing the need of a remote machine per player as the middleman, and hence the problems created by it(latency and the setup/maintenance cost from those remote machines) 3. The full cycle of the communications in cloud gaming is the following: - The player machines send the raw input commands to the remote machines - The remote machines convert those commands into new game states of the client side of the game there - The client side of the game in those remote machines synchronize with the server side of the game in the real server - The remote machines draw new visuals on their screens and play new audios based on the latest game states on the client side of the game there - The remote machines send those audio and visual information to the player machines - The player machines redraw those new audios and visuals there 4. The full cycle of the communications of this architecture is the following: - The player machines send the raw input commands directly to the real server - The real server convert those commands into the new game states of the server side of the game there - The real server send new audio and visual information to the player machines based on the involved parts of the latest game states on the server side of the game there - The player machines draw those new audios and visuals there 3 + 4 means the rendering actually happens 2 times in cloud gaming - 1 in the remote machines and 1 in the player machines, while the same happens just once in this architecture - just the player machines directly, and the redundant rendering in cloud gaming can contribute quite a lot to the end latency experienced by players, so this is another advantage of this architecture over cloud gaming. In short, cloud gaming supports games not having cloud gaming in mind(and is thus backward compatible) but can suffer from insane latency and increased business costs(which will be transferred to players), while this architecture only supports games targeting it specifically(and is thus not backward compatible) but removes quite some pains from the remote machine in cloud gaming(this architecture also has some other advantages over cloud gaming, but they’ll be covered in the next section). On a side note: If some cloud gaming platforms don't let their players to join servers outside of them, while it'd remove the issue of having 3 entities instead of just 2 in the connection, it'd also be more restrictive than this architecture, because the latter only restricts all players to play the same game using it. Advantages The advantages of this architecture at least include the following: 1. The game requirements on the client side can be a lot lower than the traditional architecture(although cloud gaming also has this advantage), as now all the client side does is sending the captured raw player inputs(keyboard presses, mouse clicks, etc) to the server side, and draws the received rendered graphics markup(without using any audio/visual assets in this step and the client side doesn't have any of them anyway) on the game screen visible by each player 2. Cheating will become next to impossible(cloud gaming may or may not have this advantage), as all cheats are based on game information, and even the state of the art machine vision still can't retrieve all the information needed for cheating within a frame(even if it just needs 0.5 seconds to do so, it's already too late in the case of professional FPS E-Sports, not to mention that the rendered graphics markup can change per frame, making machine vision even harder to work well there), and it'd be a epoch-making breakthrough on machine vision if the cheats can indeed generate the correct raw player inputs per frame(especially when the rendered graphics markups are highly obfuscated), which is definitely doing way more good than harm to the mankind, so games using this architecture can actually help pushing the machine vision researches 3. Game piracy and plagiarisms will become a lot more costly and difficult(cloud gaming may or may not have this advantage), as the majority of the game contents and files never leave the servers, meaning that those servers will have to be hacked first before those pirates can crack those games, and hacking a server with the very top-notch security(perhaps monitored by network and server security experts as well) is a very serious business that not many will even have a chance 4. Game data and state synchronization should no longer be an issue(while cloud gaming won't have this advantage), because the client side should've nearly no game data and state, meaning that there should be nothing to synchronize with, thus this setup not only removes tons of game data/state integrity troubles and network issues, but also deliberate or accidental exploits like lag switching(so servers no longer has to kick players with legitimately high latency because those players won't have any advantage anymore, due to the fact that such exploits would just cause the users to become inactive for a very short time per lag in the server, thus they'd be the only ones being under disadvantages) Disadvantages The disadvantages of this architecture at least include the following: 1. The game requirements and the maintenance cost on the server side will become ridiculous - perhaps a supercomputer, computer cluster, or a computer cloud will be needed for each server, and I just don't know how it'll even be feasible for MMO to use this architecture in the foreseeable future 2. The network traffic in this architecture will be absurdly high, because all players are sending raw input to the same server, which sends back the rendered graphics markup to each player(even though it's already highly compressed), all happening per frame, meaning that this can lead to serious connection issues with servers having low capacity and/or players with low connection speed/limited network data usage 3. The rendered graphics markup needs to be totally lossless in terms of visual qualities on one hand, otherwise it'd be a bane for games needing the state of the art graphics; It also needs to be highly compressed and obfuscated on the other, because the network traffic must be minimized and the markup needs to defend against cheats. These mean it'd be extremely hard to properly implement the rendered graphics markup, let alone without creating new problems 4. The inherent network latency due to the physical distance between the clients and the servers will be even more severe, because now the client has to communicate with the server per frame, meaning that the servers must be physically located nearby the players, and thus many servers across many different cities will be needed How Disadvantages Diminish Over Time Clearly, the advantages from this architecture will be unprecedented if the architecture itself can ever be realized, while its disadvantages are all hardware and technical limitations that will become less and less significant, and will eventually become trivial. So while this architecture won't be the reality in the foreseeable future(at least several years from now), I still believe that it'll be the distant future(probably in terms of decades). For instance, let's say a player joins a server being 300km away from his/her device(which is a bit far away already) to play a game with a 1080p@120Hz setup using this architecture, and the full latency would have to meet the following requirements in order to have everything done within around 9ms, which is a bit more than the maximum time allowed in 120 FPS: The client will take around 1ms to capture and start sending the raw input commands from the player The minimum ping, which is limited by the speed of light, will be 2 * 300km / 300,000km per second = around 2ms The server will take around 1ms to receive and combine all raw input commands from all players The server will take around 1ms to convert the current game state set with those raw input commands to form the new game state set The server will take around 1ms to generate all rendered graphics markups(which are lossless, highly compressed and highly obfuscated) from the new camera state of all players The server will take around 1ms to start sending those rendered graphics markups to all players The client will take around 1ms to receive and decompress the rendered graphics markup of the corresponding player The client will take around 1ms to render the decompressed rendered graphics markup as the end result being perceived by the player directly Do note that hardware limitations, like mouse and keyboard polling rate, as well as monitor response time, are ignored, because they'll always be there regardless of how a multiplayer game is designed and played. Of course, the above numbers are just outright impossible within years, especially when there are dozens of players in the same server, but they should become something very real after a decade or 2, because by then the hardware we've should be much, much more powerful than those right now. Similarly, for a 1080p@120Hz setup, if the rendering is lossless but isn't compressed at all, it'd need (1920 * 1080) pixels * 32 bit * 120 FPS + little bandwidth from raw inputting commands sent to the server = Around 1GB/s per player, which is of course insane to the extreme right now, and the numbers for 4K@240Hz and 8K@480Hz(assuming that it'll or is always a real thing) setups will be around 8GB/s and 64GB/s per player respectively, which are just incredibly ridiculous in the foreseeable future. However, as the rendering markups sent to the client should be highly compressed, the actual numbers shouldn't be this large, and even if the rendering isn't compressed at all, in the distinct future, when 6G, or even newer generations, become the new norm, these numbers, while will still be quite something, should become practical enough in everyday gaming, and not just for enthusiasts. Nevertheless, there might be an absolute limit on the screen resolution and/or FPS that can be supported by this architecture no matter how powerful the hardware is, so while I think this architecture will be the distinct future(like after a decade or 2), it probably won't be the only way multiplayer games being written and played, because the other models still have their values even by then. Future Implications If this architecture becomes the practical mainstream, the following will be at least some of the implications: 1. The direct one time price of the games, and also the indirect one(the need to upgrade the client machine to play those games) will be noticeably lower, as the games are much less demanding on the client side(drawing an already rendered graphics markup, especially without needing any audio nor visual assets, is generally a much, much easier, simpler and smaller task than generating that markup itself, and the client side hosts almost no game data nor state so the hard disk space and memory required will also be a lot lower) 2. The periodic subscription fee will exist in more and more games, and those already having such fee will likely increase the fee, in order to compensate for the increasing game maintenance cost from upgraded servers(these maintenance cost increments will eventually be cancelled out by hardware improvements causing the same hardware to become cheaper and cheaper) 3. The focus of companies previously making high end client CPU, GPU, RAM, hard disk, motherboard, etc will gradually shift their business into making server counterparts, because the demands of high end hardware will be relatively smaller and smaller on the client side, but will be relatively larger and larger on the server side 4. The demands of high end servers will be higher and higher, not just from game companies, but also for some players investing a lot into those games, because they'd have the incentive to build some such servers themselves, then either use them to host some games, or rent those servers to others who do Anti-Cheating In the case of highly competitive E-Sports, the server can even implement some kind of fuzzy logic, which is fine-tuned with a deep learning AI, to help report suspicious raw player input sets(consisted of keyboard presses, mouse clicks, etc) with a rating on how suspicious it is, which can be further broken down to more detailed components on why they're that suspicious. This can only be done effectively and efficiently if the server has direct access to the raw player input set, which is one of the cornerstones of this very architecture. Combining this with traditional anti cheat measures, like having a server with the highest security level, an in-game admin having server level access to monitor all players in the server(now with the aid of the AI reporting suspicious raw player input sets for each player), another admin for each team/side to monitor player activities, a camera for each player, and thoroughly inspected player hardware, it'll not only make cheating next to impossible in major LAN events(also being cut off from external connections), but also so obviously infeasible and unrealistic that almost everyone will agree that cheating is indeed nearly impossible there, thus drastically increasing their confidence on the match fairness. Hybrid Models Of course, games can also use a hybrid model, and this especially applies to multiplayer games also having single player modes. If the games support single player, of course the client side needs to have everything(and the piracy/plagiarism issues will be back), it's just that most of them won't be used in multiplayer if this architecture's used. If the games runs on the multiplayer, the hosting server can choose(before hosting the game) whether this architecture's used(of course, only players with the full client side package can join servers using the traditional counterpart, and only players with the server side subscription can join servers using this architecture). Alternatively, players can choose to play single player modes with a server for each player, and those servers are provided by the game company, causing players to be able to play otherwise extremely demanding games with a low-end machine(of course the players will need to apply for the periodic subscriptions to have access of this kind of single player modes). On the business side, it means such games will have a client side package, with a one time price for everything in the client side, and a server side package, with a periodic subscription for being able to play multiplayer, and single player with a dedicated server provided, then the players can buy either one, or both, depending on their needs and wants. This hybrid model, if both technically and economically feasible, is perhaps the best model I can think of.

Updates * v1.04a(GMT 0500 1-1-2022): * 1. Compatible With Yanfly Engine Plugins - Battle Engine Extension - * Animated Sideview Enemies Please note that using this with Yanfly's animated sideview enemies might cause minor performance issues on low-end mobiles

Unfortunately, I failed to reproduce the issue, so would you mind sending me your project via pm?

Patches (DoubleX)ECATB Base Formula(Possibly hurts code performance but frees you from copying the same <ecatb rate: RX> to every battler) Note Introduction Purpose Be an enhanced version of YSA-CATB with bug fixes and addons integrated Features Possibly upcoming features Games using this script None so far Compatibility Fix DoubleX RMVXA Enhanced YSA Battle System: Classical ATB Compatibility Screenshots Video https://www.youtube.com/watch?v=E692R6s8F0I https://www.youtube.com/watch?v=6E0-X0wbLAM Demo Coming Soon Prerequisites Terms Of Use Instructions Author's Notes FAQ Authors Changelog Download Link DoubleX RMVXA Enhanced YSA Battle System: Classical ATB

Updates # v0.05c(GMT 0600 28-11-2021): | # 1. Fixed wrong eval of ecatb_battler_scale and uninitialized battler turn | # bugs |