>>34280
Я только по мелочам кодил, ничего сложного не делал.

http://www.animeforum.ru/index.php?showtopic=61348&view=getlastpost

http://iichan.hk/vg/res/353893.html#353897 - на этот вопрос есть ответ в документации, ренпай при сохранении сохраняет diff между исходными переменными (состоянием сразу после всех init-блоков) и текущим. С точки зрения низкоуровнего питоне, массив не изменился, он как был, так и остался указателем на некоторую, одну и ту же область памяти, в которой хоть и помянялось содержимое, из кода сохранения этого не видно.

Самое очевидное решение: в ходе работы программы менять положение массива, заменять его на новый с тем же значением. Ниже приводится код proof-of-concept:

init python:
    array = [1,2,3]
    def update_array():
        global array
        array = [i for i in array]
label start:
    $ array[2] = 666
    $ update_array()
    "Save at this point and try {b}exiting game{/b} and loading later."
    "Let's check if array is saved."
    if array[2] == 666:
        "It works!"
    else:
        "Lol, fail!"

Если убрать $update_array(), то массив не сохранится.

Какой-то быдлокод. Что бы скопировать лист по значению надо всего лишь написать array = array[:] без пложения всяких функций и всяких циклов.

>>34285 Можно, но не хотелось пугать ОПа всякими конструкциями типа вырезок. А функция плодится ради случая, если у ОПа много массивов.

>>34284
Сработало. Спасибо!
Пока текстами займусь, раз уж переменные сохраняются.
Дальше у нас по плану интерактивный экран. Пиксельхантинг и всё такое. Пока я не очень вкурил как создавать активные спрайты, но, может быть, это от того, что на практике пока до них не добрался.

>>34296 Объясни точнее, какого рода пиксельхантинг тебе нужен:

• секретная возможность кликнуть на грудь героини для call/jump перехода на другой label прямо посреди обычного вн-формата игры (текст в рамочке, спрайт сверху, всё спокойно листается вперёд, но есть пасхалка, как в эрогейском эроге)
• отключение текста внизу, отображение во весь экран комнаты с активными предметами или ещё чего в таком духе (как карта лагеря в эрогейском эроге)

>>34298
Так реализация всяко одна и та же, не?
Вообще, ближе к первому варианту, конечно. В крайнем случае, окошко с текстом может быть и пустым в момент перемещения по городу.
ВНЕЗАПНО А может и не быть. Фоллауту это не помешало. Oxyeнные описания там были как раз в текстовом окне You see a rock

>>34299

> Так реализация всяко одна и та же, не?

Не совсем. Я могу придумать по меньшей мере три совершенно различных реализации, каждая из них больше подходит под свой случай.

В первом случае из требований вытекает, что кнопки могут оставаться на экране хоть в течение всей игры, не прерывая ВН-режима (хотя и прячутся при выходе в меню), при этом помимо кнопок есть и какое-то дефолтное развитие действий при простом листании текста вперёд. Такое удобно сделать через http://www.renpy.org/wiki/renpy/doc/reference/Overlays , там даже еть код примера готовый, разве что нужно для твоих целей поменять ui.image() на ui.imagebutton(). Этот же приём используется в http://cf.ichan.ru/games/vn/iichan_city/ для отображения имени лога. Примерно на этом же механизме основано выпадающее меню в эрогейском эроге, только там поверх накручена дополнительная магия для выпадания.

В принципе, на этом подходе можно реализовать и выборы типа карты лагеря, если окошко с текстом нужно оставить. Как-то так:

label start:
    $ enable_your_mega_overlay()
label loop:
    "You see a rock."
    "Click on a widget to proceed."
    jump loop
    

Если же тебе нужно породить экран без текстовой рамочки снизу, проще вручную сформировать экран прямо на месте. Если ты знаешь питон, то это можно сделать последовательностью ui.imagebutton() и прочих функций, после чего и вызвать ui.interact().

Если с питоном возиться не хочется, то, вероятно, правильнее в такой ситуации воспользоваться screen language (относительно новая штука в ренпае, специально для создания меню и прочих интерактивных экранов, по мне так слишком громоздкие конструкции получаются, но многим нравится).

Собственно, опиши предельно конкретно юзкейс, обсудим детальнее.

>>34325
Если я правильно понял вопрос, то процесс состоит из нескольких составляющих:

1. Катсцены. Игрок смотрит кинцо, в нашем случае VN.
2. Собственно игра: перемещение по локациям - бэкграундам, и юзанье скиллов на все активные предметы, реагирующие различными способами.

2.1. При наведении мыши на активный элемент тот должен среагировать: Подсветиться, моргнуть, зазумиться - что угодно.
2.2. При клике срабатывает активный скилл.
2.3. В результате, в зависимости от комбинации скилла и предмета повествование отправляется в заданную точку.
2.4. И да, как у РенПи с интеграцие баз данных?
3. Боёвка в стиле ЖРПГ со свим интнрфейсом. До этого я ещё не добрался, и доберусь, наверное, не скоро.
4. Система крафта. Не известно даже то, будет ли она. Мы лишь обмолвись о ней, при разработке концепции.
__________
Я сейчас заполняю (очень медленно) текстовые доки, так что за спрайты ещё не взялся. Я вообще в тетрадь сейчас пишу.
Кстати, ещё вопрос по поводу анимации. Всё делается вручную, или есть возможность загружать пререндеры? Если есть, как у них с альфа-слоем? Пока это меня интересует в плане погодных эффектов, но, кто знает, может это выльется в нечто большее.

>>34331
Сырна потерялась.

>>34331

>Катсцены. Игрок смотрит кинцо

Сэйберы, а можно там сделать кутэе, чтоб было как в нормальных игорях?

>1. Катсцены. Игрок смотрит кинцо, в нашем случае VN.

Делается обычным для ренпая стилем: label, за ним идут всякие scene/show/hide и простыни текста.

>перемещение по локациям - бэкграундам

В смысле, перемещение?

• На экране есть отдельный спрайт, который гуляет по локации (как в квестах 90ых)? Для этого ренпай не очень-то предназначен, хотя это и потенциально реализуемо, если закодить пачку алгоритмов для выбора маршрутов перемещения спрайта. По сути, ты будешь просто кодить на питоне, используя ренпай как высокоуровневую кроссплатформенную графическую либу.
• На экране что-то типа главного меню эрогейского эроге: статичная картинка, на которой есть активные прямоугольные области? Это функционал из коробки, смотри в сторону imagemap.

>юзанье скиллов на все активные предметы, реагирующие различными способами.

Реализуемо. Где-то на lemmasoft-форуме точно был сампл по динамическому переключению курсора мыши. По сути нужно сделать три вещи:

• оверлеем вывести инвентарь со списком кнопок выбора скиллов, каждый клик просто меняет глобальную переменную
• завязать на мышь DynamicDisplayable, которая зависит от этой самой глобальной переменной
• завязать список активных зон (в imagemap для каждой области можно указать условие её кликабельности) и результат клика по каждой из зон на эту же самую переменную

> При наведении мыши на активный элемент

Тут надо иметь в виду, что ренпи из коробки поддерживает только прямоугольные зоны для hover-эффектов, если ты используешь ui.imagebutton() или ui.imagemap(). Как правило, впрочем, этого достаточно, но если ты захочешь чего-то изометрического, придётся попотеть.

>Подсветиться, моргнуть, зазумиться - что угодно.

Функционал из коробки - замена картинки в прямоугольной области. Что нарисуешь, то и произойдёт. Разумеется, поддерживается и in-game обработка графики.

>При клике срабатывает активный скилл

Проще всего дёргать одну и ту же функций, но в ней if/elif/else перебирать значения скилла.

>В результате,в зависимости от комбинации скилла и предмета повествование отправляется в заданную точку.

Тут пригодится ui.jumps("label")()

>И да, как у РенПи с интеграцие баз данных?

Опиши сначала, зачем.

> 3. Боёвка в стиле ЖРПГ со свим интнрфейсом. До этого я ещё не добрался, и доберусь, наверное, не скоро.

Пошаговая? Реализуемо.

>4. Система крафта. Не известно даже то, будет ли она. Мы лишь обмолвись о ней, при разработке концепции.

На нет и суда нет.

>Всё делается вручную, или есть возможность загружать пререндеры?

Не понял вопроса. Если ты про поддержку gif, то её нет и не будет.

>Если есть, как у них с альфа-слоем?

Если всё хранить в png, то проблем с полупрозрачностью не будет. Это не правда, при масштабировании полупрозрачных картинок бывают косяки, если использовать Im.Scale()

Каптча намекает на волчицу.

>>34339
Непросто задавать вопросы, отталкиваясь от чистой теории. Но, раз уж пошла такая пьянка - пойду, попробую накодить несколько простых экранов.

>В смысле, перемещение?

Вариант два. Протагонист находится по эту сторону экрана.

>Базы данных

Записывать (и редактировать) свойста объектов, коих будет овер 9000, учитывая различные виды брони, оружия и прочей бабуйни.
Мне подумалось, что добавлять новые объекты будет легче, если прописывать их во внешней базе, а не непосредственно в коде.

>Анимация.

Я так понимаю, мне нужно будет сделать несколько кадров для того же дождя и положить их на нужный слой? О .gif придётся забыть.

>>34342

>Непросто задавать вопросы, отталкиваясь от чистой теории.

Ещё сложнее на них отвечать.

>Но, раз уж пошла такая пьянка - пойду, попробую накодить несколько простых экранов.

Отлично! Если будут какие-то затыки, обращайся.

>Вариант два. Протагонист находится по эту сторону экрана.

Сильно всё упрощает, т.к. ренпай не очень подходит для интерактивности аркадного плана и хорош для отображения относительно неподвижных экранов.

>Записывать (и редактировать) свойста объектов, коих будет овер 9000, учитывая различные виды брони, оружия и прочей бабуйни. Мне подумалось, что добавлять новые объекты будет легче, если прописывать их во внешней базе, а не непосредственно в коде.

Очень сомнительная идея. Подключить любой питоновский модуль не проблема, в том числе и всякий *sql, но тут явно цель неадекватна результату и затратам. Если это просто база-справочник предметов, то толку от неё мало. Если она ещё и хранит состояние текущего персонажа, то нужно заводить отдельные таблицы на каждый старт новой игры. Придётся отдельно втягивать базу для винды, для линукса, для мака, для андроида. Проще завести отдельный rpy-файл под описание предметов и редактировать его блокнотом. Что-то в стиле такого:

init -100 python:
    ObjectsBase = {}
    ObjectsBase['Sword'] = {'type':'attack', 'damage':200, 'icon':'sword.png', 'descr':u"Мечь, просто меч"}
    ObjectsBase['BigSword'] = {'type':'attack', 'damage':500, 'icon':'bigsword.png', 'descr':u"Офигенно большой мечь"}
    ObjectsBase['WoodenShield'] = {'type':'defense', 'defense':100, 'icon':'woodenshield.png', 'descr':u"Круглый щит, сделан из дерева"} 

>Я так понимаю, мне нужно будет сделать несколько кадров для того же дождя и положить их на нужный слой? О .gif придётся забыть.

Загрузить в коде пачку png не сложно, вместо "rain.gif" нужно будет написать Animation("rain1.png", 0.2, "rain2.png", 0.2, "rain3.png", 0.2)
Кадры делать придётся что так, что сяк, от рисования всё равно никуда не деться (кроме случая, когда нужно сделать простые преобразования уровня поворот/перекраска/зум/сдвиг/...)

С экранами разобрался. Почти.
У меня ушло много времени и нервов, чтобы найти call screen - в самом низу страницы. Вот что значит читать по частям. Как мне надоела эта привычка.
______
Как, говорите, создаётся текстовое окно совместимое с дефолтными репликами?
______
Also: спасибо автору game development idea generator - его творение побуждало меня продолжать разбираться в этой *ной документации.

>>34379

> Как, говорите, создаётся текстовое окно совместимое с дефолтными репликами?

В смысле, чтобы твой screen вызывался вместо стандартного на строчках типа таких?

"Однажды в студёную зимнюю пору..."
horsy "Не продолжай! >_<"

См. вот этот раздел документации http://www.renpy.org/doc/html/screen_special.html

>>34380
Что-то не могу найти свойство для слоёв внутри экрана. Или для того, чтобы поместить дождик за окно мне нужен отдельный экран для дождика, один для окна (с прозрачностью) и один для переднего плана? + для эффектов освещения

>>34384 Не совсем понимаю, что ты уже сделал и что хочешь с этим сделать дальше. И уж совсем непонятно, зачем тебе в описанной ситуации screen language, а не обычный ренпай. Можно пример кода?

>>34385
Сейчас нарисую дождик и чего-нибудь накропаю.
Что хочу - тут >>34331
Описанная ситуация никак с заявленной мной задачей не коррелирует - можно с лёгкостью обойтись без её решения/решить другими способами, так что это чистое любопытство.
Как я понял, элементы на экране накладываются друг на друга в порядке их вызова в коде. Но не могу понять, что им мешает по прихоти перемешаться в ином, нежели задуманном мной, порядке. Конкретное указание zorder я нашёл применимым только к screen, вот и поинтересовался.

>>34386
http://rghost.ru/44818896
Тут дождик.
Тут код:
transform rain_in_window:

 >#Эта фигня не работает
 "frame_01.png"
 0.25
 "frame_02.png"
 0.25
 repeat

transform riw2:

>#Эта работает, но автор грозится её похерить

 Animation ("frame_01.png",0.2,"frame_02.png",0.2)

screen rain:

>#Синтаксис, как всегда, на ощупь. Документация просто оxyительна.

 #add rain_in_window
 #Animation ("frame_01.png",0.2,"frame_02.png",0.2)
 add "back.png"
 add riw2
 add "front.png"
 #add at rain_in_window

>>34387 Через часа полтора доеду до дома и посмотрю. В следующий раз выкладывай только game-папку, она мало весит и я бы её отладил прямо из метро на андроиде. :3

Тебе это в ВН-режиме нужно или в screen-режиме?

В ВН-режиме можно в таком простом случае и без zorder обойтись, кстати. Пример, проверенный на твоих ресурсах, написанный на чистом РенПи:

image rain = Animation ("frame_01.png",0.2,"frame_02.png",0.2)
image back = "back.png" 
image front = "front.png"
label rain_l:
    scene back
    show front
    "Она стояла и всматривалась в окно, напряжённо молча."
    "Приближалась буря."
    show rain behind front with hpunch
    "Ударил гром и посыпался град."
    "Ну, или дождь. В общем, осадки."

А в screen-режиме у тебя и так всё работает. Только не хватает каких-нибудь кликабельных объектов, чтоб можно было из скрина выбраться. Like this:

screen rain:
    add "back.png"
    add rain_in_window
    add "front.png"
    button text "qwerty" action Jump("rain_l")

Any progress?

>>34447
Пишу тексты.

>>34450 Мой совет: чаще выпускай демки.

ОП в треде.
>>34620
Наверное стоит. И подталкивать в попу будет чему. У напарника сессия, так что я плюю в потолок и играю в Эадор без стимулов к работе.
___________
Вопрос. После сотен мата и охуевших глаз:
Эта бака, что, выполняет все init python фазы до начала самой программы? Если да, и меня не глючит, - как её от этого отучить?

>>34687

> Вопрос. После сотен мата и охуевших глаз
>Эта бака, что, выполняет все init python фазы до начала самой программы?

Да, всё именно так, и это описано в документации. Если вкратце, то в папке игры ищутся все-все rpy файлы, строится список входящих в них секций. Сначала выполняются все early-секции из всех файлов (тебе туда не надо), затем init и init python секции из всех файлов, в порядке указанного приоритета (гарантируется, например, что init 10 выполнится после init 9 python, для двух блоков с равным приоритетом порядок не известен), затем вызывается заставка, если она есть, после чего главное меню, если оно есть, если и его нет, то запускается метка start.

>Если да, и меня не глючит, - как её от этого отучить?

Какую задачу ты решаешь? Очевидно, тебе не очень-то нужен этот код в init python секции, если он не должен там выполняться. Если тебе нужен какой-то код, разово выполняющийся при переходе на определённую метку, можно сделать так:

init python:
    HasBeenToTheLibrary = False
label library:
    $ HasBeenToTheLibrary = True
    "Ну вот и сходил я в библиотеку. Теперь if-проверка переменной в будущем позволит это проверить даже в другом rpy-файле, чтобы повлиять на ход событий. Если меня спросят, как пройти в библиотеку, я смогу ответить."
    jump street

Если код хочется реюзать, то можно объявить его как функцию и юзать позже везде.

init python:
    HowMuchGirlsLovesMe = None
    def clearScores():
        global HowMuchGirlsLovesMe
        HowMuchGirlsLovesMe = {} 
        for it in ["sl", "dv", "un", "us", "uv", "vo"]:
            HowMuchGirlsLovesMe[it] = 0
    def addScores(who, howMuch):
        HowMuchGirlsLovesMe[who] += howMuch
label start:
    $ clearScores()
    jump street
label university:
    "Я сходил и получил знаний. Уныл-тян любит умных мальчиков. Мой рейтинг вырос."
    $ addScores("un", 100)
    jump street

Если код не умещается в одну строчку, можно оформить его как python-блок.

label ghostHouse:
    "Дом с приведениями реально страшный. Моя храбрость нравится всем девочкам"
    python:
        for it in HowMuchGirlsLovesMe:
            addScores(it, 200)
    jump street

>>34687 Надеюсь, мой ответ тебе помог.

>>34701
этот>>34689?
Да, спасибо. Всё работает.

>>34710

>Всё работает.

А что именно, если не секрет?

>>34711
Обновление характеристик. Скрипт на пересчёт (и округление и подгонку значений - он то всю малину и портил) я засунул в init python блок, т.к. не нашёл в документации (даже не знаю таких матерных слов, чтоб описать моё к ней отношение) других вариантов, и он его запускал в самом начале. Вобщем, просто стёр init.
______________
Говоря о демоверсиях, то не хочу рвать игру по кускам, разбивая на маленькие порции.
Во-первых, это сильно ударит по восприятию, лишив возможности оценить всю картину целиком;
а во-вторых, разработка принадлежит не мне одному, для публикации нужно совместное решение.
_____________
На самом деле, всё достаточно сильно тормозится, в силу моей лени и невозможности работать в одиночку, и в силу занятости других людей. Так что я просто вяло пишу элементы кода под настроение, как это самое динамическое обновление характеристик.
Такие дела.

>>34712

>я просто вяло пишу элементы кода

А сценарий кто-то пишет или как всегда?

>>34714
А как всегда - это как?
По моему мнению, сценарий первичен - если нет его - все остальные элементы теряют смысл, т.к. существуют лишь как инструменты для его подачи и раскрытия.
Я его и пишу

>>34717

>А как всегда - это как?

Молодые талантливые разработчики ищут художника, сценариста и композитора.

Какой планируется объем сценария?

Посаны, наслушался, скачал сабж - русек там теперь в пермабане или можно как-то собрать билд с русскими буковками?
Думаю сделать зероплэй No life про ммо-задрота.

>>35145
Отбой.
Я бака, надо было просто выбрать тему со стандартным шрифтом.

>>35146 Если будут вопросы, обращайся.

>>35162
Тогда вот вопрос. По оптимизации.
Модуль: выбор конкретного эвента в зависимости от текущих характеристик персонажа игрока.
Есть список эвентов.
Есть массив с ссылками на эти эвенты, с их детерминационными значениями.
Чем дальше, тем больше этот массив становится. Он уже размером 7х10х10. (первая координата - область эвента, вторая - сам эвент, третья - детерминанта). И если первые две зависят только от количества самих эвентов, то размер последней зависит от чувствительности модуля выборки к характеристикам персонажа. Сейчас она организована по принципу: "адрес характеристики + значение характеристики", коих я планировал использовать лишь две, но я уже столкнулся с тем, что нужно задавать не только минимальный порог характеристики, но и максимальный, а то и диапазон.
Я бы не беспокоился сильно о размере массива, не выделяй питон столько памяти на него. Вот и вопрос. Есть ли пути оптимизации в этой ситуации или нужно просто смириться с массивом размером в (пока) десятки мегабайт?

>>35163
Подумал. Решил записывать несколько значений в флот-переменную и потом декодировать их во внутреннюю переменную модуля. Если есть что предложить - я тут.

>>35163 Как вариант, можно сформированные массивы характеристик выгружать в файл и поднимать, когда нужно. import pickle и вперёд.

Глупая Сырна пришла к вам из ну вы сами знаете. Говорят у вас тут есть тред по Ренпаю.
Вот, вобщем, моё поделие в стадии середины недоделки.
http://rghost.ru/49241105
Художников нанимать не советуйте - денег нет. Прямых рук тоже.
------------------
Собственно вопрос:
Заедают кнопки на втором экране.
Т.е если быстро провести по mousearea мышкой, то триггер unhovered не срабатывает, из за чего приходится возвращаться.
Неприятно. Есть идеи как это исправить?

Для тех кому справедливо лень качать и копаться в коде.
____________
screen scr_Ritabar_main:

 add "bar_rita_bg.png"
 add pic
 imagebutton idle "button0.png" hover 'button0.png' xpos 346 ypos 168 action Jump("s1_ritabar_start") hovered Jump("f_s1_ritabar_button_head") 
 imagebutton idle "button0.png" hover 'button0.png' xpos 316 ypos 390 action Jump("s1_ritabar_start") hovered Jump("f_s1_ritabar_button_boobs") 
 imagebutton idle "button0.png" hover 'button0.png' xpos 316 ypos 576 action Jump("s1_ritabar_start") hovered Jump("f_s1_ritabar_button_ass") 
 imagebutton idle "button0.png" hover 'button0.png' xpos 808 ypos 576 action Jump("s1_ritabar_start") hovered Jump("f_s1_ritabar_button_propose") 
 imagebutton idle "button0.png" hover 'button0.png' xpos 742 ypos 432 action Jump("s1_ritabar_start") hovered Jump("f_s1_ritabar_button_drink") 

screen scr_Ritabar_button_head:

 #imagebutton idle "20131006_060035.png" hover '20131006_060035.png' xpos 10 ypos 10 action Jump("s1_ritabar_start") unhovered Jump("f_Test_out")
 add "bar_rita_bg.png"
 add pic
 mousearea:
    area (346, 168, 426, 144)
    unhovered Jump("s1_ritabar_start")
 textbutton("Посмотреть") xpos 346 ypos 208 action Jump("s1_ritabar_look") 
 textbutton("Поговорить") xpos 586 ypos 268 action Jump("s1_ritabar_talk")

screen scr_Ritabar_button_boobs:

 add "bar_rita_bg.png"
 add pic
 mousearea:
    area (316, 390, 426, 144)
    unhovered Jump("s1_ritabar_start")
 textbutton("Коснуться") xpos 316 ypos 390 action Jump("s1_ritabar_boobs") 

screen scr_Ritabar_button_ass:

 add "bar_rita_bg.png"
 add pic
 mousearea:
    area (316, 576, 426, 144)
    unhovered Jump("s1_ritabar_start")
 textbutton("Коснуться") xpos 316 ypos 576 action Jump("s1_ritabar_ass") 

screen scr_Ritabar_button_propose:

 add "bar_rita_bg.png"
 add pic
 mousearea:
    area (808, 576, 426, 144)
    unhovered Jump("s1_ritabar_start")
 textbutton("Предложить контракт") xpos 808 ypos 576 action Jump("s1_ritabar_propose") 

screen scr_Ritabar_button_drink:

 add "bar_rita_bg.png"
 add pic
 mousearea:
    area (742, 432, 426, 144)
    unhovered Jump("s1_ritabar_start")
 textbutton("Выпить") xpos 742 ypos 432 action Jump("s1_ritabar_drink")

screen scr_Ritabar_button_act_drink:

 add "bar_rita_bg.png"
 add "bar_rita_drink.png"
 add ritabar_drink_blink xpos 229 ypos 72  

label f_s1_ritabar_button_head:

 call screen scr_Ritabar_button_head

label f_s1_ritabar_button_boobs:

 call screen scr_Ritabar_button_boobs

label f_s1_ritabar_button_ass:

 call screen scr_Ritabar_button_ass

label f_s1_ritabar_button_propose:

 call screen scr_Ritabar_button_propose

label f_s1_ritabar_button_drink:

 call screen scr_Ritabar_button_drink

_______________
И, да, быдлокод, бла-бла.
Как можно понять тем, кто скачал и увидел ахуенные арты я за принципами не гоняюсь. Главное - чтобы работало.

>>35163
Не пиши на питоне. Нет, серьёзно. Этот язык не подходит для чего-либо подобного. Даже страдающая аутизмом ява будет это обрабатывать быстрее, не говоря уже о всяких вижуал и эмбаркодеро студиях.

>>35585
Я уже на нём пишу.
К тому же :

>я за принципами не гоняюсь. Главное - чтобы работало.

А ты предлагаешь мне тратить время ещё и на освоение новых сред. Да и мощности, вроде, должно хватать на замену одного спрайта другим.
По конкретному куску кода предложений нет?
Т.к. предложения в духе: "Всё хуйня, лучше не берись, бросай дурацкую идею", - безусловно, крайне конструктивны, но, почему-то, никак не помогают в решении конкретных задач.

>>35587
Может ты слишком быстро двигаешь мышь, так что указатель перепрыгивает через твою арию? В этом случае это протлема ОС, которую можно решить только покупкой скоростной мыши или разгоном текущей.

>>35588
Ты понимаешь, дело ведь не во мне и моей мыши.
Дело в том, что код допускает возможность такого. А уж если говорить о сенсорном вводе и прочих андроидах, то придётся, таки, для каждой кнопки рисовать внешнюю чувствительную область.

>Т.е если быстро провести по mousearea мышкой, то триггер unhovered не срабатывает, из за чего приходится возвращаться.

С трудом, но всё-таки удалось воспроизвести описанную проблему. Причём как на моём любимом RenPy 6.13, так и на твоём свежем RenPy 6.15.

Я бы на твоём месте отписался о проблеме на lemmasoft forum, потому как это откровенная бага движка, причём старая и неочевидная, а не твоё непонимание как что-то сделать. PyTom починит.

>>35596
Решил, что eбиcь оно всё, сделаю внешнюю область.

Следующий вопрос.
Если попытаться скрыть текстовое окно, скрывается вообще всё, кроме image.
Есть ли возможность сделать так, чтобы screen оставались отображаемыми, а текстовое окошко скрывалось?
Я так понял из этого треда, там нужно какое-то шаманство с Overlays, только не вкурил какое именно.

>>35598 Ставь более конкретную задачу, пожалуйста. Пока что да, всё решается с помощью слоёв.

>>35598

>Ставь более конкретную задачу

Конкретно.
Если во многострадальной второй сцене нажать "что там забиндено на скрыть текстовую область" то вместе с ней исчезнет и всё остальное, оставив пустой экран. На те случаи, когда графика отображается обычным вызовом картинок через show image, это не распространяется.
Не хотеть чтобы так было. Хотеть, чтобы при нажатии скрывалась только текстовая область.

>всё решается с помощью слоёв

Можно пример, если не сложно?

>>35609
Спасибо за помощь. Всегда приятно знать, что можно положиться на знающих сырен.
Проблема, кстати, решалась так:
$renpy.show_screen ("scr_s3_hall_main",_layer = "master")

>>35685 По идее это то же, что и

show scr_s3_hall_main onlayer master

Окно с текстом скрывается по "window hide", показывается по "window show" при наличии соответствующих настроек экрана say.

>>35687
В том засада и была, что вместе с этим окном скрывались и остальные экраны на слое.
А задним-то умом все крепки. Большое дело - переместить экраны в другой слой, но написать одну строчку никто не удосужился.
Пришлось перерыть документацию, форумы, и экспериментировать с кодом, чтоб допереть самому.

>>35686
Этот код, кстати, не работает.
Без оператора screen следующая строка воспринимается как указание на изображение, которое, кстати, и без того отображается на слое master.
А с опреатором screen отрубается свойство onlayer, так что всяко, ничего не выйдет.

Кстати, в оригинальном RenPy не было ни screen language, ни ATL. При этом функциональной гибкости эти конструкты не добавили - только синтаксический сахар.

Всё тоже самое можно было написать простеньким python-блоком с вызовом ui.button и прочих ui-функций. По мне так у такого кода даже читаемость была бы выше, чем мешанина из прыгающих друг на друга screen.

>>35690
Строго говоря, нынешняя версия RenPy и есть оригинальная. Если не ошибаюсь, права на движок никуда не передавались, и разработчик тот же.
А вообще, screen и animation & transformation language вполне соответствуют миссии РенПая, которая, как мне видится, состоит в построении языка сверхвысокого уровня, понятного любому дизайнеру.
Если же говорить о функционале - то, в общем то, что ни возьми - любой язык не имеет ничего кроме синтаксического сахара и не отличается по функционалу от ассемблеровских команд.
И, в качестве дополнения, в примере >>35685 видно, что screen language лишён функции элементарного отображения создаваемых экранов на другом слое, или я попросту его не нашёл.

ИТТ наркоманы какие-то, возвращаюсь в свою парашу...

>>35693

> п@рашу

Невелика потеря, справимся без тебя как-нибудь.

Сэйбераны, нужна ваша помощь.
http://lemmasoft.renai.us/forums/viewtopic.php?f=51&t=16273 профиль персонажа, так сказать.
Не могу понять, как добавлять эти профили по мере добавления персонажей в игре. Подскажите, пожалуйста.

>>35895 Пожалуйста, задай более конкретный вопрос. Желательно с тестовой сборкой и указанием на то, что именно в ней хочется добавить. Потому что сейчас не пойму, в чём твоя проблема.

**Решение 1: **
Сначала список персонажей пуст.

$ allchars = []

А потом по мере того, как появляется кто-то ещё, добавляешь.

$ allchars += [boy]
...
$ allchars += [girl]

Особенности: порядок профилей не фиксирован.

**Решение 2: **
Добавить в конструктор init класса char:

self.visible=False

Заменить for i in allchars: на что-то такое:

for i in [i for i in allchars if i.visible]:

А потом по мере того, как появляется кто-то ещё, добавляешь.

boy.visible
...
girl.visible

Особенности: порядок профилей фиксирован.

**Решение 3: **
То же, что и 2, но заменить allchars на массив кортежей <class char, bool>.
Особенности: порядок профилей фиксирован, при этом архитектурно правильнее.

>>35896

> allchars += [boy]

Господи, кто тебя питону учил? allchars.append(boy) и никак иначе, зачем копировать память каждый раз?

>>35966 В данном конкретном случае - преждевременная оптимизация. А в нагруженных проектах это может быть проблемой, да.

А вы знали, что экраны перерисовываются при каждой интеракции?

>>36482 на самом деле, чаще, ведь на экране могут быть анимированные объекты или и вовсе DynamicDisplayable.

>>36485
А вот и нет. Анимация обсчитывается отдельно.
А вот тело экрана, по крайней мере, написаное на скрин лэнгвидже выполняется каждый раз заново при интеракции.
Т.е., она у меня моргает глазами, но инкремент, записанный в первой строке тела экрана выполняется только при клике.
Я бака даже стёр вызов отдельных экранов, и вызываю один в начале сцены, и в его теле прописал зависимости элементов от переменных, а сами переменные меняю уже в тексте.
Ну кто бы мог подумать...

>>35690

> Кстати, в оригинальном RenPy не было ни screen language, ни ATL. При этом функциональной гибкости эти конструкты не добавили - только синтаксический сахар.
> Всё тоже самое можно было написать простеньким python-блоком с вызовом ui.button и прочих ui-функций. По мне так у такого кода даже читаемость была бы выше, чем мешанина из прыгающих друг на друга screen.

ATL и screen language - это шаг в очень правильном направлении. В отличие от питона они декларативные. В идеале в исходниках VN вообще никакого питона быть не должно, и VN должна быть не программой, а документом. Тогда её можно будет без проблем конвертировать хоть в HTML5, хоть во флэшь, хоть в бумажную книжку с картинками. Ну и безопасность: сейчас любая эроге тебе может сделать $ system('rm -rf /'). Потом, захочешь через 50 лет поиграть в старенькую эроге своей юности - будет нехилый квест: поднять эмулятор древних ПК, поставить туда древнюю ось из музея, запинать там древний ренпай и т. д. Попробуй вот сейчас на ПК запустить игрушку для PDP-1. А если VN написана декларативно, то для неё просто будет новый интерпретатор под новые платформы. Примерно как сейчас старые IF можно читать с комфортом хоть на пекарне, хоть на телефоне, хоть на кофеварке с андройдом. Или как ScummVM. Вот к этому и надо ренпаю стремиться, а то из движка скоро станет быдлокодерской платформой, нафиг.

Умнейшей пришла в голову очередная гениальная мысль.
Знатоки ATL, помогите разработать функцию для шевеления листочков дерева с края экрана. Можно, конечно, обойтись и обычными кадрами, но я хочу добиться эффекта случайного движения (и, возможно, реализации ветра).
Т.е. идея в том, чтобы один (несколько, формирующих ветку) статичных спрайтов трансформировать так, чтобы они плавно перетекал из одной формы в другую. Прозреваю использование вращений, центровки, масштабов и прочего.
Я пойду пока мануалы читать и щупать варианты наугад, но если великодушная знающая сырна снизойдёт до меня - буду благодарен.

>>37099 Я бы забил на ATL и использовал Particles(). Но тогда придётся немножко покодить непосредственно на голом питоне.

>>37105

>покодить непосредственно на голом питоне

Не проблема. рассказывай.

Если вкратце, то прочитай код http://www.renpy.org/wiki/renpy/doc/cookbook/More_realistic_snow_effect

Там по сути 2 класса. Первый - фабрика частиц. Тебе будет нужно на первом вызове create() инициализировать все частицы-листья. Во второй - дёргать листьями на функции update(). Подозреваю, что всякими im.Rotate и im.FactorScale можно добиться описанного тобой поведения. Если не получится, написать полностью с нуля DynamicDisplayable

>>37122
Прочитал.
Не совсем то. Мне не нужен листопад, я представляю, как его сделать. По сути, примерно так, как описано в примере + вращение для листочков.
Если применить описанный подход к листьям на дереве - это не будет похоже на ветку - это будет похоже, скорее на кучу шевелящихся листьев. Прозреваю ту ещё крипоту.
Особенность листьев на дереве в том, что они связаны и сильно зависимы от положения ветки к которой крепятся. И раскачиваются и пружинят вместе с ней.
Мне, по сути, нужна функция, которая будет в зависимости от силы и направления ветра выдавать значения для (понятия не имею чего) всяких ротаров и скэйлов.
В любом случае, спасибо за помощь.

>>37150
Я не питонер, но алгоритм попробую описать. Используй дерево: http://ru.wikipedia.org/wiki/Дерево_(структура_данных) для построение отношения родитель-потомок. И по этому отношению выстраивай положения изображений.
То есть элемента Б является наследником элемента А.
Элемент А располагается в координатах 100,100.
Элемента Б располагается в координатах 10,20 относительно родителя-элемента А. То есть глобально в координатах 110,120. При изменении положения А изменяется и положение Б.
По такому принципу пересчитывай углы наклона изображений и их координаты. Учитывай смещение центра (В ренпи anchor вроде) для достоверного наклона листьев и ветвей. Помимо этого тебе придется прописать поведение для элементов.

>>37153 Я что-то такое на частицах и предлагал сделать. Нужно будет только классу частицы ещё и ссылку на родителя отдать внутрь init

Недавно начал работать с рэнпай. Как можно сделать инвентарь, включаемый кнопкой. Чтобы там отображались некоторые переменные, например запас воды и еды, и некоторые предметы без возможности их использовать, но с возможностью прочитать их описание. То есть при наличии определенного предмета в развилке появляется новый вариант выбора.

>>56607
Зачем а самое главное, где? ты откапал этот древний тред, когда на нулевой есть «кружок кибернетики» с уроками/советами и прочим на нулевой.