General Discussion

[Xela]

Heh. thanks for explation of what's going on 

Ok, so my option is:
- I think that current tagger-json system is working fine for our purposes. Its likely not perfect but that could be said about just anything in game - and I just don't feel that the improvements there would be wort the time that could be spent elsewhere.
But maybe I just didn't understand the suggestion well enough.

- there is an overwhelming number of tags, but majority of them are secondary tags which are just optional to use - pack creators can just tag everything with only major tags like "profile" or "sex" and girls will work with generic texts with almost no effort (like girls imported from wm). That's why we didn't hold back there, it's just for the perfectionist freaks who care about it  But some tag revision is planned.

Yeah, I agree, there is nothing forcing modder to tag every little thing.
===================================

BTW: Is there any feedback on new city map button system? Is it acceptable/better/worse than the old one (switching back is literally just clicking one button in version control software to go back to precious map.xml).

[Xela]

F#CK YEAH!!!!

  I've got auto-equipment method to work for consumable items

Code: [Select]

        def auto_equip(self, target_stats, exclude_on_stats=None, slot="consumable", source=None):
            """
            targetstats: expects a list of stats to pick the item
            exclude_on_stats: items will not be used if stats in this list are being deminished by use of the item
            *default: All Stats - targetstats
            slot: slot
            source: list of inventories to draw from
            """
            if not source:
                source = [self.inventory]
            if not exclude_on_stats:
                exclude_on_stats = list()
            items = store.items
            returns = list() # We return this list with all items used during the method.
            if slot == "consumable":
                # The idea is to increase any particular stat to it's maximum
                # Maximum raising should be coded in at some point as well
                # Here we need the best item to increase the stat:
                # ------------->
                # Get all items availible for the task:
                for inv in source:
                    d = dict()
                    content = inv.content
                    # Try to get a dict of all useful items:
                    for item in content:
                       
                        item = items[item]
                       
                        if item.slot != slot:
                            continue
                           
                        if set(self.traits) & set(item.badtraits):
                            continue
                       
                        if any([item.ceffect, item.type == "permanent",  item.sex not in (self.chr_sex, "unisex"),
                                  item.id in self.consblock, item.id in self.constemp,
                                  item.type == "food" and self.effects['Food Poisoning']['activation_count'] >= 9]):
                            continue
                           
                        # We finally check if there is at least one matching stat and if so, add the item at 0 priority   
                        for stat in item.mod:
                            if stat in target_stats and item.mod[stat] > 0:
                                d[item.id] = 0
                                break
                               
                        # Wasteful items, we reduce the desirability by 100:
                        bonus = 0 # Actual bonus
                        possible_bonus = 0 # Total possible bonus
                        penalty = 0 # Total penalty
                        # Normal stats:
                        for stat in item.mod:
                            if stat in self.stats: # Not usefull?
                                if item.mod[stat] > 0:
                                    possible_bonus += item.mod[stat]
                                    if stat in target_stats:
                                        # This is not perfect, but it shouldn't matter (max at the game start issue)
                                        if self.stats[stat] + item.mod[stat] > self.get_max(stat) + 5:
                                            bonus += max(0, self.get_max(stat) - self.stats[stat])
                                        else:
                                            bonus += max(0, item.mod[stat])
                                            # Since (almost)) nothing is wasted, we'll just multiply bonus by 100!
                                            bonus = bonus + item.mod[stat] * 100
                                else:
                                    if stat in exclude_on_stats:
                                        penalty += item.mod[stat]
                        # We do the same thing for max stats:
                        for stat in item.max:
                            if stat in self.stats: # Not usefull?
                                if item.max[stat] > 0:
                                    possible_bonus += item.max[stat]
                                    if stat in target_stats:
                                        # This is not perfect, but it shouldn't matter (max at the game start issue)
                                        if self.stats.max[stat] + item.max[stat] < self.stats.lvl_max[stat]:
                                            bonus += max(0, item.max[stat])
                                        else:
                                            bonus += max(0, self.stats.max[stat] - self.stats.lvl_max[stat])
                                else:                               
                                    if stat in exclude_on_stats:
                                        penalty += item.max[stat]
                                       
                        # Last, we multiply bonus by two if item in in good traits:
                        if set(self.traits) & set(item.goodtraits):
                            bonus = bonus * 2
                                       
                        # Normalize the three:
                        # bonus = 0 # No need for normalization
                        possible_bonus = min(100, possible_bonus)
                        penalty = min(150, penalty*-1)
                       
                        # and finally set the priority getting this right is possibly the most important thing in this method:
                        d[item.id] = bonus * 2 + item.eqchance * 2 + possible_bonus - penalty
                       
                    # If there are no items, we go on with the next inventory:
                    if not d:
                        continue
                    # Now that we have a dict of item ids vs priorities:
                    # Sort by highest priority:
                    l = sorted(d, key=d.get, reverse=True)
                   
                    l = list(items[i] for i in l) # Get a list of item instances.
                    first_loop = True
                    for stat in target_stats:
                        for item in l:
                            while self.get_max(stat) - self.stats[stat] > 0:
                                # apply the actual item effects, do checks and repeat until stat is maxed out.
                               
                                # Break out immidiatly if item is not capable of increasing this stat:
                                if stat not in item.mod or item.mod[stat] < 0:
                                    break
                               
                                if not first_loop:
                                    # If we used this item once already, it is sensible to check if it's wasteful to use it again:
                                    # This will handle all other items as well, if expensive item is wasted (by more than 30%), we will not use it.
                                    # This will not run if any stat is below 40 (In such case we most likely want item to be auto-used anyway)
                                    if self.stats[stat] > 50 and self.stats[stat] + item.mod[stat]*0.7 > self.get_max(stat):
                                        if item.price > 100:
                                            break
                               
                                first_loop = False
                               
                                inv.remove(item)
                                self.apply_item_effects(item)
                                returns.append(item.id)
                               
                                # Check is there any new conditions preventing repeating the process:
                                if any([item.id not in inv.content, item.id in self.consblock, item.id in self.constemp,
                                           item.type == "food" and self.effects['Food Poisoning']['activation_count'] >= 9]):
                                    break
                                   
            return returns

[Xela]

Ok.. 3rd post in a row but the amount of sh!t I got done more than justifies it!

Results:



Auto-equip method is over 300 lines of code but at least it's smart enough to handle different stats under different conditions. The above pic give some idea of what it's capable of at it attempts to pick the best items for the job that do not have disadvantages and do not waste themselves (Game will not try to consume Ultimate Healing Potion to recover 30 health for example). How it's done will take too long to explain and it will likely be improved even further in the future. I tried to make it faster using as many build in Python functionality that is written in C as possible.



This is a different method using auto-equip (all slots) to prepare Hinata for Combat.

Phew... this wasn't easy

SF Updated:
- Fixed couple of typos in items.jsons
- Added Auto-Equip and Equip_for methods prototypes
- Further improved Inventory class
- Added timer to crazy tags loading routine
- Added proper exit button to custom-screens and we're now using it everywhere (I think)
- Killed Ren'Py own loading test routine during items loading (3 times slower since doesn't justify it's power (loading items from any folder))
- Fixed member from other teams being possible to set in leadership position on new teams but (Reported by Dark)
- Some code refactoring

[Xela]

=====================================
I need confirmation, we NEED to invert the fatigue stat! I want to rename it to energy but I recall that someone had problems with that name! Please comment on this...

[Pinkutako]

I'll give you an End User opinion.    


Fatigue is currently building to 300/300 correct?  Energy would start at 300 and reduce to 300 when tired?


Either method is easy enough to understand and doesn't make a difference to me.  I'd say go with what is easier to code.

[Xela]

I'll give you an End User opinion.    


Fatigue is currently building to 300/300 correct?  Energy would start at 300 and reduce to 300 when tired?


Either method is easy enough to understand and doesn't make a difference to me.  I'd say go with what is easier to code.

Thanks But I've already decided to do that, we had a discussion some time ago and someone really hated "Energy" as a name for a stat (Unless I am mistaken). I am asking about the name, process itself is very much required at this point... there is too much garbage in the code when inverting or creating special conditions for fatigue.

If someone can think of a better option, batch converting will convert every "energy" mentioned in texts as well as in code so it will lead to issues if I don't get this right from the first try.

====================================
I am almost done with specialized auto-equipment method. Next is auto-buy. As Dark suggested, I am going to make that one "stupid" instead of smart (to simulate rl, girls rarely buy what they need ). Then: Code refactoring: get rid of fatigue and kill a couple of ancient classes + adapting equipment routines to new methods.

[livingforever]

Hey there!

First things first: Let's stop the tagging discussion here. I got your points, I'll see if I can come up with something that satisfies all of them (including my own) and post it in the "Image tagging concept" thread.

Well, if you code a tool that can write data to filenames and json, we'll know. Otherwise I am not guessing what's faster.

I'll do some tests.

- Rewards work fine, I will not complicate working systems until a final release.
- Same as above.
- At higher levels fights can take a really long while, one - two hits fights are less common I believe. Also there is no point of doing this before we rework battle engine.
- And I like randomness during training.
- Job attack Events depend on clients that get "Aggressive" trait randomly assigned, they are farther mitigated by security rating. I see no reason to change that.
- I actually hate stuff like this in games, it kinda ruins the mood and disrupts continuity. I expect mods will take care of request like this in the future.

In any case, most of this is fine-tuning, we'll take care of stuff like this when there is a game with more or less solid concepts in place + locking random seed solves most of these issues, if stuff isn't randomized after loading game anymore, save-scumming becomes a lot less attractive.

Ok. First, I believe you're making a big mistake by moving everything that doesn't seem important to you to a release version. I don't want to sound like my profs (sorry if I do), but planning things through (including details, the only thing that can wait is the balance of numeric values) is very important, it's the first important step for every project. I don't expect you to say/write "Of course, I'll implement it right now!", but something along the lines of "Thanks, I made a note so I won't forget about it later!" would be great.

Now, let's check my points again:

• Just because something works doesn't mean it's good. If you never polish things you will never have a polished release.
• Same.
• Alright, have fun with the rework.
• Some randomness is absolutely fine, it would be boring otherwise. But sometimes characters get nothing and sometimes they get three points on everything - seemingly independent of what was paid for the course (correct me if I'm wrong).
• Same here, I don't want you to completely remove the RNG aspect, I simply want it to be more consistent.
• If you don't like it, fine.

And about locking the random seed: It's funny that you told me that you don't see a reason to prevent save scumming and now you're telling me that you're planning exactely that. Anyway, it's important to mention that it won't solve these issues, it will just prevent the player from doing something against them.

=====================================
I need confirmation, we NEED to invert the fatigue stat! I want to rename it to energy but I recall that someone had problems with that name! Please comment on this...

How about vigor?

Have fun!

[Xela]

Ok. First, I believe you're making a big mistake by moving everything that doesn't seem important to you to a release version. I don't want to sound like my profs (sorry if I do), but planning things through (including details, the only thing that can wait is the balance of numeric values) is very important, it's the first important step for every project. I don't expect you to say/write "Of course, I'll implement it right now!", but something along the lines of "Thanks, I made a note so I won't forget about it later!" would be great.

I'll look into it on the next Arena refactoring/review

How about vigor?

That's a good option, yet many of non English speakers may not know what it means...

I think viable options are:

Vigor
Energy
Vitality <-- (I kinda like this one, but it kinda presents same issue as Vigor )
Determination
Ability
Liveliness

[CherryWood]

I need confirmation, we NEED to invert the fatigue stat! I want to rename it to energy but I recall that someone had problems with that name! Please comment on this...

Not me! I'm innocent! I suspect the other guy!   
("Energy" sounds ok to me now, so If it was me who had the complains, then I totally forget what that was about)

Hey there!

First things first: Let's stop the tagging discussion here. I got your points, I'll see if I can come up with something that satisfies all of them (including my own) and post it in the "Image tagging concept" thread.

Hi! You're sure welcomed with that. It may be a little hard to convince some of us who already put 100+ hours into tagging images and related stuff about it, but if you really think that something could be done in a better way, it's always worth to try. We want the game to be modder friendly for sure, so more ideas about achieving that, the better.

[Pinkutako]

Energy is fine.  English is my native language; so all the the choices seem reasonable.  Energy is probably the most universal, because it is a scientific concept.


So....Go go Energy!   

[sohz]

yeah but you dont have here universal players ^^ i bet all of us are players and refer energy to an alternative for "mana".
I think vitality or vigor are the best choices (sorry my english was so terrible )

[MrKlaus]

I think viable options are:

Vigor
Energy
Vitality <-- (I kinda like this one, but it kinda presents same issue as Vigor )
Determination
Ability
Liveliness

 Maybe add to the list: tiredness or exhaustion (both plain and simple in my opinion).
 
 Update on elements alignment: I have the concept of the basic dialog tree with the menus done. Totally stuck with the expanded descriptions. 
 
 

[DarkTl]

There are very good scaling algorithms and libraries (that produce good results even when upscaling by factor two).

Even though we already resized girls pictures a lot to reduce packs size, there are still people complaining about it. Basically, it seems that people would prefer low packs size over high quality and resolution pics. And you cannot scale small, low-q pics with good results.

However, I think that less tagging effort is worth a lot more than slightly more intuitive tags.

You should try to tag at least one 1500+ pics pack before saying so 
At the end of the day you don't have enough strength to deal with unobvious tags. That being said, of course less tagging effort is important too, but not at the cost of intuitiveness.

BTW: Is there any feedback on new city map button system? Is it acceptable/better/worse than the old one (switching back is literally just clicking one button in version control software to go back to precious map.xml).

It looks very cool and it defenitely better than the old one. The only problem is that locations are invisible until you select them. Thus, you have to remember where to click, and what exists in the game at all.
Maybe it should look like in starcraft2 campaign, if you ever played it. Interactive elements there have very thin frame around them all the time.

I've got auto-equipment method to work for consumable items

Awesome 
I'll take a look at it and edit items properties a bit if necessary.

But I've already decided to do that, we had a discussion some time ago and someone really hated "Energy" as a name for a stat (Unless I am mistaken).

You see, this forum equipped with powerful search function 
Maybe it was somewhere else, but definitely not here. I don't care about it, personally.

[Xela]

Maybe add to the list: tiredness or exhaustion (both plain and simple in my opinion).

Yeah.. but neither inverts the fatigue 

Maybe it was somewhere else, but definitely not here. I don't care about it, personally.

Great, I'll go with Vitality than. It's easy to change to Vigor or Energy if it looks weird.

It looks very cool and it defenitely better than the old one. The only problem is that locations are invisible until you select them. Thus, you have to remember where to click, and what exists in the game at all.
Maybe it should look like in starcraft2 campaign, if you ever played it. Interactive elements there have very thin frame around them all the time.

Oki, we can try that or some form of animation later.

I got distracted so I still have the auto-buy method to finish. Refactoring will come after that.

[Xela]

Code: [Select]

INFO     PyTFall 0.47 Alpha Auto-Shopping + Auto-Equipping for Combat of all chars!
INFO     PyTFall 0.47 Alpha It took 2.01399993896 secs to execute!

INFO     PyTFall 0.47 Alpha Attempt to auto-buy 100 items for all girls!
INFO     PyTFall 0.47 Alpha It took 1.20599985123 secs to execute!

INFO     PyTFall 0.47 Alpha Attempt to auto-buy 3 items for all girls!
INFO     PyTFall 0.47 Alpha It took 0.159999847412 secs to execute!
Not too shabby... Refactoring will improve this but I am going to do the fatigue flip now (bored with working on auto sorting functions). (For all girls means for each girls (there are about 140 260 (Just checked) I think)).

@Dark
Do we still have Sexy Air trait, some items try to apply it?

=========================
Done with fatigue, next is actually adding auto-eq methods to the game... going to be a pain getting it right I expect...