...я конечно, не зверский программист, но ломать мозги о том, рвать или не рвать строку при передаче ее уже на уровне сети по протоколу TCP/IP - должно быть головной болью не программиста, а потока, управляющего сокетом отправления. Для сего ему положено иметь буфер для кеширования и формирования пакетов, протоколы контрольных сумм и еще многое, благодаря чему в винде еще до сих пор чудом работает сеть. Потому стоит соорудить MFC Based Application.

TRam_, не слушаешь нас — послушай Скифа.
[QUOTE=Skif;177428]начните вы с малого - с полнофункционального управления от клавиатуры и дуплексного обмена - это я вам как системщик советую.[/QUOTE]
Как раз суперуниверсальность — проблема твоих идей, где ты предлагаешь делать специфичный для мультиплееров код в драйвере. Неужели тебе непонятно, что:
[SIZE="3"][FONT="Century Gothic"]Единственной заботой драйвера должен быть обмен данными, который используют другие скрипты и плагины[/FONT][/SIZE].
[QUOTE=Skif;177461]MFC Based Application.[/QUOTE]
МФС имеет несколько дубовый вид. Я думаю, по простоте и удобству .NET больше подойдет.

[QUOTE]Единственной заботой драйвера должен быть обмен данными, который используют другие скрипты и плагины.[/QUOTE]обмен данными с требуемой скоростью.

Например для клавиатуры код вообще отдельный надо делать, так как для неё нужно 3 байта (2 на код клавиши + флаг) , но обмениваться часто (~0.01 с). А мультиплееру надо 1 строку или массив писать, по несколько тысяч символов, но раз в 0.5 секунды. И запись ответной строки (в случае одномассивного интерфейса) задерижит отправку очередного ответа от клавиатуры.

Не, если считаешь, что запись этих строк происходит почти мгновенно, я не имею ничего против. Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с (т.е. 5 пропущенных сигналов клавиатуры)

[QUOTE=TRam_;177511]Например для клавиатуры код вообще отдельный надо делать, так как для неё нужно 3 байта (2 на код клавиши + флаг) , но обмениваться часто (~0.01 с). А мультиплееру надо 1 строку или массив писать, по несколько тысяч символов, но раз в 0.5 секунды. И запись ответной строки (в случае одномассивного интерфейса) задерижит отправку очередного ответа от клавиатуры.[/QUOTE]
Ну да, это у тебя серьезные проблемы, ведь ты передаешь только одну строку за раз.
[FONT="Century Gothic"]А еще, к твоему сведению, в ТРС многозадачность кооперативная. Так что как бы ты не выпендривался с десятком строк для каждой функции, по твоим суждениям следует, что запись данных мультиплеера по-любому заблокирует клавиатуру.[/FONT]
[QUOTE=TRam_;177511]обмениваться часто (~0.01 с)[/QUOTE]
Ты не прав. Во-первых, номинал времени отклика для нажатия клавиши — 0.1 с. Во-вторых, используя паттерн ли...
[QUOTE=TRam_;177511]Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с[/QUOTE]
А зря, вот сначала посчитай, а потом уже пиши, а то нередко "факты", написанные тобой, оказываются бредом. Живо встает в памяти проблема отражения ГСТСа от стрелок.

Счеты
 

[B]Тест:[/B]
[CODE]int[] a = new int[10000];
int i;
int j;

Interface.Log("START");

for (i = 0; i < a.size(); ++i)
{
for (j = 0; j < a.size(); ++j)
{
a[i] = j;
a[j] = i;
}
}

Interface.Log("STOP");
Interface.Log(a[0] + a[a.size() - 1]);
[/CODE]

[B]Результат:[/B]
[CODE]? 000004AC Warn 0:25.7 Trainz : WorldState::NativeLog> START
? 000004AC Warn 0:41.2 Trainz : WorldState::NativeLog> STOP
? 000004AC Warn 0:41.2 Trainz : WorldState::NativeLog> 19998[/CODE]

[B]Скорость записи:[/B]
2 * 10000 * 10000 / (41.2 - 25.7) = 12903225,806451612903225806451613

[B]То есть:[/B]
12.9 МБ/с (считаем целое четырехбайтовое число за один байтовый символ)

[B]Вывод:[/B]
Скрипты в ТРС прекрасны.

Миша, Вова, Саня! Каковы перспективы увидеть мультик в ТРС вцелом?)
Ребята вон для ГТА довольно быстро управились

Надо пробовать :)

Если техническая сторона все это вполне допускает, то организационные моменты гораздо сложнее, мне кажется.

[QUOTE]Живо встает в памяти проблема отражения ГСТСа от стрелок.[/QUOTE]да, ГСТС неверно отпределяет положение переведённой не на нас противошёрстрной стрелки.
ЭТО ФАКТ. А моё предположение о том, что оно неверно определяется для противошёрстных стрелок вообще было вызвано фитчей АЛСН потери кодирования на стрелке и фактом не оказалось.

[QUOTE]То есть:
12.9 МБ/с (считаем целое четырехбайтовое число за один байтовый символ)[/QUOTE]
остаётся только мне со строками проверить и покончить ещё с одним своим бредом.

Строка — тот же массив чисел. Ничего иного ты не обнаружишь.
К тому же имеет смысл работать именно с массивом интов. Так имеется возможность экономно передавать бинарные данные. Извлечь из такого массива строку легко, а наоборот — уже труднее.
[QUOTE=TRam_;177552]да, ГСТС неверно отпределяет положение переведённой не на нас противошёрстрной стрелки.[/QUOTE]
Как он может определять положение стрелки, ГСТС лишь ищет и находит, а положение стрелки выдается Junction.GetDirection() и от поиска не зависит.

[QUOTE]Как он может определять положение стрелки, ГСТС лишь ищет и находит,[/QUOTE]ну не положение относительно поиска, так направление относительно поиска, выдаваемое
public native bool GSTrackSearch.GetFacingRelativeToSearchDirection ( void ) .


[QUOTE]К тому же имеет смысл работать именно с массивом интов. Так имеется возможность экономно передавать бинарные данные.[/QUOTE]а может вовсе с плавающей точкой делать? А то нам целочисленные не очень-то нужны, главное - имена и значения скорости и расстояния

[QUOTE]Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с (т.е. 5 пропущенных сигналов клавиатуры)[/QUOTE] Ну на твоем кассетном Спектруме, может, и так... У всех людей скорость перемещения данных в ОЗУ давно уже имеет исчисление гигабайтами.

[QUOTE]Миша, Вова, Саня! Каковы перспективы увидеть мультик в ТРС вцелом?)
Ребята вон для ГТА довольно быстро управились[/QUOTE] Технически проблем никаких нет. А так бы я на вашем месте давно подсадил меня на героин и заставлял работать в обмен на дозу.

[QUOTE]а может вовсе с плавающей точкой делать? А то нам целочисленные не очень-то нужны, главное - имена и значения скорости и расстояния[/QUOTE] Лучше булев.

P.S. Володя, ради бога, занимайся лучше своим делом — сопроматом и не мотай нам нервы и не трать наше время на опровержение твоей бредятины.

[QUOTE=TRam_;177580]ну не положение относительно поиска, так направление относительно поиска, выдаваемое
public native bool GSTrackSearch.GetFacingRelativeToSearchDirection ( void ) .[/QUOTE]
Интересно услышать детали.

[QUOTE]Ну на твоем кассетном Спектруме, может, и так... [/QUOTE]хочешь чтоб а ещё попетросянил? Пожалуйста. Мой камп, с которого я написал это сообщение
[URL=http://radikal.ru/F/i060.radikal.ru/1005/dd/a004749af898.jpg.html][IMG]http://i060.radikal.ru/1005/dd/a004749af898t.jpg[/IMG][/URL]

[QUOTE]Интересно услышать детали.[/QUOTE]это не детали. Это пояснение.

[QUOTE]P.S. Володя, ради бога, занимайся лучше своим делом — сопроматом и не мотай нам нервы и не трать наше время на опровержение твоей бредятины.[/QUOTE]Вероятно ты прав... Пора уже TRainzManual_'у на покой. Свою самую сложную мечту - связать trainz и свою программу - он уже осуществил

[QUOTE=TRam_;177596]это не детали. Это пояснение.[/QUOTE]
Что в нем не так — вот что я хочу услышать. Возвращает ли он правильное значение, или неправильное, или противоположное правильному, или всегда одно, или вообще рандомное.

возвращает всегда false. При любом положении левера относительно пути.

Следующий SearchNext выдаёт null, так что для маршрутизации надо запоминать объект перед стрелкой и его направление относительно поиска, чтобы после её перевода возобновлять поиск с этого объекта, а не со стрелки.