Page 27 of 38
Re: Ren'Py Gripes
Posted: Mon May 30, 2016 11:23 am
by jack_norton
Wait, to be clear the code above doesn't work
it's just an example of how I would do it at language level, by adding key bindings to actions. Just a suggestion for Pytom. Maybe he has a better idea in mind though!
Re: Ren'Py Gripes
Posted: Mon May 30, 2016 6:31 pm
by nyaatrap
Yeah, it looks there isn't a way to done in SL. Defining ui.adjustment is needed and I have to dig in an ancient document.
Re: Ren'Py Gripes
Posted: Tue May 31, 2016 10:30 am
by nyaatrap
When I looked akakyouryuu's site, he's solved this already. code is like;
Code: Select all
screen something:
$ adj = ui.adjustment(1.0, changed = store_yvalue)
viewport yadjustment adj
bar style "vscrollbar" adjustment adj
key "rollback" action ReadbackScrollUp(adj)
key "rollforward" action ReadbackScrollDown(adj)
init python:
yvalue = 1.0
def store_yvalue(y):
global yvalue
yvalue = int(y)
class ReadbackScrollUp(Action):
def __init__(self, adj):
self.adj = adj
def __call__(self):
rv = self.adj.change(self.adj.value - self.adj.step)
if rv is not None:
return rv
else:
raise renpy.display.core.IgnoreEvent()
class ReadbackScrollDown(Action):
def __init__(self, adj):
self.adj = adj
def __call__(self):
rv = self.adj.change(self.adj.value + self.adj.step)
if rv is not None:
return rv
else:
raise renpy.display.core.IgnoreEvent()
I think this kind of operation should imported into default ren'py?
Re: Ren'Py Gripes
Posted: Mon Jun 27, 2016 12:44 pm
by nyaatrap
Code: Select all
show screen something onlayer master
hide screen something onlayer master
can show/hide screen statements take onlayer clause?
I know screen(_layer="master") works, but I hardly remember it's syntax and have to search again and again when I need it.
Re: Ren'Py Gripes
Posted: Mon Jun 27, 2016 12:59 pm
by PyTom
What's the application. It strikes me that having screens jump from layer to layer seems bad.
Re: Ren'Py Gripes
Posted: Mon Jun 27, 2016 1:04 pm
by nyaatrap
I have a few layers for screens. Some screens show on screen layer A, and some show on screen Layer B. It's inconvenient to use only one layer. There are several reasons to use layers instead of zorder: transition, at layer transform, tag, and new context calls.
Re: Ren'Py Gripes
Posted: Tue Jun 28, 2016 12:40 am
by PyTom
It seems like maybe a default layer per-screens would be the right way to handle this - no?
Re: Ren'Py Gripes
Posted: Tue Jun 28, 2016 2:58 am
by nyaatrap
Yes. That what I want.
Re: Ren'Py Gripes
Posted: Tue Jun 28, 2016 7:38 pm
by PyTom
Re: Ren'Py Gripes
Posted: Wed Jun 29, 2016 8:32 am
by Taju
I would like to suggest putting more examples in the documentation. Preferably after almost every feature, and examples can be really simple. Just something which helps beginners to understand what the feature would look like in their code.
I myself have struggled with the most trivial problems: for example I didn't think to put "$" in front of some code snippets, and it took a long while to finally figure out what was wrong. The problem would not have even risen if the documentation page had a simple example.
I wanted to point this out, because isn't it Ren'Pys mission to be accessible to everyone, even if they can't code
The old wiki was more easy to understand, this new documentation feels like something advanced coders propably understand really well but is not as accessible to complete beginners.
Re: Ren'Py Gripes
Posted: Wed Jun 29, 2016 9:26 am
by Donmai
You are right, but remember that keeping the documentation up to date and organized is a lot of work already. More detailed examples of use should come from the community. Many times they exist, but you will have to do a search for them on the forums threads
. The Ren'Py Questions and Announcements and the Cookbook forum sections are good places to find examples.
Re: Ren'Py Gripes
Posted: Thu Jun 30, 2016 5:27 am
by xavimat
Taju wrote:isn't it Ren'Pys mission to be accessible to everyone, even if they can't code
I agree that examples are very useful and the new doc could add more of them (with the added workload to review all of them every time renpy is updated and some things change a bit). But the renpy approach is to make coding simple not to avoid coding (this is the aim of novelty, IIRC).
Reading the Quickstart is a good..., well, quick start
A line beginning with a dollar-sign is a single-line python statement,
Doc:
https://www.renpy.org/doc/html/quicksta ... statements
Re: Ren'Py Gripes
Posted: Thu Jun 30, 2016 3:20 pm
by gas
I think this level of complexity require 2 manuals: a reference guide and an how to guide (and a flashing red alert_ learn some python!).
The cookbook and Q&A sections are too specific (while not outdated) to offer a broad support.
The Quick start guide doesn't even touch the surface, and nowadays a simple scripting stuff is common thing. Stripping it out from the docs and insert it as a separate file...? Anyway this could be an heavy burden to mantain updated, i Know.
Re: Ren'Py Gripes
Posted: Sat Jul 02, 2016 1:02 pm
by nyaatrap
Hi, it's me again and again (sorry). It there future plan to move to 64 bit?
I kept RAM usage lower than 1 GB on a game I made, but it still causes out of memory error, so I had to make 500MB average not to crash the game. 500MB seems good on low resolution VN - 1280x720 or lower. But Full HD VN, or games not just VN, is hard to keep 500MB.
Re: Ren'Py Gripes
Posted: Sat Jul 02, 2016 1:20 pm
by PyTom
gas>>> There's a new gui customization guide being added. But fundamentally, there's only so much I can do while also maintaining and improving Ren'Py, so I leave it up to the community to make the non-normative documentation.
nyaatrap>>> We're 64 bit on Mac and Linux already. I'm not sure what 64-bit on windows would give us - are you running out of memory?