Вопросы, касающиеся создания мультиплеера с синхронизацией поездов

[Skif]

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

[genesis]

TRam_, не слушаешь нас — послушай Скифа.

Сообщение от Skif

начните вы с малого - с полнофункционального управления от клавиатуры и дуплексного обмена - это я вам как системщик советую.

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

Сообщение от Skif

MFC Based Application.

МФС имеет несколько дубовый вид. Я думаю, по простоте и удобству .NET больше подойдет.

[TRam_]

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

обмен данными с требуемой скоростью.

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

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

[genesis]

Сообщение от TRam_

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

Ну да, это у тебя серьезные проблемы, ведь ты передаешь только одну строку за раз.
А еще, к твоему сведению, в ТРС многозадачность кооперативная. Так что как бы ты не выпендривался с десятком строк для каждой функции, по твоим суждениям следует, что запись данных мультиплеера по-любому заблокирует клавиатуру.

Сообщение от TRam_

обмениваться часто (~0.01 с)

Ты не прав. Во-первых, номинал времени отклика для нажатия клавиши — 0.1 с. Во-вторых, используя паттерн ли...

Сообщение от TRam_

Но я не считаю, что ТРС умеет записывать строки в 2000 байт даже за 0.05 с

А зря, вот сначала посчитай, а потом уже пиши, а то нередко "факты", написанные тобой, оказываются бредом. Живо встает в памяти проблема отражения ГСТСа от стрелок.

[genesis]

Тест:

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]);

Результат:

? 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

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

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

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

[Midnighter]

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

[genesis]

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

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

[TRam_]

Живо встает в памяти проблема отражения ГСТСа от стрелок.

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

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

остаётся только мне со строками проверить и покончить ещё с одним своим бредом.

[genesis]

Строка — тот же массив чисел. Ничего иного ты не обнаружишь.
К тому же имеет смысл работать именно с массивом интов. Так имеется возможность экономно передавать бинарные данные. Извлечь из такого массива строку легко, а наоборот — уже труднее.

Сообщение от TRam_

да, ГСТС неверно отпределяет положение переведённой не на нас противошёрстрной стрелки.

Как он может определять положение стрелки, ГСТС лишь ищет и находит, а положение стрелки выдается Junction.GetDirection() и от поиска не зависит.

[TRam_]

Как он может определять положение стрелки, ГСТС лишь ищет и находит,

ну не положение относительно поиска, так направление относительно поиска, выдаваемое
public native bool GSTrackSearch.GetFacingRelativeToSearchDirection ( void ) .

К тому же имеет смысл работать именно с массивом интов. Так имеется возможность экономно передавать бинарные данные.

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

[Combine]

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

Ну на твоем кассетном Спектруме, может, и так... У всех людей скорость перемещения данных в ОЗУ давно уже имеет исчисление гигабайтами.

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

Технически проблем никаких нет. А так бы я на вашем месте давно подсадил меня на героин и заставлял работать в обмен на дозу.

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

Лучше булев.

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

[genesis]

Сообщение от TRam_

ну не положение относительно поиска, так направление относительно поиска, выдаваемое
public native bool GSTrackSearch.GetFacingRelativeToSearchDirection ( void ) .

Интересно услышать детали.

[TRam_]

Ну на твоем кассетном Спектруме, может, и так...

хочешь чтоб а ещё попетросянил? Пожалуйста. Мой камп, с которого я написал это сообщение

Интересно услышать детали.

это не детали. Это пояснение.

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

Вероятно ты прав... Пора уже TRainzManual_'у на покой. Свою самую сложную мечту - связать trainz и свою программу - он уже осуществил

[genesis]

Сообщение от TRam_

это не детали. Это пояснение.

Что в нем не так — вот что я хочу услышать. Возвращает ли он правильное значение, или неправильное, или противоположное правильному, или всегда одно, или вообще рандомное.

[TRam_]

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

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