Development Galacticraft code overhaul?

Tesik

Member
Jul 25, 2015
30
3
8
Hello everyone, I have some notes to the structure and organization of galacticraft's code and I'd like to propose some changes to make the code more navigable, easier to maintain and just better overall, I hope you get the point.
Here they are:
1) Item/Block misplacement - Some resources, like titanium or desh and some machines, like geothermal generator, launch controller or terraformer are a part of the Galacticraft Planets mod. The machines and resources should be moved to GC Core so that they could be obtained through creative or/give.

2) Resource blocks/items could be automated by exposing them in an enumeration. This way there could be a Storage Block or Ore Block class automatically creating a blockstate for every block, automatic compressor recipes and so on. It would mean less work with new resources and would be less prone to errors. I have also considered a registry but it would only be useful if other mods wanted to add resources to galacticraft.
Here's an example of such enumeration:

public enum EnumResource {
SILICON = new EnumResource("silicon", 1, 2.0F, true, true, false, false, true, true);

private final String name;
private final int numId;
private final float hardnessMultiplier;
private final boolean hasOre;
private final boolean hasLunarOre;
private final boolean hasRaw;
private final boolean hasIngot;
private final boolean hasCompressed;
private final boolean hasBlock;
private final boolean oreDropsRaw;

EnumResource(String name, int numId, float hardnessMultiplier, boolean hasOre, boolean hasLunarOre, boolean hasRaw, boolean hasIngot, boolean hasCompressed, boolean hasBlock, boolean oreDropsRaw){
this.name = name;
/*...just initialize all the variables here*/
}
public int getId(){return this.id}
public String getName(){return this.name}
public float getHardness(){return this.hardnessMultiplier}
/*all other getters*/
}​

3) Canisters of liquids should use NBT to store a fluid stack. I will look up some more information about this and try to think up an implementation.
 

MJRLegends

Member
Mar 13, 2015
539
63
28
Im finding it hard to see the purpose of this, the Galacticraft code has the organised in the way the developers like to have it. There is no wrong way to layout any code, it could even be in one class if you wanted too.
 

Tesik

Member
Jul 25, 2015
30
3
8
Galacticraft code has the organised in the way the developers like to have it
I would rather say Galacticraft code is as organized as much effort the developers put into the organization.
There is no wrong way to layout any code
Of course, but that doesn't mean different layouts don't have different properties, such as execution speed, readability or editability.
it could even be in one class if you wanted too
With the amount of features in GC, one class (without inner classes) wouldn't really be possible as minecraft/forge is kinda relying on polymorphism in some parts.
 

MJRLegends

Member
Mar 13, 2015
539
63
28
I would rather say Galacticraft code is as organized as much effort the developers put into the organization.
Of course, but that doesn't mean different layouts don't have different properties, such as execution speed, readability or editability.

With the amount of features in GC, one class (without inner classes) wouldn't really be possible as minecraft/forge is kinda relying on polymorphism in some parts.
The point im trying to make here is its down to @micdoodle8 and @radfast to how they wanted to do it since there the ones using and coding with the layout, players of the mod dont see it so they dont have to worry
 

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
I am not in favour of structural reorganisation to existing, working, code.

Many add-ons - 10 at least, including the one made by MJRLegends - reference the existing code, so any change would also require changes by the add on authors.

In addition, structural reorganisation makes it hard to trace code through to the pre-reorganisation commits, which makes tracking down the causes of bugs harder, and it risks introducing new bugs. This problem increases because we are currently simultaneously maintaining Galacticraft code for 1.7.10, 1.8.9, 1.10.2 and 1.11.2 versions of Minecraft. Small size commits are ideal as those track through more easily to other versions. But a structural reorganisation is a massive commit.

Galacticraft is not a High School or College project and is not intended to be a text-book demonstration of how to code. Probably, some of the code does not reflect current fads or fashions in coding. Basically, it's coded (a) however the person at the time thought best (b) with adjustments for higher performance.

Most kids these days have little or no idea how to code for performance. Performance is incredibly important in any game, especially a cumbersome, clunky game in the form of Minecraft for Java with 100 mods installed. Therefore, changes to the code designed to increase performance - even if quick and dirty changes or hacks - would be much more likely to be acceptable to us, than changes designed to increase the structure, readability, or code style.

We are grateful for all help with Galacticraft, the team needs another talented and creative programmer. The best way to start is by fixing an issue or making a nice little improvement in one area of the game which interests you. Another reason to "start small" like this is that it's important to understand that every change needs to be "save-compatible" with all the existing saved games of all the current Galacticraft players. Once you take into account that changes will need to be merged to several different Minecraft versions, and might also need .lang file language updates, you will start to see that even the smallest changes involve careful work. There's no dishonour in starting small!
 
Last edited:

radfast

Member
Staff member
Apr 27, 2014
1,118
339
83
On the thing about /give, it's not clear what's not working, can you give a specific example?

By fundamental design of the mod, GalacticraftPlanets is modular with all its new blocks and entities separate from GalacticraftCore.
  • This allows someone, if they want, to use only GalacticraftCore (for Overworld, orbit and Moon) without the other planets and their features - GalacticraftCore should run correctly even if GalacticraftPlanets is not present.
  • It means that in theory a Galacticraft add-on could completely replace Mars, Venus and Asteroids with different versions.
  • It's also intended to be a demonstration of how to make an add-on. OK, there is slightly closer integration than for most add-ons - for example Launch Controller code is incorporated in the API prefab classes, even though Launch Controllers are in GalacticraftPlanets - but the overall structure of GalacticraftPlanets is as an add-on.
 
  • Like
Reactions: Ezer'Arch

Tesik

Member
Jul 25, 2015
30
3
8
To clear the ability to /give resources and machines which are currently in GCPlanets, I meant to move them into GCCore as their functionality is often not tied to the planets and they might be useful for people who don't wish to use the add-on. For example if they added a different recipe or got it through the give command or creative mode.
The next thing is that compatibility is important and if you, the developers, wish to keep the code as it is, it's only your choice. My intention had nothing to do with appearance nor fashion; it's reason was purely pragmatic. Having the code more organized and documented might give people such as myself a better opportunity to get involved in creating the mod. If I am not alone, this would speed up development of the mod greatly. That is about it. My opinion remains that it would still make some sense despite the time it would take, albeit you have made me fell some doubt against it with the compatibility issue.
About performance coding, first most significant thing is knowing at least basics of algorithm analysis as well as the difference between cache, RAM and disk and something about threads, where applicable. The other thing is not using a virtual machine with a garbage collector and if it is not a possibility as in here, you should avoid unneeded allocations.
 

Share this page