Thank you for your feedback!
The combat system in terms of options is not flawless yet. This will likely be fixed and attempted balanced in patch #2, and not #1 though, among some other things.
Thanks a bunch for the feedback!
Yes thank you, you are right about the len function, and I was also stupid not to use it. I will likely start using it from the next patch onward. My idea in the beginning was that if I need to use it multiple times, it doesn't need to iterate multiple times, which is true, however I never have lists where this concept would matter anyway, and usually, I end up iterating over them anyway if I need to count them multiple times
Extremely well done! Love the design of this.View attachment 1730246
Having stats to tweak balance is way better
I've also added 18 variations of nude bodies, a mod is definetly coming ^^
I didn't quite get what you are trying to achieve... You can store the result ofYes thank you, you are right about the len function, and I was also stupid not to use it. I will likely start using it from the next patch onward. My idea in the beginning was that if I need to use it multiple times, it doesn't need to iterate multiple times, which is true, however I never have lists where this concept would matter anyway, and usually, I end up iterating over them anyway if I need to count them multiple times
It was an attempt to be effecient and not lazy, but meh xD
len() in a variable at the beginning and never call len() multiple times, and that's efficient too. You can iterate once or multiple times just like you can call len() once or multiple times, and for each time of counting, len() is faster than iteration, takes less memory since iteraion constructs a generator in memory that yields the next value when called, and destructs itself when going out of scope.len() does a global symbal lookup, then invokes the __len__() of list class, which looks up a stored integer(length) and returns it. Then another symbal lookup for the variable, then update its value as the result.__iter__() of list class, which constructs the corountine and returns it, and prepares the next object to be yielded. During each pass, the coroutine yields a reference to the next element in the list (even though you don't do anything to it). Then you increment the counter, which also needs to be looked up every single pass, and store it away. After the loop, the coroutine takes some ops to self destruct.len() has constant time complexity no matter how much stuff is in the list, whereas iteration scales linearly as list grows.
Yes exactly. That is why I will be utilizing len() from now on :-DI didn't quite get what you are trying to achieve... You can store the result oflen()in a variable at the beginning and never calllen()multiple times, and that's efficient too. You can iterate once or multiple times just like you can calllen()once or multiple times, and for each time of counting,len()is faster than iteration, takes less memory since iteraion constructs a generator in memory that yields the next value when called, and destructs itself when going out of scope.
To compare ops happening underneath,len()does a global symbal lookup, then invokes the__len__()of list class, which looks up a stored integer(length) and returns it. Then another symbal lookup for the variable, then update its value as the result.
On the other hand, iteration does a global symbal lookup, then calls the__iter__()of list class, which constructs the corountine and returns it, and prepares the next object to be yielded. During each pass, the coroutine yields a reference to the next element in the list (even though you don't do anything to it). Then you increment the counter, which also needs to be looked up every single pass, and store it away. After the loop, the coroutine takes some ops to self destruct.
Basically,len()has constant time complexity no matter how much stuff is in the list, whereas iteration scales linearly as list grows.
Hope that helps
$noPanties as "Panty", where in girl.rpy setClothing() you ask the type to be "Panties", so they don't match.
This seems to confirm to me that there is an independent chance for the girls to answer a question correct each turn, which I had already feared. This is probably the source of at least some of people's frustration, since it will be why even a stupid character will sometimes answer 5 questions in a row. I think a much better system would be to have a question-progress variable, that goes from 0 to 100 and gets a random amount added to it each turn. When it goes above 100 she's answered another question and you subtract 100 from the question-progress. This is far more realistic too, since even if she hasn't fully solved the question yet its likely that she will have made some progress.View attachment 1730246
Having stats to tweak balance is way better
I've also added 18 variations of nude bodies, a mod is definetly coming ^^
Hello and thank you a lot for your feedback.
Stay tuned!Go to the folder>games>saves and drag and drop 1-1-LT1.save or any other into save editor. Edit what he showed. Go to bottom of page, download save, droped into >saves. Overwrite.
or you simply use the attached URM mod (universal RenPy Mod)
i forgot to mention it was for a macbook device that i don't understand where to go to(sorry)
For Windows users:
sorry - i didn't see that right from the start ... unfortunately i don't know where the files are located on MAC