General Discussion

[Xela]

Menu extensions are ready! They'll have a new cool blueish button (actually I just could come up with a better color to stand out from normal choices  ). Also there is a new minor effect to all menus buttons where buttons are being slightly zoomed in on hover.

I haven't documented them yet but tested well enough in the frog quest:



No more need for ugly, randomly placed next to NPCs onscreen buttons and issue #33 is Fixed

[DarkTl]

Yes, about menus... Why menu buttons are so huge even when we have short options like "Yes"/"No"? Ideally they should be a bit larger than the longest line in menu, in your case than the second line asking to teach spells. When you have a short option with a huge button, it's not very pretty.
There is something about menu styles.

[Xela]

Yes, about menus... Why menu buttons are so huge even when we have short options like "Yes"/"No"? Ideally they should be a bit larger than the longest line in menu, in your case than the second line asking to teach spells. When you have a short option with a huge button, it's not very pretty.
There is something about menu styles.

It's shouldn't be too hard to fix... I kinda like consistent size, even with short choices. I think Menu in your example is defined in a way very similar to ours, just with older syntax and without a background.

[Xela]

===
Just pushed, can't say that I like it. I'll look into adding padding and push again, maybe it'll be better...

===
Just pushed...
Yeap, a bit better, slightly increased horizontal zoom now also looks more appropriate. I'll leave it as it is unless you/Gismo want to add something else. Gotta work now, I'll check in a bit later.

[DarkTl]

Yeap, I like it. Now buttons no longer overlap background more than necessarily.

No wonder I had issues with checking quest stage before btw. The function also checked if the quest is active, and failed =/= active.

[Xela]

Kewl

I'll put some time into jobs tonight if I got any fight left in me by then, otherwise it's code refactoring or some simpler issue like quick friends/lovers access.

We'll have a chain of remarks after release I think, Gismo likes this menu design from some other game but it does look like the hover button size is simply f*cked Two people PMed me about that after youtube demo was posted. It will take some time for that design to sink into player minds, took me couple of weeks to get used to it.

===
On the quests front, it looks like it's in an ok shape (judging from the Frogs quest anyway). I've actually used manual control there and simply forgot, the idea was to make sure Thewlises code worked. Method checked if stage is active because if you just try to check stage of a dead quest, game will crash (aka None.stage > 1 Error you posted couple of days ago). It'll take some time to get used to the system, I'll refactor it at some point in the future but for now, it should be sufficient, we'll never get it perfect for every possibility so it's a matter of understanding it through reading it's code or trial/error.

[DarkTl]

Well, the automatic events system expects many very different arguments in various cases. Like that recent "jump=true" out of nowhere for example.
If there will be more functions with more narrow purpose instead of one multi-purpose, I think it will be easier to understand and use.

Basically, you need to know how exactly events work in order to use the automatic system right now. That's not how it should work if you expect modders to do stuff.

[DarkTl]

*Also I rewrote stage checking because I need to check stage like ==, not >=. That might break existing quests, I'm afraid 

I think we do it wrong. Stage checking function should return the number of the current quest stage instead of true/false. And for example -1 for non active quests. This way you can check anything with just one function.

[Xela]

*Also I rewrote stage checking because I need to check stage like ==, not >=. That might break existing quests, I'm afraid 

I think we do it wrong. Stage checking function should return the number of the current quest stage instead of true/false. And for example -1 for non active quests. This way you can check anything with just one function.

Don't rewrite existing code, you can just add your own methods. I don't recall a single quest that checks stages except for your quests but if you mess up a method that may be sued by the system internally, it will be very difficult to track errors in the future.

You can write safe_stage() method that returns stages as you describe...

[DarkTl]

How can I use jump inside a function? When I try usual renpy's jump place where place is an argument, it gives a syntax error.

Wait. Is it even possible, I wonder? Seems like pure python doesn't have such stuff at all. Now I'm surprised 
We jump to locations and events in renpy all the time, but python team doesn't support jumps to labels. Lol.
 

[Xela]

renpy.jump("label_name")

is the direct Python equivalent. Alkions:

jump("label_name")

is a safe way to make a jump where nothing happens if a label you try to jump to doesn't exist. You may still be notified about it in the left, top corner of the screen.

[Xela]

Calling it a night, didn't get much done tonight, but I got a good start. Here are two previews of the layout that I just started. One with a red/gold scheme and one where I tried to incorporate the old bg for the bestiary.

Any pointers?

***
I made a screenshot of old bestiary from Alpha release, this one was made without graphics, just Solids with tweaked Alpha channel and default font. I think that the second version of your design looks better but graphics are too detached from one another making it look like it is thrown together rather than carefully designed. If you don't have time to think about/create a whole new screen, there should be many simpler, cleaner tasks.

[DarkTl]

Xela, I recall you promised a function that will check if a character is available.

[Xela]

Property, not a func. char.is_availible will return true or false. For now it just checks life. We will expand it in the future.

ima on andoid atm 

===
Edit from a normal PC:

Code: [Select]

if char.is_available:
    # Do something
(there was a typo before)

I want this to mean physical accessibility of a character to interact with the game world. If a character was sent to a distant quest, exploring some far away area, presently taking active part in some event/quest and etc. This should prolly return True is char is low on health/vitality... I am not sure, maybe we'll add another property to include those two into checks.

Right now it just checks if the character is alive, I will most definitely add a check for a distant location exploration as well before the next release but that code is not ready atm due to refactoring.

[DarkTl]

Method checked if stage is active because if you just try to check stage of a dead quest, game will crash (aka None.stage > 1 Error you posted couple of days ago).

I don't think it works like this. I made a function that returns stage of the quest or -1 if it's not active.

Even if quest exists and works perfectly, it's not active until you start it in the game. It has stage 0, unlike quests that don't exist (obviously they don't have a stage).