Сообщений в теме: 215

[Вадим Буренков]

Что-то не работает . Попробую переустановить игру на английскую версию 1С и на нее поставить второй патч(я правильно понял что английский патч 1.0.2.0 второй по номеру выпуска?).

Сообщение отредактировал Вадим Буренков: 15 June 2009 - 17:42

[Вадим Буренков]

Установил, теперь работает . В GTASA скрипты перезагружались во время старта игры, а здесь также, или нужно заново запускать игру? Seeman, а сушествует какая документация для базовых понятий скриптинга на Delphi? Например зачем типы ................. // standard data types i32 = type LongInt; u32 = type LongWord; i16 = type SmallInt; ................. Зачем так сделано? Например b8 = type Boolean; почему надо писать не Boolean а b8.Это что сокращение кода? i и f как я понял сокращение от integer и float, а что значат цифры 32, 16, 8 и.т.д? На странице указаной выше есть список native функций, их можно использовать в Delphi?, ведь там процедуры и функции из Scripting.pas?Или функции из Scripting.pas являются аналогами native'ов? Нашел функцию проверки нахождения Char'а в самолете , но ведь в игре самолетов нет! function IsCharInAnyPlane(ped: Ped): b8; cdecl; external libname; Как то странно, что-то не найду процедуру чтоб Char стрелял в кого нибудь или куда нибудь.Она есть?

Сообщение отредактировал Вадим Буренков: 16 June 2009 - 08:34

[JNikc]

Сейчас смотрю Delphi SDK от Александера. Это почти те же функции что и в dhook, с точностью до того, что они вызываются не из dhook.asi а из AliceUltimate.asi.

Вадим, вещи типа

i32 = type LongInt;	  //32 битное знаковое целое
u32 = type LongWord; //32 битное безнаковое целое
i16 = type SmallInt;	//16 битное знаковое целое

это определения синонимов. Вся документация - это сами заголовочные файлы и описания нативов в вики на этом сайте. Вызовы нативов упакованы в asi библиотеки, а вызвать мы их можем хоть из дельфи хоть из С, хоть из lua.

У меня такое предложение. Вместо однократного объявления в interface:

procedure AddScore(playerIndex : PID; score : i32); stdcall; external LIB;

определить классы Player, Ped, Vehicles, и т.д., опубликовать функции:

type Playa = class
  public
	procedure AddScore(playerIndex : PID; score : i32); stdcall;
	procedure Char(playerIndex : PID; ptrPed : PPedID); stdcall;
	procedure Group(playerIndex : PID; pAnyGroup : PGroup); stdcall; 
	function Id() : u32; stdcall;
	function Name(playerIndex : PID) : PChar; stdcall;
	...
end;

Я тут укоротил имена функций, в принципе можно доть любые имена, и даже одни и те же для разных функций в разных классах. Потом уже в implementation писать:

implementation

procedure Playa.AddScore; external LIB name 'AddScore';  // тут реальные имена
function Playa.Id() : u32; external LIB name 'GetPlayerId';
function Playa.HasChar(playerIndex : PID) : b8; external LIB name 'PlayerHasChar';
...

Если занятся таким редактированием, то в принципе у натив-функций должна вырисоваться некая иерархия, и можно даже будет построить дерево классов с полиморфизмом (например функция здоровья для игрока и педа - override одной абстрактной функции), а не просто объявлять функции одну за другой.

Сообщение отредактировал JNikc: 21 June 2009 - 20:23

[JNikc]

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

Прикрепленные файлы

•  8.jpg   37.21К   24 загрузок

[Вадим Буренков]

Я только за! Я сам ранее работая с SannyBuilder'ом понял прелесть разбивания процедур и функции на классы, а в программировании без них вообще туго (учусь делать простые 2D игры, например http://www.vadim-bur...CosmoNoid2.rar)
Но я еще помимо разбивания на классы делаю работу с процедурами более удобной. Например чтобы создать машину нужно загрузить ее в память, проверить загружена ли она, создать ее и очистить память. Делать это крайне неудобно, поэтому я заношу в класс не стандартные процедуры, а измененные мной.
Вот процедура простого создания автомобиля:

function CreateCar(x,y,z:f32;CarModel:eModel):vehicle;
begin
RequestModel(CarModel); // запрашиваем модель
// ждем пока не загрузится
while not(HasModelLoaded(CarModel)) do
begin
Wait(0);
end;
//спавним тачку в координатах
CreateCar(CarModel, x, y, z, Result, true);
// освобождаем память
MarkModelAsNoLongerNeeded(CarModel);
end;

А в скрипте можно создать машину всего одной командой

Car:=CreateCar(x,y,z,MODEL_ANNIHILATOR);

Сейчас загрузил Alice Ultimate Delphi SDK, буду разбераться.

Сообщение отредактировал Вадим Буренков: 20 June 2009 - 13:55

[JNikc]

Вот я и подумал, что описать нативы не в стиле МОДУЛЬНОГО програмирования, а в стиле ООП - весьма полезно, и игру позволит лучше понять.

В игре обсчим счетом ~3000 функций. Это больше, чем описано в Windows.pas, или WinNT.H (в смысле импортных)!!! При том, что в последних активно используются классы и ООП. Поэтому я вижу, что с таким обилием функций трудновато справится, не упаковав их. При этом спад в скорости врят ли будет большим.

Все типы

type
  ScriptAny = u32;
  Player = u32;
  Vehicle = u32;
  Ped = u32;
  Group = u32;
  Obj = u32;
  CoverPoint = u32;
  Train = u32;
  Interior = u32;
  Blip = u32;
  Pickup = u32;
  TextureDict = u32;
  Texture = u32;
  Fire = u32;
  Car = type Vehicle;  // = u32
  Char = type Ped;	 // = u32
  Marker = type Blip;  // = u32

это по сути ID, разных объектов. Т.е. в игре экземпляры этих типов могут иметь идентификаторы от 0 до 2^32 - 1, и этого точно хватит на все про все (можно было взять меньше, но 16 бит вроде мало, а 32 - прекрасно поддерживается большинством аппаратных платформ). Пока мы описываем все функции в модуле - для наглядности можно разделять разные ID, но если использовать классы, то за счет инкапсуляции становится ясно к чему относится идентификатор - к игроку, модели, интерьеру, и т.д. Поэтому вместо типов выше я определяю только два:

ID =  u32;  // Общий идентификатор любого объекта
  PID = ^u32;  // Соответствующий указатель

Что касается векторов, то всё так же:

TVector = record
X, Y, Z : f32;
end;
PVector = ^TVector;

Плюс, я определил для вектора функции перемещения, поворота и масштабирования. Теперь немного о классах. Всего два общих класса. Один общий класс - GObject (аналог TObject в Дельфи) имеет защищенный, наследуемый ID, также защищенный абстрактный виртуальный метод его получения (который будет различаться у потомков) и конструктор с деструктором. Пока так:

type GObject = class
  protected
	ID  : ID;
	Ind : Ind;
  public
//	constructor Create;
//	destructor Destroy; override;
	procedure Refresh; virtual; abstract;
end;

Далее от него наследуем остальные классы. Если посмотреть на функции Char, Group, ... со всеми этими create, и remove, то кажется естественным определять их как классы. Особенно для педов - там около 5 функций создания и еще несколько уничтожения, то же самое для разных объектов - можно сразу делать перегрузку функций.

type TPlayer = class(GObject)
  public
	Name : String;
	Char : ID;
	Group : ID;
	MaxArmorr : u32;
	constructor Create; overload;
	constructor Create(NID : ID; x: f32; y: f32; z: f32); overload;
	procedure AddScore(score: i32);
	...
	function IsDead: b8;
	function IsFreeAimingAtChar(ped: Ped): b8;
	function IsFreeForAmbientTask: b8;
	function IsPlaying: b8;
	function IsPressingHorn: b8;
	...
end;

В первую очередь появились поля - ID, наследуемый от GObject, плюс Name, Char, Group, MaxArmorr. Сразу по созданию экземпляра класса эти поля заполняются. Все остальные функции стали методами, укоротились в названии (понятно, что относятся к плееру), и больше не надо указывать ID, потому что он прописывается при создании. Есть функции, которые вообще носят вспомогательную роль, например ковертация индекса и ID, их можно вообще спрятать. А вот примерный конструктор:

constructor TPlayer.Create;
begin
   ID := GetPlayerId;
   Name := GetPlayerName(ID);
   GetPlayerChar(ID, Char);
   GetPlayerGroup(ID, Group);
   GetPlayerMaxArmour(ID, MaxArmour);
end;

Здесь функции уже непосредственно нативные, но они скрыты и не должны быть доступны, только если специально подключить к скрипту модуль Native.
Другой общий класс - TGame - определяет работу с опциями и свойствами игры.

TObject
  TPlayer
  TPed
  TGroup
  Tvehicles
  TGarages
  TInteriore
  TBlip
  TPickups
  TWorld
  Tobj
  Tmodels

TGame
  TText
  TTexture
  TStats
  TPad
  TSound
  TMisc

Функции General в класс лучше не объединять.
Итого 2 общих класса = 11 + 6 классов.

Сообщение отредактировал JNikc: 21 June 2009 - 19:52

[JNikc]

У меня главным образом такой вопрос - каково происхождение dhook.asi и alice.asi? Я могу только сказать, что первая написана на vС, а вторая - на Delphi. А исходники есть? Можно ли объединить исходники библиотеки типа *.asi и исходники типа Script*.pas. P.S. Вот в этом архиве уже 8000 строк)). Но пока как следует расписан только TPlayer, TPed только начат. и это при том, что в asi сейчас только третяя часть функций.

Прикрепленные файлы

•  Classes.4.GTA.rar   123.95К   14 загрузок

[Seemann]

dhook.asi - это скомпилированный под Visual Studio исходник С++ Hook от aru с некоторыми добавками для работы с дополнительными дельфи-модулями.

[JNikc]

Да я что-то не подумал поискать, спасибо, исходники нашед на gtaforums, также как и SparkIV (- хорошая весчь). А что думаете о попытке писать библиотеку? Может функции из исходников aru встроить прямо в неё?

[Вадим Буренков]

Посмотрел Alice Ultimate Delphi SDK, классная вещь. Отличий от DHook'a почти никаких, но имеет два больших плюса 1)Доступно около 2000 комманд из 3000 2)Код в procedure main(); export; выполняется один раз, а не каждую милисекунду как в DHook. А за архив с классами спасибо. У меня вопрос: Как узнать какие параметры в командах за что отвечают? Например procedure TaskSitDownOnObject(Ped : Ped; UnkI1, UnkI2 : i32; Obj : Cardinal; UnkF1, UnkF2, UnkF3, UnkF4 : f32; UnkI3, UnkI4 : i32); stdcall; external LIB; Что за переменные UnkI1, UnkI2, UnkF1, UnkF2, UnkF3, UnkF4, UnkI3, UnkI4 Ведь как-то создатель SDK узнал переменные например для AddAmmoToChar(pedestrian : Ped; weapon : eWeapon; amount : u32);

Сообщение отредактировал Вадим Буренков: 22 June 2009 - 08:22

[JNikc]

Ну это настоящий прорыв!)) Количество функций возросло вдвое по сравнению с dhook и С++ hook. Но, параметры Unk это Unknow т.е. неизвестные. Насколько понимаю, функции изучаются вручную под дизасаблером. Тут есть два варианта, один "лучше" другого - либо декомпилировать sco и смотреть КАК используются функции по контектсу, и делать выводы. Либо ставить разные параметры и смотреть на результаты в игре. Кстати, разработчики сделали так, что все нативные функции принимают аргументы только по 32 бита. Так что остальные типы - это для удобства.

Сообщение отредактировал JNikc: 22 June 2009 - 08:37

[Вадим Буренков]

либо декомпилировать sco и смотреть КАК используются функции по контектсу, и делать выводы. Либо ставить разные параметры и смотреть на результаты в игре.

Проблема в том, что раньше (GTASA и SannyBuilder) я пользовался первым способом, а тут никакого SCO нет, ведь скрипты пишутся в чистом .ext на Delphi, а подбирать такое количество значений вручную можно вечно и безрезультатно.
А разве уже есть программы для редактирования игровых скриптов gta4 в SCO?

А как с помошью Alice SDK вывести на экран коогдинаты игрока. Получить я их смог, а выводить не умею(пробовал Print'ом и не получается).

Сообщение отредактировал Вадим Буренков: 22 June 2009 - 11:19

[JNikc]

В SDK есть примеры скриптов, в том числе там - вывод строки (PrintStringWithLiteralStringNow), превратить числа в строки можно уже средствами дельфи (т.е. код будет приатачен к твоей dll = ext). В sco тоже вызываются нативы, и указывается сколько у них аргументов, я это имел в виду (есть статья тут в вики). С помощью SparkIV или OpenIV можно редактировать ресурсы игры, например смотреть, дизасаблируя, sco файлы. Там ещё есть хитрая зависимость хэша натива от её номера.

[listener]

JNikc - безотносительно к последним нескольким постам.
Все мысли, в общем-то правильные, вот только они получаются слишком оторванные от реальности. Посмотри, как в GTA вообще и в IV в частности устроена система объектов. Много станет понятнее.

(для меня, при взкляде со стороны игровых объектов, многие вещи звучат просто дико)

Что касается размера аргументов - все типы виртуальной машины кратны 32 битам.
В описании нативных функций есть несколько неточностей, когда параметром передается не набор отдельных значений, а целые структуры.

Там ещё есть хитрая зависимость хэша натива от её номера.

От какого номера?

Сообщение отредактировал listener: 22 June 2009 - 13:06

[JNikc]

Посмотри, как в GTA вообще и в IV в частности устроена система объектов. Много станет понятнее.

Я действительно не имею никакого представления об этом. Надо видимо пройтись по Вики...

А то, что выглядит дико, это как? Я конечно в том файле неправильно прописал конструкторы, но в остальном - ещё почти ничего нет. Я просто подумал паковать шаблоны, которые используются при скриптинге (делай раз, делай два, ...) в методы, ну и воспринимать объекты игры как ООП экземпляры. Или это вообще не пройдёт?????

вот только они получаются слишком оторванные от реальности

Это всего лишь "размышления на тему". Однако - работает. Правда я не знаю что лучше - писать как обычно или на классах. Вот пример spawn в классах:

program Spw;

uses GameClasses;

procedure Spawn; ctdcall;
begin
  Game := TGame.Create;
  Playa := TPlayer.Create;

  if Game.KeyPressed('K') then begin
	 Car := TVehicle.Create(Playa.X + 2.0, Playa.Y, Playa.Z);
	 Game.Wait(100);
  end;

  // Делаем ещё что-то

  Car.Free;
  Playa.Free;
  Game.Free;
end;

exports Spawn;

От какого номера?

От номера в списке NativesList.txt. Я имел в виду hash = Hasher.Hash(item); Эта функция показалась мне хитрой)) - т.е. почему именно так? Ответ видимо в exe...

[listener]

Посмотри, как в GTA вообще и в IV в частности устроена система объектов. Много станет понятнее.

Я действительно не имею никакого представления об этом. Надо видимо пройтись по Вики...

Эх, если бы было все так просто... В wiki есть очень мало. В теме на sb-шном форуме есть несколько больше, чем в wiki и на gtaf вместе взятых. Плюс к этому, я выкладывал некоторое количество отреверсенных исходников - по ним должно быть слегка понятно, что-же происходит в мире системных объектов.

А то, что выглядит дико, это как? Я конечно в том файле неправильно прописал конструкторы, но в остальном - ещё почти ничего нет. Я просто подумал паковать шаблоны, которые используются при скриптинге (делай раз, делай два, ...) в методы, ну и воспринимать объекты игры как ООП экземпляры. Или это вообще не пройдёт?????

Пройдет, конечно. Вот только пользоваться этим за рамками "шаблонов скриптинга" будет крайне неудобно.

Вообще, игровые объекты GTA - тема для очень большого отдельного рассказа.
Несколько фактов.

Есть объекты, которые можно условно назвать "статическими" и "динамическими". Статические объекты, создаются при инициализации игры. Это гаражи, парковки, пикапы, модели и т.д. Да, некоторые из них можно добавлять из скрипта, но это именно добавление - убрать уже созданный гараж - нетривиальная задача. Эти объекты собираются в массив и обращение к ним производится по индексу в массиве.

"Динамические" объекты постоянно создаются и разрушаются. Они собраны в пулы, и обращения к ним производтся по хэндлу, в котором кодируется индекс в пуле и номер поколения объекта.

Плюс к вышеперечисленному, есть уникальные объекты (CWeather, CClock, CPopulation и т.д.), которые существуют в единственном экземпляре и которые в opcode/native не передаются в явном виде.

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

Уходя чуточку в сторону, RAGE VM используется не только в GTA, но и в других играх. А объекты в них совсем другие (поискать список natives MC:LA ?). Т.е., если закладываться на GTA-шную структуру объектов и поддерживать их на уровне транслятора - то этот транслятор нельзя будет использовать в MC:LA, Red Dead Redemption и остальном (Mafia2 ?)

Еще немного о структуре объектов.

CPlayer и CPlayerPed - это концептуально разные классы. Первый содержит набор структур, которые существуют только для игрока (CWanted, деньги, небольшой кусочек статистики (вся статистика находится в CStats) и т.д.) Второй - это сабкласс CPed, у которого заоверрайдены методы управления и заблокирована часть AI.

CGame вообще имеет три метода инициализации, три метода завершения и метод process. Т.е., никаких методов и полей, интересных с точки зрения скрипта, у него нет. (Wait - метод CRunningScript/rage::scrThread).

CVehicle в чистом виде, никогда не используется. Используется один из его сабклассов. И, если CHeli или CPlane унаследован от CAutomobile, то CTrain или CBike - нет. Пока используются абстрактные хэндлы, это можно игнорировать (тип хэндла общий для пула, а пул? для всех потомков CVehicle, используется один), как только начинается описание классов, либо нужно копировать иерархию, лито переносить в CCar методы, которые гарантированно не применимы к произвольному транспортному средству, например, getNextCarriage).

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

От какого номера?

От номера в списке NativesList.txt. Я имел в виду hash = Hasher.Hash(item); Эта функция показалась мне хитрой)) - т.е. почему именно так? Ответ видимо в exe...

Хм. Это в где такой?
Вообще, в скрипте для вызова native используется хэш от имени. Если быть совсем точным - Jenkins One-at-a-time hash.
Имена были взяты из функций, регистрирующих обработчики для native.

[Вадим Буренков]

Путем проб и ошибок понял одну важную вещь: если создаешь какой либо игровой объект ( машину, человека и.т.д), то нужно останавливать код до тех пор пока она не создастся. Например:

//создаем человека
CreateChar(4, Model, x, y ,z, @Actor, true);
//даем оружие
GiveWeaponToChar(Actor,WEAPON_SHOTGUN, 100, true);

Данный код не работает, поскольку человек создается командой CreateChar определенное время, а команда GiveWeaponToChar наступает до его создания

Вот рабочий пример:

//создаем человека
CreateChar(4, Model, x, y ,z, @Actor, true);
//если Char не создан ждем 
while not DoesCharExist(Actor) do wait(0);
//как Char создался код идет дальше.
GiveWeaponToChar(Actor,WEAPON_SHOTGUN, 100, true);

Также разобрал команду
TaskShootAtChar(Char1, Char2 : Ped; TimeMaybe : u32; UnkI : i32);
Char1-кто стреляет
Char2-в кого стреляют
TimeMaybe-время
UnkI- мне известны значения: 1 - просто навести оружие на Char2 но не стрелять; 5,4(возможно 3 и 2) - стрелять
Есть предположение что 2,3,4,5 это часть тела в которую стрелять.

Сообщение отредактировал Вадим Буренков: 22 June 2009 - 19:01

[JNikc]

О, спасибо за ликбез, я нативно) думал что всё проще.

Бедная hash = Hasher.Hash(item) : это из исходников Aru (RageLib/Common/Hasher.cs), там есть как бы бетовый декомпилятор sco и я до него дорвался. Кстати есть там же и ресурсы (в виде исходников) по моделям и аудио..

"Отреверсенных"?? Вам что удалось откатить ассамблер обратно к классам и объектам которые могли использовать в R* разрабы, и востановить их иерархию? (Вот было бы шикарно если бы они к каждой игре выпускали обширный мануал).

Статические объекты - добрался до гаражаей, моделей и т.д. для них действительно не ввести конструктор/деструктор, нет смысла.

CPlayer и CPlayerPed - это концептуально разные классы.

Но у них есть много общих свойств, почему нельзя сделать их потомками абстрактного класса?
Да : я описываю классы скорее не с точки зрения ресурсов игры (за незнанием) а с точки зрения пользователя игры.

если создаешь какой либо игровой объект (машину, человека и.т.д), то нужно останавливать код до тех пор пока она не создастся

Это общее правило для всех версий, в SB тоже нужно было ожидание делать. Уже немало скриптовых модов (в т.ч. gta-real.com) и под луа немало интересных, поэтому советую сразу учится на примерах, да и просто попробывать неплохо.

Так, о TaskShootAtChar я думал как о ->CTask. Теперь это не имеет смысла, можно асоциировать методы Task c CMan(<-CPed, <-CPlayer)

Есть предположение что 2,3,4,5 это часть тела в которую стрелять.

Видимо так оно и есть!

Сообщение отредактировал JNikc: 22 June 2009 - 20:33

[Вадим Буренков]

Это общее правило для всех версий, в SB тоже нужно было ожидание делать.

В SB я не делал ожидания и у меня все работало. И я не видел ни одного скрипта в SB где проверялось существование обьекта командой Exsist после создания . Эта команда нужна была только когда ты берешь например случайную машину из игры в раюиусе x метров от игрока , и нужно проверить существует ли такая машина.

Уже немало скриптовых модов (в т.ч. gta-real.com) и под луа немало интересных

В основном все моды по изменению погоды и времени, камеры, прицепления к обьектам и.т.д. Ничего интересного не нашел. Правдо был мод киллера(типа миссий), но он упакован в ASI и я не знаю как достать исходный код.

Кто нибудь зеает как использовать Group команды?Вот код:

//создаб группу
CreateGroup(false,@MyGroup,true);
while not DoesGroupExist(MyGroup) do wait(0);

//находим координаты
 GetOffsetFromCharInWorldCoords(PlayerChar, 0, 15, 0, @tx, @ty, @tz);
//создаем Char'а
Actor.ActorCreate(MODEL_IG_BRUCIE,tx,ty,tz,Actors[1]);
//дальше нужно добавить его в группу,  но ничего не происходит
SetGroupMember(MyGroup,Actors[1]);

Я также эксперементировал с коммандами
SetGroupFormation
SetGroupFormationSpacing
SetGroupSeparationRange, но они не дают результата.
Если же добавлять Char'а в группу игрока, то все работает:

GetPlayerGroup(PlayerID, @MyGroup);
SetGroupMember(MyGroup,Actors[1]);

Помогите, очень нужно.Кстати, может знает кто где найти моды на Alice SDK с открытым кодом на Delphi?

Сообщение отредактировал Вадим Буренков: 23 June 2009 - 09:50

[RussianCJ]

Кто-нибудь знает, возможно ли какой-нибудь из уже известных команд заставить игру прекратить выполнение заскрипченного в SCO команд...ну чтобы игра как будто с чистыми скриптами запускалась?