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

[Dennis_Chikin 3 658]

Ковыряемся в файлах ТЧ

Прежде чем писать в тему - внимательно читаем первый пост, и пользуемся поиском.
Возможно, ответ на Ваш вопрос уже есть.

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

[ARayKo60 233]

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

[naxac 2 441]

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

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

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

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

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

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

Изменено 8 Февраля 2017 пользователем naxac

[Карлан 1 049]

 

 

Ну, это кому как. Мне буква 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 с одинаковым значением и это нормально?

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

[dsh 3 824]

 

 

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

 

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

 

 

 

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

 

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

[naxac 2 441]

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

[dsh 3 824]

 

 

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

 

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

[Карлан 1 049]

 

 

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

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

 

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

[dsh 3 824]

@Карлан, не, в описанном мной случае 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 никакой чехарды нет.

Изменено 8 Февраля 2017 пользователем dsh

[Карлан 1 049]

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

 

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

 

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

[Dennis_Chikin 3 658]

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

 

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

[Карлан 1 049]

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

 

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

[dsh 3 824]

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

[Карлан 1 049]

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

 

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

 

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

[PGU_tk 9]

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

 

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

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

Изменено 9 Февраля 2017 пользователем PGU_tk

[Dennis_Chikin 3 658]

if obj:spawn_ini():section_exist( "нужная секция" ) then ...

не подойдет ?

[PGU_tk 9]

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

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

[Dennis_Chikin 3 658]

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

[GROM_27 1]

Всем привет! Подскажите как возможно реализовать правильное движение солнца в ТЧ?

[dsh 3 824]

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

[Карлан 1 049]

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

 

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