Ah-hah, you've figured out the key to how I plan on making boosters balanced. ;-)
A lot of people assume that the Booster-Brake will act just like a glitch booster but that is not the case.
One look at your avatar and I should have known this was part of your evil plan all along.
Good stuff. Just don't make the Booster-Brake too expensive (in Iron). 1 Booster-Brake = 16 regular tracks with proposed recipe. That might be too steep, depending on how far they'll boost, of course.
Keep in mind, tracks are often set up as 2-way single-rail lines. We still need to be able to apply a large amount of boost (way over 100% speed) at our stations (and/or 2-way boosters) in order for this to be practical, even if it takes a long line of Booster-Brakes to do it.
Personally I use Powered Minecarts and boosters on the same rail line. I don't know how Powered Minecarts are going to interact with your boosters, but it will be annoying if I need to place Boosters all along the track and then the carts I am pushing with my PMC keep shooting way ahead of me.
What I'm saying is, if you are planning to take away the ability to boost carts way beyond 100% speed, like we can do now, then I think I have a problem with that.
Especially in multiplayer, where someone else might switch your booster settings somewhere, even if they just figured "Well I need full boost power or I might not make it to the next stop." Or something along those lines. If you see a booster set to 50%, you might wonder if it's supposed to be set that way.... if you see two non-variable boosters next to each other, you won't question it.
Everything in multiplayer runs the risks of getting messed with, boosters would be no exception. In my mind I just see this as another block in multiplayer.
As for the cost vs the current glitch booster system. I'd say the trade off of needing a bit of redstone vs the extra iron needed for at least 10 more tracks and a cart would be fair. That being said, I'd like to see the output from the crafting of a booster-brake piece being increased to 4 or maybe even 8.
Rollback Post to RevisionRollBack
No matter how dark the night may seem, there is always the light of hope to guide your path, you only need to allow it.
The Meaning of Life, the Universe, and Everything.
Location:
Brisbane
Join Date:
9/15/2010
Posts:
50
Minecraft:
TerrorBite
Member Details
[b]@Ehnonimus:[/b]
Thanks a lot for your detailed reply to my post. I hadn't given any thought to the amount of boosters one would require to keep a minecart going at full speed. Yes, I see your point about initial outlay of resources needed to construct such a system, and I think yours is a reasonable proposal.
To clarify some of what I said and to answer a few questions:
Quote from Ehnonimus »
To clarify, there are only four power levels for the user to choose from when setting booster power (25-50-75-100%). Technically, the "off" state is a power level of zero, but the user can't set it by right clicking the booster, it's simply activated by removing a redstone charge from the booster.
[list=][*]Booster-Brake is receiving no redstone charge (OFF) = power level 0%
[*]Booster-Brake is receiving a redstone charge (ON) = power level 25%, 50%, 75%, or 100%, depending on what the user set it to previously.[/list]
I apologise, as I misunderstood what you were saying in the first post, namely this:
Quote from Ehnonimus »
[list][*:21m9fl8j]It has five different power settings including "off". These settings are indicated by the two chevron lights. (See fig. 2)
[*:21m9fl8j]The power setting is adjusted by right clicking the track piece.[/list]
This makes it sound like there are five different options available via right-click, including an option where the booster would give zero boost whether it was powered or not. I was wondering about this as it didn't make much sense. You should probably clarify that in the first post.
In light of the above, you shouldn't need to do the following:
Quote from Ehnonimus »
Despite the clarification, I suppose I might have to still remove another level of boost to keep it under the bit-range limit.
The only things you need to store are the orientation (four settings, two bits) and the speed setting (also four settings, two bits). This puts you within the limit and is therefore doable.
[b]@Zenofire:[/b]
2. There's something I don't get about block id's and such. If note blocks have such a huge repertoire of uses why can't a Booster Brake have 5? I was wondering if you could explain that to me. (I'm not being sarcastic or critical here, I really don't get it ^^:wink.gif:
Okay, let me explain.
The Minecraft world is stored in "chunks", each 16x16 and extending from sky to bedrock. (Each used to be stored as an individual .dat file. The new .mcr save file format basically packs up to a thousand of these chunk files, representing a 32x32 chunk area, into a single .mcr file.) We are going to discuss just a single chunk, since they all work identically and are more or less independent of each other.
In the save file format for a single chunk, the terrain is represented by a long list of block IDs, each 8 bits in size, meaning a block ID can be between 0 and 255. Air is 0, smooth stone is 1, torches are 50, etc... there's a full list on the wiki. However, this isn't enough to describe the world, as some blocks have extra information associated with them.
This is what the metadata is for. Every block in the world has 4 extra bits available to store a value between 0 and 16. What this value means depends on the block type. Most blocks (air, cobble etc) don't use it, but some do, for example: torches, signs, rails and stairs use it to remember which way they are facing; wool uses it to store the color; water uses it to remember the water level at that block; leaves and logs remember if they are birch, pine or normal. Levers not only remember whether they were placed on the wall or the floor, but also whether they are on or off. Generally, if it's the same block but can be placed in a different way, or can be changed somehow, it's stored in the metadata. (Technical note: Some older blocks like furnaces actually have separate block IDs for lit and unlit, as they predate the metadata system; but this is wasteful, as there is a maximum limit (256) on how many different blocks there can be.)
This system is quite useful and fulfills the needs of most blocks. However, some blocks require additional information that cannot be stored in 4 bits. An example of this is text on signs, the contents of chests, etc. And, as you mentioned, the [url=http://www.minecraftwiki.net/wiki/Alpha_Level_Format/Chunk_File_Format#Music]pitch value of a note block[/url]. These are instead stored as a special type of extra data section called Tile Entities. (An entity is basically anything in the world that is in motion or isn't a block; Cows, pigs, minecarts, sand while it's falling, and paintings for some reason.) Unlike regular entities, Tile Entities don't actually exist in the world but instead have an x/y/z coordinate that links them to a block that they further describe. They can contain any amount of data, but require specialized code for each block type to read it from the save file (unlike metadata, which every block has and so the mechanism to read it already exists and is the same for every block).
Anyway, I hope that isn't too technical, I tried to keep it simple. The main reason for wanting to store booster data in the metadata bits instead of a tile entity is literally simple: Keeping it simple is the goal.
@Brigander:
Quote from Brigander »
You'll have to excuse my lack of understanding of Minecraft/Java programming, but what would be restricted by this bit-range limit?
See above. This 4-bit limit only applies to extra data some blocks require, such as the direction stairs face, how far wheat has grown, wool color, etc. The limit was chosen by Notch to keep the save file size as small as possible, and is not a limitation of Java.
If there's anything I've failed to address, please point it out.
List tags are malformed.
The Meaning of Life, the Universe, and Everything.
Location:
Brisbane
Join Date:
9/15/2010
Posts:
50
Minecraft:
TerrorBite
Member Details
I forgot to mention something which I think is a good idea. This proposal is getting a lot of attention, but a lot of information about it, like the FAQs and your rationales, are getting lost in the thread. I think setting up some sort of wiki would be a good idea, even if you just copy-pasted posts from this thread onto it. I suggest either Wikispaces or Google Sites depending which you prefer.
Wow, everyone's feed back is awesome. Thanks a lot!
@LarvaLounge: To be clear, carts will never be boosted over 100% speed. 100% is the maximum, no exceptions (unless Notch changes something, in which case, 100% is still the maximum. It's just faster than the old 100% maximum...if you catch my drift.) Anyway, the important thing to note is that (as far as I know) top speed is id directly dependent on momentum, but they can have different values. Specifically, speed will stop rising at a certain threshold but momentum will continue to rise. With my booster proposal, I plan on allowing this momentum to pass the speed threshold since not allowing this would cause carts to slow down way too quickly otherwise.
Disclaimer: This all might be complete BS since my understanding of how speed and momentum work could be completely skewed. In any case, I don't want speed to drop too quickly so I'll ensure that doesn't happen when the mod is programmed. Don't worry. :-)
@Brigander: Another good reason for keeping non-adjustable boosters. Also, aside from the recipe and the materials involved, the precise amount of track crafted per "craft" has not been finalized yet. I'm leaning towards four booster-brakes or full-stops per "craft" at the moment, but that may change once I get a chance to really work on the balance of things. The other thing I'm considering is how powerful I intend on making the booster. The more powerful it is, the less pieces will be made in a single "craft". I have yet to decide on this.
@TerrorBite: Thank you so much for the explanation! I have a couple years of experience coding java and java script, so I could follow your explanation easily, but coding really isn't my area of expertise and I've never had the confidence to dig around in the Mincraft code and figure things out myself. Your technical insights are really appreciated!
Regarding the organization of the OP, I will be updating the entire thing soon so a lot will be changing. I just finished sketching up draft layouts in my sketch book and I intend to start work with photoshop within the week. (If you guys want a sneak peek, I could dump some of my sketches up online on request but I have to warn you, they're still pretty damn rough.) Among other solutions for including the "extra info", I've been considering just adding links to the relevant pages on various topic pages. Alternatively, I might set up a dedicated website since I currently have some dedicated webspace available to me.
A request for help:
One snag I still haven't sorted out that maybe someone can help me out with: I don't know how to make temporary re-skinned objects for use as in-game screenshot props. I want to create some images of what the objects would look like in-game for use in the upcoming layout but I can't simply re-skin the current rail since I need both in the shot. If anyone has any suggestions, or can help in some other way, I'd really appreciate it.
@LarvaLounge: To be clear, carts will never be boosted over 100% speed. .... I plan on allowing this momentum to pass the speed threshold since not allowing this would cause carts to slow down way too quickly otherwise.
Yeah that clears it up, thanks. And no I wasn't suggesting they need to go faster than 100% speed. When I said we need to be able boost past 100% speed, I just meant into that 'reserve momentum' that they can have. It seems like your understanding of it corresponds with mine, and we are on the same wavelength there.
@Brigander: Another good reason for keeping non-adjustable boosters. Also, aside from the recipe and the materials involved, the precise amount of track crafted per "craft" has not been finalized yet. I'm leaning towards four booster-brakes or full-stops per "craft" at the moment, but that may change once I get a chance to really work on the balance of things. The other thing I'm considering is how powerful I intend on making the booster. The more powerful it is, the less pieces will be made in a single "craft". I have yet to decide on this.
A request for help:
One snag I still haven't sorted out that maybe someone can help me out with: I don't know how to make temporary re-skinned objects for use as in-game screenshot props. I want to create some images of what the objects would look like in-game for use in the upcoming layout but I can't simply re-skin the current rail since I need both in the shot. If anyone has any suggestions, or can help in some other way, I'd really appreciate it.
Well I was meaning it to be a reason to keep the adjustable boosters but if it helped you solidify something in your mind I'm glad I could help xD.
I wish I could do more to help on the coding and modeling side but I'm not a java programmer else I would give it a shot.
Rollback Post to RevisionRollBack
No matter how dark the night may seem, there is always the light of hope to guide your path, you only need to allow it.
A request for help:
One snag I still haven't sorted out that maybe someone can help me out with: I don't know how to make temporary re-skinned objects for use as in-game screenshot props. I want to create some images of what the objects would look like in-game for use in the upcoming layout but I can't simply re-skin the current rail since I need both in the shot. If anyone has any suggestions, or can help in some other way, I'd really appreciate it.
Why can't you just put the new track pieces onto a background, like stone, and then paste that new texture, at different orientations, onto (for example) the colored wool textures in the terrain.png?
Why can't you just put the new track pieces onto a background, like stone, and then paste that new texture, at different orientations, onto (for example) the colored wool textures in the terrain.png?
It seems he wants actual in game demos as it were. They don't have to work but without copying the parameters of the placement for the track it wouldn't work like he wants it to. The detector blocks would easily be represented by a wool block or something else, but the track pieces are a bit more problematic.
Edit: Meh I re-read your post more carefully and understood it a bit more. Your method could work but I'm not sure if it would fill the capacity of his request. His call.
Rollback Post to RevisionRollBack
No matter how dark the night may seem, there is always the light of hope to guide your path, you only need to allow it.
@LarvaLounge, Glad we could sort things out. :smile.gif:
@Brigander, Hey, you might not be able to help with java or programming, but your comments are still valuable contributions to the topic. You've just proven that. Thanks again.
A couple things before I head to bed:
[*:2kni7qan] I'd like to get a bit more feedback regarding the proposed update to the Detector Block Mechanics, especially if you see anything wrong with them. (Scroll to the bottom the post in the link)
[*:2kni7qan] I'm looking for assistance in making some in-game mockups/props for screen shot purposes. I have all the texture files needed, but modding knowledge. If you have any experience in this, your help would be much appreciated. (Scroll to the bottom of the post in the link for relevant info) [EDIT] LarvaLounge's suggestion might provide a suitable alternative. I'll look into it tomorrow. Thanks for the quick feedback!
[*:2kni7qan] I'd like to hear more opinions on the current variable-power booster-brake mechanic vs the old single setting booster-brake. I still haven't decided which one to go for.
[*:2kni7qan] If anyone cares to see my sketches up the upcoming layout, I'll scan and put them up. Otherwise, look forward to seeing photoshop mockups in a couple days or so.
[*:2kni7qan] Chiptunes anyone? It's called "getting stuff done" music.
[*:2kni7qan] I've just sent another email to Glitchfinder regarding his status in the project since it's been two weeks since I last heard from him. If I don't get a definite response, I'll start taking offers from other Modders/programmers who might be interested in helping Minecarts Mk.II become a reality.
[*:2kni7qan] I'd love some technical insight on this concept and whether or not it's realistically feasible in a practical programming sense. If it is, we might have a solution to replace my crappy Powered Cart GUI concept.
1. I read your 'proposed update' for the detector block. I don't see a problem, though I did like the idea that the indicator light would be facing the track. Just for aesthetic purposes, and it makes some sense that a detector would have some sort of eye toward what it was detecting. Maybe the indicator 'eyes' are on all sides, and the thing that designates where the current comes out is something else?
I read back several pages but couldn't find any explanation for what was wrong with having the output on all sides... since I don't know what exactly you are trying to do with it. What if it only outputs current to a wire directly below it? Would that fix your problem?
okay, ive read though the first page and last two pages of this thread and if things are, how i think they are (assumeing all the info i read is correct and up to date) here is my input
A) Detector Blocks: haveing only one output is just fine, but im not sure about removeing all the lights from the block, people (and by people i mean me, and possibly others) would like to be able to easily see if the block is active or not, all other redstone triggers have a clear way of identifying this, swiches are well, swiches, buttons and plates move a littlebit, torches glow or not, ect, if you remove all the indicators, it will make it harder to tell from most angles
instead, think about maybe altering one side, make a ring gold, or make one star shaped or something to indicate direction of output, and leave the rest to glow when active
this ofcorse wont matter at all when placed under a booster track as you wont see it, but if you place it to the side, chances are, you will want to look at it
side note: reguardless of which direction you put the output on, it should also output below it, because chances are you wont see the bottom, and it would be alot of work to place a block to output below otherwise (think, you go under the place you want, you place a placer block next to where you want it, you put the detector from below, then have to dig your way out to remove the placer block, much easier if it just outputs down aswell as any direction it faces)
:cool.gif: Booster-Break Tracks: i am of the personal opinion that booster tracks only really need 2 speeds, 50% power, and 100% power, chances are, thats what people will use 90% of the time by default (and even then, only 50% so that they can reverse a carts direction more easily)
so basicly, off and 50% or 100% is all you really need
now as for distance, i would suggest several options
Simplicity: 50% = 50 track distance, 100% = 100 track distance all nice round and simple, makes for easy track counting for those who like energy efficiency
Direct: 100% = however much a standard 3 track glitch booster currently does (this would make repourposing old tracks easy, however you have your boosters currently set up, easily has a direct translation to how many boosters you nee
Balanced: 50% = 64 tracks distance, aka 1 stack 100% = 128 tracks distance, 2 stacks, all nice and even
Balanced, nerfed: 50% = 32 100% = 64, self explanitory
and the last potential
50% = 8, 100% = 16 tracks , not my idea of fun (thus it doesnt get its own name)
my favorite is the first balanced, its nice and easy to calculate when makeing tracks and would leave alot of people happy without making them OP
ive said my piece, given my 2 cents
i have to say, i like your ideas quite a bit, and i look forward to building minecart stations with them once you release a working mod, ive already got ideas brewing
id help you make it if i could, but well, i suck, so i can do is watch and let you know im looking forward to seeing what you do
@LarvaLounge and kreek, Re: Detector Blocks
I think you guys are right. I'll keep the indicators and call them"eyes" or something. I guess I'll try and come up with a better way of distinguishing the output side. (Diamond shaped light perhaps? Star seems too..fancy. I'd rather keep to simple geometry) For those of you who were asking, yes, it's really important that the detector block's output is adjustable. This maintains a level of flexibility that will allow players to build much more compact systems.
The point LarvaLounge and kreek make about it being difficult to access the bottom of the block to set it as the "output" is a valid one. However, I don't think there should be a constant down output though. Instead, why not have the default orientation of the block "output down" when placed? That way, if a player needs to output to the side, or on top, they just place it, then right click to re-orient it to the preferred side.
p.s. The problem with having the DB output to all sides is that it would interfere with creation of ultra compact stations. It's hard to explain without a lot of diagrams or showing you in game.
@Flesh_Engine, Re: Powered Minecarts
I have considered dropping them from the proposal, but I think it's really important that they stay because I'm trying to make a complete solution for Minecart Gameplay. Not all players want to have to create complex booster systems to get around. For these players, I wanted to leave the option of simpler-to-operate Powered Minecarts. I believe there is a niche for them, it's just a matter of making the Powered Cart capable enough to fill that niche.
@kreek, Re: Booster-Brakes
Your two-cents are duly noted. I appreciate the input and I'll keep it in mind. :-)
I'd like to get a bit more feedback regarding the proposed update to the Detector Block Mechanics, especially if you see anything wrong with them. (Scroll to the bottom the post in the link)
Quote from Ehnonimus »
I think you guys are right. I'll keep the indicators and call them"eyes" or something. I guess I'll try and come up with a better way of distinguishing the output side. (Diamond shaped light perhaps? Star seems too..fancy. I'd rather keep to simple geometry) For those of you who were asking, yes, it's really important that the detector block's output is adjustable. This maintains a level of flexibility that will allow players to build much more compact systems.
Hey, first post! I've been itching to comment for a while now, but I felt I should chew my way through the thread first. Since then, you've done some of the stuff I wanted to agitate for, such as improving the boost amount.
Anyway, I think a good way to handle the indicator lights would be to leave the ones that are on it already -- I presume I'm right in thinking the circle is on all sides. The "output" side would be lit all the time, and when the detector block ... detects ... they would all light up while it's active. Simple, right?
But I'm concerned that having an adjustable output in the first place would run into the same objection TerrorBite had about the boosters: namely, that it requires note-block-style special programming.
Other than that, I think that 4 is a good craft number for the detector blocks. For the boosters, it's hard to say. Maybe 4 is a good number for your adjustable ones, or hell, at that point it might be simpler just to make the formula give 16 of them (just like regular track but with redstone) locked at 25% instead. It would reduce the potential problem of riders fiddling with the speed -- by accident or design -- and simplify things generally, without adding TOO much to the size of the boost-track. (Only 4 spaces to get to 100%, unlike 10 in the initial proposal.) The only objection that comes to mind is that it makes them pretty cheap on the redstone cost, but people usually have redstone coming out of their ears no matter what (or at least that's my experience) so who cares? [edit]
Oh, and one more thing: I really think that boosters ought to be on by default, instead of off. It just seems silly to go down my freeway, sticking a redstone torch under every booster. Unless that's your way of increasing the redstone cost.
Geez, I spend one day packing.... Anyway, here are the subjects I at least remember I should address.
Powered Minecarts
Should be left in. The main reason being the tech-tree format for Minecarts as a whole. Once you get red-stone, sure they'd be obsolete but that doesn't mean you should get rid of them. Once you find stone, wood tools become obsolete but they are still in the game.
Detector Blocks
1. First the design. I got ninja'd by ehnomius thinking that there should be 5 eyes and 1 diamond. I was also thinking 2 vertical lines (like a plug) or perhaps a large square (taking up about 80% of that side so its easily distinguishable from the circle)
2. Second Why would you need to place a detector block down? Answer: Well to hide my redstone of course. Counter Question: Then wouldn't you need to dig under the track anyway?
Booster- Brakes
Now for my favorite piece. Adjustable speeds was one of the things I liked best about this proposal. I would hate to see them go. But I can also see the sense of having one booster set at 25. This would craft 4 (possibly 8) and fit the purpose of the system. But that means no more 100% Booster Brake Piece so my roller coasters would be a bit limited... But that's not what the game is about nor what Minecarts are used for. So oh well.
Oh and off as default should definitely be the case. It doesn't make sense to be on without receiving power. Otherwise it'd be just like a torch.
All-in-all I wish I could go though every post again and write another page to add to this novella but my girlfriend is cutting my time short (again...) so I must be off. Next week I should be able to be more active again. Toodles yall
EDIT:
Quote from Georgeparty »
I think Feanoriths Minecarts advanced mod is far better.
Can we get a link?
Rollback Post to RevisionRollBack
-Yes he's 100% vanilla minecraft (without the cherry) legit
-No I do not plan on setting him on fire
@FinalFan,
Thanks for your input and welcome to the forums! I don't think the "always on" method for the detector block would work. It sounds pretty straight forward, but it goes against all other redstone display conventions. I think it would just look confusing. Also, I don't think adjustable directions will need special programming like note blocks since the orientation can be contained within the memory limit for regular blocks.
Quote from Georgeparty »
I think Feanoriths Minecarts advanced mod is far better.
That's nice, but you should share some reasons why if you want us to care.
[EDIT]
Quote from Zenofire »
Geez, I spend one day packing.... Anyway, here are the subjects I at least remember I should address.
-snip-
All-in-all I wish I could go though every post again and write another page to add to this novella but my girlfriend is cutting my time short (again...) so I must be off. Next week I should be able to be more active again. Toodles yall
Eh. I don't like its design. I don't like its cost. It seems sloppily put together. I think I'll stay right here thank you
Quote from Ehnonimus »
I pretty much agree with all of this.
Lol, Awesome.
I started this post with another thought in mind but I can't remember it now. XD Oh well. But as a thought just now, I told you should put liking in the OP. Finally XD
*Several hours later...* I remember now!
Quote from Ehnonimus also »
if a player needs to output to the side, or on top, they just place it, then right click to re-orient it to the preferred side.
This is what I meant by rotating earlier. I think due to programming things can't just auto reset to player's position with a right click (though I could be wrong). So if you're going to rotate use a die as example. It starts down facing 1. Then rotates to 2 then 3 da da da to 6 back to 1. But as I mentioned earlier, I don't think rotating would even be necessary.
Anyway I had forgotten to reply to that so, here ya go XD
Rollback Post to RevisionRollBack
-Yes he's 100% vanilla minecraft (without the cherry) legit
-No I do not plan on setting him on fire
@LarvaLounge and kreek, Re: Detector Blocks
I think you guys are right. I'll keep the indicators and call them"eyes" or something. I guess I'll try and come up with a better way of distinguishing the output side. (Diamond shaped light perhaps? Star seems too..fancy. I'd rather keep to simple geometry) For those of you who were asking, yes, it's really important that the detector block's output is adjustable. This maintains a level of flexibility that will allow players to build much more compact systems.
when i said star, i was really thinking of something more of a diamond shape myself something of a
- ^
< - >
- v
type shape (excuse my crappy letter art XD, the - are used just for adjustments as for some reason this forum likes to remove spaces XD)
Quote from Ehnonimus »
The point LarvaLounge and kreek make about it being difficult to access the bottom of the block to set it as the "output" is a valid one. However, I don't think there should be a constant down output though. Instead, why not have the default orientation of the block "output down" when placed? That way, if a player needs to output to the side, or on top, they just place it, then right click to re-orient it to the preferred side.
this would entirely work for me, i haddent even considered the option of having a redirect-able detector block
though i would prefer it orient itself to the way you place it first then it be redirect-able on first click
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
One look at your avatar and I should have known this was part of your evil plan all along.
Good stuff. Just don't make the Booster-Brake too expensive (in Iron). 1 Booster-Brake = 16 regular tracks with proposed recipe. That might be too steep, depending on how far they'll boost, of course.
Keep in mind, tracks are often set up as 2-way single-rail lines. We still need to be able to apply a large amount of boost (way over 100% speed) at our stations (and/or 2-way boosters) in order for this to be practical, even if it takes a long line of Booster-Brakes to do it.
Personally I use Powered Minecarts and boosters on the same rail line. I don't know how Powered Minecarts are going to interact with your boosters, but it will be annoying if I need to place Boosters all along the track and then the carts I am pushing with my PMC keep shooting way ahead of me.
What I'm saying is, if you are planning to take away the ability to boost carts way beyond 100% speed, like we can do now, then I think I have a problem with that.
Everything in multiplayer runs the risks of getting messed with, boosters would be no exception. In my mind I just see this as another block in multiplayer.
As for the cost vs the current glitch booster system. I'd say the trade off of needing a bit of redstone vs the extra iron needed for at least 10 more tracks and a cart would be fair. That being said, I'd like to see the output from the crafting of a booster-brake piece being increased to 4 or maybe even 8.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks a lot for your detailed reply to my post. I hadn't given any thought to the amount of boosters one would require to keep a minecart going at full speed. Yes, I see your point about initial outlay of resources needed to construct such a system, and I think yours is a reasonable proposal.
To clarify some of what I said and to answer a few questions:
I apologise, as I misunderstood what you were saying in the first post, namely this:
This makes it sound like there are five different options available via right-click, including an option where the booster would give zero boost whether it was powered or not. I was wondering about this as it didn't make much sense. You should probably clarify that in the first post.
In light of the above, you shouldn't need to do the following:
The only things you need to store are the orientation (four settings, two bits) and the speed setting (also four settings, two bits). This puts you within the limit and is therefore doable.
[b]@Zenofire:[/b]
Okay, let me explain.
The Minecraft world is stored in "chunks", each 16x16 and extending from sky to bedrock. (Each used to be stored as an individual .dat file. The new .mcr save file format basically packs up to a thousand of these chunk files, representing a 32x32 chunk area, into a single .mcr file.) We are going to discuss just a single chunk, since they all work identically and are more or less independent of each other.
In the save file format for a single chunk, the terrain is represented by a long list of block IDs, each 8 bits in size, meaning a block ID can be between 0 and 255. Air is 0, smooth stone is 1, torches are 50, etc... there's a full list on the wiki. However, this isn't enough to describe the world, as some blocks have extra information associated with them.
This is what the metadata is for. Every block in the world has 4 extra bits available to store a value between 0 and 16. What this value means depends on the block type. Most blocks (air, cobble etc) don't use it, but some do, for example: torches, signs, rails and stairs use it to remember which way they are facing; wool uses it to store the color; water uses it to remember the water level at that block; leaves and logs remember if they are birch, pine or normal. Levers not only remember whether they were placed on the wall or the floor, but also whether they are on or off. Generally, if it's the same block but can be placed in a different way, or can be changed somehow, it's stored in the metadata. (Technical note: Some older blocks like furnaces actually have separate block IDs for lit and unlit, as they predate the metadata system; but this is wasteful, as there is a maximum limit (256) on how many different blocks there can be.)
This system is quite useful and fulfills the needs of most blocks. However, some blocks require additional information that cannot be stored in 4 bits. An example of this is text on signs, the contents of chests, etc. And, as you mentioned, the [url=http://www.minecraftwiki.net/wiki/Alpha_Level_Format/Chunk_File_Format#Music]pitch value of a note block[/url]. These are instead stored as a special type of extra data section called Tile Entities. (An entity is basically anything in the world that is in motion or isn't a block; Cows, pigs, minecarts, sand while it's falling, and paintings for some reason.) Unlike regular entities, Tile Entities don't actually exist in the world but instead have an x/y/z coordinate that links them to a block that they further describe. They can contain any amount of data, but require specialized code for each block type to read it from the save file (unlike metadata, which every block has and so the mechanism to read it already exists and is the same for every block).
Anyway, I hope that isn't too technical, I tried to keep it simple. The main reason for wanting to store booster data in the metadata bits instead of a tile entity is literally simple: Keeping it simple is the goal.
@Brigander:
See above. This 4-bit limit only applies to extra data some blocks require, such as the direction stairs face, how far wheat has grown, wool color, etc. The limit was chosen by Notch to keep the save file size as small as possible, and is not a limitation of Java.
If there's anything I've failed to address, please point it out.
List tags are malformed.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium@LarvaLounge: To be clear, carts will never be boosted over 100% speed. 100% is the maximum, no exceptions (unless Notch changes something, in which case, 100% is still the maximum. It's just faster than the old 100% maximum...if you catch my drift.) Anyway, the important thing to note is that (as far as I know) top speed is id directly dependent on momentum, but they can have different values. Specifically, speed will stop rising at a certain threshold but momentum will continue to rise. With my booster proposal, I plan on allowing this momentum to pass the speed threshold since not allowing this would cause carts to slow down way too quickly otherwise.
Disclaimer: This all might be complete BS since my understanding of how speed and momentum work could be completely skewed. In any case, I don't want speed to drop too quickly so I'll ensure that doesn't happen when the mod is programmed. Don't worry. :-)
@Brigander: Another good reason for keeping non-adjustable boosters. Also, aside from the recipe and the materials involved, the precise amount of track crafted per "craft" has not been finalized yet. I'm leaning towards four booster-brakes or full-stops per "craft" at the moment, but that may change once I get a chance to really work on the balance of things. The other thing I'm considering is how powerful I intend on making the booster. The more powerful it is, the less pieces will be made in a single "craft". I have yet to decide on this.
@TerrorBite: Thank you so much for the explanation! I have a couple years of experience coding java and java script, so I could follow your explanation easily, but coding really isn't my area of expertise and I've never had the confidence to dig around in the Mincraft code and figure things out myself. Your technical insights are really appreciated!
Regarding the organization of the OP, I will be updating the entire thing soon so a lot will be changing. I just finished sketching up draft layouts in my sketch book and I intend to start work with photoshop within the week. (If you guys want a sneak peek, I could dump some of my sketches up online on request but I have to warn you, they're still pretty damn rough.) Among other solutions for including the "extra info", I've been considering just adding links to the relevant pages on various topic pages. Alternatively, I might set up a dedicated website since I currently have some dedicated webspace available to me.
A request for help:
One snag I still haven't sorted out that maybe someone can help me out with: I don't know how to make temporary re-skinned objects for use as in-game screenshot props. I want to create some images of what the objects would look like in-game for use in the upcoming layout but I can't simply re-skin the current rail since I need both in the shot. If anyone has any suggestions, or can help in some other way, I'd really appreciate it.
Yeah that clears it up, thanks. And no I wasn't suggesting they need to go faster than 100% speed. When I said we need to be able boost past 100% speed, I just meant into that 'reserve momentum' that they can have. It seems like your understanding of it corresponds with mine, and we are on the same wavelength there.
Well I was meaning it to be a reason to keep the adjustable boosters but if it helped you solidify something in your mind I'm glad I could help xD.
I wish I could do more to help on the coding and modeling side but I'm not a java programmer else I would give it a shot.
Why can't you just put the new track pieces onto a background, like stone, and then paste that new texture, at different orientations, onto (for example) the colored wool textures in the terrain.png?
It seems he wants actual in game demos as it were. They don't have to work but without copying the parameters of the placement for the track it wouldn't work like he wants it to. The detector blocks would easily be represented by a wool block or something else, but the track pieces are a bit more problematic.
Edit: Meh I re-read your post more carefully and understood it a bit more. Your method could work but I'm not sure if it would fill the capacity of his request. His call.
@Brigander, Hey, you might not be able to help with java or programming, but your comments are still valuable contributions to the topic. You've just proven that. Thanks again.
A couple things before I head to bed:
[*:2kni7qan] I'd like to get a bit more feedback regarding the proposed update to the Detector Block Mechanics, especially if you see anything wrong with them. (Scroll to the bottom the post in the link)
[*:2kni7qan] I'm looking for assistance in making some in-game mockups/props for screen shot purposes. I have all the texture files needed, but modding knowledge. If you have any experience in this, your help would be much appreciated. (Scroll to the bottom of the post in the link for relevant info) [EDIT] LarvaLounge's suggestion might provide a suitable alternative. I'll look into it tomorrow. Thanks for the quick feedback!
[*:2kni7qan] I'd like to hear more opinions on the current variable-power booster-brake mechanic vs the old single setting booster-brake. I still haven't decided which one to go for.
[*:2kni7qan] If anyone cares to see my sketches up the upcoming layout, I'll scan and put them up. Otherwise, look forward to seeing photoshop mockups in a couple days or so.
[*:2kni7qan] Chiptunes anyone? It's called "getting stuff done" music.
[*:2kni7qan] I've just sent another email to Glitchfinder regarding his status in the project since it's been two weeks since I last heard from him. If I don't get a definite response, I'll start taking offers from other Modders/programmers who might be interested in helping Minecarts Mk.II become a reality.
[*:2kni7qan] I'd love some technical insight on this concept and whether or not it's realistically feasible in a practical programming sense. If it is, we might have a solution to replace my crappy Powered Cart GUI concept.
I read back several pages but couldn't find any explanation for what was wrong with having the output on all sides... since I don't know what exactly you are trying to do with it. What if it only outputs current to a wire directly below it? Would that fix your problem?
Subjects 2-7 I've contributed what I can toward.
Also... that Piston Block.... is f***ing rad.
A) Detector Blocks: haveing only one output is just fine, but im not sure about removeing all the lights from the block, people (and by people i mean me, and possibly others) would like to be able to easily see if the block is active or not, all other redstone triggers have a clear way of identifying this, swiches are well, swiches, buttons and plates move a littlebit, torches glow or not, ect, if you remove all the indicators, it will make it harder to tell from most angles
instead, think about maybe altering one side, make a ring gold, or make one star shaped or something to indicate direction of output, and leave the rest to glow when active
this ofcorse wont matter at all when placed under a booster track as you wont see it, but if you place it to the side, chances are, you will want to look at it
side note: reguardless of which direction you put the output on, it should also output below it, because chances are you wont see the bottom, and it would be alot of work to place a block to output below otherwise (think, you go under the place you want, you place a placer block next to where you want it, you put the detector from below, then have to dig your way out to remove the placer block, much easier if it just outputs down aswell as any direction it faces)
:cool.gif: Booster-Break Tracks: i am of the personal opinion that booster tracks only really need 2 speeds, 50% power, and 100% power, chances are, thats what people will use 90% of the time by default (and even then, only 50% so that they can reverse a carts direction more easily)
so basicly, off and 50% or 100% is all you really need
now as for distance, i would suggest several options
Simplicity: 50% = 50 track distance, 100% = 100 track distance all nice round and simple, makes for easy track counting for those who like energy efficiency
Direct: 100% = however much a standard 3 track glitch booster currently does (this would make repourposing old tracks easy, however you have your boosters currently set up, easily has a direct translation to how many boosters you nee
Balanced: 50% = 64 tracks distance, aka 1 stack 100% = 128 tracks distance, 2 stacks, all nice and even
Balanced, nerfed: 50% = 32 100% = 64, self explanitory
and the last potential
50% = 8, 100% = 16 tracks , not my idea of fun (thus it doesnt get its own name)
my favorite is the first balanced, its nice and easy to calculate when makeing tracks and would leave alot of people happy without making them OP
ive said my piece, given my 2 cents
i have to say, i like your ideas quite a bit, and i look forward to building minecart stations with them once you release a working mod, ive already got ideas brewing
id help you make it if i could, but well, i suck, so i can do is watch and let you know im looking forward to seeing what you do
Thank you. :-)
@LarvaLounge and kreek,
Re: Detector Blocks
I think you guys are right. I'll keep the indicators and call them"eyes" or something. I guess I'll try and come up with a better way of distinguishing the output side. (Diamond shaped light perhaps? Star seems too..fancy. I'd rather keep to simple geometry) For those of you who were asking, yes, it's really important that the detector block's output is adjustable. This maintains a level of flexibility that will allow players to build much more compact systems.
The point LarvaLounge and kreek make about it being difficult to access the bottom of the block to set it as the "output" is a valid one. However, I don't think there should be a constant down output though. Instead, why not have the default orientation of the block "output down" when placed? That way, if a player needs to output to the side, or on top, they just place it, then right click to re-orient it to the preferred side.
p.s. The problem with having the DB output to all sides is that it would interfere with creation of ultra compact stations. It's hard to explain without a lot of diagrams or showing you in game.
@Flesh_Engine,
Re: Powered Minecarts
I have considered dropping them from the proposal, but I think it's really important that they stay because I'm trying to make a complete solution for Minecart Gameplay. Not all players want to have to create complex booster systems to get around. For these players, I wanted to leave the option of simpler-to-operate Powered Minecarts. I believe there is a niche for them, it's just a matter of making the Powered Cart capable enough to fill that niche.
@kreek,
Re: Booster-Brakes
Your two-cents are duly noted. I appreciate the input and I'll keep it in mind. :-)
Hey, first post! I've been itching to comment for a while now, but I felt I should chew my way through the thread first. Since then, you've done some of the stuff I wanted to agitate for, such as improving the boost amount.
Anyway, I think a good way to handle the indicator lights would be to leave the ones that are on it already -- I presume I'm right in thinking the circle is on all sides. The "output" side would be lit all the time, and when the detector block ... detects ... they would all light up while it's active. Simple, right?
But I'm concerned that having an adjustable output in the first place would run into the same objection TerrorBite had about the boosters: namely, that it requires note-block-style special programming.
Other than that, I think that 4 is a good craft number for the detector blocks. For the boosters, it's hard to say. Maybe 4 is a good number for your adjustable ones, or hell, at that point it might be simpler just to make the formula give 16 of them (just like regular track but with redstone) locked at 25% instead. It would reduce the potential problem of riders fiddling with the speed -- by accident or design -- and simplify things generally, without adding TOO much to the size of the boost-track. (Only 4 spaces to get to 100%, unlike 10 in the initial proposal.) The only objection that comes to mind is that it makes them pretty cheap on the redstone cost, but people usually have redstone coming out of their ears no matter what (or at least that's my experience) so who cares? [edit]
Oh, and one more thing: I really think that boosters ought to be on by default, instead of off. It just seems silly to go down my freeway, sticking a redstone torch under every booster. Unless that's your way of increasing the redstone cost.
Powered Minecarts
Should be left in. The main reason being the tech-tree format for Minecarts as a whole. Once you get red-stone, sure they'd be obsolete but that doesn't mean you should get rid of them. Once you find stone, wood tools become obsolete but they are still in the game.
Detector Blocks
1. First the design. I got ninja'd by ehnomius thinking that there should be 5 eyes and 1 diamond. I was also thinking 2 vertical lines (like a plug) or perhaps a large square (taking up about 80% of that side so its easily distinguishable from the circle)
2. Second Why would you need to place a detector block down? Answer: Well to hide my redstone of course. Counter Question: Then wouldn't you need to dig under the track anyway?
Booster- Brakes
Now for my favorite piece. Adjustable speeds was one of the things I liked best about this proposal. I would hate to see them go. But I can also see the sense of having one booster set at 25. This would craft 4 (possibly 8) and fit the purpose of the system. But that means no more 100% Booster Brake Piece so my roller coasters would be a bit limited... But that's not what the game is about nor what Minecarts are used for. So oh well.
Oh and off as default should definitely be the case. It doesn't make sense to be on without receiving power. Otherwise it'd be just like a torch.
All-in-all I wish I could go though every post again and write another page to add to this novella but my girlfriend is cutting my time short (again...) so I must be off. Next week I should be able to be more active again. Toodles yall
EDIT:
Can we get a link?
-No I do not plan on setting him on fire
http://www.minecraftforum.net/viewtopic.php?f=1032&t=162515
Eh, I don't care for the implementation. It works to a degree and it might appeal to some but not quite enough for my taste.
Thanks for your input and welcome to the forums! I don't think the "always on" method for the detector block would work. It sounds pretty straight forward, but it goes against all other redstone display conventions. I think it would just look confusing. Also, I don't think adjustable directions will need special programming like note blocks since the orientation can be contained within the memory limit for regular blocks.
That's nice, but you should share some reasons why if you want us to care.
[EDIT]
I pretty much agree with all of this.
Eh. I don't like its design. I don't like its cost. It seems sloppily put together. I think I'll stay right here thank you
Lol, Awesome.
I started this post with another thought in mind but I can't remember it now. XD Oh well. But as a thought just now, I told you should put liking in the OP. Finally XD
*Several hours later...* I remember now!
This is what I meant by rotating earlier. I think due to programming things can't just auto reset to player's position with a right click (though I could be wrong). So if you're going to rotate use a die as example. It starts down facing 1. Then rotates to 2 then 3 da da da to 6 back to 1. But as I mentioned earlier, I don't think rotating would even be necessary.
Anyway I had forgotten to reply to that so, here ya go XD
-No I do not plan on setting him on fire
when i said star, i was really thinking of something more of a diamond shape myself something of a
- ^
< - >
- v
type shape (excuse my crappy letter art XD, the - are used just for adjustments as for some reason this forum likes to remove spaces XD)
this would entirely work for me, i haddent even considered the option of having a redirect-able detector block
though i would prefer it orient itself to the way you place it first then it be redirect-able on first click