General Discussion

[DarkTl]

I am not sure what you mean here. We gather the stats from every ND event sequence and apply them once, during that application (or any application), effects are applied over them automatically.

I don't get it. If they are already applied, then why self.loggs('vitality', -40) ignores the testing effect which should make it -20?

[Xela]

I don't get it. If they are already applied, then why self.loggs('vitality', -40) ignores the testing effect which should make it -20?

Ok, think about it like this (which is exactly how it is working):

Code: [Select]

class Char():
    ...

char.vitality += 100 is where the magic happens.


Code: [Select]

class Job():
    ...

Job.events():
    self.loggs('vitality', -40)
    self.loggs('vitality', 20)
    self.loggs('vitality', -30) # All three of this commands plainly log the change to a dict, they do not apply anything.

Job.end():
    build_nd_event() # with raw data from self.loggs
    for stat, value in self.loggs:
        char.stat += value # This is where the actual magic is happening, but it is not exposed in any way or form to outside scopes.


Code: [Select]

class Char():
    ...

Char.next_day():
    ...
    This method creates a copy of old stats dict.
    On every next day, it checks new values vs old values, these are final, true, concrete values including all magic, newly equiped items and etc. So basically everything...


We can rip effects mods calculations from the Char class and calculate it for every Job ND Event and than have the magic still happen on application but I don't particularly like create more mess in code, especially before another decent cleanup/refactoring effort.

[Xela]

If you think about it, we might not even want to f*ck with jobs data. It might be confusing to both players and ourselves, not mentioning that if a worker, say, gained:

10 JOY
5 ATTACK

during the events but both of these stats are maxed out, if we go through the true dict, it'll show up as if nothing happened at all... if we put them through some windmill of logic before displaying them, balancing and keeping track of jobs will become that much harder for both, us and players. While pointing out that what you see there is raw data, seems to negate all of that.

[DarkTl]

There might be something wrong with reports atm.

Our testing file gives Nami 0 vitality from the beginning. If you set her to rest and go to the next day, the next day log will have two events about her. One will give +70 vitality, another one about -60. And the resulting vitality will be about 80 if you look at her stats.

Two events happen because we mistakenly have two places which could restore vitality.

Code: [Select]

                if self.AP > 0:
                            if self.health < 90:
                                txt += "She had some strength left left over today so she took some time to heal her wounds. \n"
                                self.health += self.AP*2
                                self.vitality += self.AP*4
                           
                            else:
                                txt += "She had some strength left over today so she spent some time taking a break and having fun. \n"
                                self.joy += self.AP
                                self.vitality += self.AP * 5and

Code: [Select]

            while self.worker.AP and not all([(self.worker.vitality + self.workermod.get('vitality', 0) >= self.worker.get_max("vitality") - 50),
                                                          (self.worker.health + self.workermod.get('health', 0) >= self.worker.get_max('health') - 5)]):
                self.loggs('health', randint(2, 3))
                self.loggs('vitality', randint(35, 40))
                self.loggs('mp', randint(1, 3))
                self.loggs('joy', randint(1, 2))
                self.worker.AP -= 1But it's not the point. Even if these events work one after another, there is no way for self.vitality += self.AP * 5 to give -60, and there is no way for 70-60=80, nor 70+60=80. And she doesn't even have any special traits with effects.

[DarkTl]

If jobs cannot be directly affected, it makes the (re)creation of slow learner and fast learner effects complicated...

If you think about it, we might not even want to f*ck with jobs data. It might be confusing to both players and ourselves

Ok, what about consumables? I did some testing, effects do not affect them.

[Xela]

I am on Andoid again. Items prolly go around the usual python mech. It may be possible to force the effects, I didn't have time to look into that yet.

[Xela]

Yeah... I just ran a search over the whole project... stats modification is a fucking mess because of all the ways it can be achieved. It could be worth the effort of another rewrite and adding _ in front of all methods that should not be accessed directly.

It's just very difficult and confusing system to work with because of all the fucking insane complexity we've added to it, like special consumables, misc items, normal items that mod a whole other stats dict, traits, trying to sure stats are not messed up by temporary consumables and misc items and when normal items are equipped and unequipped and all the special considerations made for traits and other shit like that. But code seems to be in an ok shape, I'll just try move effects from Char.__setattr__ to Stats and try setting some solid rules to how stats are to be modified, updating code that does it in other ways... it'll prolly take a good while.

[DarkTl]

I always can make custom effects by hacking your code directly.
Just now I added Left-Handed trait which makes all left-handed weapons/tools twice as effective, and vice versa for right handed ones. It's permanent, so there is no need recalculate stuff for it.

I can just as easily tie consumables to any other trait instead of rewriting the whole process of items control.

[DarkTl]

I don't understand the meaning of this insanely long check in the rest job 

            while self.worker.AP and not all([(self.worker.vitality + self.workermod.get('vitality', 0) >= self.worker.get_max("vitality") - 50),
                                                          (self.worker.health + self.workermod.get('health', 0) >= self.worker.get_max('health') - 5)]):

[Xela]

I think it will run the loop until "worker" runs out of AP or both gets max_health - 5 and max_vitality - 50.

[Xela]

I always can make custom effects by hacking your code directly.
Just now I added Left-Handed trait which makes all left-handed weapons/tools twice as effective, and vice versa for right handed ones. It's permanent, so there is no need recalculate stuff for it.

I can just as easily tie consumables to any other trait instead of rewriting the whole process of items control.

Why...? without making slots interchangeable it will just feel stupid and half-implemented...

[DarkTl]

Because it's a fun effect which makes balance more interesting. It shouldn't be perfectly logical.
For instance, all shields immediately become twice as powerful, so defense will be better with this trait, at the cost of attack of course.

[Xela]

Is there any chance we can do without traits/items that can fuck up max/min limits beyond reason? There is a lot of clumsy code that is required because of that, I was wondering if there is something we could agree on content level...

[DarkTl]

Min values I use only in special cases to make item/trait a bit more unique. Although, every one of them can be replaced with unique effect, assuming that items support equippable effects (I think they should, but never tried before).

As for maxes, unlike WM (the last time I played it, at least), we have level max and max. They guarantee that simple bonuses to stats, without touching max values, very soon will be useless once value=max value due to training and using consumables.

If you want to get rid of bonuses to max values, the only alternative is to make items bonuses ignore characters maxes. So max attack will only restrict character's own attack, but a weapon with +10 attack will give that +10 once equipped no matter what, and will remove that 10 once unequipped no matter what.

This will make items system much simpler, yet all items still will be useful. Consumables will be a bit tricky though, we don't want healing potions to heal higher than max health.

[Xela]

No, I don't want to get rid of those bonuses completely but if there is some way you can see to make sure they don't send max to negative territory and send min above max values and other stuff like that, I'd like to know... it's how we mainly got into trouble in the first place, traits and items (especially monster-fuck items that send stats flying all over the place with huge modifications) would snowball and completely mess up the system. I've put safeguards at your request and they seem to be working but the resulting code is really difficult to work with as it is becoming increasingly harder to recall what safeguards against what even with some comments I left behind.

In either case, it's a bit better now... I've put a lot of time into refactoring stats code but it is still pretty fucked up and I don't believe that it can be significantly improved upon. The system is simply too complex and tries to anticipate too many things that can go wrong with all the features we put into the game for code to (perhaps ever) be clean and intuitive. I am sure that some things broke down and would have to be fixed as we go and get errors and there were many collisions between changes you and I made at the same time and I am not 100% sure that I've fixed all of them correctly

All and all, there are many new improvements now and I have some ideas on how to further improve upon them but it will be slow...