VN Ren'Py Lilith Rising [v2.0.11ns] [Jubei]

[Sancho1969]

I'm guessing the biggest problem with this, other than convention, is that those variables can never have a default state to return to?

Well... kind of, yes. Basically one (regardless of coding language) declares (defines) all variables at project initialization... the "base" of the variable's state (doesn't matter if it's integer, boolean, text, etc... it's the same principle). Once the actual coding is executed past initialization then one sets the variables as needed (they've already been declared). Then the rest of the code operates based on the variable setting (which can change of course).

So, you are likely thinking correctly tbh. For example one might have a variable that will be later used to reference an LI's relationship condition. So, we would declare something like "define li_relp = 0", so that the baseline (default) is nothing... no relationship. Then, as the story (in the case of the code being an AVN) we would set it to be something different on an as needed basis. One would NEVER use a conditional to define (declare) variables that I can think of. I've never seen it myself ever, and never seen any language documentation that would state otherwise.

So, that's basically the nitty-gritty summarized in layman's terms... if that makes sense. Bottom line: declaring (defining.. same thing) variables is VERY different that setting variables. Variables must be defined as one base then later set as needed.... never defined willy-nilly based on conditionals (again, that I've every seen or read).

Again, I'd love to be schooled where I'm incorrect (I'm all for learning new shit)... in any coding language (it's not specific to Python but all languages).

 

[illogicallity]

Does this version actually have any new content? I thought season 1 was already finished back in September.

 

[motseer]

Well... kind of, yes. Basically one (regardless of coding language) declares (defines) all variables at project initialization... the "base" of the variable's state (doesn't matter if it's integer, boolean, text, etc... it's the same principle). Once the actual coding is executed past initialization then one sets the variables as needed (they've already been declared). Then the rest of the code operates based on the variable setting (which can change of course).

So, you are likely thinking correctly tbh. For example one might have a variable that will be later used to reference an LI's relationship condition. So, we would declare something like "define li_relp = 0", so that the baseline (default) is nothing... no relationship. Then, as the story (in the case of the code being an AVN) we would set it to be something different on an as needed basis. One would NEVER use a conditional to define (declare) variables that I can think of. I've never seen it myself ever, and never seen any language documentation that would state otherwise.

So, that's basically the nitty-gritty summarized in layman's terms... if that makes sense. Bottom line: declaring (defining.. same thing) variables is VERY different that setting variables. Variables must be defined as one base then later set as needed.... never defined willy-nilly based on conditionals (again, that I've every seen or read).

Again, I'd love to be schooled where I'm incorrect (I'm all for learning new shit)... in any coding language (it's not specific to Python but all languages).

Thanks for the detailed explanation. Your example is pretty much what I had in mind. I have some coding experience though it mostly resides in the last century... hehe... c++, cobol, fortran, java... I feel certain there are few who could or would want to "school" you in your coding skills and conventions. There may be areas where "thinking outside the box" is good but this is probably not one of them. One always needs a core or base to return to.

 

[e6mill]

you set variables in conditionals after they've been declared in initialization, you don't declare variables in conditionals.

They'll be undefined (throw an error if you try to reference them) if the condition isn't true.

 

[Sancho1969]

They'll be undefined (throw an error if you try to reference them) if the condition isn't true.

No, no.... you're missing the point I'm making. I'm saying the variables should be declared (defined) WITHOUT conditionals. That's what my original post is pointing out. The use of a conditional to declare or define a variables is incorrect. They should always be declared/defined via only one basis and one basis only. In the case of conditionals they should only be used to SET a previously declared variable to a different state. It's two very different things.

 

[Sancho1969]

Joubei, another thing: did the steam app ID change for some reason recently?

In v1.0.2 was:

ju "{a=https://store.steampowered.com/app/2864850/Lilith_Rising__Season_2/}{u}Please wishlist Season 2 on Steam - click here.{/u}{/a}"

... and now:

ju "{a=https://store.steampowered.com/app/2424440/Lilith_Rising__Season_1}{u}Please wishlist the game on Steam{/u}{/a}"

Why did the app ID change bud?

 

[motseer]

Does this version actually have any new content? I thought season 1 was already finished back in September.

Yes and yes. But now, it's "more finished".

 

[e6mill]

No, no.... you're missing the point I'm making.

I didn't. I was agreeing.
It's a bad practice.

 

[rando gamer]

just wondering will the multi mod be updated or does the current version still work

 

[Sancho1969]

just wondering will the multi mod be updated or does the current version still work

... you literally just made a post without reading anything above bud? Updating SanchoMod is exactly what I've been doing all morning. There's info not only above your post but in the mod's thread as well. Click here if it's easier.

 

[motseer]

just wondering will the multi mod be updated or does the current version still work

Look up.

 

[motseer]

... you literally just made a post without reading anything above bud? Updating SanchoMod is exactly what I've been doing all morning. There's info not only above your post but in the mod's thread as well. Click here if it's easier.

 

[Sancho1969]

... and here we go.

Joubei: Bug Report

"lunch choice" variables not defined (declared) anywhere in the VN which results in an exception error being either:
NameError: name 'L2S08_valery' is not defined
or
NameError: name 'L2S08_freja' is not defined

This exception occurs here due to the variables never have being previously defined:

Spoiler: code snippet

You don't have permission to view the spoiler content. Log in or register now.

Now, to be fair this is older code that has been replaced by "outpost_logistics"... so most users won't experience an error... but some will. The reason being is that the old screen code is still in the project and if read by RenPy (in my case it was) then the error is thrown regardless.

 

[onefingersalute]

CHOICE!! will check out latest update

 

[Sancho1969]

Joubei: Another bug in Ep3, Scene10:

Spoiler: code snippet

You don't have permission to view the spoiler content. Log in or register now.

The variable was already defined in "scene08" here:

Spoiler: code snippet

You don't have permission to view the spoiler content. Log in or register now.

The bug that is the result is that when starting a new playthrough "monastery_mission_first " is True due to Scene10 issue... and it should be False until SET in Scene10. This is totally borked. You need to speak to your new coder imho... they don't seem to understand a few basic coding fundamentals regarding defining variables and setting variables which are two totally different things.

To easily fix the bug, in Scene 10 it should be written like this:

    if witch_hut_mission == False:
        $ monastery_mission_first = True

 

[Sancho1969]

Joubei: Another bug in Journal after both Ep2 and Ep3:

Since the VN is now coded to allow the Player to select which location on the Map they travel to first (Monastery or WitchHut), the Episode ending's Journal entries can reflect incorrect information. This is due to the Journal entries still being static and assuming the pre-v1.0.3 Map selection code (since the pre-v1.0.3 Map was coded to force the Player to the Monastery first).

So, if the Player goes to the WitchHut first, that evening's Camp Room selection only has Freja/Val room choices (since the Sisters haven't been discovered by the Player yet) and only Val's scene is available. So, the Player can select the Val Room scene in Ep2 (was only in Ep3 previously) and the ending Journal states "Had sex with Freja" and "Rescued Sophie and Sylvie" which is not correct. The same happens vice-versa in Ep3 with this scenario.

To fix this the Journal text entries need a conditional to check where the Player went on the Map in Ep2 (for Ep2's Journal) and in Ep3 (for Ep3's Journal) and change the entries accordingly.

Visual example of the issue: In this case the Player chose to travel to the Witch's Hut first (in Ep2), then in Camp goes to Val's room. Result of the Journal doesn't change to reflect this scenario:

 

[Havik79]

Has anyone played the update, is it worth it, doesn't seem like there is much of anything new, at least going by how shitty the change log is, 2 updates and both saying season 1 is complete?

 

[Sancho1969]

Joubei: Another bug in Journal after both Ep2 and Ep3:

Since the VN is now coded to allow the Player to select which location on the Map they travel to first (Monastery or WitchHut), the Episode ending's Journal entries can reflect incorrect information. This is due to the Journal entries still being static and assuming the pre-v1.0.3 Map selection code (since the pre-v1.0.3 Map was coded to force the Player to the Monastery first).

So, if the Player goes to the WitchHut first, that evening's Camp Room selection only has Freja/Val room choices (since the Sisters haven't been discovered by the Player yet) and only Val's scene is available. So, the Player can select the Val Room scene in Ep2 (was only in Ep3 previously) and the ending Journal states "Had sex with Freja" and "Rescued Sophie and Sylvie" which is not correct. The same happens vice-versa in Ep3 with this scenario.

To fix this the Journal text entries need a conditional to check where the Player went on the Map in Ep2 (for Ep2's Journal) and in Ep3 (for Ep3's Journal) and change the entries accordingly.

Visual example of the issue: In this case the Player chose to travel to the Witch's Hut first (in Ep2), then in Camp goes to Val's room. Result of the Journal doesn't change to reflect this scenario:
View attachment 3537973 View attachment 3537976

Joubei, here are the Journal fixes you can use to sort this particular bug. I thought if I didn't do it myself it might get borked yet again in any pending "bug fix" release by your team.

Copy/paste as needed:

In "journal2" script:

Spoiler: code snippet

You don't have permission to view the spoiler content. Log in or register now.

In "journal3" script:

Spoiler: code snippet

You don't have permission to view the spoiler content. Log in or register now.

That'll get you done bud.... for this one bug.

Also note that the formatting you have in the Episode2 Journal is different from Episode1 and Episode3. I kept it the same as you have it in each.

 

[Jimmy_Jam]

Has anyone played the update, is it worth it, doesn't seem like there is much of anything new, at least going by how shitty the change log is, 2 updates and both saying season 1 is complete?

I just finished it and there really isnt anything new that I seen, still ends at the same point after seeing HER sitting next to you when you wake up. It feels like this was all just UI changes and such unless for some reason I got the wrong file lol

 

[-CookieMonster666-]

Has anyone played the update, is it worth it, doesn't seem like there is much of anything new, at least going by how shitty the change log is, 2 updates and both saying season 1 is complete?

I think Avaron is probably right: https://f95zone.to/threads/lilith-rising-v1-0-3ns-jubei.140205/post-13459998 It's probably also why they both say "complete". Season 1's story was complete with the previous release, and this new version probably doesn't do much other than polish (or maybe add an earlier scene or two). But story-wise, I doubt there's a huge amount of difference.