www.mudconnector.su

А для чего тебе нужны раунды, если умения реализовываются так же, как магия, а пассивных атак нет?

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



Тут не понял, надевать несколько вещей в 1 слот... идея интересная, но вынеся в скрипты такую функциональность
мы поменяем шило на мыло... Сделать интуитивно понятным и легко отлаживаемым столь обширный интерфейс будет ой
как непросто.


А что такое "скрипты на коде ядра" ?
Скриптовые языки не подходят для многих вещей.
Нескриптовые для других.
Надо просто грамотно использовать то и сё.
Вопрос с производительностью не вполне праздный. Хотя... черт его знает, может и не стоит об этом думать.
По мне, так надо выделить "общую" часть, и "настраиваемую".
И общую можно сделать hard coded.

Это следует читать "на языке ядра", не то слово подставил.

Так преимуществ никаких.
Тогда просто давайте откажемся от скриптов и всё будем на языке ядра писать .

А почему тогда все плачут, когда надо триггера для зоны на с++ писать и хотят скрипты?

Именно по вышеописанной причине.
С++ абсолютно не подходит для написание триггеров для зон. Увы.
Мне вот вчера довелось вантузом попользоваться... убил бы того, кто этот вантуз сделал,
он абсолютно не подходит даже для того, для чего предназначен. С С++ получше, он подходит
для многого, но пользоваться им для триггеров примерно тоже самое, что пользоваться вантузом
для прочистки засоров в ушных каналах .

ЗЫ. В свое время я скачал и посмотрел пример этих конструкций на С++... это было помнится "нечто".

Да, с++ плохо подходит для массового использования при написании триггеров для зон. Но как раз у вас были опасения, что в некоторых случаях производительности скриптов может и не хватить. В этом случае иметь возможность написать вместо скрипта для зоны с++ код с использованием того же интерфейса - это хорошо.

Если честно, не вижу смысла.
Проще просто вызвать функцию. А саму эту функцию написать на С++.
Т.к. неминуемо это всё будет нерядовой билдер делать. Такой механизм конечно нужен.
(он везде по-моему уже и есть)

Разрешить всем подряд писать что-то на С++ - это похоронить себя под лавиной весьма оригинальных ошибок.

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

ИМХО не стоит заранее переживать о производительности ядра с многочисленными скриптами: во-первых, компьютеры нынче на порядки мощнее времён зари МАДов, когда не было альтернативы, кроме как писать на С или других низкоуровневых языках; во-вторых, скриптовые языки тоже не стоят на месте, и даже большие и требовательные игрушки не гнушаются переносить большие куски логики в скрипты; ну и в-третьих, помните о золотых правилах оптимизации:
“The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.”

Исходя из этого, имеет смысл сначала писать ядро так, как удобно: максимально выносить логику в скрипты и т.п.; а уже получив хотя бы минимально рабочую версию заниматься profiling, и, по необходимости, переносить функции из скриптов в ядро/библиотеки/etc.

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

Хотя есть и иной подход.
Всё делаем внутри, по мере необходимости переносим то, что нам нужно наружу. .