A Function that Fits Level-up XP Requirements?

It had been years since I last installed Arcanum, but now that I've started re-playing it, I'm quickly remembering why it's one of my favourite games. It's only been about two weeks since I re-installed it, but I've already started over countless times, partly because I regretted early bad decisions, partly because I've encountered far more bugs that in my earlier experiences, and overwhelmingly because I figured out that the pseudo-random number generator for chest loot is seeded by a hash of the name you choose for your character (who could pass up optimizing the loot in the starting magick chest?).

I am now starting over again (mostly because I've gained too many levels before working on the main quest and I'd like to pick up my followers at around their level), and have decided to first install an xp cap remover (As a melee fighter, I am probably going to run out of levels fast), but I want the amount of XP needed for each level to stay true to the proportions set forth by the developers.

Sorry for the rambling, but what I am trying to say is that I have been trying to find a contiguous function that fits the existing XP requirements for leveling, so that I can continue it to 127. I know that others have written their own .mes files with growth up to this point (both linear and exponential), but I have been trying to deduce how the original table was produced for 3 days now and I think that only a formula will satisfy me. It started as "oh this looks interesting, let's see if I remember my calculus..." and has now devolved into something I don't know the answer to, which means I MUST KNOW THE ANSWER AT ALL COSTS.

The closest I have gotten to the function (or at least the one that looks the nicest) is round(2800e^(x/25)-100x-2800)*100

It should be so easy... as a programmer I know that we like nice, friendly, memorable numbers in our equations, but due to rounding (and the magnification thereof), too much oscillation occurs in higher derivatives to calculate accurate regressions. It's probably something obvious that I'm not seeing, though... and then you can all have a laugh while I pretend that I was just joking about that whole three days thing, so everyone is a winner.

Thanks (pre-emptively) to anyone who already knows the answer and is willing to clue me in, and extra thanks to anyone crazy enough to obsess over finding it, like I'm doing. Of course, if the answer is that the values are mostly arbitrary, thus why they are stored explicitly in a .mes, I'd still like you to tell me, but know that you will be crushing all my hopes and dreams in this world and I will possibly shed a tear.

Good day.

 

Yes that is definitely a good point. However, there may be other explanations for why the values are stored explicitly on disk.

For example, while I am still learning game engine development, I do know that speed is everything. While an exponential function can be calculated incredibly quickly, it would not be efficient to have to calculate it every time you need to use it. This means that some sort of caching would be used on the results, keeping the most relevant output in memory and storing values that are predicted to be relevant later on disk. If you think about it, though, that is already what has been done with this .mes file; It describes all values that would be relevant, and is loaded into memory on execution, allowing the currently needed values to remain there, while the rest is swapped out.

Pardon for getting a bit technical with my bullshit, but the point is thus: Why calculate something every time you need it, when you could store it once after calculating it when you first need it, when the application first starts up, when the application installs, or even when the application is being packaged for distribution? Having a file with all the data you will need in it might be more convenient than having to compile in the algorithm, store the starting value and input range, and then generating that exact data when you need it.

Of course, a more likely explanation is that such game logic is handled by dynamic scripting interpreted by the engine post-compiletime, and that the language would be slower and less sophisticated than the actual engine. This means it may not be capable of producing accurate results, produces them slower, or stores and interprets data better than an algorithm and its parameters.

Thus, I'm still holding out hope that the actual function can still be found. Of course, it is possible that I am just rationalizing in an attempt to forestall the inevitable epiphany in which I realize that I've wasted countless hours on something completely arbitrary, but that's rather pathetic.