There's no real meaning in naming games when, as I said, the problem isn't directly linked to them and can't be reproduced by following a given pattern. What is important is what I did, explain why it happen and how to solve it.
Because yes, the explanation and solution are in what I wrote. It's not explicitly said, but it's far to be something difficult to understand for someone with enough knowledge regarding Ren'py to consider making a code that will interact with its internals.
“I gave a proper bug report, it's just implicit.” Er…
What?
What you did write is a claim that you did some (
entirely undescribed) manipulations which resulted in errors. Which is –
as I mentioned – not quite helpful at all.
So, apart from commenting the two scrollbar property that appeared in the version 6.99.13, what does it need for,
Babe Runner (6.99.12.4), by example, to have clickable menus ? And it's not the sole 6.99.12.4 game with which I had this issue, just the one I remember right now.
(Whoa, an actual example…)
I suspect that the issue in question is specific to the game (problems caused by global styles, as mentioned in Q&A), and based on description alone I'm pretty sure it's due to the button having zero width (which doesn't stop the text from rendering – probably due to layout overflow): I encountered a case like that yesterday.
Either way, that particular issue was fixed in yesterday's release (and yes, I checked just now if the buttons work in this particular game
(they do)).
- There's one, and only one, way to tell if a variable will be saved or not. It's to look at the
ever_been_changed store's set. You are not doing it, therefore, at no time your code is able to hide unsaved variables.
- The menu show us attributes that can not even be saved (Pickles would throw an exception), like the modules by example. Therefore, at no time the filter is "on by default".
…Condescending wording aside, you clearly didn't bother looking at the
new code of the
yesterdays release which I was talking about. And I'm guessing you haven't even
noticed that there was a new release in the first place, judging from your answer.
Also, while there's
some truth to this (as
ever_been_changed is indeed used in determining what gets saved), it's not the
only way to obtain that list (and not even the most convenient one). …Incidentally, it also doesn't show
all in-game variables that get saved – only those that would be saved
in the current game state (which is another reason I decided against
hardcoding this filter: it's perfectly possible for the game dev to introduce variables in such a way that they don't get added to savefile until their first change from initial value).
Documentation regarding
You must be registered to see the links
: "The call screen statement shows a screen, and then hides it again at the end of the current interaction".
Documentation regarding the
You must be registered to see the links
function you used: "The screen is hidden at the end of the interaction, [...]".
They both tell why there's the error, and give you a strong lead regarding how to solve it.
This is some superb inability at reading text you're showing here…
Either that, or your idea of responding involves quoting the text and giving an entirely unrelated response to it.
I said it in my initial comment.
There's no precise steps to follow, and it don't explicitly depend of the game. Just pass enough time wandering in your menu, going up and down, searching value, adding some, that's all.
It's a pure structural flaw in your tool. And like any pure structural flaw, whatever if it's a piece of code wrongly designed, or a steel pillar with a crack, there's no path to it, it will happen at one time, dot.
Incredible. “Your code is bad, so you will stumble upon it eventually if you use it.” Don't tell me you actually
believe that I never tried running the code that I wrote, or that I hadn't fiddled with it more than a tiny bit to see if it actually works.
(Also: did you perhaps mean “period”? The word ‘dot’ has no applicable meaning in that context.)
If it was a due to Ren'py, a game like Super Powered, that massively rely on label arguments (since near to 5 years that it's Ren'py version exist) and have thousands of players for each updates, would have triggered it a long time ago. And like it's far to be the sole game codded that way, the problem would be known and solved since a long time.
You… don't sound like someone familiar with bugs, or large software in general.
FYI:
not all bugs come up immediately in a code related to them in some way; some only happen randomly and in rare specific circumstances. They still are bugs though.
What is happening is a fatal combination between the lack of rollback compliance of your CustomMenu class, and the fact that you create a new context each time the user click. You are using objects that can only evolve in the future, to handle attributes that can evolve both in the future and in the past.
And it happen that each time that Ren'py finally return from a context, those attributes are reverted to their value in this context ; a value that can be "do not exist at all". In the same time, the CustomeMenu objects that host them stay the exact same, hosting attributes that should have disappeared because, in term of game context, they are coming from a future that never existed.
It's not a problem for the attributes themselves, being rollback compliant they are designed to deal with this. It's also not a problem for the prompt argument, because it rely on information that are independent of the context ; either because not rollback compliant themselves, or because they come from the top level context. But it become a problem for the then argument, because suddenly it refer to something that never existed in the current context. What lead to the error.
And, this is just the verbose version of what I already said in my first comment.
First of all. “[Y]ou create a new context each time the user click[s ]”. That statement is false, and/or you don't quite understand what you said here. Did you not read my code properly? Or do you have your own definition of “context” which doesn't match the Ren'Py one (and which you abstained from describing before using)?
Second. Judging from what you say about “rollback compliance”, I'm
positive you're also either using your own personal definition of the word, or you misunderstand the Ren'Py term. Because “rollback“ of Ren'Py has
nothing to do with what's happening in the code you're talking about.
Third. What in the blazes does
CustomMenu class have to do with input/confirm dialogs?! It contains data and functions for in-memory representation of the custom menu;
no part of it has anything to do with user input itself.
…And of course, no matter how you (mis)explain it, buggy behaviour remains buggy behaviour.
Well, back to the documentation and the two lines I already quoted. The screen is shown, then Ren'py wait the end of the interaction before hiding it. There's, in this, an explicit implication that there's no stack behind it, because there's just no need for it.
0_o
I dunno what method of interpretation you used to read the docs, but your third sentence in this paragraph directly contradicts the second one (and is also blatantly wrong, as
this is exactly the place where the stack is being used).
Each time you're creating a new context, you are creating a whole copy of the game context inside the actual (copy) of the game context. It's another form of stacking.
By the way, jumping to called labels imply that you are totally messing with the return stack. The only thing saving the user from a forced return to the main screen is the fact that each stack is forgot once Ren'py return from a context.
…So you don't understand how this works, huh. Hell, you didn't even notice a tautology in your own statement (which kinda renders it nonsensical).
I'm just gonna say that no,
call_screen does
not create a new context (it's actually a regular, singular function call – which
is where stacking in the old version of the code comes from), and no, jumping does not mess with “return stack” (
specifically because it's done in the new context – the one created explicitly during the opening of the menu after hitting [k]).
And all this for a problem that could have been solved by one 10 characters long line and the use of the right function. All you needed to do is to put modal True at the start of your screen, then use renpy.show_screen, that's all.
(What are you doing?! Don't give direct pointers, it kills all of the mystery you so carefully built up!)
I've tried both of those already – together and separate; but regardless of what I did to the code, replacing
call_in_new_context and/or
call_screen with
show_screen resulted in the screen immediately closing… which kinda matches the description of these commands in the docs… or, occasionally, in breaking UI interaction altogether.
Fuck, near to 40 years of coding that I have to throw to the trash can.
…Yanno… I've seen this exact claim fairly recently… And this time I'm having the same strong urge to respond in fashion similar to the talker's and question
what exactly he spent all that time doing if he has so little understanding of the trade he's supposedly got lots and lots of experience in.
(And no, I haven't had much insight into your software development ability so far, but the attempt of asserting your authority instead of addressing the statement is telling… not to mention annoying.)
A list can be as good as any other structure to handle large amount of data. Simply because the structure matter less than the algorithm using it. It doesn't mean that a list is always the best solution, but it will always be a better solution than an over complicated option.
Oh, I get it now. You didn't actually understand the first thing about my code, and got it in your head that I created a bunch of custom data structures to represent whichever data I need instead of using ones provided by the language.
Well, the answer is no, that never happened. The “classes” in there are specifically for namespacing functions (and the few related data values). Both variable names and menu items are stored and processed as plain Python data. The “objects” I'm using to access them are merely convenience interfaces (again,
namespacing, not
gratuitous OOP nonsence).
You understand the difference between his and your list, right ?
In your tool, the only information that are relevant are the information at the actual level. What mean that the grouping is already performed naturally by the algorithm.
…
…
…What are you even talking about?
Judging from the context, you seem to be referring to the variable lookup here – but it has
zero releveance to any data structures you were talking of before, as it's not stored anywhere other than immediate rendering information (i.e. as UI buttons data for the current menu window state).
CustomMenu is only related to, well,
custom menu (as in, the part that is customized by the user, as opposed to being generated at runtime based on game state and user input).
Also, while I'm guessing that the “level” is depth of variable being inspected, I've got no damn clue what “grouping” (and by which “algorithm”) you're referring to here. Is it grouping-by-type which happens in exactly one place in the whole menu? But what does it have to do with current topic of discussion?
But anyway, your whole thing could have been handled with two lists, small, and absolutely no objects. For what would probably have been less than 200 lines:
[It's wrote on the fly, so it's to be seen as a structure more than an effective code, but really, there's absolutely no need for more complex.]
[…]
The only thing to effectively change is the assignation for kind. It would be easier to have a function that will return a more abstract value, than having to deal with the effective type of the attribute. But as I said, this show the structure more than the code.
And really, in the case of your menu, there's no real need for anything more complex. Just extend throwMeBack if you want to handle list/dict as a list of entries. And take care of the first level, that take it's entry from the ever_been_changed set.
Everything else is totally useless in your code, because totally useless for a cheat menu generator.
…Alright, I'll ignore how you're barbarically polluting global namespace in what's supposed to be a mod intended for any game whatsoever, and will simply give the same response as the last time over:
I'm not gonna reduce the code size by means of discarding functionality.
And, to elaborate, here you seem to be reverting to the thing I was talking of back then (which is clearly unrelated to what you responded to it with above… so this change back is somewhat unexpected): you're both a) oversimplifying the interface (at the cost of UX), and b) suggesting to discard functionality that is convenient for
some users at the very least simply because
you,
personally,
for whatever reason don't consider it particularly useful.
The answer was in the sentence where I talked about them:
"to see if your code can deal with the second hands bugs that I know, what it do..."
Unfortunately as I'm male, I can't speak in the tongue of implications. Me, being the brute I am, needs a straight and unambiguous answer: does this “what it [did]” mean
“no, you looked for those issues but only the ones actually named came up and you talked about that large list of potential bugs for no good reason”, or
“yes, there were some but you only care about those other things you encountered”?
My report was explicit enough for anyone having enough knowledge regarding Ren'py to consider interacting with its internal mechanisms. And, interacting with Ren'py's internal mechanisms is what this tool do.
You're repeating yourself. Did you like this particular sentence that much? (Also, as mentioned before, at least
half of it was less of a report and more of an abstract rambling which contained no tangible, usable information.)
It happened that I was overestimating, and I'm sure that now you see an even greater level of passive-aggressiveness in my answer that can be summarized by: RTFM
Well, this response of yours – the final sentense at the very least – clearly does indeed contain an indirect insult wrapped into a wee tad of pathos. Which is kind of ironic as it also attepts to imply (by means of sarcasm) that your response is completely level-headed. (And your response to “you're not being helpful” is also ironic, as you switch between showing lack of understanding of the topic, and insisting that not being helpful
is “the way”.)
And yes, I realise this second response of mine gets visibly sarcastic at times, but it certainly does feel like an appropriate level here.
