General Discussion

[Xela]

Well, they should have levels when you meet them in GMs. If you want to tie them to MC level, they will become much better than uchars at higher levels.

1) I know that this was mentioned before, the idea is for ingame chars to gain experience as the game is progressing, not as much as they could have if well managed but still.

2) This still doesn't explain why one rchar should have higher levels than any other. There should be no way for MC to recruit a character with a much higher level than his own. I'll take care of that when the time comes.

3) They will have levels when you meet them no matter what you do.

==>
I am asking what you want those levels to do? To have a locked range on rchar generation is not an option, I need very high levels chars for Arena to work properly, maybe for some other part of the game as well. If you want to lock levels for chars that you can meet for interaction, I don't understand how you see the same static system working @ MC lvl 1 and MC lvl 100. It will be very difficult to find a low level rchar to hire at the beginning and almost impossible to find one that you don't have to train for 100 days @ MC lvl 100.

[DarkTl]

If you want those animations to be perfect, they would have to be handled on per case basis, just like zoom_out/zoom_in of the portraits.

I'm afraid you have to give me an example of how to pass a transformed picture with custom anchor to your overlay function. You already have seen my transform function, it's nothing special.

[DarkTl]

1) I know that this was mentioned before, the idea is for ingame chars to gain experience as the game is progressing, not as much as they could have if well managed but still.

Yet uchars have different initial levels AND gain experience as the game is progressing.

2) This still doesn't explain why one rchar should have higher levels than any other.

You tell me. Why uchars have them? Why high level rchars at arena have them?

3) They will have levels when you meet them no matter what you do.

And atm those levels == 1. See issue 152.

I'm talking about starting levels for characters that are not needed as high level fighters at the arena and other places.

[Xela]

Yet uchars have different initial levels AND gain experience as the game is progressing.

Who gives a damn? rchars will guide the game and be drivers/fillers for it's most important parts. If someone wants to setup arena with 100 unique chars at lvl1 and cut through them by day 30, it's their business, I am balancing the gameworld with rchars, control of which I can count on...

You tell me. Why uchars have them? Why high level rchars at arena have them?

Uchars are there for player to form connections based on the original sources. Uchars have preset levels because most players may want to control that but Rchars are game's domain. They are the inhabitants that balance everything out at the end...

At Arena we need them cause it would not make any sense without high leveled chars. Neither will the game world at the end of a day.

And atm those levels == 1. See issue 152.

Yeah, I know, but they are not supposed to be lvl1, I just never got around to writing an algorithm to create new once cause it's a very complex issue that needs a lot of game world analysis and data which we do not even got at this moment. A lot of stuff needs to be taken into consideration there so the world doesn't get filled with (for example) 100 warriors when you really need/want SIW workers.

It's a complex issue, it'll take time to get that sorted.

I'm talking about starting levels for characters that are not needed as high level fighters at the arena and other places.

And:

==>
I am asking what you want those levels to do? To have a locked range on rchar generation is not an option, I need very high levels chars for Arena to work properly, maybe for some other part of the game as well. If you want to lock levels for chars that you can meet for interaction, I don't understand how you see the same static system working @ MC lvl 1 and MC lvl 100. It will be very difficult to find a low level rchar to hire at the beginning and almost impossible to find one that you don't have to train for 100 days @ MC lvl 100.

That all still doesn't explain two things:

1) Why should we have different ranges for different rchars?

2) Why do we want the same ranges locked thought out the game (as asked above)?

3) How is this better than having in game mechanic determine the range during gameplay?

[Xela]

I'm afraid you have to give me an example of how to pass a transformed picture with custom anchor to your overlay function. You already have seen my transform function, it's nothing special.

You do it in two steps, search for this code in screens.rpy:

Code: [Select]

        if isinstance(side_image, Char):
            if side_image.say_screen_portrait_overlay_mode == "zoom_fast":
                add At(side_image.say_screen_portrait, interactions_zoom(.2)) pos 219, 639 anchor .5, .5
            elif side_image.say_screen_portrait_overlay_mode == "zoom_slow":
                add At(side_image.say_screen_portrait, interactions_zoom(.8)) pos 219, 639 anchor .5, .5
            else:
                add side_image.say_screen_portrait pos 219, 639 anchor .5, .5
And add a new elif option to the fork, name the animation as you see fit.

Next:

UNIQUE_SAY_SCREEN_PORTRAIT_OVERLAYS = ["zoom_fast", "zoom_slow"]

on Char's namespace and add the condition string there and you're done.

Note: You need to pull my last push, I flipped that list to be a constant which it is.

[Xela]

You do it in two steps, search for this code in screens.rpy:

Code: [Select]

        if isinstance(side_image, Char):
            if side_image.say_screen_portrait_overlay_mode == "zoom_fast":
                add At(side_image.say_screen_portrait, interactions_zoom(.2)) pos 219, 639 anchor .5, .5
            elif side_image.say_screen_portrait_overlay_mode == "zoom_slow":
                add At(side_image.say_screen_portrait, interactions_zoom(.8)) pos 219, 639 anchor .5, .5
            else:
                add side_image.say_screen_portrait pos 219, 639 anchor .5, .5
And add a new elif option to the fork, name the animation as you see fit.

Next:

UNIQUE_SAY_SCREEN_PORTRAIT_OVERLAYS = ["zoom_fast", "zoom_slow"]

on Char's namespace and add the condition string there and you're done.

Note: You need to pull my last push, I flipped that list to be a constant which it is.

Actually no... you need to do something like this:

Code: [Select]

add side_image.say_screen_portrait pos([color=green]add proper coords...[/color])
add [color=green]your_animation[/color]
(I am a bit on the slow side today, it's the last day I have off so I am taking a break (with wine )). Proper pos is likely something like this:  pos 219, 639 anchor .5, .5 or the align thing of Gismo which can be found below in the code.

[DarkTl]

If we assume (we do atm according to rchars descriptions  ) that humans are local city girls, elves are from wild forests or remote non human cities and slimes are monsters from the wild areas, they all have different possibilities for training.

Although one thing I never thought about is different classes, I usually looked at it from the viewpoint of warriors, when for rchars Human<Elf<Slime. But for other classes it will be different, for maids probably Slime<Human=Elf...

I mean, Slimes warriors normally should have more fights than Humans, thus more exp and higher starting level. While Humans maid should be hired more often than Slimes maids. So I suppose it should be randint tied to classes, not just randint 

[Xela]

If we assume (we do atm according to rchars descriptions  ) that humans are local city girls, elves are from wild forests or remote non human cities and slimes are monsters from the wild areas, they all have different possibilities for training.

That's way too advanced...

Although one thing I never thought about is different classes, I usually looked at it from the viewpoint of warriors, when for rchars Human<Elf<Slime. But for other classes it will be different, for maids probably Slime<Human=Elf...

Same as above...

I mean, Slimes warriors normally should have more fights than Humans, thus more exp and higher starting level. While Humans maid should be hired more often than Slimes maids. So I suppose it should be randint tied to classes, not just randint 

Screw that! At least for now, you're talking about advanced world customization and while I am all for that, this is not something we will add before the world control module (which we already sort of have but it's not nearly advanced enough).

==>
Lets keep sh!t simple for now... I am going to take a look at some other issue, I think the one with the rchar datafiles should be closed cause I still haven't heard a solid way to handle rchars levels through JSON.

[DarkTl]

Hmm. What about gold and skills? Uchars have this stuff

        "gold": 200,
...
        "skills": {
            "dancing": 10,
            "exploration": 15

But rchars don't atm. I'm not even sure if they are supported since I never tried to use them.

[Xela]

Hmm. What about gold and skills? Uchars have this stuffBut rchars don't atm. I'm not even sure if they are supported since I never tried to use them.

Gold (single int, not random) is supported but I'll prolly overwrite that in the future. Skills are once again level/class dependent and should be handled by the game. Our concept is too complicated for that stuff to be controlled through JSONS... not on the game-wide base.

[DarkTl]

"color", "what_color", "arena_willing" fields? Not random, of course.

[Xela]

"color", "what_color"

Absolutely, going to add that now so I can close the issue

"arena_willing" fields? Not random, of course.

Also game's priority, unless you want to limit classes for rchars in general (like some cannot be warriors or servants). It also kinda feels like a more advance world kinda thing.

[DarkTl]

I added "full_race": "Digital Android" to rchar, and now I see race in her profile.
Then I added "full_race": "Human" to uchar, and I don't see her race in profile.

Too early to close the issue, it doesn't count as solved when a field works for rchars but not uchars 

[Xela]

I added "full_race": "Digital Android" to rchar, and now I see race in her profile.
Then I added "full_race": "Human" to uchar, and I don't see her race in profile.

Too early to close the issue, it doesn't count as solved when a field works for rchars but not uchars 

Works the same for both... why would you even want to see full_race of it is the same as a normal race trait which is always shown...

[DarkTl]

Ah, that's what going on. If race==full_race, gui doesn't show race string, but only race icon.
Well, it's an unobvious concept that will rise questions until player will notice that rule.