[1.6.2]Несколько вопросов о блоке

127
0
Приветствую всех.

У меня тут возникло несколько вопросов о блоках.
Делаю я подобие гравитационного поля.

  • Блок должен быть полностью проходимым и прозрачным. Что у меня осуществить не получается. Использую сии код:
Код:
    public AxisAlignedBB getCollisionBoundingsu_boxFromPool(World par1World, int par2, int par3, int par4)
    {
        return null;
    }
 
    public boolean isOpaqueCube()
    {
        return false;
    }
 
    public boolean renderAsNormalBlock()
    {
        return false;
    }

    public int getRenderType()
    {
        return 8;
    }
    
    public void setBlockBoundsBasedOnState(IBlockAccess par1IBlockAccess, int par2, int par3, int par4)
    {
        float f = 0.0000F;
        this.setBlockBounds(0.0F, 0.0F, 0.0F, 0.0F, f, 0.0F);
    }

  • Блок должен постоянно обновляться, проверяя условие, за что у меня и должен отвечать метод updateTick. Однако, метод отказывается работать и я не понимаю почему.
P.s. код изначально был красивым, но после возникновения выше перечисленных проблем мне пришлось исковырять его...
[merge_posts_bbcode]Добавлено: 14.05.2014 02:09:09[/merge_posts_bbcode]

Дополню тем, что сам блок прозрачным становится, но он по прежнему непроходим.
 
1,990
18
105
Добавь @Override к каждому методу, чтобы убедиться, что не накосячил с именами методов и они переопределяются.

А updateTick и не будет тикать твой блок каждый тик. Он будет срабатывать лишь при апдейте чанка, в котором находится этот блок. А это происходит случайно. Сделано в целях снижения нагрузки, иначе был бы ад.
Поэтому делай свой TileEntity и в его update делай что нужно.
Блок придется наследовать от BlockContainer, чтобы он видел TileEntity (ловил нужные события).
 
127
0
Oldestkon написал(а):
Добавь @Override к каждому методу, чтобы убедиться, что не накосячил с именами методов и они переопределяются.

А updateTick и не будет тикать твой блок каждый тик. Он будет срабатывать лишь при апдейте чанка, в котором находится этот блок. А это происходит случайно. Сделано в целях снижения нагрузки, иначе был бы ад.
Поэтому делай свой TileEntity и в его update делай что нужно.
Блок придется наследовать от BlockContainer, чтобы он видел TileEntity (ловил нужные события).
Так и знал, что рано или поздно дело дойдет до тайла. Ну, что ж, будем пробовать...
 

necauqua

когда-то был anti344
Администратор
1,216
27
172
ДА НЕ НАСЛЕДОВАТЬ ОТ BLOCKCONTAINER, ВАШУ ЖЕ.

Нужно имплементировать ITileEntityProvider, делов-то.
 
127
0
Oldestkon написал(а):
Добавь @Override к каждому методу, чтобы убедиться, что не накосячил с именами методов и они переопределяются.

А updateTick и не будет тикать твой блок каждый тик. Он будет срабатывать лишь при апдейте чанка, в котором находится этот блок. А это происходит случайно. Сделано в целях снижения нагрузки, иначе был бы ад.
Поэтому делай свой TileEntity и в его update делай что нужно.
Блок придется наследовать от BlockContainer, чтобы он видел TileEntity (ловил нужные события).
Действительно, все работает, как нужно. Спасибо.

И еще вопросец: Я вот за пол года опыта с игрок, ни разу глубоко в нем не копался, лишь декоративные блоки делал. И теперь имею дело с привязкой модели к блоку. Все у меня, как в туторе на май*****фт.су, но модели я не наблюдаю, лишь в руках она у меня рендерится. Там случаем не нужен тоже родитель BlockContainer ?
[merge_posts_bbcode]Добавлено: 14.05.2014 03:39:26[/merge_posts_bbcode]

anti344 написал(а):
ДА НЕ НАСЛЕДОВАТЬ ОТ BLOCKCONTAINER, ВАШУ ЖЕ.

Нужно имплементировать ITileEntityProvider, делов-то.
Мне особой роли не играет, что использовать. Результат одинаковый, а значит можно использовать и наследство.

[merge_posts_bbcode]Добавлено: 14.05.2014 03:40:34[/merge_posts_bbcode]

anti344 написал(а):
ДА НЕ НАСЛЕДОВАТЬ ОТ BLOCKCONTAINER, ВАШУ ЖЕ.

Нужно имплементировать ITileEntityProvider, делов-то.
И не обязательно капсом там что-то писать, я человек адекватный, понимаю с первого раза, если все внятно объяснят.
 
675
2
Evgeniy написал(а):
Мне особой роли не играет, что использовать. Результат одинаковый, а значит можно использовать и наследство.
Если хочешь делать читсый и читабельный код, то лучше не наследовать класс с лишними методами.
 
1,990
18
105
anti344 написал(а):
ДА НЕ НАСЛЕДОВАТЬ ОТ BLOCKCONTAINER, ВАШУ ЖЕ.

Нужно имплементировать ITileEntityProvider, делов-то.
Я конечно понимаю, что тебе хочется везде обо всем кричать, но ты попытайся заглянуть в класс BlockContainer.
Если ты будешь имплементировать интерфейс тебе придется переопределять нужные методы заново, в то время, как в BlockContainer'е это уже сделано и лишнего там ничего нет.
А вот с названием класса залажали. Могли бы назвать BlockTileable, или что-то вроде того.
 

necauqua

когда-то был anti344
Администратор
1,216
27
172
-_- А теперь загляни в класс Block и посмотри на то, что делают в нём те же методы.
[merge_posts_bbcode]Добавлено: 14.05.2014 20:07:21[/merge_posts_bbcode]

И да, если лень - там стоит проверка, if(this instanceof ITileEntityProvider){тоже самое, что и в BlockContainer}

[merge_posts_bbcode]Добавлено: 14.05.2014 20:07:40[/merge_posts_bbcode]

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

[merge_posts_bbcode]Добавлено: 14.05.2014 20:08:35[/merge_posts_bbcode]

Я ЖЕ НЕ ДОЛБОЕБ
А, ну да, мы же не кричим.

[merge_posts_bbcode]Добавлено: 14.05.2014 20:12:44[/merge_posts_bbcode]

С каких это пор капс стал обозначать крик? А если я Caps Lock случайно нажал?
 
1,990
18
105
Да ладно?
iua0Pj4.png
 

necauqua

когда-то был anti344
Администратор
1,216
27
172
Уговорил, onBlockEventReceived-а(который вообще хрен знает зачем нужен) нету, а так - сколько лет той версии, скрины которой ты мне показываешь?

7a331977ff716b1887cdcad889a35dc3.png

cf195ce12ec04d93b1450aee90f6376a.png

51bd4f5cf5cdb6a160c340bc0c7f74b6.png
 
1,990
18
105
Вот столько:
YHx3LYI.png


Заглянул в тот же мцп, но с форджем - там всё как у тебя, только переменные нормально названы.
Буду тогда в следующий раз смотреть именно в фордже-мцп. Так что спор был абсурден, ибо разные версии, лол.
Извиняюсь за косяк.
RYGG14U.png
 
Сверху