Lemma Soft Forums

PyTom wrote: Unfortunately, it will be harder for people to edit the documentation, as I'll be moving it out of the wiki.

Out of interest, did this happen much anyway? I know the few times I've found something that needed an edit in the manual I've been unsure as to whether it's a documentation problem or a code problem - and in the case of doc problems, unsure as to what the text should read...

Presumably you'll be keeping the wiki around for the other ancillary stuff anyway?

Jake wrote:Out of interest, did this happen much anyway?

While there were a few edits, and I appreciated them, there weren't a huge number of contributions to the wiki documentation, especially when the Reference Manual was involved. For a while, the primary advantage of the wiki was that it provided me an easier-than-HTML authoring environment - but Sphinx and reStructuredText is easier still.

Presumably you'll be keeping the wiki around for the other ancillary stuff anyway?

The long-term (post 6.11, probably pre-6.11.1) plan for the website is:

- There will be a new, less busy, Ren'Py home page.
- Ren'Py downloads will be moved off the wiki, at least for new versions.
- The Quickstart and Reference Manual will be edited into one document, the Ren'Py Manual.
- The Ren'Py Shop will finally be finished.

The wiki will still remain, but it will be used more for the cookbook, faq, frameworks, editors, and so on, rather than documentation of the Ren'Py core.

I don't want to delay 6.11 for this, however. It's been forever already.

PyTom wrote:It's been forever already.

Offtopic, but this sounds cool in a sunglasses-and-long-coat-fluttering-in-the-wind kind of way..

luminarious wrote:Offtopic, but this sounds cool in a sunglasses-and-long-coat-fluttering-in-the-wind kind of way..

That's sounds far better then the actuality, which is me pouring though documentation, trying to figure out a way for mingw-gcc to compile a program in a way that satisfies both autoconf and python. The occasional curse may have been uttered.

Anyway, my current task is to try to get Ren'Py building on three platforms. This is made a little more difficult by my deciding that I would bump the version of Python we use to 2.6.5, so that we can take advantage of various bug fixes and performance improvements.

Linux is always the easy the platform. Half of it is because it's my main development platform, but mostly it's because Linux has its act together when it comes to libraries. No DLL hell here.

Mac was the second system I tried. There were the usual problems as I convince the compiler to do multi-architectures builds properly. And a lovely hard-coding of /usr/bin/arch in the Python build scripts, just to make the build process that much harder.

Windows is the land of DLL hell, and every time Microsoft tries to deal with it, they make it worse. The problem of the day is that Python is now built using libmsvcr90, which requires that you add a small XML document into every program you make. This is pretty easy to do - unless it's not you making the program, but autoconf.

The solution wound up being to change the GCC spec file to link the XML document in every time a program is compiled. But that took a day to come up with - and I have no idea why MS adopted such a complicated solution, when Linux has had a simple elegant one for 15 years or so.

Anyway, right now, Windows is busy building it's various dependencies. So hopefully, I'll be able to begin testing Ren'Py tomorrow.

PyTom wrote:... - and I have no idea why MS adopted such a complicated solution, when Linux has had a simple elegant one for 15 years or so.

To make Windows non-Microsoft programmers' life a lot harder since it means more money for Microsoft.

I am not sure if this is the right place to ask, but I encountered a small problem when using the inline translation (http://www.renpy.org/wiki/renpy/doc/coo ... ge_Support) in combination with the nvl-mode. When using different klick-indicators for "new textline" and "nvl clear" it depends on if the last textline of the screen is shown or not because of the language adjustment whether the "nvl clear" - indicator is shown. Perhaps there is a possibility to include some workaround in the next version.

delta-ion: Can you prepare a small game that exhibits this problem? I'm not sure I could recreate it from your description.

Ah, sure. I hope it will work.
Here is the link for the small test-game that shows the problem.
http://www.delta-ion.bplaced.net/bugfix/

Let me know, if you need further information.
By the way, with build do you prefere for something like this? (at the moment I prepared an all-plattform build)

Just to touch base on where I am right now:

6.11 is now running on all three platforms. I did some last-minute tweaks to drop the common-case CPU usage, and have run through the demo game a few times, to provide a basic check against regressions. I still have a few bugs to take care of (including delta-ion's issue - thanks for a reasonable test case), but Ren'Py 6.11 is in pretty good shape... except for the documentation.

In the (relatively long) time since the last release, I've fallen in love with the Sphinx documentation system. It's just so much easier to write than wiki-markup, which is what I've been using, that I don't want to write the wiki-markup anymore.

Unfortunately, rewriting all the documentation is a huge effort - and if I don't rewrite, or at least edit, things as I put them into Sphinx, I never will.

I'm trying to figure out what to do with the next-generation Ren'Py documentation. I'm currently leaning towards distributing the current version of the documentation with 6.11.0, and including links to and from the wiki. All the new stuff would be in the documentation, but a lot of the old stuff won't be migrated over in time for 6.11.0. Over the next few months, I'll finish the documentation, and we can retire parts of the wiki (like the reference manual, and the quickstart guide).

To put things in perspective, the current documentation is 12 thousand words long, not including the 2300 words pulled from the Ren'Py code, and I'm guessing is maybe 20% or so done.

I have some paying work, but it's looking likely that I'll get a first pre-release out sometime early next week. I'm not sure if this will be final-release-worthy, but it will at least let people get a first look at OpenGL support, Screen, the new Transform semantics, and so on.


renpy.list_files()

Finally, one potentially controversial addition. I've added a function, renpy.list_files(), that will get a list of the files in the game directory and archives. My proximate motivation for this is that I'm considering putting together a gui-based imagemap screen editor, and want to do so using only public APIs. This would also be useful in that it would allow people to automatically scan files and define images, build up image and music galleries, and do various other fun things.

The downside is that this will make it possible to write a file extractor using only documented Ren'Py APIs. I don't see this as being a huge problem - there's been a point-and-click RPA unpacker for a while now, and I'm pretty sure people have dug around in the Ren'Py internals to write their own. So we're not changing the landscape drastically here. But I do want to announce this here, now, to see how troubled people are by it, before a pre-release happens and I can't take it back.

list files could be very helpful And indeed, there's no way you can be sure to encrypt your game files, so... not a big deal for me.

I don't think an RPA extractor will be to much of a bother to commercial devs since they know it can be passed off either way. Kinda like using the honor system.

Anyone who doesn't want to keep their files in a publicly known format can write their own closed-source module supporting their own special currently-unbreakable file format. Like a passworded zip file with a password they'll have to fetch over https from their own server, or something. As far as I remember, the public APIs are sufficient for this. (And if I'm wrong, that would be a nice thing to add sometime in the future, since it would simplify using RenPy as a port engine for legal translations of things data for which cannot be distributed legally.)

Really, shouldn't be an issue at all.

config.file_open_callback exists to let you define your own archive format.

PyTom wrote: Finally, one potentially controversial addition. I've added a function, renpy.list_files(), that will get a list of the files in the game directory and archives. My proximate motivation for this is that I'm considering putting together a gui-based imagemap screen editor, and want to do so using only public APIs. This would also be useful in that it would allow people to automatically scan files and define images, build up image and music galleries, and do various other fun things.

The downside is that this will make it possible to write a file extractor using only documented Ren'Py APIs. I don't see this as being a huge problem - there's been a point-and-click RPA unpacker for a while now, and I'm pretty sure people have dug around in the Ren'Py internals to write their own. So we're not changing the landscape drastically here. But I do want to announce this here, now, to see how troubled people are by it, before a pre-release happens and I can't take it back.

Not a big deal, since people who will know how to extract the files will already be familiar with the majority of Ren'Py games being CC-licensed and they can't use the resources in their own games unless they were made for that express purpose.

That said, can I say that I have an open-source game if I did not remove the .rpy files but kept the resources in RPA? That means I won't have to risk making a separate dev release that's totally naked (can see the internals) and anyone out there capable of porting games to smartphones, android or whatever will already have all the tools they need. One of my motivations to not yet go commercial is the drive to just make a good game and see what other unexpected platforms it turns up on.

I've said countless times how I'm excited for 6.11 It would be great if the new tutorial now only use ATL and screen language to illustrate the common tasks (scene, show/hide, show_side_image, NVL, etc) while still supporting the old syntax that's not yet deprecated. I mean I understood the ATL in the latest demo but it still felt like it was added on and that the 'correct' language is still the usual language. In other words I would like to be shown the 'correct' common syntax way to do things even though there are countless methods... renpy, python or otherwise... that could get the same job done. If one can get almost anything done without invoking python proper, then that's when I think the language is getting to be complete.

Well, the general idea is that the ATL and Screen language will be the preferred way of doing things, in most cases. There will always be cases where Python is necessary - like variables, expressions, and the like. But say you want to put a date indicator in the upper right of the screen. Now, one can do:
And then use it like:
Is this using Python? Well, things like the strings and numbers are Python, and in most of those places, lots of Python expressions will fit. So the boundary between Ren'Py and Python is intentionally blurry. Certainly, I'm trying to add more declarative languages, on top of Python.

That said, can I say that I have an open-source game if I did not remove the .rpy files but kept the resources in RPA?

Well, you could do that, but I'm not sure I'd call it open source. To me, one of the big bits of open source is making available the work in the "preferred form for modification" - a quote from the GPL, but it applies to the basic concept of open source, IMO. That means things like making the .psds available for people who want to change them. (If you want to discuss this further, please start a new thread - I'm going a bit off-topic here.)