Kinniken

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...

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.

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.

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.

Blaming backward compatibility seems more appropriate 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...

Sounds like what I was looking for, thanks!

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?

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

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?

But registerAnimation() has to be implemented by the mod class, so I can't do it elsewhere. At least that's how I used it in ML. Is there an other way? I have three item textures to register.

No way out? Then I need separate mod classes... Annoying. Any chance of this changing in a future release? It seems unfortunate that Forge would manage to make it 95% possible to reuse a mod class only for one thing like that to break it

Thanks. I'll look at it now in fact, if it's not too complicated I'd rather use that rather than splitting my mod class. What would be the tick types to use as equivalents to the onTickInGame() and onTickInGUI() methods? Same question for registerAnimation(). Is there an alternative that doesn't cause compile problems?

Anybody for this? If the answer is indeed that it's not possible, I'd like to know, I'll just duplicate my mod class.

Small question, the signature of onTickInGame() is different on the client and sever (one has a Minecraft parameter, the other a MinecraftServer one). Is this intended? I wanted to keep the same mod_Millenaire class for both sides but I don't see how I can do that and use the method in question.

Ah, convenient. And I see that the movement values of entities are automatically synched, in EntityTrackerEntry. However there doesn't seem to be a way to keep extra pieces of data synchronised - am I missing something? Ok... So the whole GUI interaction is emulated server-side in the container class... Let's see if I can use that. Yep, all clear now.

So what happens when I've created an entity server-side? What infos about it will be sent by the server to the client? And is there a standard way to send extra data? I guess what I don't get is why the server would need that. When the player moves a stack from his inventory to a chest for example, how is the info sent back to the server? The GUI code will update the stack on the client I assume, by what mechanism is it synched back? Hmm, I guess that might work for me as well. Bit of a hack but well... Also, just to be sure, methods like Block.blockActivated or Entity.interact are called both client- and server-side, right? Looking at the vanilla code, EntityCow for instance, I find it strange that: par1EntityPlayer.inventory.setInventorySlotContents(par1EntityPlayer.inventory.currentItem, new ItemStack(Item.bucketMilk)); is executed both client-side and server-side. Unless the client-side version is only to give immediate feedback to the player, and the server-side one is the only one that matters? So that if for some reason I changed the server-side one to give the player a lava bucket instead, the player would briefly get a milk bucket visible in his inventory due to the client code executing and a second later it would be replaced by a lava one as the server executes its own code and the player's client inventory is overwritten by the server one?

Actually, it does seem like I'll have an issue with the ForgeMP GUI setup. Based on the API's and cpw's Iron Chest mod, it seems like to have MP GUIs be handled by Forge I need to call player.openGui. However the parameters sent only work if what the GUI needs is a block coordinate. Many of my GUIs however need to have a reference to the villager the player is interacting with. I suppose I'll have to build my own system for those, using custom packets instead. Also, maybe it's a stupid question, but what is the use of having a container generated server-side for it? Does Forge take care of synching its data with the client? Otherwise I see that to keep tile entities' data synched I need to manually send updates with world.sendClientEvent. What is the equivalent for entities?

Yeah right, I can have a "mock container" with the data I want. Not terribly OO but should work. And for the button press, I'll probably end up doing what you say, with internal commands for things like accepting missions that are independent of the GUI aspect.

Ah, didn't know that. Some of my GUIs are container-based to some extent (like the trade one), but some have nothing whatsoever to do with containers. They are all subclasses of a "GuiText" class of mine, taking as input pages of text with various buttons. They are used for example for quests (display infos on the current step, allow the player to accept or refuse), to buy buildings from a village, or to influence diplomatic relations between villages. Basically I'll need a way to send the pages to the client and the button press back to the server (most of them having server-side effects). I also have some that are more or less container-based, such as the trade interface and my puja enchanting system. However in both cases I need more data than just the inventory of the container and that of the player.

Ok, will try. That's what I'm thinking of. Not ideal but the best in my case. That's a good principle, but tricky for a mod like mine that can have sub-mods written for it. There's not one "translation file", there are several for the main content and more for each potential sub-mod. In fact if I go that way I might as well do full transfer of sub-mods to the client, that way I'll solve the villager skin problem too (that any villagers added to the server that require new skins will not get displayed on the client if he doesn't have them as well). However that's best left to a future update, I should get the basic SMP working first Otherwise, do you know of any well-written MP GUI that's not container-based that I could look at?

Can it work without zipping? Would be easiest for users. I could, but having SVN inside Eclipse is convenient. Well, that's minor. That was my first idea but it has significant drawbacks. It means that any building or quest present on the server must also exist on the client. That means that I can't add any without breaking client/server compatibility, and that the server operator cannot add custom content to the server. Even if it means sending more text I think I'll have to go for server-side translations for quite a few things. In turns that means I must overhaul Minecraft's translation system, as currently on the main language and backup language are loaded at any point - server-side that won't work. Anyway, that's problems in my own code, not with Forge

Thanks, I'll check that out! And I'm not yet worrying about Bukkit support but when that comes I might like a look at that script Should be possible to integrate that with my own bash packaging scripts too. I did both yesterday. For the packages, I had actually started in my own package when I started developing Millénaire but had stopped when I realised I'd be accessing lots of protected MC variables. I don't know if anything changed in the MC code though but when moving my code yesterday I found out that ultimately there's only a dozen protected members/methods I need access too, which is few enough that a couple of utility methods in one class in the main package can handle fine. Yeah, I'll probably do something similar, maybe not with the annotations but at least with a common interface or parent class and then client and server implementations. In fact I was thinking of also having one for single player, to isolate that code - when 1.3 comes out it will probably have to be removed so might as well centralise it instead of mixing it with the client. Anyway, I haven't really looked at the Forge MP APIs yet, so far I've been focusing on splitting my code and planning how to make Millénaire multiplayer (functionally-speaking). There are aspects like missions or the language system that I designed with only one player in mind and which are a little tricky to make multiplayer. I'll surely have more questions when I get to the actual networking code. Otherwise, small not-Forge-related question - anyone know how to get Eclipse to load files from MCP/bin when launching the client from Eclipse itself? I have all my skins and textures there and when running Minecraft from Eclipse I get errors due to them being missing (I have my own Eclipse project BTW, I do not use the MCP-provided workspace). Alternatively, is there a way to store textures and skins outside /bin? That would also make it easier for Millénaire modders, that way any skin they need to add could go in the same directory as the other Millénaire files.

Thanks, that should work fine. Though using linked source folders means that I can't use SVN in those projects. I can always have separate projects for that though. Or maybe it's time to move to Git. Does eGit work with linked source directories? And is it simple to use to keep in sync two dev environments? I currently use SVN partly for backup/history but also mostly to move changes from my laptop to desktop and vice-versa as I code on both.

Ok, got them and had a look. Very clean code. I liked how you isolated the server and client specific parts so as to have the maximum amount of code being shared. That should help me work out my split. One question though, in practice how do you work on it in Eclipse and to test compilation? It looks like it would only compile and run if you put client+common in a client MCP install, and server+common in a server MCP one. Is that what you do, just moving the changes you make in common to both sides manually?

Makes no difference either way.