Making an items inventory- need help with global variables.

[ParsonSyunOwen]

I've been trying to learn enough Python to hack some stuff together, and it's actually been working pretty well. But now I've hit something that's stumped me.

The relevant code, a small slice of a 136-line .rpy file:

Code: Select all

init:
    python:
        invslot_1 = "Empty"

[...]

        def get_item(item):
            global invslot_1

[...]

             if invslot_1 == "Empty":
                    invslot_1 = item
             elif [...]

Pardon the indents, but you get the idea.

Anyway, it doesn't work. The strings are identical, so the if should be true and the item should be put in the slot, but instead the program goes on to the elif. The only thing I can think of is that Python doesn't know how to put the global invslot_1 into the local.

[ParsonSyunOwen]

Okie dokie, turns out I'm an idiot. It had nothing to do with global variables, I was confusing "=" and "==" elsewhere in the function. Again. -_-;;;;;;

Move along, nothing to see here... just the smoldering wreckage of a Ren'Py newb's confidance...

[Gau_Veldt]

I've been trying to learn enough Python to hack some stuff together, and it's actually been working pretty well. But now I've hit something that's stumped me.

The relevant code, a small slice of a 136-line .rpy file:

Code: Select all

init:
    python:
        invslot_1 = "Empty"

[...]

        def get_item(item):
            global invslot_1

[...]

             if invslot_1 == "Empty":
                    invslot_1 = item
             elif [...]

Pardon the indents, but you get the idea.

Anyway, it doesn't work. The strings are identical, so the if should be true and the item should be put in the slot, but instead the program goes on to the elif. The only thing I can think of is that Python doesn't know how to put the global invslot_1 into the local.

One thing to watch is that if you have it in init: as you do this breaks horribly when the game is saved or when rollback is used. If you want them to be saved when the game is saved, put them in start: (or any subsequent label).

[Gau_Veldt]

Okie dokie, turns out I'm an idiot. It had nothing to do with global variables, I was confusing "=" and "==" elsewhere in the function. Again. -_-;;;;;;

Move along, nothing to see here... just the smoldering wreckage of a Ren'Py newb's confidance...

Isn't an appropriate error raised if you try to use = rather than == in an if?

[ParsonSyunOwen]

Okie dokie, turns out I'm an idiot. It had nothing to do with global variables, I was confusing "=" and "==" elsewhere in the function. Again. -_-;;;;;;

Move along, nothing to see here... just the smoldering wreckage of a Ren'Py newb's confidance...

Isn't an appropriate error raised if you try to use = rather than == in an if?

If you screw it up the usual way, yes. But I'm an ambitious little newb, I screw up with style. The code for get_item essentially went like this:

Code: Select all

         resolved_to_inv = False
            while resolved_to_inv == False:
                if invslot_1 == "Empty":
                    invslot_1 = item
                    resolved_to_inv == True
                elif invslot_2 == "Empty":
                    invslot_2 = item
                    resolved_to_inv == True
                elif invslot_3 == "Empty":
                    invslot_3 = item
                    resolved_to_inv == True
(... etc, etc...)
                else:
                    resolved_to_inv = inv_full(item) 
            return

The idea was, it was supposed to browse the inventory, find the first available slot, and put the item there. Once it does, it sets resolved_to_inv. At the end of the while loop, resolved_to_inv basically says "we're done here", and the function returns. If the function finds no room in the inventory, it calls "inv_full", which prompts the user to make room or chuck the new item, then returns to get_item and tries again. The reason for resolved_to_inv was that the original idea was for inv_full to re-call get_item, but while writing the code I realized this caused a recursive loop that could eat up memory and eventually crash the game if the player was dumb enough to try and take an item repeatedly with a full inventory. The while loop was an alternate way of doing the same thing, but since I coded it as "resolved_to_inv == True" rather than "resolved_to_inv = True", the value was never set and the while loop never terminated- instead, it ran until it had put the item in every available slot, then it called inv_full, which in turn crashed the game due to a completely diferent bug.

My code-fu is weak. -_-;;;;;;

Anyway, it doesn't matter now. The inventory as I designed it is a disaster on several levels- I'm scrapping it and starting over with a different approach.

[PyTom]

Anyway, it doesn't matter now. The inventory as I designed it is a disaster on several levels- I'm scrapping it and starting over with a different approach.

I hope you're going to be using Python's lists. Lists are the right solution for something like an inventory, as you can just loop over them to do everything you want.

[ParsonSyunOwen]

Anyway, it doesn't matter now. The inventory as I designed it is a disaster on several levels- I'm scrapping it and starting over with a different approach.

I hope you're going to be using Python's lists. Lists are the right solution for something like an inventory, as you can just loop over them to do everything you want.

Well, the major problem with the method I was using was that I wanted the inventory to be constantly on-screen, so I had it implemented as a layout with the items listed as ui.textbuttons that could be clicked at any time to use the item. But this caused nothing but trouble- first there's the fact that the interpolation features become very dicey when applied to widgets. There's also the fact that I kept getting a runtime error to the effect that I was calling ui.interact wrong and/or missed a ui.close. Which is garbage- I counted them three times. I could probably figure it all out and get it working if I put enough time into it, but it's just not worth the aggrevation. So now the idea is to make inventory a seperate screen using the on-screen button feature listed in the cookbook, which will make things much simpler.

I hadn't really given much thought to lists, mainly because my programming skills are so mediocre- I had read about them on the wiki, but couldn't get my head around how they worked based on the description there. I just found a webpage that explains the functions of lists in Python pretty well, so that'll be helpful.

On the subject, I hate to complain but the reference guide on the wiki could really stand to be more layman-friendly, people. I've all but given up looking up stuff there because it's almost always written in programmer-speak, and the examples are either not terribly helpful or replaced by a TODO.

[JQuartz]

On the subject, I hate to complain but the reference guide on the wiki could really stand to be more layman-friendly, people. I've all but given up looking up stuff there because it's almost always written in programmer-speak, and the examples are either not terribly helpful or replaced by a TODO.

I think Pytom is free to write in programmer-speak since he's a programmer. Furthermore it's a voluntary effort so it just doesn't seem right to complain.

For the list, I used them in the following way:

Code: Select all

        ui.vbox()
        for chapter, branch, choices, location in ch_data:
                if chapter == current_ch and branch == current_br:
                    ui.textbutton(choices, clicked=ui.jumps(location),xfill =True)
        ui.close()
        ui.interact()

Note: ch_data is a list with each item having four data (chapter, branch, choices, location)

[Gau_Veldt]

Code: Select all

         resolved_to_inv = False
            while resolved_to_inv == False:
                if invslot_1 == "Empty":
                    invslot_1 = item
                    resolved_to_inv == True
                elif invslot_2 == "Empty":
                    invslot_2 = item
                    resolved_to_inv == True
                elif invslot_3 == "Empty":
                    invslot_3 = item
                    resolved_to_inv == True
(... etc, etc...)
                else:
                    resolved_to_inv = inv_full(item) 
            return

The idea was, it was supposed to browse the inventory, find the first available slot, and put the item there.

Maybe use a list instead of lots of variables. Lists have a handy .append() method which you can use to "add" things to the inventory, as well as Python's in operator to easily find out if the player has a certain item and a remove command for removing things from the list.

Code: Select all

init:
  $ e=Character("Eileen",color="#40c040")
start:
  $ inventory=[]   # empty list

  # give player an apple
  $ inventory.append("apple")

  # does player have an apple?
  if "apple" in inventory:
    e "You have an apple!"
    # All that Ren'Py coding must make her hungry!
    # She's eating your apple!
    e "Mfmm... mfmm...  It'f gfood!  [munch... munch... munch...]"
    # use up apple
    $ inventory.remove("apple")

Using a list like this means you don't need to worry much about slots at all and no large numbers of invslot_XXX type variables.

Edit: Use of .remove() which is easier than del

[Jake]

I think Pytom is free to write in programmer-speak since he's a programmer. Furthermore it's a voluntary effort so it just doesn't seem right to complain.

Hmm. It's a known problem that programmers will frequently talk in impenetrable field-specific jargon which makes it difficult for others to understand what they mean - often not because they can't write any other way, but because they don't think to. In the same way that you happily use words like 'voluntary' without considering that there might be four-year-olds reading the forum who don't know what it means - it's just naturally assumed that everyone reading it will follow, and I'm sure if you were writing deliberately for four-year-olds you'd avoid using longer words with no trouble.

It's a thing which is less-than-good about the current state of affairs, and it makes sense to point these things out so that people who are so inclined than improve them. As a community, we ought to be wanting things to improve, no?

On the subject, I hate to complain but the reference guide on the wiki could really stand to be more layman-friendly, people. I've all but given up looking up stuff there because it's almost always written in programmer-speak, and the examples are either not terribly helpful or replaced by a TODO.

I think a fair chunk of the manual needs to be written in precise language - the User-Defined Displayables page, for example, is not a beginner's article and really, there's little point trying to make it accessible to people who aren't programmers because it's necessary to understand several more-complex programming concepts in order to get anything out of that page anyway.

Pages like The Ren'Py Language I'm less sure about - on one hand, from a programmer's point of view it's nice to have the precise description, but I can see how it would be off-putting for beginners, and there's nothing between the Quickstart Manual and the Web Tutorial and the main reference manual.

Do you mean to suggest it would be useful to have a utility-driven equivalent of the reference manual? I can see that could be useful, but - what problem do you have with the examples? Can you pick some out which exemplify the 'not terribly helpful' kind? I can understand that a lack of examples isn't helpful, but on a quick skip through random parts of the reference, I didn't see any present examples which I would describe as 'not helpful'...

[ParsonSyunOwen]

Do you mean to suggest it would be useful to have a utility-driven equivalent of the reference manual? I can see that could be useful, but - what problem do you have with the examples? Can you pick some out which exemplify the 'not terribly helpful' kind? I can understand that a lack of examples isn't helpful, but on a quick skip through random parts of the reference, I didn't see any present examples which I would describe as 'not helpful'...

Well, for example, try the DynamicDisplayable page. When I first encountered this, I read it two or three times and came up with several questions:

-What exactly is this meant to be used for? Can I use it for what I'm trying to?
-The function needs two arguments. What kind of arguments? Don't they have to be declared beforehand? These are time units, are they built-in to RenPy or something? If so, do I have to use the built-in ones? If not, how can I build them?
-Keyword arguments on DynamicDisplayable go to the function it calls- so what does that mean? What happens if I send it an argument it already has?
-What on earth is a 2-tuple? I've seen it in several pages, and there's no article on it on the wiki. What is it, and how will RenPy expect it to be used?
-It says DynamicDisplayable does not accept properties. What properties? Are those like arguments? What happens if I give it one anyway?

The example code raises other questions:

-Why isn't gm_background defined as an image? Shouldn't it have an image keyword?
-What are st and at? do I have to use those variables? Why aren't they declared?
-What is style.gm_root.background? Is that changing the game background? Can't you use scene for that? How do I use this for something else?

And all of this is accompanied by the inevitable: What happens if I do it wrong? Will it crash the game? Will it not work? Will it not work and not tell me? Will I have to spend hours trying to debug? etc., etc. I have no clue, because I don't understand how the function works or what it's suppossed to do.

It's like when the first homo sapiens made an axe of flint and branches, he understood everything about it by means of being the one that made it- how to shape the flint, how to trim the branches, what kind of flint and wood were usable, etc. but when he gave it to his son, his son couldn't understand any of that. What the son needed to know was "You hold this end, you swing it like this, it cuts." I feel like I asked dad how to swing the axe, and he's started babbling on about how the blade is gnapped and how the blade fits to the shaft and something. It might help me if I need to make an axe myself one day, but right now I just want to know how to chop dinner's skull open.

[EvilDragon]

Well, it makes it a bit easier if you have some previous knowledge about programming if you want to do something more specific in renpy. I had some background with C and it's really helpful.

To answer some of your questions, a "tuple" is something like a dimensional variable. Meaning it can take several values. For example, look at the way you define main menu buttons: you have tuple: for every button (start, continue, config, quit...) you have to define button name (first value), then an event which happens when you click on the button (a jump to a certain label or _intra_jumps function), and third, a python expression (which means: test a variable and return True or False) which determines if you will be able to click the button in the first place. That's a tuple, a multi-dimensional variable, as I see it. I may have gotten it wrong, but I envision it like that.

style.gm_root.background is a style property, which enables you to change how the user interface will look. You can't exactly do it with scene statement, since scene is ingame feature, while style variables are all processed in init blocks, before loading the actual game.

[JQuartz]

-Why isn't gm_background defined as an image? Shouldn't it have an image keyword?

Because you'll only need to define it as an image if you're using show. If you're using python codes you don't need to do so.

What happens if I do it wrong? Will it crash the game? Will it not work? Will it not work and not tell me? Will I have to spend hours trying to debug?

The game will either crash or it will not work (but won't crash). Yes. Yes. Yes but you can see that it's not working. Yes if you can't interpret the traceback.txt or error.txt.

I feel like I asked dad how to swing the axe, and he's started babbling on about how the blade is gnapped and how the blade fits to the shaft and something. It might help me if I need to make an axe myself one day, but right now I just want to know how to chop dinner's skull open.

Unfortunately, the codes in reference manual isn't as simple as swinging an axe. It's more like driving a car. You'll have to learn how to change gears, drive within safe speeds, know where to go, etc. Everything stated is part of the explaination on what you need to do to set up the code.

It's just like what Jake said:

there's nothing between the Quickstart Manual...Web Tutorial and the main reference manual.

Basic Renpy is easy to learn but start treading into reference manual, it's totally a different story.

This is all the questions I can answer since I'm a non-programmer as well so you'll have to wait for someone else to answer your more difficult questions.

[Jake]

Well, for example, try the DynamicDisplayable page. When I first encountered this, I read it two or three times and came up with several questions:

Again, though, that's a more-advanced topic that one is only really going to be able to make decent use of if one already understands the programming concepts behind it. Most of your questions would be answered by a working knowledge of Python (most can be accurately guessed with a programming background in any language), and realistically, I think it's reasonable to presume that without a working knowledge of programming it's going to be difficult to do anything worthwhile with a DynamicDisplayable anyway. As it goes, there are introductory Python tutorials elsewhere on the web, it seems silly to add one to the Ren'Py wiki as well. Here's one place to start. Maybe a link would be a good idea, although I'm not sure whereabouts on the wiki it would go...

(To my eye - that is, from the point of view of someone who understands most programming concepts pretty well and has a functional understanding of Python - the example there is simple but perfectly sufficient.)

-What is style.gm_root.background? Is that changing the game background? Can't you use scene for that? How do I use this for something else?

This is the only question which remains once you remove all of the ones which are solved by a bit of Python knowledge. On one hand, I agree that the wiki could do with a good bit of cross-referencing, but on the other I don't think that's something that this particular question would be answered by. (I also don't think it's a good idea to put links inside example code...)

As it goes: it's assigning a property value to a style. If you're inside Ren'Py you can hit Shift-D to get to the developer menu, from which you can get to the style browser, which will tell you that 'gm_root' is the name of the style used for the game menu screen. So setting the background property is setting the background of the game menu.

And all of this is accompanied by the inevitable: What happens if I do it wrong? Will it crash the game? Will it not work? Will it not work and not tell me? Will I have to spend hours trying to debug? etc., etc. I have no clue, because I don't understand how the function works or what it's suppossed to do.

To be honest, listing these things would again probably only be useful to someone with sufficient understanding of Python, because otherwise - to borrow your prehistoric-man analogy - it's like telling the guy who's been handed the axe that if he hits the wrong things with it, impact stress will propagate throughout the axehead, leading to a structural failure along a plane of the crystal matrix of the flint.

With respect to the DynamicDisplayable page, it's more like you took the axe, and the first thing you asked Dad was "Hey, if I want the blade here to have a steeper angle to it, how do I do that?" and Dad assumed from this that you must already understand the basics and went right in to an in-depth discussion about chiselling flint.



So, what I'm wondering is:

- Are there any parts of the manual about Ren'Py script which you don't think have sufficient examples?
- Would it be worth producing a "non-programmers Ren'Py script manual" which covered all of the basics in a functional, non-technical manner but excluded all of the more complex topics - generally the ones you need to understand Python/programming to follow - entirely?

I don't personally think there's much mileage in making articles like DynamicDisplayable more 'friendly' - fundamentally, if you're going to be doing more-advanced stuff with Ren'Py you do need to learn some of the programming stuff sooner or later. It's a bit of a jump, you need to do more work to do the more-advanced stuff, but equally none of it is at all necessary for making a Ren'Py game.

[Deji]

- Would it be worth producing a "non-programmers Ren'Py script manual" which covered all of the basics in a functional, non-technical manner but excluded all of the more complex topics - generally the ones you need to understand Python/programming to follow - entirely?

I don't personally think there's much mileage in making articles like DynamicDisplayable more 'friendly' - fundamentally, if you're going to be doing more-advanced stuff with Ren'Py you do need to learn some of the programming stuff sooner or later. It's a bit of a jump, you need to do more work to do the more-advanced stuff, but equally none of it is at all necessary for making a Ren'Py game.

In my humble oppinion, it'd be really helpful a more "non-programmer-friendly" approach to more complex code, at least the more used command/things that are a step more complicated than the basics.
Also some "See Also:" links to related commands/concept/examples could be helpful as well.
Some screenshots of what the commands are supposed to do on screen (the ones that affect the screen, not values of variables) could be helpful too.

----------------

From my experience....

As I've noticed while I've been lurking here, which hasn't been that much time either, people wanting to create games with Ren'Py belong roughly to two categories:

- Game developers
- People wanting to tell a story they made, with pretty pictures.

For the first group, the wiki is clear and helpful, and they just need to ask few things to other comunity users to figure out how to make things work the way they want.

For the second group, assuming they have very little to no knowledge on programming, the Ren'Py demo, the quickstart manual and the web tutorial are very helpful.
Now the problem comes when you want to customize your game and do more nifty things.

Being Ren'Py a script/code-based program, it's pretty obvious you're supposed to get into more complicated code... But the Wiki is doesn't help you learn how to get into more complicated code from the basics.
Once you find a property/command/something you were told it could help you do what you want to do, it's all written in programmer's language and when you get to the example code provided so you can finally understand what this thing does, it's twice as complicated because you find several other complicated commands/code you don't know what they do.
So you either get frustrated and decide against customizing your game, or you try to find another place where you'll be able to find help with this weird language (for you).