[SoC] Ковыряемся в файлах - Страница 854 - Скрипты / конфиги / движок - AMK Team
Перейти к контенту

[SoC] Ковыряемся в файлах


Рекомендуемые сообщения

Подскажите, в чистом ТЧ есть движковый класс SM_KARLIK в исходниках его не нашел,  он рабочий или нет?

более того, clsid.zone_radiation_s равно nil.

Только что посмотрел - это потому что в ТЧ не экспортирован клиентский класс CRadioactiveZone.

Мне буква S больше на Server намекает

Да я её просто от балды написал, можно написать что угодно.

в чистом ТЧ есть движковый класс SM_KARLIK

Это, вроде, из Lost Alpha? Смотри в class_registrator.script мода. Он добавлен через туда.

Изменено пользователем naxac

 

 

Ну, это кому как. Мне буква S больше на Server намекает. Не стоит свои ассоциации прямо так на других проецировать.

Тогда интересно на что тебе буква Z намекает, будет занятно, если и до RADIO дойдет.

 

 

 

От того, что в cs_register я указал zone_radiation_s, вместо zone_radiation, ничего с clsid не поменялось. Все осталось так-же, как я описывал и более того, clsid.zone_radiation_s равно nil.

Да, все верно.

 

 

 

Т.е. то, что я делаю, вообще делать нельзя, т.к. какой-нибудь условный clsid.zone_zharka_s уже будет обозначать не аномалию, а какого-нибудь условного тушканчика, раз все сбивается?

Делать можно, если магические цифры в коде не используются, а делается все по человечески. Если используются магические цифры, то все плохо. clsid.zone_zharka_s всегда будет жаркой, так как не число (читай выше).

 

 

 

Тогда почему у жарки, радиации и фонтана это значение стало одинаковым? Или может быть несколько имен в clsid с одинаковым значением и это нормально?

Не, не может. Не под тем углом смотришь.

 

 

Только что посмотрел - это потому что в ТЧ не экспортирован клиентский класс CRadioactiveZone.

 

Т.е. получает нельзя делать то, что я делаю? Ведь в этом случае по clsid невозможно будет определить радиоактивную зону. В принципе, оно вроде как не очень и нужно, главное, что аномалия, а это определить возможно будет все равно. Но как-то некрасиво.

 

 

 

clsid.zone_zharka_s всегда будет жаркой

 

Ну как же всегда, если оказывается, что это еще и фонтан и радиоактивная зона.

@dsh, да, так наверно так делать не стоит. В оп2 был (есть) один класс - то ли zone_buzz_s, то ли zone_bfuzz_s - тоже равен nil при проверке в скриптах - тоже понять не мог, почему. Оказалось так же - не экспортирован класс, хотя и написан в луа_хелпе. В общем, во избежание непоняток лучше делать как положено)

 

 

лучше делать как положено

 

Эхъ, а хотелось красиво. :) Что бы "for id, sobj in pairs( se_zones.anoms ) do" вместо "for i = 1, 65534 do".

 

 

Ну как же всегда, если оказывается, что это еще и фонтан и радиоактивная зона.

Я совсем уже не понимаю о чем ты. Еще раз только повторю, что есть поле, а есть магическое число. Продемонстрируй что-нибудь для прояснения. Как ты выясняешь что поле жарки принадлежит фонтану и радзоне? Просто я это все рассматриваю сугубо ассоциативно, и мысли о том, что что-то чему-то может быть несколько раз равно звучат абсурдно.

 

Ты имеешь ввиду, что у тебя clsid.zone_zharka_s == clsid.zone_radioactive?

@Карлан, не, в описанном мной случае clsid.zone_radioactive == 190, а метод clsid() у жарки, фонтана и радиации возвращает 180. Т.е. если я сравню clsid() == clsid.zone_zharka_s для жарки, фонтана и радиации, то получу true, что не есть правильно для случая, когда мне все-таки их нужно различать. А вот если не баловаться с регистрацией, тогда clsid() для радиоактивной зоны возвращает 190, т.е. clsid.zone_radioactive. Но все это уже пустое, т.к.  naxac подсказал причину этой чехарды.

 

Продолжая свои вопросы, что плохого будет, если я вместо

cs_register( object_factory, "CRadioactiveZone", "se_zones.se_zone_anom", "ZS_RADIO", "zone_radio_s" )

сделаю

cs_register( object_factory, "CMosquitoBald", "se_zones.se_zone_anom", "ZS_RADIO", "zone_radio_s" )

т.е. укажу "CMosquitoBald" вместо "CRadioactiveZone", который, как подсказал @naxac, не экспортирован? Во втором случае у меня все работает и с clsid никакой чехарды нет.

Изменено пользователем dsh

@dsh, все, теперь я въехал о чем вы. Да, для создания типа объекта в скриптах нужно брать оба валидных класса, и клиентский и серверный должны быть экспортированы. В твоем случае для радзоны будет вызываться конструктор CMosquitoBald.

 

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

 

P.S. Если хит не приходит - все в порядке ;).

"P.S. Если хит не приходит - все в порядке ;)."

 

Ну, например, костры, сделанные на CMosquitoBald убивают неписей сразу. С учетом того, что для 99%, сидящих у костров, прописан вход в онлайн именно в костре - результат слегка предсказуем, если радиус срабатывания не обнулить.

О том и говорю, потому-что в теории получается шляпа, так как клиентский класс, мягко скажем, не радзоны, а практику всю забыл, поэтому и рекомендую перепроверить. Понятно, что эта проверка как собаке еще одна нога, и так видна пара, но все же.

 

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

@Карлан, проверил. На первый взгляд нормальная радиоактивная аномалия. Хит радиации приходит, но сила хита 0 и кость тоже 0. Детектор трещит, радиация актора увеличивается.

@dsh, а теперь посмотри приходит ли в коллбек хит от стандартной радзоны ;). Затем найди мой пост про, собственно, мою разбираловку с хитом радзоны и выводы не заставят себя долго ждать.

 

От себя в общем не советую делать костры на CMosquitoBald (см. посты Дениса), но каждый делает как считает нужным.

 

P.S. Теория полностью подтвердилась, деревня получила трактор.

Товарищи, вопрос)

 

Как узнать содержимое physic_destroyable_object?

Или хотя бы пуст он или нет (скриптово имею ввиду)

Изменено пользователем PGU_tk

По идее нет "нужной секции"..

Хотелось бы аналог is_inv_box_empty() или точный список содержимого . И чтобы с оффлайновыми работало..)

spawn_ini читается из любого объекта, хоть онлайн, хоть нет. И именно там пишут все, что хотят. А как интерпретировать написанное - дело хозяйское.

  • Спасибо 1
@Карлан, от стандартной радиоактивной зоны хит приходит с не нулевой силой и по кости 65535. В общем, реестр аномалий того не стоит. Буду использовать стандартную зону и по старинке перебирать все id для поиска аномалий. Изменено пользователем dsh

@dsh, аномалии всегда в онлайне на текущем уровне, поэтому перебор всех объектов можно сделать только на старте, а потом перелопачивать аномалии не разом во всей игре, а только на тех уровнях на которых бываем, это лучше, и в этом случае ты можешь уже все радзоны ловить в их биндере. Биндер то у них я надеюсь нормально у тебя там работает?

 

@PGU_tk, destroyable объекты завязаны на свой менеджер, а там рандом, никогда ты содержимое не узнаешь. По остальному уже сказали.

  • Спасибо 1

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...