Forge MP, Bukkit and Minecraft 1.3

[Kinniken 2]

Never mind, I'll just make my mod_ class abstract and implement the MP and SP specific parts in sub-classes. As long as the class' name doesn't start with mod_ Forge won't try to load it right?

[Kinniken 2]

It can delegate to another class, and the other class can register the animations on the client and just be a dummy on the server.

 

I don't see how. The signature itself is different on client and server.

[ScottKillen 17]

It is a dummy on the server.

[Kinniken 2]

Yep, but with a different signature:

 

public void registerAnimation(Object game)

 

Anyway doesn't matter, the abstract mod class with two implementations works for me.

 

Otherwise, quick question: how do the world objects work on the server side? There's one per dimension I assume, how can I check which ones are available? On the client side, I assume that minecraft.theWorld is always the dimension the player is in, so that I do not have access to other dimensions even if they are loaded server-side?

[ScottKillen 17]

Glad it worked out. In my mods, there is no functionality whatsoever in in the mod_ classes.

 

As to the SMP Multiverse...will DimensionManager.getWorld(id) work for you?

[Kinniken 2]

Sounds like what I was looking for, thanks!

[LexManos 1620]

Ya, pretty much all the hold overs from ModLoader are the reasons why we are still incompatible with the BaseMod interface.

So, blaim Risu, not us.

 

However, @SidedDelegate would be the way to go as well as re-writing your animations to use the new ITextureFX interface, that makes your textures TexturePack change aware.

FMLTextureFX is a helper class, see how its used inside Minecraft Fire and Water animations.

 

If you are doing things properly, you only have to register your animations once at load.

[Kinniken 2]

Ya, pretty much all the hold overs from ModLoader are the reasons why we are still incompatible with the BaseMod interface.

So, blaim Risu, not us.

 

Blaming backward compatibility seems more appropriate

 

However, @SidedDelegate would be the way to go as well as re-writing your animations to use the new ITextureFX interface, that makes your textures TexturePack change aware.

FMLTextureFX is a helper class, see how its used inside Minecraft Fire and Water animations.

 

If you are doing things properly, you only have to register your animations once at load.

 

That's the case already. I'll check those APIs but latter, my plate is more than full already. I'm getting close to getting the server code to compile, but haven't even started on the interaction code...

[LexManos 1620]

Well, there is no backwards compatibility in the minecraft world, so that's not a valid thing to blame, when it comes to ML.

He has an opportunity every MC version to cleanup his interface, because he knows that modders will have to recompile anyways

 

But ya, sounds good, getting closer to compiling, once you get things going we can help you make things more efficient/cleaner.

Just so you know, registerAnimations doesn't only get called at load. It gets called every mod pack change.

[Kinniken 2]

Sure, would certainly help. Though the biggest challenges I forsee are internal to Millénaire. I'm really not decided in particular on how much data I'll send to the client. On one side giving the client a copy of the village and quest objects will require a lot of back-and-forth synching, on the other not doing it will make displaying the information GUIs client-side a real pain. Tricky.

 

Also, there are some features where I'm not even sure how they'll work in multiplayer. Quest deadlines and hired villagers in particular - in MP time never stops, even when a player is disconnected.

[LexManos 1620]

Well, for quests that have deadlines, you could freeze the player's time when they login and out. Ae, in the quest you'd store a start time and a end time. If a player logs out before that end time arrives you'd store a remaining time (start-now) and when they login reset the end to (now+remaining).

 

As for the village objects, hum, depends on exactly what type of info that is and when it changes.

[Kinniken 2]

Yeah, I guess i'll do that. I'm definitely going to have to build some kind of player profile system to store data that was game-wide until now (like quests or reputation with cultures), I'll add time passed to it.

 

Otherwise, I assume all the multiplayer minimaps are fully client-based? I'm wondering how to manage my village map. The data it depends on should really be server-only (it includes all the pathing details), but sending the picture seems wasteful.

[LexManos 1620]

Well what all do you use to generate the minimap?

Lat time I played there was a sign in the town hall that showed the map of the town? Is that what you're referring to?

That would be fairly small info, just square here, square there.

 

But i'd have to see the particular details to see what would be the best solution.

If you're not sending them updates every tick, its fairly good to just send any of the data you need.

 

So ya, depends on exactly what you need to print.

[Kinniken 2]

The map also shows what ground is water, dangerous blocks, suitable for  building on etc. But I'mm sure I can condense the info needed and then it's not so big.

 

Otherwise, quick questions:

- does MinecraftForge.registerEntity() replace ModLoader.registerEntityID() or is in addition to it?

- in MinecraftForge.registerEntity(), I assume the range is in blocks?

- what would "standard" values be for the range and the update frequency?

- why would I need or not need the velocity info?

 

Presumably whatever settings are used for mobs would be fine for my villagers.

[LexManos 1620]

Yes, you can use the local world to show that map info, if a player is close enough to see the map, he should be close enough to have the chunks sent to him right?

Use the client side chunk data to determine simple terrain stuff like that.

 

No, registerEntity does not replace registerEntityID()

It register the entity for tracking, and that information, and makes it so that you can not care and just use a random number for the ID in registerEntityID.

The ID you give to MinecraftForge.registerEntity is a mod unique id instead of a globally unique ID. So you can use 1, 2, 3 etc..

But in registerEntityID you can use Random.nextInt(35565) for all MC cares.

 

As for your other questions, you can check EntityTracker on the server to see some example values for normal mobs.

As for the velocity info.. is your mob velocity sensitive? Like Minecarts, or boats? If not you prolly don't need that info.

 

[Kinniken 2]

Ok, got it to run in Multiplayer* The pure server-side aspect seems to be working fine, I found a village and the villagers are doing their work properly. The spooking part however is that they are completely invisible client-side. I'm seeing regular errors of this kind in the log file: "Could not find entity info for 0 : 106". I assume that's due to an error in how I registered my entities? Any idea?

 

And thanks for the explanation.

 

* without any kind of support for interaction, client-side data or GUI...

[Kinniken 2]

Also, I have multiple types of packets to send. Should I declare several channels or am I expected to put a packet id as the first value in the data?

[LexManos 1620]

yes, take a look at how Forge deals with it's packets. It sets the first to a packet type, and the rest is the data.

Think of it this way, the channel name is SHARED with all other mods, so why use more then you need to?

 

And ya that error in the log is cuz you messed up the registration, show me code.

[Kinniken 2]

Not much to see, just this in mod_Millenaire.load() on client and server side:

 

MinecraftForge.registerEntity(MillVillager.class, instance,VILLAGER_ENT_ID, 80, 3, true);

 

(after the ModLoader.registerEntityID)

 

Did I miss something?

[Kinniken 2]

Also, to send packets form the server to the clients I can use methods like this:

 

((MinecraftServer)ModLoader.getMinecraftServerInstance()).configManager.sendPacketToPlayersAroundPoint(p.x, p.y, p.z, range, 0, packet);

 

What should I use client-side to send packets to the server? Should it be MinecraftForge.sendPacket? If yes, what is the NetworkManager I'm expected to pass to it?

[LexManos 1620]

Is your mods extending NetworkMod now?

That issue is usually caused when it cant find your mod, or it's not assigned an id, which happens if its not a NetworkMod.

 

As for where you get teh NetworkHandler, you get it from the IConnectionHandler events.

[Kinniken 2]

Yes:

 

public abstract class BaseMillenaireMod extends NetworkMod implements IConnectionHandler, IPacketHandler {

 

So for that NetworkHandler, I just keep a reference to it from onConnect()? Why do I need to do this on the client and not on the server?

[LexManos 1620]

Because on the client, there is no way to get the network handler for the current connection.

And on the server there are many many users, so it makes sense that they have such things built in.

 

Interesting, then im not sure why your mod wouldn't be assigned an id.

Perhaps try debugging and sticking something in the ModList packet handler to see if it's sending your a ID.

[Kinniken 2]

The weird thing is that custom packets work fine. I'll try that debugging.

[Kinniken 2]

Just an idea, could it be because I extend NetworkMod indirectly?