Hello,

 

here are my suggestions about what could be added/changed about forge:

 

Note: I could add a pull request, but i first wanted to hear what you think about these ideas.

 

- Improved Loading Screen (my Mod MinecraftLoader) and the ability for mods to render the screen using a function updateScreen(String Message), hope you know what i'm talking about

- GuiOverlayRegistry (Many mods are adding an overlay for the ingame menu, a registry for that would be very useful, also the problem of overlapping what be fixed )

- Add a more simple way to render Items 3D and 2D, maybe something like a RenderHelper2Dand3D, example of a method could be renderItemIntoGUI(ItemStack stack, int posX, int posY, int rotation, boolean useInventoryTint ...) and the same for 3D.

- a better gui, i hate the normal minecraft gui, a useful api/registry/utils would be so awesome, methods like getButtons, getTextFields or getControls would help. This should be huge and make it much more easy to add a gui in minecraft (of course this would be helpful for Containers as well).

- The Container api, should also include a better IInventory class, everyone has to copy and paste methods like decrItemStack, this could be much much more easier.

- block method "couldRecieveAnRedstoneSignal"

- add more abstract blocks like "needGroundBlock" for plants etc., "rotationBlock" could be rotated in all direction or only "laterally" (actually there are many of abstract blocks which could be added, to uniform the blocks)

- make the modders always update to the newest (recommend) forge version. You could do this by adding an update checker into the src-forge version, which stops starting minecraft if a new version is available. Of course an easy way to update the environment would be very great and i think also necessary.

 

Huge Changes (not needed, but you could think about that)

- make Block extending Item, this is now done by ItemBlock, but in my eyes not that useful

- make more things public, many important fields/methods are private, why? An example: the field worldGenerators in GameRegistry. If modders want to modify this field they can using a transformer, but why so complicated?

 

 

I think you suggested things that are impossible to be in forge. You have gui overlay event, you have gui open event,. It's not the forge's job to change such things like these.(i think)

Hello,

 

here are my suggestions about what could be added/changed about forge:

 

Note: I could add a pull request, but i first wanted to hear what you think about these ideas.

 

- Improved Loading Screen (my Mod MinecraftLoader) and the ability for mods to render the screen using a function updateScreen(String Message), hope you know what i'm talking about

- GuiOverlayRegistry (Many mods are adding an overlay for the ingame menu, a registry for that would be very useful, also the problem of overlapping what be fixed )

- Add a more simple way to render Items 3D and 2D, maybe something like a RenderHelper2Dand3D, example of a method could be renderItemIntoGUI(ItemStack stack, int posX, int posY, int rotation, boolean useInventoryTint ...) and the same for 3D.

- a better gui, i hate the normal minecraft gui, a useful api/registry/utils would be so awesome, methods like getButtons, getTextFields or getControls would help. This should be huge and make it much more easy to add a gui in minecraft (of course this would be helpful for Containers as well).

- The Container api, should also include a better IInventory class, everyone has to copy and paste methods like decrItemStack, this could be much much more easier.

- block method "couldRecieveAnRedstoneSignal"

- add more abstract blocks like "needGroundBlock" for plants etc., "rotationBlock" could be rotated in all direction or only "laterally" (actually there are many of abstract blocks which could be added, to uniform the blocks)

- make the modders always update to the newest (recommend) forge version. You could do this by adding an update checker into the src-forge version, which stops starting minecraft if a new version is available. Of course an easy way to update the environment would be very great and i think also necessary.

 

Huge Changes (not needed, but you could think about that)

- make Block extending Item, this is now done by ItemBlock, but in my eyes not that useful

- make more things public, many important fields/methods are private, why? An example: the field worldGenerators in GameRegistry. If modders want to modify this field they can using a transformer, but why so complicated?

 

- What is the point of that?

- mods can either override the current MainMenu or add to it already. The Aether devs had an API where mods can register their own MainMenu and you could choose which MainMenu you want (It's not updated, AFAIK)

- Isn't there a vanilla helper class for this already (ItemRenderer)?

- would require too much work and recoding.

- The current "Container API" is fine as it is. Also, except "copying some methods", what would be another benefit to your suggested API?

- Why do you need this?

- How about

canPlaceBlockAt

,

canPlaceBlockOn

etc.? Also how about

BlockRotatedPillar

?

- You should not prevent functionality of a workspace if there's an update. What if the update had an error? Suddenly nobody could mod anymore. Also there's also a pretty easy way to update your workspace: change the forge version in your build.gradle, run

gradlew setupDecompWorkspace

 

- Why? Also you would have to recode most of the stuff because of method clashes etc.

- You can have your own AT in your normal mod now if you want/have to. Access levels are there for a reason.

- What is the point of that?

- mods can either override the current MainMenu or add to it already. The Aether devs had an API where mods can register their own MainMenu and you could choose which MainMenu you want (It's not updated, AFAIK)

- Isn't there a vanilla helper class for this already (ItemRenderer)?

- would require too much work and recoding.

- The current "Container API" is fine as it is. Also, except "copying some methods", what would be another benefit to your suggested API?

- Why do you need this?

- How about

canPlaceBlockAt

,

canPlaceBlockOn

etc.? Also how about

BlockRotatedPillar

?

- You should not prevent functionality of a workspace if there's an update. What if the update had an error? Suddenly nobody could mod anymore. Also there's also a pretty easy way to update your workspace: change the forge version in your build.gradle, run

gradlew setupDecompWorkspace

 

- Why? Also you would have to recode most of the stuff because of method clashes etc.

- You can have your own AT in your normal mod now if you want/have to. Access levels are there for a reason.

 

- LexManos wanted to implement that (he asked for my source), also people loving the progressbar

- i'm not talking about the game menu, but the ingame menu overlays like how much power a tool have or something like that. Also a minimap would be an overlay or a tooltip and so on. I think this would be very helpful for modders and prevent overlapping.

- Here is an overview of the methods http://pastebin.com/sxXXYJGX, but there is no way to change size and rotation and there is not really a render 3d method using an ItemStack.

Here is an example for 2D http://pastebin.com/Nb9nzkuL and 3d (isn't that complex and necessary) http://pastebin.com/vnEUwyCs.

- I could add an api , if you don't have enough time for it. I already did something like that for my mod CraftingManager. Features could be:

*prompt guis,

*more and better guicontrols like (statebuttons, text fields, lists, scrollbars, etc.)

*Using a standard gui background texture, draw slots and controls on them. Modders wouldn't have to draw a new image for every gui.

*add a page view

*i think you agree me that a gui api would be very helpful

- ContainerAPI:

*Less bugs from modders,

*a really easy way to include SHIFT Click into the container,

*better InventoryPlayer support, so that not every container has to copy and paste the add slot code,

*methods like "onbuttonclicked" (button/controll has a boolean "sendtoSever"),

*"tileEntityUpdateTick" represent how often an update tileentity packet is send 0: never; 0< time in ticks (the tileentity update packet does not equal the normal update packet necessarily: Furnace would only send the current progress),

*new methods like "onSlotClicked" (example: to open a prompt), "getInteractRange()"

*better IInventory system, IIventory change to class to add basic methods. Add a new interface for tileentities IAccessInventory (or something like that) which are easy to connect with each other. Example:

public Inventory getInventory(Side){ if(side == up) return Inventory.getSlotRange(int start, int end)} <- is just an example

*support pages

-Example: Redstone alloywire, knows if it should connect or not and many other modder added redstone components.

- Uniform equal things is always useful, you could need it for something. Here is a list of all methods that are needed to use the canBlockStay method (it's in BlockBush) http://pastebin.com/Hzqh5z3A why? it should be in an abstract block needGround (yes my names are bad) and this is only one example this could be done more often.

Furnace doesn't extend BlockRotatedPillar, he has his own methods to calculate rotation.

- Only recommend and tested forge version of course, this will not be to often i think 3 times in a minecraft version. It should help finding a forge version that every mod supports. In 1.7.2 this was almost impossible.

 

- yes like i said huge changes, but may be very useful

- maybe you are right but i don't see any.

 

Thanks for taking time to read this ,

Time and work shouldn't be the problem, i will do it, if i'm sure forge will include it.

 

Honestly, I don't see the point of any of these - they are either already implemented in some away, or can be implemented easily by the individual modder.

 

If you really want to give it a try, I suggest making pull requests on the github for Forge and seeing what other people say about it. Also remember to make a different pull request for each feature, and follow the contribution guidelines.

Honestly, I don't see the point of any of these - they are either already implemented in some away, or can be implemented easily by the individual modder.

 

If you really want to give it a try, I suggest making pull requests on the github for Forge and seeing what other people say about it. Also remember to make a different pull request for each feature, and follow the contribution guidelines.

YEEEESSS, of course every modder could to this and ever modder can add his own core mod, which does all this things. BUT WHY? sorry i'm a little bit disappointed. This causes more lag more bugs and more time for the modders to update.

Forge should do these things not the modders. ARG. Sorry, but this has to be said.

 

Also i'm not really willing to to program those things and then to release they won't be added.

This causes more lag more bugs and more time for the modders to update.

Forge should do these things not the modders.

 

How does this cause more lag? Things like duplicate code don't cause lag, just make some code harder to read. Any helper class would cause just as much as a 'Forge' helper class.

 

Also, the progress bar on the main menu - In my opinion that's pure redundant. 'Improved Loading Screen'. Improved means better - and since Forge is a public library it has to be an obejctive better, as in 'faster' or 'uses less memory', not 'prettier' or 'cooler'. Some people may like it, some people may not - that's what we have mods for.

How does this cause more lag? Things like duplicate code don't cause lag, just make some code harder to read. Any helper class would cause just as much as a 'Forge' helper class.

Yes you are right, not every new library causes lag, but sometimes a forge way would improve that and what about the other two reasons?

 

Also, the progress bar on the main menu - In my opinion that's pure redundant. 'Improved Loading Screen'. Improved means better - and since Forge is a public library it has to be an obejctive better, as in 'faster' or 'uses less memory', not 'prettier' or 'cooler'. Some people may like it, some people may not - that's what we have mods for.

I know it sounds wired, but using my mod in a modpack causes minecraft to launch faster (in Windows), this is caused by the fact that a freezed window in windows is slower and please don't take it that serious, also like i said LexManos wanted to implement it.

I wanted to implement something like your loader screen because I thought it was more then just a hack.

After reviewing it, it wasn't worth implementing.

As for the others, they are either already completely possible with current hooks, not thought through, horrible names, or just horrible concepts in general.

I wanted to implement something like your loader screen because I thought it was more then just a hack.

After reviewing it, it wasn't worth implementing.

A hack?

As for the others, they are either already completely possible with current hooks, not thought through, horrible names, or just horrible concepts in general.

WOW, why this thread "Suggestions" does even exits? Hm don't know. Sorry, but i'm a little bit pissed off. If you want people help you at forge, why do you act like that? Why you don't just be happy, someone wants make a better gui api  (because the current doesn't even exits) or you could say sorry, but i don't think you are able to program something like that or i will take a look once you finished if i will implement it.

And thats why I didn't respond to you when you first posted this.

I'm not going to get into this argument.

Properly thought out suggestions and feature requests are accepted. These do not qualify.

Locking thread before this turns into a flame fest.