Replace/change/do something to make vanilla minecarts work on any of our tracks

[mariodk]

like the vanilia tracks got 3d models for them why not changing the minecart aswell: mainly have small pixel like wheels like traincraft´s trains had just a small idea :D

[AlexIIL]

I was originally just going to provide a programmatic "wrapper" around vanilla minecarts to make them recognise curved track but replacing them and adding models doesn't sound like a bad idea :)

[mariodk]

i will say your Traincraft should be split up in 2 mods: -the track part(railcraft support since im sure this will happen) so for ppl who want to have this mod but dont want many trains but only minecraft/railcraft trains & carts (only reason for i can think of they only want that is to make it as light weighted modpack as possible)

-the Trains & cart part: kinda a offcial addon from you AlexIIL that adds all the trains & carts stuff

also for the slopes of the tracks (both the big slopes & the vanilla slopes): if you can you can do like carpenters block did with rails they added so if you make a rail slope on top of capenters blocks there will come a 1/2 block under that rail(instead of nothing under it) and like every block from that mod you can give it a Block in your hand and it will get that block´s textures

again just giving ideas also wish i could help but not knowing so much to coding and modeling/texture i am decent at but never made a train model in my life + only like 2 MC like 3d models

[NitroxydeX]

@mariodk you should open an issue for this over here: https://github.com/AlexIIL/TrainCraft-Ideas/issues So that these Issue Tickets stay as clean as possible.

[ZnDevelopment]

Hello there, I was linked to your works from two kind users who talked to me about your project. As I was browsing your ideas, I stumbled across this certain one. If you'd like to have help with Vanilla/ Railcraft Minecarts running on your custom tracks, feel free to let me know; the tracks of my mod (Zora no Densha) already contain this feature, and I'd be happy to share my experiences (and perhaps some code) with you. If you'd like to have some help with something else, feel free to let me know as well, of course.

Greetings!

P.S.: In the near future you might receive a private message regarding cross-mod compatibility and some other features, if you don't mind.

[AlexIIL]

@ZnDevelopment Does your mod have curved tracks? I haven't seen any from some quick google searching but I would like to be told I'm wrong :)

My current plan is to rewrite the custom tracks to be in railcraft so that I won't be name-confilicting with Traincraft so this isn't a mod you can be compatible with.

[AlexIIL]

Oh right you have diagonal tracks. I missed that part!

[AlexIIL]

I somehow forgot to say this: yes I am interested in what you have needed to do to make vanilla minecarts work :)

[ZnDevelopment]

Okay, that's good to hear. I am not sure whether my code will work on 1.8.9, but we might give it a try, right? If you don't mind, please message me on Skype: zndevelopment

Greetings!

Edit: Also, Zora no Densha currently implements curves that transfer from one angle to another. Angles currently present are 0°, 11°, 18° and 45°.

[AlexIIL]

Thanks for the interest @ZnDevelopment , I'm currently working on a set of forge events for 1.9 that should replace your ASM and allow both mine and your curved rails to co-exist in peace and harmony (and traincraft when/if it gets ported). When I get a set of working forge event's I'll post them here so you can see how well they might fit in with your system.

[ZnDevelopment]

@AlexIIL That's great news. Being dependent on ASM isn't a nice thing, especially in the long run, so I'm glad you're dealing with Forge events. Personally, the only "hook" that I'd depend on - and that is currently implemented by ASM code - is in EntityMinecart's onUpdate, shortly after the dimension and portal code. If it'd be possible to have a ForgeEvent at that position that, when cancelled, does not execute vanilla Minecart logics, I'd be super happy. But well, we'll see how things turn out, right? ^.^

Greetings!

[AlexIIL]

@ZnDevelopment Currently (one) of my events is position here:

public void onUpdate()
{
  // Portal code
  // Is yours here? (#1)
  if (world.isRemote) {
    // Turn progress stuff
  } else {
    // Bit of motion code
    // Line 341 in forge deobfuscated decompiled 1.9 workspace
    // Or is it here-ish? (#2)
    if (canUseRail() && BlockRailBase.isRailBlock(iblockstate)) {
      this.updateRailPosition_func_180460_a(blockpos, iblockstate);

      if (iblockstate.getBlock() == Blocks.activator_rail) {
        this.onActivatorRailPass(k, l, i1, ((Boolean)iblockstate.getValue(BlockRailPowered.POWERED)).booleanValue());
      }
    } else if (!net.minecraftforge.common.alexiil.tmp.MinecartHooks.onUnknownRail(this, blockpos, iblockstate)) {
      this.moveDerailedMinecart();
    }
  }
}

Where alexiil.tmp.MinecartHooks refers to an event class that distributes the event. It currently contains the minecart, block position and the block state at the position. This works rather well for server-side movement of minecarts on custom tracks, and going from vanilla rails to custom ones.

I also have some more events for handling maximum rail speeds and rendering positions

/** Fired before moving a minecart as if it was derailed.
 * 
 * @return True to continue moving it as if it was disabled, false to abort. */
boolean onUnknownRail(EntityMinecart cart, BlockPos pos, IBlockState state);

/** 
double getRailMaxSpeed(EntityMinecart cart, BlockPos pos, IBlockState state);

/** Gets the current blockposition of the rail. Used by getRailMaxSpeed. */
BlockPos getCurrentRailPosition(EntityMinecart cart, BlockPos current);

/** @return The adjusted position that the minecart should use when rendering. */
Vec3d getMinecartAdjustedPosition(EntityMinecart cart, double x, double y, double z);

@SideOnly(Side.CLIENT)
Vec3d getMinecartAdjustedPositionForRender(EntityMinecart cart, double x, double y, double z, double offset);

I also expose the non-public method EntityMinecart.applyDrag through a helper method so that custom rails can apply drag properly, and use whatever custom drag implementation is native to a particular minecart.

[ZnDevelopment]

@AlexIIL This looks quite well! In fact, I hook into the Minecart code at position # 1, just after the portal code. Then, if the Minecart is on a ZnD track, I cancel all other code execution.

So, the code (after ASM transformers) looks roughly like this:

if (!this.worldObj.isRemote && this.worldObj instanceof WorldServer) {
        // Portal code here
}

/* ASM Code - Start */
if (TileEntityTrackBase.setPositionOnTrackWithCheck(this)) {
        return;
}

/* ASM Code - End */
if (this.worldObj.isRemote) {
           // Client-sided rotation code
}
else {
           // Server-sided code
}

However, I just realised I also hook into func_145821_a. There I check if the Minecart is on a ZnD track and, if so, simply return - cancelling out all other code. I doubt that a custom Event would be needed there, so it's fine to leave this section ASM-dependent.

Greetings!

[AlexIIL]

From my tests its been necessary to have an event called during render time to make sure the minecart renders properly. However I have hooked into it differently so it may be easier to just override all the code.

I'm confused- from the 1.7.10 code func_145821_a is only called by the code that you just returned from if your TileEntityTrackBase.setPositionOnTrackWithCheck returned true. Is that not the case, or do you do different checks in your second hook?

(also code highlighting is 4 single-quotes (`) rather than a single one) (and if you append "java" directly after first four quotes it colours it a little bit like java code)

[ZnDevelopment]

Surprisingly it is sufficient - at least out of own experience - to change client-sided rotation values and the like where necessary. So, I personally don't see the urgent need for a render event there, but it's still better to have the option in the end. Ah, sorry for the confusion. Yes, the second hook is a different check, that only checks if the vehicle is on a ZnD track. It was needed as the first hook might return false - and thus, let vanilla code execute - even though we actually are on a ZnD track. This might happen if said track was not finished building, for example.