Прокси позволяют разделить твой код на серверный и клиентский. И являются по сути инструментом разделения кода на исполняемые стороны. При помощи
@SideProxy
ты можешь пометить какой класс будет выступать в качестве прокси, если мод запущен на клиенте, и какой класс, если мод запущен на сервере.
Вот пример:
@Mod(modid = "mymod", version = "1.0.0")
public class MyMod {
...
/** Класс, который сожержит код для той стороны, на которой запущен мод */
@SidedProxy(clientSide = "com.mymod.ClientProxy", serverSide = "com.mymod.CommonProxy")
public static CommonProxy proxy; // Не нужно вызывайть конструктор, т.к. Forge самостоятельно его взовет и присвоит переменной proxy соответствующее значение
...
}
Чаще всего,
ClientProxy
наследуют от
CommonProxy
(это не ванильные классы, а названия кастомных) и выглядят они примерно так:
public class CommonProxy {
public void preInit(FMLPreInitializationEvent event) {}
public void init(FMLInitializationEvent event) {}
public void postInit(FMLPostInitializationEvent event) {}
}
А потом просто вызываешь методы прокси из класса мода:
@Mod(modid = "mymod", version = "1.0.0")
public class MyMod {
@EventHandler
public void preInit(FMLPreInitializationEvent event) {
proxy.preInit(event);
}
}
НО! Нужно сказать, что некоторые люди негативно относятся к существованию ComonProxy. Мол прокси нужн для
разделения на стороны, а CommonProxy - общий прокси и для клиента, и для сервера (в случае, если ClientProxy наследуются от CommonProxy). Типа пишите общий код сразу в основном классе мода. ИМХО, не знаю насколько это верно, т.к. подход с сохданием CommonProxy широко прижился, так что выбор за тобой. Подробнее в
бест практис моддинга. Так же советую изучить
доки про прокси.
Так же отмечу что прокси удобно использоать для имплементации
IGuiHandler
'а и места для регистрации KeyBinding'ов