Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Do not use Discord to host any images you post, these links expire quickly! You can learn how to add images to your posts here.
Apologies if you've had troubles connecting to the site, you may need a VPN to access it. Staff are also facing issues connecting, so if it's urgent please message Cat on-site or through Discord directly.
Hey Guest, staff applications are open! If you are interested in becoming a forum staff member and/or Discord staff member, please apply through this Google Formbefore April 2! You can also message Cat with any questions.
Very cool script. I wanted to have something like that for a long time. I'm very curious what you will add in the future.
I have one question though:
Does it make sense to give a trainer SkillLevel over 100?
According to Essentials it would follow the same logic above >100.
I hope not, because otherwise it wouldn't make sense to give my champion skill level 255. At least 255 was always the upper limit you could set.
Yes, actually! In short, this script makes the AI more likely to choose moves the game sees as favorable, scaling with AI level.
The AI is split into two phases; determining scores for each move, and choosing a move based on those scores. For the first phase, there are basically only 4 skill levels, to determine whether the AI will favor more strategic moves (such as ones that raise stats, set weather, etc.) or if it'll just attack recklessly. In this first phase, there's no difference between a 100 and a 255 skilled opponent.
The second phase is where most of my changes apply. In base Essentials, if one move comes back with a score of 1 and another comes back with a score of 2, it'll choose the second move 2 out of 3 times. That's only a 66% chance to choose a move the AI has already determined to be twice as good. My script applies an exponent to these numbers before deciding, with the power being influenced by the opponent's skill level. In layman's terms, this means that lower skill levels may choose the better move 75% of the time, for example, while higher skill levels might choose the better move 98% of the time.
The AI was only designed with skill levels between 1-100, but numbers above 100 should still be more likely to choose better moves in the second phase than 100 skill opponents, even though the raw scores determined in the first phase stay the same. The only concern would be integer overflow, though I've already gone to some lengths to guard against in the script.
This was a great adition to my game. This doesn´t fix every AI issue (the AI sometimes still trys to use moves like fake out after turn 1) but it makes the AI not fully stupid. Would recommand for everyone who wants their game to be instantly better.
The AI is split into two phases; determining scores for each move, and choosing a move based on those scores. For the first phase, there are basically only 4 skill levels, to determine whether the AI will favor more strategic moves (such as ones that raise stats, set weather, etc.) or if it'll just attack recklessly. In this first phase, there's no difference between a 100 and a 255 skilled opponent.
The second phase is where most of my changes apply. In base Essentials, if one move comes back with a score of 1 and another comes back with a score of 2, it'll choose the second move 2 out of 3 times. That's only a 66% chance to choose a move the AI has already determined to be twice as good. My script applies an exponent to these numbers before deciding, with the power being influenced by the opponent's skill level. In layman's terms, this means that lower skill levels may choose the better move 75% of the time, for example, while higher skill levels might choose the better move 98% of the time.
The AI was only designed with skill levels between 1-100, but numbers above 100 should still be more likely to choose better moves in the second phase than 100 skill opponents, even though the raw scores determined in the first phase stay the same. The only concern would be integer overflow, though I've already gone to some lengths to guard against in the script.