Apparently, the server command "/time set" breaks red-stone circuits. Note to self, stop adjusting the time!

Just so Kerm/Pizza/Elder know, Fidden was asking me for access to my plot because you guys weren't on to let him dig some more. After multiple times of telling him no, he said he should kill me. So I teleported home (and didn't get to work on the subway test ) and will await further instructions dealing with him. I don't trust the guy.

Regarding the Minecart Subway system. This is sort of the idea I was having for the stations and resupply system. There is more complications on mine, but this is the simple version. Seems someone else had similar ideas.

http://www.youtube.com/watch?v=6eNdUANJ1HI&NR=1

Beta7, we "fired" Fidden, because he was way too expensive for us. He was earning 5Kd+ just selling cobble and valuables, plus he wanted 2Kd per plot in payment.

Elder, very nice. Let's do some more mocking-up on Comic's server when we get a chance, perhaps with a larger subsegment of the railroad.

Regarding the Big Dig, Pizzabboy and I were running some calculations, and I am STRONGLY of the opinion that we should either enlist Legion's help or scale back the plans. We have about 72 plots left to dig, say from about y=50 to y=6. That's 44 layers per plot, at 16x16 = 256 blocks per layer per plot, that's 11,264 blocks per plot to be dug, or 811,008 blocks all together. Constantly using an iron pick, and accounting for the .2sec cooldown, tool switching, other ores, means an average of 1 second per block. That's 13,516 man-minutes of work, or 225.28 man-hours (9.38 continuous man-days! One and a half man-weeks!) Not to mention that would require roughly 3,168 iron picks, or 9,504 iron ingots. We could even use diamond, but we'd still need 528 diamond picks, or 1,584 diamonds. I'm thinking it's just not worth it to sink that much time into a map on a game where there's even a danger of an eventual map wipe. To that end, I recommend one of the following options, listed in order of preference (preference that is weighted by possibility and feasibility):

1. Finish digging the few plots near my plots, where we have already gotten three completely-dug plots and several partials. Level off the rest of the Dig to a reasonable level, say 9 below the ceiling, since most of it is already there. If, in the future, we need more space, we can clear plots around the dug plots to expand the area.

2. Ask Legion to either do a handful of cuboid clears, or ask him to do some /replace cobble air within the Dig cuboid.

3. Ask Legion to give us the superpickaxe for a few days

4. Ask Legion to give us infinite TNT and TNT block damage for a day

Needless to say, I don't see 2-4 happening. Even with my bot, it would be a massive amount of computer time, and we would still have to supervise, save it when it made an error, and make more picks. Not to mention the ridiculous iron cost.

Which, turned into a TNT fest.


Code:


Needless to say, in the middle of a PhotoShop save, my computer ceased all function except for calculating MineCraft explosions and my PS save for a good fifteen minutes. Around the end of that time, the clock started updating, and conversations on Skype started appearing (as I ended up signing in on my phone and the two versions sync but that's a Skype thing to a mobile application bonus).

I'm sorry, though I blame Kerm entirely :-p

--------------------

That said, I think we have a few topics we should codify, namely, using coloured wool to designate specific types of data lines, etc.

While the transmitters will help, they are vulnerable to external tampering, so for some systems, we will need hard-line connections for security reasons.

Additionally, even in our IC based circuity, it would be nice to see flow control using colours. Even if we only colour code systems, that will help immensely. Similarly, We will need to label everything, and to that end we will need a code system for descriptive, yet compact descriptions which outsiders cannot understand. (Think geekcode etc.) This is especially true of the complex calculations we will need to perform for tracking invaders. (more on that in another post)

--------

On the subject of Trains

I have come up with a proposal for the stations we will need.

0) Town Entrance Gate
1) Subterranean Canal Dock (needs rebuilt and de-greifed to Tesseract)
2) Town Hall
3) Caste: Mountain Top
4) Caste: Lakeside
5) Eastern Valley (with connection to tower railway)
6) Control Room (perhaps limited to people with clearance?)
7) Mob Spawner Collection Zone
8) Mid-West Valley (west valley, but near the bottom of the stairway)
9) Northern Reaches (Region with gate, but closer to the mountain)
a) North East Extension (as yet unclaimed)

In addition, We will need a sort of tracking system to prevent collisions between carts traveling in opposite directions on the same track. The system as I envision it only needs 2 lines running to each station, both bi-directional. 1 "main line" and 1 "supply line". The supply line will function as a 'shift register' moving carts from one sub-station (because of the chunk loading issue for large systems) in the opposite direction of the cart on the main line. Think of it as similar to this puzzle:



Each time a cart is used, it will create a closed loop between the origin and destination through the switching area, ie. the supply line for the departing station advances all its carts 1 position while the supply line for the arriving station recedes 1 position. This will allow the departing station to replace the cart from the arriving station, which will receive a new cart from the rider.

Questions? Comments? Concerns?

I was imagining a one-way loop if we were going with the loop scenario rather than the hub scenario. The supply-line scenario should work nicely, wherein each station forwards its spare iff the next station has no spare. I still think we need a larger collection of spares at some "main" station to fill in spare slots to make up for in-use carts.

The idea is that each time a trip is made there is a 1 way loop created between the supply line and the main line. Basically, the main line is 1 half of the loop and the supply line the other half. If done properly, and no carts are destroyed, then it should function just fine forever.

They are creating shift registers (of a sort) set to loop. The cart you are in progresses back and forth as needed. The only difference is that this shift register can break in the middle, and connect 2 different ends together from time to time.

I agree that if the main loop and supply loop counter-rotate, that we could make do with N carts for N stations. The only flaw I see is that when M people are riding, potentially boarding at 1 to max(N,M) stations, M carts will be in use, leaving only N-M carts available, and potentially leading 1 to M-1 people to have to wait.

Remember, we don't have to deal with the entire server deciding to come for a romp on the trains at the same time. I anticipate that the most simultaneous riders we will ever have is maybe 6, barring intentional stress testing.

Also, the supply track is envisioned to also function as storage. There will be 'mini-stations' at several points along the resupply track to give some buffer.

An excellent point in both cases. Sidebar, I should mention that Cemetech forum netiquette requires between 12 and 24 hours for a double-post; please edit your post instead.

Also, I'm conversing with Chris on Skype at the moment to discuss the 1.7 memory leak problem and try to think of a solution.

I am too

Here's a comment slash suggestion for you. It sounds simpler to have two tracks. Again, for simple reasons one rail goes left one rail goes right.

Each station will have a loop that holds carts for say, X seconds. Before it moves on, Empty or full. The line will have enough carts flowing that there will always be a cart back at the station within X seconds. Travel starting at A to the next station, B, shouldn't be longer than Y. So, X+X=Y. So, to get to C, it'd be a time of 2Y.

If you wanted to go back, just hop on the other rail.

Now, I'm not familiar with storage carts but I'm sure there are mods out there that allow to put items in single chests, break the chest and keep that chest in your inventory, and consequently and minecart. Break it when you arrive, and viola!

The problem is that a constantly moving system does not work when you have chunks going in and out of existence. You need a system which only operates when it is called to operate, because it cannot be called to operate when the chunk is unloaded. That is the reason for the complications. If you send a cart off into an unloaded chunk, it will not return until that chunk is loaded. It's not that the cart disappears, but it goes into the twilight zone until you go looking for it, then it starts moving again. Looping circuits, while ideal in theory, in practice can't work with the way the map is handled in game.

You're idea would be fine provided the entire network was loaded in memory at the same time, but that will be rare unfortunately.

I was hoping we'd be able to use minecart ejectors for delivering people to their stations to prevent possible runaway carts from clumsy exits. Although there's also the danger of runaway carts from clumsy entrances, I suppose.

Random Evocat.us News:
>> I am a mod now
>> Server is on a scratch map atm to try to track down MC 1.7.2 instabilities

Well, if we have a booster track tied to a pressure plate that one would exit onto, the cart can be launched back into the holding line on the supply side of the track. Also, that will hold the cart at least somewhat still. If that doesn't work, there are alternative methods for creating a stable exit. 2 possibilities come to mind at the moment, one more simple than the other, and probably the system we will want to use.

I'll think about it a bit before posting a description, but It might solve 2 problems at once, namely, security of the track and preventing the dislodging of the travel cart. I'll need to think about it some more though.

Also, having used the ejectors from craftbook, they are somewhat dangerous and only semi-reliable.

Excellent, glad to hear you're thinking about it. On a sad note, I was talking to Legionarius about 1.8 and his map wipe plans, and it sounds like he indeed wants to wipe the map for 1.8, since Jeb from Mojang (the tards) says that pre-1.8 maps might be corrupted by 1.8. He didn't sound enthusiastic about carrying over any chests, towns, or even Denari balances.

This is lamesauce.

And now we have received news that Towny is indeed being maintained, and converted to SQL support from flatfiles, and majorly bugfixed, so towns and/or balances might be preserved after all! Hope and pray, and lobby Legionarius if you must.

How would one preserve just the towns and not the entire map?

Each town falls wholly in chunks, so the chunks containing towns could be transplanted, especially if Legionarius force-grows the map from the same seed.