You are not logged in.
В следующей версии ожидается пополнение списка классов. В связи с этим принимаются ваши предложения, каких классов вам не хватает, какие частоиспользуемые опкоды можно заменить них, ваши варианты названий свойств и методов.
Будьте активнее, разрешаю мультипостить в этой теме.
Offline
У меня не предложение,а скорее замечание ,некоторые опкоды написаны не совсем корректно например:
0668: AS_actor 35@ rotate 374.2905 -125.681 1001.308 2000 ms
судя по написанию актер должен повернутся к точке за 2 секунды,а вместо этого он атакует в сторону этой точки
Sergino_thirty_seven ака Sergino37 скриптер с missions.gtamaps.net
Offline
У меня предложение добавить в Санн функцию поиска(сравнения) элементов в массиве.
Например:
$rez_poska = in_mass($mass, $isk_elem)
// результат true/false или номер элемента массива, или сам элемент.
А то надоедает писать циклы.
Offline
2Sergino_thirty_seven:
Учту это. Если есть еще ошибки - говори.
А то надоедает писать циклы.
Добавь макрос с болванкой поиска в массиве, а потом по нажатию F2 вызывай его.
Offline
Может имена классов Car и Actor заменить на Vehicle и Ped?
Offline
Будет не совсем корректно насчет Ped,а вот насчет Vehicle очень кстати
Sergino_thirty_seven ака Sergino37 скриптер с missions.gtamaps.net
Offline
Нет, старые классы меняться не будут, т.к. ничего, кроме проблем совместимости со старыми исходниками, это не даст.
Вы лучше предлагайте новые классы или новые методы к существующим классам.
Offline
Вы лучше предлагайте новые классы или новые методы к существующим классам.
1. Класс (Math) для математических функций (sin, cos, rnd);
2. Класс (Print) для всех текстовых опкодов.
Offline
Класс (Print) для всех текстовых опкодов.
Была такая идея, только вот название мне кажется не совсем подходит. Есть варианты Text, Screen, что скажешь?
Offline
Есть варианты Text, Screen, что скажешь?
Лучше тогда Screen.
Offline
Есть ли смысл добавить в класс Screen кроме текста команды типа Fade, IsFading или ToggleRadar, ToggleHud?
Offline
Ну раз уж класс называется Screen, то можно и добавить.
Offline
Еще вопрос, нужны лы субклассы? Например, Screen.Panel.GetActiveRow, Screen.Text.DrawAt(). Или делать одним классом (разными классами)?
Субклассы можно и для некоторых других классов, например: Actor.Task.ExitVehicle(), Player.Stat.IncreaseByFloat()
Offline
Да будет лучше с сабклассами,новичкам будет легче учится
Last edited by Sergino_thirty_seven (14-06-2007 18:52)
Sergino_thirty_seven ака Sergino37 скриптер с missions.gtamaps.net
Offline
Я предлагаю сделать с субклассами , насчёт Screen.Text - это то что надо , один из самых разнообразных классов , который ещё не задейстован
Offline
Еще вопрос, нужны лы субклассы? Например, Screen.Panel.GetActiveRow, Screen.Text.DrawAt(). Или делать одним классом (разными классами)?
Может для текста - GXT, а в Screen все остальное
Да будет лучше с сабклассами,новичкам будет легче учится
С субклассами конечно будет лучше, но новичкам будет не легче учиться, а легче запутаться.
---
Можно сделать классы Fire и Train.
---
Хотелось что-бы все конструкторы и деструкторы имели одинаковые имена. (Create, Destroy например).
Offline
Может для текста - GXT
GXT подходит только для некоторых опкодов, а вот для большинства text_draw именно Text - хороший вариант.
С субклассами конечно будет лучше, но новичкам будет не легче учиться, а легче запутаться.
Ну в следующей версии их не будет, это я скорее на будущее спрашиваю.
Offline
Идея с субклассами хорошая, потому что если добавлять новые классы, то получится неразбериха, кто где.
У актёров, машин, объектов и др. нужно добавить одинаковые проверки места, например: Actor.InRestangle_OnFoot (или с субклассами Actor.InRestangle.OnFoot (или Actor.Pos.InRestangle.OnFoot)) и Object.InSphere. И другие однотипные действия, а то очень неудобно искать в опкодах, да ещё в SASCM.INI параметр Sphere то идёт то вторым, то последним.
[small][/small]
Offline
Субклассы добавлять надо однозначно, а для совместимости со старыми версиями санни сделать конвертор кода.
Еще было бы не плохо добавить возможность скрывать(как в Visual studio например) отдельные участки кода в едиторе или хотя бы потоки
Offline
Еще было бы не плохо добавить возможность скрывать(как в Visual studio например) отдельные участки кода в едиторе или хотя бы потоки
Это называется Code Folding и, к сожалению, SynEdit это не поддерживает (есть сторонние разработки, но они не совсем подходят).
Offline
Это называется Code Folding и, к сожалению, SynEdit это не поддерживает (есть сторонние разработки, но они не совсем подходят).
Может тогда использовать закладки. Автоматически создавать закладки для каждого потока или раздела, а для быстрого доступа к ним добавить панельку со списком всех закладок в виде ссылок.
Это я думаю реализовать возможно.
Offline
Ну что, кто у нас ответственный за классы?
P.S. Лично я мог бы оказывать разовые помощи [small](для постоянных у меня связь не стабильна, да и ошибок наделаю).[/small]
Last edited by VcSaJen (16-09-2008 08:30)
[small][/small]
Offline
Предлагаю добавить такие классы:
Animation .Load .Loaded .Unload .PerformPed (или переместить этот в класс Actor) .EnablePause .GetTotalTime .GetCurrentTime .SetProgressTo Text .ShowDialog .DisplayBox .PrintWithStyle .Align .Color .Shadow .Size .Style .Font .Linewidth .DrawingMode .DrawAt Texture .LoadTXD( txdName ) .SetNumber( textureName, id ) .SetAntialiased .Release .DrawAt Display .EnableWidescreen .EnableRadar .EnableHud .FlashHudComponent .EnableStatBox .SetGreyRadar Fire .InitInWorld .CreateAnActor .CreateAnCar .Extinguished .Remove .Exists .StorePosition
Предлагаю также добавить следующие команды:
Actor.Defined($PED)
CarDefined($Car)
load_models (кейворд 038B)
function (кейворд 0AB1)
repay (кейворд 0AB2)
start_scene (кейворд 0707)
end_scene (кейворд 0701)
Как показала моя долголетняя практика последние команды очень востребованы в написании скрипта и было бы очень мега удобно включить их в комплект SB.
Суб-классы бы не помешали
Last edited by wmysterio (22-02-2014 14:29)
Offline
Проблема в том, что сначала нужно переименовать все опкоды. Сейчас известны оригинальные названия всех опкодов, и оригинальные названия сущностей, которые использовали R*. Например, актеры в оригинале назывались Ped, значит по-хорошему и соответствующий класс должен называться Ped, а не Actor. Вместо Player - Char. Попутно нужно решить, что делать с порядком следования параметров. Сейчас они идут как попало, где-то в оригинальном порядке, где-то переставлены. Во всех конструкторах переменная, куда записывается результат, стоит в конце. Но логичнее смотрится когда эта переменная стоит в начале:
009A: 0@ = create_actor #null 0 0 0 вместо 009A: create_actor #null 0 0 0 0@
Не все опкоды-конструкторы приведены к единому порядку следования, поэтому и запихнуть их в классы не получится.
Вот пока я не придумал хорошего и удобного решения для этой проблемы, чтобы не пропала возможность использовать старые скрипты.
Offline
Проблема в том, что сначала нужно переименовать все опкоды. Сейчас известны оригинальные названия всех опкодов, и оригинальные названия сущностей, которые использовали R*. Например, актеры в оригинале назывались Ped, значит по-хорошему и соответствующий класс должен называться Ped, а не Actor. Вместо Player - Char.
Я могу заняться переименованием. Случилось так, что у меня появилось много свободного времени да и заняться в общем-то нечем.
Попутно нужно решить, что делать с порядком следования параметров.
Как вариант: оставить оригинальное последование параметров. Сделать новую разметку классов, с описанием где какой параметр должен стоять. К примеру можно использовать xml-файл с такой разметкой:
<CLASSES> <PED> <COMMAND> <NAME>Create</NAME> <OPCODE>XXXX</OPCODE> <PARAMS> <DESCRIPTIONS>%d %i %f %f %f %h</DESCRIPTIONS> <POSITION>6 = LEFT</POSITION> </PARAMS> </COMMAND> <COMMAND> <NAME>PutAt</NAME> <OPCODE>XXXX</OPCODE> <PARAMS> <DESCRIPTIONS>%f %f %f %h</DESCRIPTIONS> <POSITION>%h 0</POSITION> </PARAMS> </COMMAND> <COMMAND> <NAME>Destroy</NAME> <OPCODE>XXXX</OPCODE> <PARAMS> <DESCRIPTIONS>%h</DESCRIPTIONS> </PARAMS> </COMMAND> <COMMAND> <NAME>Healt</NAME> <OPCODE>XXXX</OPCODE> <PARAMS> <DESCRIPTIONS>%d %h</DESCRIPTIONS> <POSITION>1 >= RIGHT</POSITION> </PARAMS> </COMMAND> </PED> </CLASSES>
Это в компиляторе должно выглядеть как
%h = PED.Create( %d %i %f %f %f )
PED.PutAt( %h %f %f %f )
PED.Destroy( %h )
PED.Health( %h ) >= %d
При компиляции берётся порядок с DESCRIPTIONS и подставляются соответствующие значения. Идея в том, чтобы не писать порядок каждому опкоду, а только тем, что описаны в файле классов.
чтобы не пропала возможность использовать старые скрипты
Да, с этим есть проблема. Возможно есть смысл всё-же начать новую главу в СБ и кардинально всё поменять, введя новизну, но это грозит утомительный переход как "старых волков" в скриптинге, так и пользователей, которые, скорее всего, будут забивать форум вопросами "почему" и.т.п. Две стороны медали.
Offline