Bukkit

In addition, I would have a bug or at least a serious improvement suggestion for you to make: In MM, we used the very handy "prefix" for all announcement messages. Our prefix was [METRO], and with the use of colour codes, all messages coming from the metro system were golden.

I tried to do the same with the messageShortcuts in config.yml, by specifying

  m: '&6[METRO] '

and then starting all announce signs with "m". That has the disadvantage of replacing all the m's in my signs with [METRO] in chat, which obviously is not what I want.

Is there a prefix parameter somewhere i could use to color and prefix all my "metro messages" as I like? Or, otherwise, could the "m" be escaped somehow in the code handler?

Thank you for your thorough answers; while waiting for an explanation, I ended up playing with some stuff on my test track, and decided to read this conversation a few pages back. Then I learned that 1.72.0 actually had quite a few directional functionalities broken, and switched to 1.72.1 TEST2 build.

Boy did that make a difference: with the help of a few blocker signs on the routes I don't want the carts to take (we use two-way railwork with right-hand side traffic, so basically left tracks are always forbidden), the system is now able to find the right station 100% of the time! With 1.72.0, the route finding functionality seemed severely broken and failed roughly 50% of the time to find the correct station on my test network (of 9 stations). I have yet to test the [+train:west] type of blockers: I am now using [+train:r] type, with the blocker attached "to the side" of the rail, and that seems to work just fine.

When it comes to "to-blockers" vs. "from-blockers": I understand your logic, but how would you then block a certain exit from a square junction, say block the exit to the east (marked with "=") from the following:

    |    |
    |    |
----*----*====
    |    |    
    |    |
----*----*----
    |    |
    |    |

You see, you can approach the junction from all four directions. If you set your blocker somewhat (even one block) down the eastern route, then your cart has already gone there and its blocking is "too late". How would you be able to totally forbid that eastern route from being taken on that junction, so that you can arrive FROM the East, but you cannot to TO the East?

Sorry to spam you, but this one I still need to be clear about so I can really get going on implementing your plugin into our metro system: Blocker signs?

• Seems like directional blockers still use the old directionality system. I just noticed that a [train:east] blocker blocks in North-South direction and vice versa. To me, that is a symptom of the old coordinate system being used - or then, I have totally misunderstood the funcionality of a blocker. If the old system is used, then my request is you implement at least a configurable support for the current system, otherwise directional blocking becomes very cumbersome to set up. I did a lot of work in changing the way MM handled the directions, so I know this is probably not so easy though...

• Why block based on the direction the cart comes FROM? What is the use of this? In MinecartMania, the logic was to specify the directions where it was forbidden to GO, and that was perfect for us, since we use right-hand traffic in the whole metro system. So basically, in each intersection, we specified the directions where the cart was not allowed to go "against the traffic".

• With regards to the last point: how to set up blocking for the path finding process? To me it seems quite hard to do since your logic is to block based on the direction the cart is coming from. How then to tell to pathfinder algorithm that it cannot choose a certain direction to go to on a certain intersection?

I do realise these might be silly questions, but bear with me: I am coming from the MinecartMania land, and it takes some time to get used to your plugin's workings. Anyway, may I compliment you on an excellent plugin - I think it has already implemented some really superb ideas!

Thanks for the quick response, bergerkiller!

Now, to get going and trying your plugin out on one track of our metro system, I'd just need one hint more, regarding friction and powered rails...

We have been using MinecartMania for long and have optimised our powered rails such that they are only needed somewhat 200 blocks apart from each other. Now, with Train Carts, the train speed slows down so fast that there's no way the powered rails will be enough to carry the train from one station to another.

I looked upon the MM code and found that it has a "speed down factor" of 0.96289, which is roughly the same as your default 0.997 (actually, I think yours is better :) So I think it really comes down to the effect of powered rails, which in MM was to multiply the speed by 16, while now I guess we have to rely on game mechanics.

My question is, by playing aroind with your slowDownMultiplier, is it possible to increase the distance the cart can travel not slowing down between two powered rails? We'd really hate to start adding tens of powered rails in a row to our network.

EDIT: Or, of course we can set slowDown to false, that seems to work, but just in case we want to keep a bit of reality and have the powered tracks still with us, then I guess the question is still valid.

No matter, I was able to reduce the size of my setup considerably with a little tinkering of the train station idea. But: This setup for destroying empty carts, copied straight from the wiki:

https://dl.dropbox.com/u/6411310/2012-11-07_23.07.26.png

causes this NPE every time it is activated by an empty cart:

23:05:47 [SEVERE] [Train Carts] Failed to perform physics on train 'train5':
23:05:47 [SEVERE] java.lang.NullPointerException
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.signactions.SignActionSwitcher.execute(SignActionSwitcher.java:132)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.signactions.SignAction.executeAll(SignAction.java:184)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.signactions.SignAction.executeAll(SignAction.java:168)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartGroup.setActiveSign(MinecartGroup.java:158)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartMember.addActiveSign(MinecartMember.java:333)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartMember.onBlockChange(MinecartMember.java:216)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.NativeMinecartMember.postUpdate(NativeMinecartMember.java:800)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartMember.postUpdate(MinecartMember.java:126)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartGroup.doPhysics(MinecartGroup.java:819)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartGroup.doPhysics(MinecartGroup.java:783)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.MinecartMember.onTick(MinecartMember.java:107)
23:05:47 [SEVERE]       at com.bergerkiller.bukkit.tc.controller.NativeMinecartMember.j_(NativeMinecartMember.java:401)
23:05:47 [SEVERE]       at net.minecraft.server.World.entityJoinedWorld(World.java:1278)
23:05:47 [SEVERE]       at net.minecraft.server.WorldServer.entityJoinedWorld(WorldServer.java:526)
23:05:47 [SEVERE]       at net.minecraft.server.World.playerJoinedWorld(World.java:1260)
23:05:47 [SEVERE]       at net.minecraft.server.World.tickEntities(World.java:1159)
23:05:47 [SEVERE]       at net.minecraft.server.WorldServer.tickEntities(WorldServer.java:439)
23:05:47 [SEVERE]       at net.minecraft.server.MinecraftServer.r(MinecraftServer.java:566)
23:05:47 [SEVERE]       at net.minecraft.server.DedicatedServer.r(DedicatedServer.java:215)
23:05:47 [SEVERE]       at net.minecraft.server.MinecraftServer.q(MinecraftServer.java:495)
23:05:47 [SEVERE]       at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:428)
23:05:47 [SEVERE]       at net.minecraft.server.ThreadServerApplication.run(SourceFile:818)

I was able to build a working setup, but it is rather bulky, when compared to a one-block implementation of the MinecartMania...would there be any chance of reducing the size of the setup by using [!train] instead?

Bergerkiller, we are now seriously considering switching over to your plugin, since MM seems to die from the client-server sync problems, here since 1.3.x Minecraft.

One question though: our station design relies pretty heavily on a special case of a station sign/block: one which lets through a cart with a player in it, but stops an empty minecart. Then when a player hops in, the cart takes off.

Is this possible to do with Train Carts? I didn't immediately see how to do it.

Berger, The Playerexit property doesn't work on the 2nd testversion. I think Playerenter will not work also.

PS: Switchers are working fine now ;) I will reboot a new bug later, because I have to film that, and my internetspeed is crap atm *fuuuuu ziggo*

Thanks Berger, I'll update later today. Hope that the switcher and destinations are working proper now.