RailUnion.net

И так тоже пробовал. И даже пробовал images\fon.txt (с альфа-каналом) = ничего не меняется. Бред какой-то. При прописи параметров окна и его содержимого в скрипте нет картинок ни в каком формате, а точно такое же hlml-окно из сессии открывается со всем содержимым.
Получается, что чёрный прямоугольник - соответствует заданному в скрипте размеру текстуры. Кратность степени 2 в данном случае не важна. А вот почему изображения на эту "рамку" не натягивается - загадка. Думаю, это из-за создания окна браузера с помощью Constructors.NewBrowser()? Странно, но текстуры, заданные из стороннего ассета типа string s=hw.MakeImage("<kuid:236444:100000>",true,128,64) отображаются в нём без проблем.

Добрый писал(а):okno=okno+HTMLWindow.MakeRow(HTMLWindow.MakeCell(HTMLWindow.MakeImage("images/fon.tga",true,516,393)));

Попробуй так.

Да пробовал и вообще без вложенной папки - не работает. Плюнул на это дело. Загружаю теперь сторонний html-файл.

Вопрос вот такой возник. JAVA предусматривает многопоточное программирование. В сценарии к Абхазии есть указание на возможность создания параллельных потоков (thread). А кто-нибудь в Трайнзе уже экспериментировал с этим делом?
Вопрос возник потому, что в новом скрипте уже 1000 строк и возникла потребность некоторые процессы для ускорения работы запускать параллельно. Самому экспериментировать - времени не хватает.

А кто-нибудь в Трайнзе уже экспериментировал с этим делом?

собственно это применяется начиная с самых первых отечественных скриптов (а именно в скриптах "анимсцепки" в каждом вагоне есть поток, проверяющий сцепки).

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

Но если события одновременны и никуда не деться, просто вызывай разные thread'ы - они будут выполняться "параллельно" вызывающей их функции. Для синхронизации использовать глобальные переменные или сообщения.

Ясно. Была мысль создание/удаление попутных/встречных составов обрабатывать параллельно основной нити сценария. Но раз производительность хуже - обойдёмся.

+ одна нить особо погоды не сделает. Так что если удобно, можешь её сделать (особенно если удаление не зависит от основной линии сценария), но прироста производительности это никак не даст.

Добрый день, вопрос по звукам в 12 трейнзе.
не хочет воспроизводить звук - switchlight0 change-notch switch2.wav в cabin.txt
подскажите пожалуйста! и еще, Sleep(World.PlaySound(asset,"sound/klub_beep_3.wav",1.0f,100,5,loco,"a.zz"));
звук тянучий какой-то, и с задержкой. может другую функцию включили в 12 трайнз.
в API смотрел там World.PlaySound(soundAsset,"sounds/allaboard.wav",1000.0,10.0,100.0,Station,"a.loudspeaker");
нужно использовать. я пока не разбирался не копался слишком глубоко, чтоб времени не тратить, скажите формат пожалуйста!

звук тянучий какой-то, и с задержкой

вместо старого надо применять что-то типа

World.PlaySound(asset,"sound/klub_beep_3.wav",1.0f,5,100,loco,"a.zz");
Sleep(3.5);

вместо 3.5 вписать длину нужного звука в секундах.

Спасибо, огромное! Предположения были, но все-же спросил.
Спасибо!

Решил попробовать свои силы в скриптовании сигналки. Понял, что надо бы осмыслить некоторые фундаментальные для сигналки вещи. А именно как контролировать занятость рельсовых цепей (как проверять и так понятно, интереснее как контролировать)?
Итак, на ум приходит несколько вариантов:

• дефолт дефолтные светофоры очень хорошо контролируют занятость, ибо делают это нативно. Однако использование дефолтных показаний не приемлемо. Вот бы управлять светофором вручную, а контролировать занятость нативно...
• поток с периодической проверкой т.е. делаем отдельный поток, который один раз в n миллисекунд проверяет занятость. И так на каждом светофоре. Как я понял, именно так работает M-Signals
• реагирование на события триггера именно так работает z*. Но и тут не всё так просто. Событие Enter ещё не означает, что поезд занял охраняемый участок, и в скрипте светофора запускается поток, который ждёт когда же это произойдёт. Однако и этот способ не идеален. Если расцепиться в зоне действия триггера, то вполне можно получить ложную свободность.
• TargetTrigger не так давно я написал скрипт, который позволяет триггеру реагировать не на поезд целиком, а на конкретную точку отдельного вагона. Может имеет смысл делать сигналку на основе таких триггеров?

Кто что думает? Какой вариант лучше?

Событие Enter ещё не означает, что поезд занял охраняемый участок, и в скрипте светофора запускается поток, который ждёт когда же это произойдёт. Однако и этот способ не идеален. Если расцепиться в зоне действия триггера, то вполне можно получить ложную свободность.

1) никаких потоков! Только обработчики (хендлеры)
2) перепроверку занятости надо делать, и только . Хотя это и не обязательно - вон xPath проверяет занятость только "конечных" участков пути, а промежуточные не проверяет.

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

TargetTrigger не так давно я написал скрипт, который позволяет триггеру реагировать не на поезд целиком, а на конкретную точку отдельного вагона

и там всё на TrackSearch'e и потоках ? Ты случаем с луны не свалился,предлагая это встроить в 1500 объектов одной карты с 40 поездами?

TRam_ писал(а):1) никаких потоков! Только обработчики (хендлеры)

А как же WaitForClose? Я про него говорил.

TRam_ писал(а):2) перепроверку занятости надо делать, и только

Может я чего не понимаю... Но если расцепиться на светофоре и уехать, то светофор откроется (как и положено). А вот когда поедет вторая половина события Enter уже не будет, WaitForClose не запустится, светофор не закроется...

TRam_ писал(а):По моему мнению "сигналки" как таковой быть не должно. Должна быть система прокладки маршрутов и система отображения собранных маршрутов. Больше ничего не требуется, и в реальности сигнализация работает именно так.

Но РЦ контролировать-то надо в любом случае. А вот про то, как должна быть устроена сигналка я бы ещё почитал)))

TRam_ писал(а):и там всё на TrackSearch'e и потоках ? Ты случаем с луны не свалился,предлагая это встроить в 1500 объектов одной карты с 40 поездами?

Ну вот и я о том же, какой способ лучше. А на мои триггеры гнать не надо! Они "просыпаются" по Enter и засыпают обратно когда никого нет. Так что в итоге по количеству потоков получаем ту же z*.

Они "просыпаются" по Enter и засыпают обратно когда никого нет.

1) количество одновременно "спящих" не должно превышать 1000 (если я правильно помню), в то время как число обработчиков неограничено. Число светофоров на БМО около 2 000.
2) пробуждение всех триггеров после того, как пояляется сообщение Enter (и их последующее усыпление), тратит намного больше ресурсов, чем вызов обработчика

А вот когда поедет вторая половина события Enter уже не будет

вообще-то намного лучше использовать не Enter, a Leave. Кстати при расцепке состава та половина, которая "появилась", даёт своё сообщение Enter.

Так z7 светофор же тоже просыпается по Enter и ждёт. Да, Leave тоже учитывается, но поток-то уже запущен. Говорю же, количество потоков у меня как в светофоре z* сигналки.

Не знаю, чего там посылает вторая половина, не проверял. А вот светофор закрылся не сразу, явно по Leave. Конечно, в итоге это оказалось не фатально, но всё равно как-то я этому методу не доверяю...