New Release! (BTW V3.10)

[FlowerChild]

Anyway, to get the thread back on track :P I tried the repeater fix on the door, worked like a charm. Guess that means more cool traps on smp :P Can't wait to try that for real

Yeah, the door code is a bit fucked up in all honesty.

What happens is this:

Redstone wire sends notifications up to two blocks away when it is powered. I guess this is to support indirect powering and such.

The door gets this notification, two blocks away and says "oh! I am receiving a notification of change in state from a redstone element!"

So it then checks if it is being powered, but since the wire is two blocks away, it's not powering it, and the door treats this as if it had just turned off and is directly neighboring it, so it closes. Obviously, this is fucked up :)

What the door really needs to do is keep track of its power state internally in its meta-data and separately from its open state. It should only be reacting to changes in redstone elements when its new power-state differs from its old one.

This is just a straight-up vanilla bug. The thing is, I think it's so obscure in regular play, that it probably hasn't even been noticed. I still haven't decided if I'm going to fix it though, as I'm not sure it warrants an additional base-class mod to do this. Then again, it's probably pretty rare that mods change the door code.

[jorgebonafe]

Now that I think about that, this could actually be a "it's not a bug, its a feature" situations.... That is kinda convenient for traps, because the unsuspecting victim won't have time to actually go through the door and escape doom somehow, because the door didn't open at all :P

[FlowerChild]

Now that I think about that, this could actually be a "it's not a bug, its a feature" situations.... That is kinda convenient for traps, because the unsuspecting victim won't have time to actually go through the door and escape doom somehow, because the door didn't open at all :P

I dunno man. It's just weird, non-intuitive, and makes people thing Buddy is buggy (hey...that rhymes) when they first try him out with one of the simplest applications that comes to mind.

The more I think about it, the more I suspect that I'll probably fix it.

[jorgebonafe]

I dunno man. It's just weird, non-intuitive, and makes people thing Buddy is buggy (hey...that rhymes) when they first try him out with one of the simplest applications that comes to mind.

The more I think about it, the more I suspect that I'll probably fix it.

I guess that's true. I had this problem with doors several times. The door closing when a redstone signal passes nearby. Even with the red power wire that happens. But when the door didn't open with buddy, I assumed it was a bug with the block, I didn't even think about that. Seems obvious its a vanilla bug in hindsight, but I guess a lot of people will also assume its a bug with the block. If for no other reason, fixing that may spare you of some headaches on the MC forums :P

[FlowerChild]

I guess that's true. I had this problem with doors several times. The door closing when a redstone signal passes nearby. Even with the red power wire that happens. But when the door didn't open with buddy, I assumed it was a bug with the block, I didn't even think about that. Seems obvious its a vanilla bug in hindsight, but I guess a lot of people will also assume its a bug with the block. If for no other reason, fixing that may spare you of some headaches on the MC forums :P

Don't feel bad man, as I must have spent about an hour trying to figure out what was wrong with Buddy's code when I first ran into that problem myself. I was using a door as the basic test-case for the block as I was working on it, and quite a stream of vulgarity was pouring out of my mouth as it kept happening no matter what I did to the code ;)

[Gilberreke]

I'm going through almost all the possible blocks that can update and everything seems fine. Even pulleys/platforms/ropes work fine :)

One minor one that might be fun if it worked, but doesn't is chests. I assume there's no hooks, so it'd require a base class edit, which is not worth it though.

One that screws up is water. Retreating water flows trigger the Buddy multiple times. I'm not sure if that's fixable from within the Buddy class, otherwise I wouldn't bother. Water mechanics are crazy enough as it is.

Appearance of a portal doesn't trigger Buddy, but reappearance of air does (I guess that's expected behavior).

Growing of vines doesn't trigger Buddy

As you can see, I tested lots of insane stuff :D. For example, I now know that a Buddy detects when a companion cube is sawed in half. A buddy even reacts correctly to cement. It pulses every time the cement goes to the next stage.

Unless there's more of these stray updates from several blocks away, it seems Buddy is as stable as can be. I expect the block to be a little wonky with other mods though, not all authors properly use block updates when necessary and when not necessary.

[FlowerChild]

Cool stuff man! Thanks for all that info :)

On the chest, do you mean it doesn't trigger on open/close, or on item removal/place?

The vine thing in particular I find strange. I'll have to take a look at that as it seems very odd that they wouldn't be notifying neighbors when they grow into new blocks.

[Gilberreke]

On the chest, do you mean it doesn't trigger on open/close, or on item removal/place?

Open/close. I guess that's expected behavior, there's no reason for a chest to update neighbors when it's opened, but if this were detectable, it'd open up some cool new behavior. For adventure maps, it's a fun way to trap chests for example or you could make a cool hidden door that is opened when you open/close a chest.

Like I mentioned though, most of these would require base class edits and on top of that, if those kinds of things started sending block updates, it might cause performance issues down the line, break people's set-ups where pistons are close to chests, etc.

[FlowerChild]

Like I mentioned though, most of these would require base class edits and on top of that, if those kinds of things started sending block updates, it might cause performance issues down the line, break people's set-ups where pistons are close to chests, etc.

Neighbor block change notifications are really not that expensive man, especially when you're talking about user-triggered events like opening or closing a chest.

It doesn't force a full update of a block or what have you (the name BUD is not exactly an accurate term for what a BUD really does), it just tells neighboring blocks that a state change has occurred and they can do whatever they want with that information.

I see no reason why a state change notification from a chest would affect piston behavior for example.

I'm pretty down on modifying base-classes for this in general, but there are some cases where I might make an exception if the functionality it generates is exceptionally cool. Not saying the chest thing would be one of them, but it might be. It certainly is super-simple to do, only requiring maybe two lines of code to send notifications at the appropriate times.

[Gilberreke]

I'm pretty down on modifying base-classes for this in general, but there are some cases where I might make an exception if the functionality it generates is exceptionally cool. Not saying the chest thing would be one of them, but it might be. It certainly is super-simple to do, only requiring maybe two lines of code to send notifications at the appropriate times.

For me, the Buddy really shines when you make creative inputs with it. Using the handcrank as a button will be something that will be a staple of my buildings from now on.

This sentiment comes from the fact that I feel there is a serious lack of interactive redstone elements at the moment. The buddy makes a number of them, like all the gates, interactive, but I feel like there's still room to explore there. If we look at a bunch of great games, we see stuff like the push-blocks in Tomb Raider and the valve wheels in Half-life (that take a while to turn), that really offer tactile interactive experiences. These might be largely aesthetic, as they act either like a button or like a lever, but I think interaction with the world is what makes a sandbox game interesting.

In the same vein, there's noteblocks and jukeboxes, but Notch didn't really explore these sound mechanics. I imagine going to a player's house, ringing a bell, which causes another block to activate based on sound, opening the door.

[Urian]

Would it be possible to have the BUDdy detect when an item enters a hopper? Potential uses would be if combined with counters (e.g. the recent coloured wool slabs and BDs) you could make a hopper smpty it's contents without it sending out a signal that would activate e.g. a booster track underneath it or keeping track of how many souls have been absorbed in a soulsand filtered hopper.

[MineUK60]

Buddy Block Not In TMI?
:~[

[Gilberreke]

Buddy Block Not In TMI?
:~[

Yes it is.

[Mintdragon]

Once again, you never fail to please. ;) One thing though: can I drag all the new class files in my jar? Or do I have to rewrite the whole thing?

[Battosay]

Yes, you can ;)
Though someone mentioned that BTW is now incompatible with SPC and ... what was the other one already ?
Nature Overhaul ? Not sure.

[FlowerChild]

Yes, you can ;)
Though someone mentioned that BTW is now incompatible with SPC and ... what was the other one already ?
Nature Overhaul ? Not sure.

Yeah, I'll have to take a look at SPC in particular as I know a huge number of people use it. On the bright side though, in the case of the above two mods, there's not much of a negative impact in overwriting this mod's class-files with theirs.

[Battosay]

What would be the negative impact ?
Growing trees not notifying Saw and Buddy ?

[FlowerChild]

What would be the negative impact ?
Growing trees not notifying Saw and Buddy ?

Yup, in the case of NO, it would be precisely that (along with trees no longer growing in front of the Detector Block as I moved that functionality in there as well to cut down on the number of base-class mods I make).

What I basically did there was create a few custom classes that duplicate the functions for tree growth. I then modified the sapling code to call these functions instead of the default Minecraft ones. This is because the default Minecraft ones are also used during world generation, and I didn't like the potential impact of sending out neighbor notifications during world-gen if I just modified the existing tree code to do that.

So yeah, it cut down on the number of base-classes I modify, but unfortunately moved my changes into a class that seems to be more commonly overwritten by other mods (the sapling).

In the case of SPC, it would be the Composite Bow not properly animating as it is drawn by the player (as well as the field of view not narrowing during the same). Again, a relatively minor impact that is strictly visual, as the bow still functions the same way regardless. Unfortunately, Mojang crammed the code for animating items in first-person into the player class instead of associating it with the items itself, as it probably should be. I'll probably try to get Forge hooks in for this in the near future, but the problem is that this will likely mean the Forge will become incompatible with SPC, which I know will piss a lot of people off.

[Shengji]

I would just like to say the Buddy Block is amazing, thanks FlowerChild!

With reference to Nature Overhauled - If you install BTW after it, 5 classes are overwritten. The functionality you lose is mossy cobblestone no longer spreads, Fire acts as Vanilla and Grass does not spread.

If you're after NO simply for the animal breeding, it actually removes a lot of redundant functionality, and all the important bits of NO still work perfectly, you can use bonemeal to spread long grass and mossy cobblestone spreading unbalances BTW anyway!

[BigShinyToys]

What would be the negative impact ?
Growing trees not notifying Saw and Buddy ?

Yup, in the case of NO, it would be precisely that (along with trees no longer growing in front of the Detector Block as I moved that functionality in there as well to cut down on the number of base-class mods I make).

What I basically did there was create a few custom classes that duplicate the functions for tree growth. I then modified the sapling code to call these functions instead of the default Minecraft ones. This is because the default Minecraft ones are also used during world generation, and I didn't like the potential impact of sending out neighbor notifications during world-gen if I just modified the existing tree code to do that.

So yeah, it cut down on the number of base-classes I modify, but unfortunately moved my changes into a class that seems to be more commonly overwritten by other mods (the sapling).

In the case of SPC, it would be the Composite Bow not properly animating as it is drawn by the player (as well as the field of view not narrowing during the same). Again, a relatively minor impact that is strictly visual, as the bow still functions the same way regardless. Unfortunately, Mojang crammed the code for animating items in first-person into the player class instead of associating it with the items itself, as it probably should be. I'll probably try to get Forge hooks in for this in the near future, but the problem is that this will likely mean the Forge will become incompatible with SPC, which I know will piss a lot of people off.

Well if you implement the new crossbreed or grafting trees maybe there are a hardier breed and capable of growing in front of BTW blocks. as opposed to the normal ones that are not . saving a base class modification and adding Better trees.

[FlowerChild]

I would just like to say the Buddy Block is amazing, thanks FlowerChild!

Thanks man! Glad you like it :)

I'm opening up more and more to the idea of modifying some vanilla blocks as well to send notifications for crucial events to it (like, I think I'm going to do that for the chest in the next release), so if anyone has any useful suggestions in that regard, feel free to post them.

[FlowerChild]

Well if you implement the new crossbreed or grafting trees maybe there are a hardier breed and capable of growing in front of BTW blocks. as opposed to the normal ones that are not . saving a base class modification and adding Better trees.

That would only come across as a bug. Trees not growing into what is only perceptible as an empty space will never feel right.

It will also get even worse once I add the Lens, as trees not being able to grow into an invisible beam of light will cause all kinds of confusion.

[Gilberreke]

It will also get even worse once I add the Lens, as trees not being able to grow into an invisible beam of light will cause all kinds of confusion.

I know I'm not supposed to discuss implementation details, so I won't discuss this, but that's a really interesting comment :)

I wonder if BC does its beams in the same way or if they have another system. I'm guessing they use another system, but one that requires tile entities.

I'm so excited about the lens coming closer, especially since I was playing around with day/night clocks earlier.

[FlowerChild]

I'm so excited about the lens coming closer, especially since I was playing around with day/night clocks earlier.

Hehe...you may have noticed that the New Age is primarily having a redstone focus right now (bondage gear aside), so yeah, the Lens might not be far off at all ;)

One of the aspects of the Age of Wood was that it provided a system that was in many ways simpler to use than redstone (mechanical power), while slowly encouraging the player to make more and more use of redstone in their contraptions, and which required a greater understanding of redstone to make use of (with elements like the Bellows). It's one of the things that people that have been asking for "finite power" in mechanical devices haven't really been getting about the concept. The mechanical system was always really intended to be simpler and more intuitive to work with than redstone to ease more people into experimenting with these kinds of contraptions in MC. I've received a number of "I never got into redstone, but mechanical power changed that!" messages over time, so I think that aspect of the mod's design has been a success so far.

So, in terms of viewing the gameplay experience as being somewhat of a guided tutorial on how to make use of various Minecraft elements, we've now reached the point in the tech tree where I think I can confidently assume that the player has a decent working understanding of redstone and can now start playing around with more advanced aspects of its usage. Moving the more "advanced" redstone blocks (like the BD and DB) into the New Age was part of this process, and now I'm getting to adding completely new functionality that further fleshes that out.

Thinking that a long-distance signal-transmission and detection device might be part of that would be a fair assumption ;)

[Gilberreke]

That's a cool way of looking at it. It also hints at a possible future system that IS finite. I've been studying IC and RP a little lately and have found that there's certainly a few different ways to tackle energy in the future that will be fun.

Redstone is basic, it's infinite, but it's Turing complete. It's the single best part of MC for lots of people, lots of possibilities.

Mechanical power is infinite, slow, but allows for complex block interactions and the two infinite systems intertwining basically allows blocks to have inputs and outputs without being awkward. We notice with the gearbox that input and output of the same power source through certain block sides is not the way to go with everything (reference the difficulty of working with energy in IC to get a good look at that)

A new source of power could be finite. This source would likely still need to be on/off binary, for users to really get it. I think complex water streams and hardcore bucket mode could be a candidate here. The user has to guide the resource around with certain rules in place.

The next step would be a source that is not only finite, but variable in strength. Electricity in certain mods works like this, in BTW's case, the obvious elephant in the room is steam. You manage pressure/power, while still having to maintain the transport.

A final step would be an energy source that is finite, variable in strength, with wildly different applications depending on strength. In IC, high voltage electricity can shock you, it's expensive to transport and provides a different gameplay from low voltage stuff that is easier to transport, but harder to calculate in terms of how many machines it covers.

In short, there's tons and tons of gameplay features still to explore that gradually let the player into the wonderful world of automation. Steve is going to have to jump through LOTS of hoops before he gets anywhere close to the moon, but we'll get there :)

I like the journey of this mod just as much as the actual playing. That's what makes this one stand out to me.