6.11 Development

[Jake]

ZOMBIE SLUTS FROM MARS

This sounds like a fascinating project - so awesome! Do you have an estimated release date?

[papillon]

I have always wondered why the traceback gives out so much information about the developer...

[PyTom]

It's something we inherit from Python. When Python code is compiled, it includes the full path to the file, for debugging purposes. I don't want to ship a modified Python compiler, so we're kinda stuck with what we can get out of the default one.

[number473]

You could just put the whole project on a USB disc and build the distributions at an internet cafe or on some other public computer ;D

[Spiky Caterpillar]

Ack, NO!

Building projects on random public computers sounds like a great way to wind up distributing virused .exes... if anyone's bothered by their username and paths showing up in tracebacks, the best approach is probably to create a new user account on your main box and move the Ren'Py directory out of /Files/<YourRealName>/Porn/FutaXTentacleZone/ before building distributions. (And probably grep the distribution after building to make sure that none of the old paths are still showing up - you might need to touch the .rpy and .py files to force .rpy/.rpycs to get recompiled.)

[PyTom]

I've managed to whittle my Ren'Py TODO list down to 2 items and one maybe-item. So things are looking good for me to begin the 6.11 release campaign some time this week.

[denzil]

Games with more gameplay than VN will already quite possibly have infrequent saves which aren't accurate down to the last thing that happened and an exact screenshot simply because of the way Ren'Py works; if you save in the middle of Python code, then what you actually get is a save for the last line of Ren'Py code you hit before you started the Python.

I was a bit worried when I started work on my battle engine project that I'd have to mess around a lot behind the scenes to ensure that all the various variables which get changed would be correctly saved and it wouldn't crash or behave weirdly if you saved and re-loaded... then I remembered this limitation of Ren'Py, and it's all no problem; if you save during the battle, when you load your game you just get the Ren'Py scene immediately before the battle.

(The downside to this, of course, is that it doesn't allow for the quicksave-in-battle option that many tactics games give you... at least, not without some messing around.)

Yeah, I have run into this too. It seems that if you call a function defined in init block Ren'Py doesn't save state until you exit the function. So if you run your battle engine is run as one function its state is not saved until you exit the battle engine.
There's way around it though... well thinking about it there might be more ways, but I guess all will have something in common they will exit to normal Ren'Py code, outside of init. I solved it by writing the whole loop outside of init, and the idea is about this:

Code: Select all

# this is just a pseudocode, not a real renpy code
label battle_engine( parameters):
label loop:
    $ check_what_should_happen_now()
    $ do_it()
    if not done:
        jump loop
    return

Hope this helps.


Anyway, since I'm already here... a feature request:
There is function for manipulating image colors by using matrix (im.matrix).
Would it be possible add function that would manipulate the image itself using matrix (something like: http://en.wikipedia.org/wiki/Gaussian_b ... ian_matrix)?
Would be kind of handy for game I'm working on...
Thanks.

[Jake]

It seems that if you call a function defined in init block Ren'Py doesn't save state until you exit the function.

I believe it's Python code in general - if you try and save in the middle of Python code, you'll actually get a save at a point immediately before the beginning of the Python code. So if you have:

Code: Select all

label start:
  "Dialogue 1"
  python:
    renpy.say(narrator, "Dialogue 2")
    renpy.say(narrator, "Dialogue 3")
    renpy.say(narrator, "Dialogue 4")
  "Dialogue 5"

and you played through 'til "Dialogue 4" was on the screen and saved, then when you loaded that save you'd be confronted with "Dialogue 2". If you'd played 'til "Dialogue 5" and saved, then "Dialogue 5" would be on-screen when you loaded.

[Aleema]

I've managed to whittle my Ren'Py TODO list down to 2 items and one maybe-item. So things are looking good for me to begin the 6.11 release campaign some time this week.

I'm so freakin' excited!!! No really!! I'm using multiple exclamation points and everything!!!!:D!

[PyTom]

I'm now into the 6.11 release campaign. The big thing today was to write some documentation for the scene language. I've decided to start putting the documentation into sphinx. This won't be done in time for 6.11, but I'll be writing the new things in the new format, and then moving the old stuff over.

Here's some sample documentation in the new format. It's not done - it needs better styling, and syntax highlighting, at least. But it gives you a feel for what you'll be getting, and also for the new screen language.

http://www.renpy.org/doc/html/screen.html

[LVUER]

I've read it... still a bit confused (since I just skim it), but I think it's great and will have great impact when making a VN.

[IceD]

New documentation looks great for me! It'll surely be much more legible and even if it's still unfinished, already seems nice and using it will be a pleasure. In overall, this might be one of the most interesting and important Ren'Py releases, so far

If you lack hands to work on the text formatting, or if there's a large portion of material to be done I propably might help, just give me a call.

[Kinsman]

The screen language looks very interesting. It's going to be even more interesting when we look at the default libraries, and see all the default screens we know and use being written in the scene language.

For instance, I know that NVL mode makes use of an "NVL buffer" and a variable, nvl_variant. Will we see references to those when we see the scene language implementation of NVL mode?

[PyTom]

The current plan is to release 6.11 before re-implementing all the screens in screen language, just for time reasons. But I will be releasing with 6.11 descriptions of what all the screens take as input and output.

(Sample screens will come soon after, maybe even while 6.11 is in testing.)

[PyTom]

New documentation looks great for me! It'll surely be much more legible and even if it's still unfinished, already seems nice and using it will be a pleasure. In overall, this might be one of the most interesting and important Ren'Py releases, so far

6.11 is the most ambitious Ren'Py release ever. Frankly, the release is starting to scare me, that's how huge it is. But hopefully, with proper documentation and testing, the process will go smoothly, and people can quickly begin to take advantage of the new features.

If you lack hands to work on the text formatting, or if there's a large portion of material to be done I propably might help, just give me a call.

Once things calm down, I'll be happy to have people proofread things. Unfortunately, it will be harder for people to edit the documentation, as I'll be moving it out of the wiki.

Switching to sphinx as a documentation tool has a bunch of advantages perhaps the biggest being that I can generate some of the documentation from the Ren'Py source code. It's also a far easier format to work with, with less markup than even wiki - being able to easily read the documentation is quite helpful. Finally, it can generate several formats, which is nice.

With the exception of examples, I'm pretty much done with writing the screen language documentation. That was 8500 words, so a decent amount. Here are the current docs: reasonable comments are welcome. I still need to implement things like syntax highlighting, and better stylesheets.

HTML: http://www.renpy.org/doc/html/
PDF: http://www.renpy.org/doc/latex/all.pdf