jabelar

Yes, there are GuiScreen, GuiButton, GuiSlider, etc. classes that help provide consistency. For the placement and sizing of buttons and text, you should just copy what the vanilla classes that extend GuiScreen do. Lastly, you can simply copy the gui texture assets and just modify them in an image editing program like GIMP. Like if I want to make a container with slots placed differently, I just cut and paste the slots in an image editing program. Do you know how to find the textures and code for GUI in the referenced library for forgeSrc?

I think there are legitimate cases where code-based texture assignment makes more sense than JSON. With JSON you have to create properties to map all possibilities to textures, whereas like the OP said with code you could do something like having a large array of textures with file names that are algorithmically deterministic. Something that might take 10 lines of code could take hundreds, even thousands, lines of JSON. The ISmartBlockModel sounds interesting, gotta have a look at that.

I have a tutorial on events here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html I have some examples in the tutorial. Is making an explosion when a block is placed what you're trying to do? Is it your own custom block, or a vanilla block? If it is a custom block then you probably don't need event handling (although you certainly can use events for custom blocks if you wish).

I think maybe you can just change Minecraft.getMinecraft().gameSettings.thirdPersonView. You'd need to do this on client side only. EDIT: Actually I tried that and it sort of works, but it makes it look like the player is hovering in the air for some reason. Okay, maybe you should check out this thread here: http://www.minecraftforge.net/forum/index.php?topic=17968.0

Okay, that isn't quite the EULA but it is still a pretty clear statement of what they feel they want to own exclusively so I guess would be considered an extension of the EULA. Note they're not saying you can't render things on a player, and theoretically you could make your own cape-like stuff to render, but obviously they've chosen to block out interacting with the official cape system. Interesting...

A big question when creating a GUI is whether or not it will need a container -- needed if you have slots that you want the player to interact with. If you don't need that, then GUIs are actually very simple -- you just extend GuiScreen, open them, and have a drawScreen() function that draws what you want (colored rectangles, image textures, text, etc). The second question is whether your GUI is only informative or whether it needs to change behavior in the game. If it changes the game, you need to understand that the GUI only executes on the client side so you'll need to send a packet to the server to let it know what the player did in the GUI. What exactly do you want your GUI to do?

So you know how to place a block in the world? To "destroy" a block in Minecraft it actually gets replaced with a Blocks.air block. Do you know how to make a custom entity? Then in the entity's update method you can create the movement and also destroy blocks as you wish. Every entity has a posX, posY, posZ position that you can convert to a block position so you can then find the blocks you need to destroy. Why don't you start by making an entity that just stands there, then work on the movement and block breaking. I have a tutorial on custom entities here: http://jabelarminecraft.blogspot.com/p/creating-custom-entities.html

This all seems pretty complicated. Why not something simple like putting the list of names into a string array, and then just doing a loop through different indexes drawing the subset of strings you want based on the scrolling progress?

Well, when your mob is moving, just take the blocks ahead and set to air blocks and generate any particle effect you might want to show. The one other tip is that you'll probably have to code up the AI for the movement yourself because the built-in AI uses pathfinding that will avoid blocks .

actually he should use e.player since he's named the parameter simply e. But yes he should access the field directly instead of calling a method.

I'm not certain, but you can register your own keybindings during the init handling method of your client proxy, so I suspect that the vanilla keybindings might already be in place by that point.

That's really my point. I was worried that you're just taking a cool mod that you did and trying to re-purpose it as a "library". Someone just saying "I want to make a library" sounded suspiciously naive. However, you obviously know what it means: you're trying to build up a grounds-up codebase intended for multi-coder use from the start. I'll be quiet now...

That's how I see it, and that's why I was a bit confused with jabelar's first statement. Sorry for the confusion. Almost everything has an API of course. But I think the attitude is different when creating a library versus "just another mod with an API". When I provide a rudimentary API to mod my mods I wouldn't go as far as calling the result a library. Furthermore, even though the Minecraft decomp source are a referenced library, they are in my opinion not proper libraries because there is public access to all sorts of stuff that isn't really intended as the modding API. Maybe it is just me. To me a library has a high standard of intention behind it, not just any decomp code that you dump into your referenced libraries.

My point is more the attitude about how the code is organized and presented. a professional library of course has a well managed API. But a person could create a library where everything is exposed or something and make a mess of it.

You'll end up much better if you figure things out on your own, however there is a point where you don't even know where to start. The thing we don't want to do is discuss every line of code with you -- it's your mod and should be unique to you (also why there is never a perfect tutorial for what you want to do).

I agree that the original question isn't quite clear on what is to be achieved. It does sound like they mean just one of the players and not all players, so yeah changing the game rules is probably not the way to go. Like 61352151511 said, the best way is to record the foodTimer value at the time the effect starts and then in the player tick event use reflection to keep the foodTimer set to that amount.

The reason no one is answering is because it is obvious from your question that your coding isn't strong enough. If you were strong in coding, you'd already figure out how to put it together. Now I know people have to start somewhere, but scrolling is really just a matter of looping through a subset of a list or array of strings, which is really very basic. But here's a hint of the steps you need to figure out: 1) how to draw something on the screen at all -- look at rendering overlay and hud tutorials 2) how to draw text on the screen 3) how to create an array of text based on the player list info people above have already explained how to get. 4) figure out how to send packets from server to client to get the player list to the client. 5) figure out how to loop through a subset of the list and draw the text 6) figure out how to change the subset of the list you draw -- this is where it actually scrolls.

Look at the BlockPos class' code. The constructor can take in x, y, z and there are methods to get those back.

Are you sure you want to create a library, or maybe you just need to publish an API -- i.e. just expose those methods that you are actually interested in providing to other modders? Alternatively, if you're just keen to share useful code maybe just leave it open source and people can copy it and modify it directly if they wish. I feel like publishing a library is a bit grandiose because it implies (at least I only undertake it if it has) a very high degree of general usefulness. What is the functionality this library would provide?

CoolAlias, I checked out GotoLink's code. It is pretty much the same as what I'm doing. I create a GUI factory and call a GuiConfig, whereas he calls a custom GuiScreen. Or maybe I'm missing what you were trying to point out to me... The cool thing about the built in config gui (even if it is just a starting point) is that it automatically creates all the buttons and layout simply based on your Configuration file. So once you set it up, you just have to manage the Configuration and the GUI automatically will show those options, limit the range, allow reset to default, etc. It is pretty slick in my opinion.

Just a random FYI about your tutorial comments: the 'Mod Settings' gui in Forge was never intended to be functional - it was added by cpw purely as an example for modders to see what was possible with the config API. Many of the features (parent/child menus etc) need to be implemented by the modder, but Forge will correctly interpret them. You may want to check out GotoLink's Battlegear2 config code - it's not really 'replacing' the gui menu so much as adding yours to the list of mods with config guis using IModGuiFactory. Thanks. I think my tutorial does the right thing though. In the main menu if you select mods I implement the config gui (yes pretty much just implementing the example). However I also handle the in-game pause menu config gui and replace the example with proper configuration settings. The one piece I hadn't worked through was how to handle multiple mods having ingame config so I'll check out GotoLink's stuff to see if that what he's solving. But basically I think it is weirder to have the in-game pause menu have a GUI that only contains example stuff instead of handling it as appropriate to your mod. At very least people should disable that GUI then for their mod if they're not going to use it. I personally think that all mods should be able to be configured in-game if possible. Whether or not that uses the actual Configuration or GuiCofig classes is up to the modder, although I think it would also be cool if everyone settled on a standard where you could go in and change settings for all your mods through a common interface. Regarding Draco's comment -- I find configurations are perfectly capable of turning off things in your mod. Since the majority of stuff is in registries you can quite simply just not register blocks and stuff (the original poster is citing an example where the blocks are in one part, entities in another). Certainly there can be cases where there is more interaction but I'm not sure how splitting the JARs would make that any easier to manage.

Sure. You can also just allow the players to configure one mod the way they want. I usually have configuration options to disable certain things. It just seems like splitting a mod might be a lot of work. I know you're an experienced modder, so I'm not questioning whether you should do it, but the guy who started this thread may not be as confident.

You need to send packets to each player when they join to help them "catch up" on the information about the other clients/players. I think you can handle the PlayerJoinEvent for this, and send the packet.

Why do you want to split your mod anyway? If you want people to be able to only enable certain things in your mods, you could more easily just make it configuration options. The Minecraft Forge wiki has a tutorial on that here: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file You can even make a nice GUI so the player can change the configuration from within the game (instead of manually editing the config text file). I have a tutorial on making a config GUI here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

I'm not sure how that mod specifically does it, but I think generally these are just separate mods that are dependent and maybe have an API to better facilitate the interaction between them. The dependencies have to be arranged in the proper order. For example, if one part's code references a block from the other part's code, then you need that mod loaded first. The API exposes the methods you want for interaction, so if you had for example a vampire entity in one part and wanted to allow other parts create new vampire types, then you'd provide an API for createVampireEntity() or similar. The key point though is that those guys didn't just take an existing mod and split it -- instead they coded their mod from the start to be in multiple parts. That takes good structured approach to the mods.