Changing Parameter Values Via Script

There was already a thread on this from a few months back with a rather brilliant solution imho here from a member I was hoping to alert with this follow up.

Alas, same question, hopefully using same solution formatting, but for Ex- and Sp- parameters.

Possible?

Thanks in advance.

Did some toying around and came up with this, though it may not be the cleanest solution (but it was what I could come up with before work)

console.log($dataActors[1].traits[0].value)
$dataActors[1].traits[0].value += 0.05
console.log($dataActors[1].traits[0].value)

In this example its looking at actor 1 (obviously), checking his traits from the database (the array is drawn in the order you list them, in this example Critical Hit was first on his list, thus array slot 0), if you were to put this into an event as a script call and check the console, it would print out the default value from the database and then the 2nd console.log would show the updated value.

so if you were to make this work, you would reaaaaaaally want all your actors to have all their params/traits set up in the database set up in the exact same order so making the script calls much easier, as if you had actor 1 with (crit, hit, eva) and actor 2 with (hit, crit, eva) using the same line of code to change traits[0] would only change the 1st one in each of those examples.

sorry if this is somewhat of an incoherent mess, I was trying to do this very fast and explain it the best I could in a rush! I can help more later if needed, but its a start and either myself or someone else can branch off or do it better/differently, lol

To modify x and s params you need to add/remove features/traits that add them. That would be easier than the one above in case you want to modify params that the heroes might not have beforehand.

PS: At the very least that's how we used to do it back in VX Ace

I only explained the way to do it the way I did because they were specifically asking for it via script.

I realized that this actually has a use I could add to my games questing system though... using the code I provided and setting up players all the same, I could actually offer permanent special stat increases as quest rewards now ( +1% crit baseline when turning in a quest, not dependent on weapons/armor/states)... so even if this isn't something that was what the OP was looking for, I did get something out of it. :)

Even adding features/traits would be done via script call anyway, I dont think theres an event command for doing that

I couldn't find a way of adding a trait by script call when I tried, only was able to modify the ones already present on the character... so what would the proper code be to add/remove something on someone? o_O

You would probably add it to that same .trait array, as in put a new value into that array. So you'd first need to know how the engine pushes the traits you put in the database into the actor object during game initialization then you'll follow that very same method to add/remove new traits into an actor.

Heh, seems overly complicated considering most people would have all of a characters base stats set up by default in the database anyways, otherwise everything would come back as 0. To each their own I suppose though :)

Not really, most users wont be putting all of the Traits in their actor, and thats what adding Traits mid-game is for. Even just talking about Ex and Sp params, most wouldnt be using all of them, or have them setup already.

practically speaking, its just calling the trait object of the actor and using the .push function to it (assuming its just an array) while supplying the correct data for the new Trait to be added (iirc traits only have 2 components, the trait ID which tells the game what trait it is and the value)

Actually I looked again on what you first posted and it seems you used $dataActors, that object actually is loaded from the database every the game runs, and changes to it doesnt get saved in the save file. When an actor is initialized in the game, it creates a new entry in the $gameActors object and uses the data in $dataActors as initial values but after that all changes should be done via $gameActors afterwards since that is what gets saved in save files and is what is actually used by the game. Once you close your game, the changes done to any $dataXXX object is lost and during the next run of the game it will load the values for the $dataXXX objects again from the database.

You can test it by playing your game, run your function, save, close the game, open it again, load your saved game, then run your function again. It will show you the same set of values from the two runs, when it should have shown you successive values (like if first run is 0.05,0.1 then second run should already be 0.1,0.15)

Now because of that, there's actually a problem. Game_Actor actually just reads the $dataActors object to get the actor traits, and since $dataActors doesnt get saved into the save file, you cant make Trait changes to the actor that actually gets saved. Ofc we can add $dataActors to the saved file but that would mean saved files wont take into account database changes to Actors (which might be fine or not). So if you want Trait changes to actor that persist on save files while maintaining linkage to the database, we actually need to define an additional traits list for Game_Actor itself. Or you would use invisible states to modify the Traits

Take note though that modifying $dataActors also has another side effect due to its nature. If a player don't close the game, the $dataActors data doesnt reload from the database even if he goes on a new game, meaning your edits to it will also be present in the player's new game. You can actually test this by playing your game, then use your sample function above, go back to title and start new game (remember without closing the game) then call your function again, your first console.log on the new game will be same as the last value of your last console.log

so like if ur base crit was 0.05, your console log will be

0.05
0.1
0.1
0.15

while it should have been the same set of numbers

0.05
0.1
0.05
0.1

That is unless they changed the $dataXXX to force reload during New game in newer versions of MV

Interesting to read... I didn't try saving and quiting or saving and reloading this morning since I didn't have that kind of time, but that does make sense now that you mention it. :/ Well crap, lol

I can still make this idea work for the idea I had for my personal game since I actually have something setup to run every time a game is started or loaded to initialize some of the enemies parameters that scale (mainly so they show properly in a bestiary), but you're right... my method would not be a good solution for the OPs request after all.

I'll try something again when I finally get a chance after work, but thank you for finding the massive flaws in my quick idea XD

What if i said this is exactly why i am inquiring, to do exactly what you've described.

I am organizational on these matters to a fault (irl anyway). Setting all the actors the same way would be my norm, mandatory.

States?

Solid insight.

I admittedly don't know how the engine pushes those traits, but none-the-less remain very curious as to if this
can be utilized in a similar manner to manipulate ex/sp params.

Nope, because x/s params are obtained only via the collection of all trait objects that give that x/s param. That method you quoted increases params via adding to the param_plus variable (or whatever it is called in MV) of the actor (which is considered when the game takes the actor's param) but sadly that variable is only for the normal params, not ex/sp params

Yes you could use states, but since states cannot stack with itself, you'd then need new state for every possible point.

Like if you want to increase crit by 1% every level, you will actually need to have 1 state per increase and add/remove the correct state upon level up (or use combinations of them as long as you use different states).

So like if ur gonna add 1% crit 10 times over the game, you'd at the very least need 4 states which gives 1,2,3,4% crit since a combination of them can give you the remaining 5-10%

Because of that, adding/manipulating the traits directly will be easier and more efficient

Back in Ace, Shaz iirc made a script for this called Dynamic Features which lets you add Features (Traits) to the actor mid-game.

Since Engr. Adiktuzmiko pointed out to me that you would need it to fix itself on loading or starting a new game, I've been working on something a bit to work with my game, once its done I'll post with how iIdo it, and see if it is something you would want to use yourself.

A brief description would be using variables for each attribute, and have a common event run when starting/loading the game to take the base of each for every party member and adding X value to them based on the (variable * value)... so if you finished 9 quests that reward crit chance and you have it set so each quest gives 0.5% crit, then when the common event runs it would give (base crit + (variable * 0.5))

I'll give this a bit more thought and make sure I can get it working for myself before torturing you with crazy ideas too much! XD

Please and thank you!

Also, I may have hit the motherlode here: https://forums.rpgmakerweb.com/inde...out-using-traits-or-states.75600/#post-710771

With a pretty promising promise here (concerning the changes not sticking) that we'd have to hunt down the status of: https://forums.rpgmakerweb.com/inde...out-using-traits-or-states.75600/#post-711077

That is exactly what I was telling earlier, using push on the traits array to add new traits.. but then again as the thread says (which is btw an old one), its still using $dataActors at the end ($gameActors(x).actor() returns the $dataActor object) so it still will not stick..

Making a plugin that adds an actual trait array to the $gameActor and make the game read it so that we can add/remove traits on the go is pretty simple though, and somebody might have already written one.

Does the age of the thread make it somehow less valid? (Being serious, like were there updates that would negate the approach since then or something?)

I highlighted that the poster acknowledged it didn't stick and had a fix (second link I shared), but the transmission ends there, so I mentioned we'd have to hunt for possible follow through.

Also the walls of exact code ready to copy/paste were a pretty substantial contribution imo.

What I mean is that since it hasnt been updated since last year with a better solution, it probably means that they stopped trying to fix the solution. Or ofc they could have just forgot that the thread existed

Edit: Actually Ive re-read the next replies in the thread and it seems like that person just decided to use Yanfly's parameter control plugin

Well sadly you're not supposed to update the post after 30 days of silence, so who knows. And then I simply don't think the question was asked again until now.

The OP did... but the specific poster I directly linked to was very confident they had it nailed (they definitely had the first non-sticking part nailed) and then (I just discovered) went on to do some pretty in-depth scripting tutorials. I wonder if he covered the topic at hand and shared his sticking solution.

You would still end up writing up something akin to a script/plugin to make it stick (either via the script calls in an event or full external js file).

And practically, it's already been done anyway.

Even I can make it stick via different ways (which I already outlined in one of my posts above), but I would rather write that as a js file in itself coz its more efficient.

No doubt.

For MV?

Makes sense.

FWIW this didn't actually sound that scary to me. If the progression system were "creatively" pared down and streamlined a bit it probably wouldn't be that taxing. But yeah I'd love to read through some direct manipulation.