Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request / Fix: Energy Control Mod Compat #551

Open
wants to merge 3 commits into
base: MC1.12
Choose a base branch
from

Conversation

n-507
Copy link

@n-507 n-507 commented Apr 14, 2024

This pull request implemented:

  • Compatibility with IC2 Energy Control (1.12.2, 0.3.2)

It have been brought to attention that there is multiple compatibility issues with the mod Energy Control, specifically when blocks from this mod is installed and used on ships. The problem is as follows:

  • While some block, such as the alarm, can rotate due to implementing BlockDirectional, more advanced block would fail to properly rotate, as their actual direction of functionality is dictated by the property rotation and facing in its NBT. This includes the screen, and also the thermal monitor - the latter has caused explosive consequences on a ship with IC2 nuclear reactor as its main power.
  • Multi-block screen, utilizing screen extenders, can not rotate correctly. Most times, these multi block screen would become an utter mess of visual artifact, either flipped, rotated in weird angle, or completely stops rendering. In rare circumstances, it will cause a client crash.
  • All the sensor cards utilize absolute coords. This means they are nearly useless on a moving ship, unless someone is willing to re-link them after each trip.

This PR have implemented compatibility patch to fix the above issue. The patch is implemented in CompatEnergyControl.java.

  • Rotation is now properly mapped for the NBT properties. This handles both facing (the physical orientation of the block) and rotation (which dictates the 'up' direction of texts on a screen, when the screen is placed on floor or ceiling.)
  • The screen's min/max X/Y/Z are now calculated by applying the transformation first, then compare the two coordinate to determine which is the min and which is the max. This replace the primitive compatibility patch that existed in JumpBlock.java.
    • Further more, screen extender now gets their reference to the main screen, which is the coreX/Y/Z field, updated. This fix the issue where sometimes extenders can no longer be right clicked (or worse, cause a crash) after a jump.
  • All cards within (advanced) screens, holo panels, remote temperature sensor, and range trigger, will be updated after the jump to reference the same coordinates, provided that their linked block is onboard the ship.

Additionally,

  • The screen extenders are now default configured to place later, and screen itself placed the latest. This ensures that the screen will not fail due to extenders gone missing, and that any monitored device is placed either before or at the same time as the screen.

These modifications will allow Energy Control displays and devices to operate normally while onboard a ship.

n-507 added 3 commits April 13, 2024 22:27
Add handling for Energy Control mod 1.12.2, Version 0.3.2.
Compat added to CompatEnergyControl.java.
- Correctly calculates new screen min/max.
- Rotates screens, screen extenders, and temperature monitors properly through their NBT.
- Recalculates X/Y/Z reference in extenders.
- Update inserted data cards, if the referenced coordinate is onboard.

In addition, default config entries have been added to place screen extenders before main screen, to avoid main screen disconnecting from the extenders.
It also utilizes directional data in NBT, and require update to the inserted card.
This caused error spam. Furthermore, it seems to be not needed with the placement order set in the config.
@n-507
Copy link
Author

n-507 commented Apr 17, 2024

@LemADEC Please kindly review the above PR/Changes. Thanks.

@@ -373,7 +377,7 @@ public BlockPos deploy(final World worldSource, final World worldTarget, final I
nbtToDeploy.setTag("screenData", nbtScreenData);
}
}

*/
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider removing the legacy NuclearControl code altogether?


private static Class<?> classRangeTrigger; //Range Trigger

public static void register(){
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider following existing code spacing rules?

  • tabulation -> space
  • space before and after { } + - / etc.
  • first condition on the same line as if
  • then instruction always on a different line than the if
  • case aligned (not indented) vs switch statement
  • etc.

private static final byte[] horizontalRotFacing = { 1, 2, 3, 0, 5, 6, 7, 4, 8, 9, 10, 11, 12, 13, 14, 15};

@Override
public int rotate(Block block, int metadata, NBTTagCompound nbtTileEntity, ITransformation transformation) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Parameters should all be final by default, consider updating accordingly?

classRangeTrigger = Class.forName("com.zuxelus.energycontrol.blocks.RangeTrigger");
WarpDriveConfig.registerBlockTransformer("energycontrol", new CompatEnergyControl());
}catch(final ClassNotFoundException exception){
WarpDrive.logger.error(exception);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider printing the stack trace like other compatibility module do?

classRemoteThermalMonitor.isInstance(block) ||
classRangeTrigger.isInstance(block)
){
NBTTagList items = nbtTileEntity.getTagList("Items", 10);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid harcoded values, consider using the NBTType.xxx related constant instead?

itemTag.setInteger("x", result.getX());
itemTag.setInteger("y", result.getY());
itemTag.setInteger("z", result.getZ());
item.setTag("tag", itemTag);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This modify the original item, then overwrite it with a copy, consider skipping the copy and just modify in place? and by extension, no need to call itemsNew.set() and using anyChange boolean either...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants