Flower's Dev Diary (Week of December 31st)
-
- Posts: 4
- Joined: Wed Jul 06, 2011 4:12 am
Re: Flower's Dev Diary (Week of December 31st)
FlowerChild, congrats on the update man as always!
I am really sorry to hear about everything you are going through. It must be incredibly disheartening to see something that you have put so much creative energy into forming, be turned into a 'forgery', forgive the pun. I do hope that whatever decision you make on the matter, it brings you peace in the long run.
I would like to say that if you wanted to you could beat the BWF guy to the punch. No-one knows your code better than you do. Base class edits could be fixed up with a couple (okay little exaggeration, I have no idea how many base class edits you make) of ASM class overloadings for speed in transition, later you could easily reduce this to method transformers, and modloader hooks replaced with fml hooks. No speedy task, but mostly grunt work compared to the actual thought processes that have gone in to creating such a detailed mod.
So, and here is where I will likely get a ban despite using BTW since the hibachi was first released and chatting with you on MCF, I can only assume that the decision is rooted at a very personal level. I dont deem myself wise enough to comment on that, but all I have to say is that if BTW were my creation, its longevity would be above any opinions that I had formed. You have built up an excellent core community here, which as my post count would indicate I am not a part of (being, as you are, an isolationist), but delegating responsibility within the community would reduce the number of tech support requests, that were previously liable to overwhelm you, whilst still providing you with control over the project itself. To be honest, from both a consumer and developer point of view, I fail to see the negatives to adopting what is quickly becoming the new 'standard' in modding (my opinion only from an uptake and barrier to entry point of view there). You could even oversee the project but hand over the grunt work, giving you time to work on RTH whilst keeping your promise for continued maintenance. I dunno man, just not sure if 1 year down the line, when RTH *may* still be in development, you dont look over at what could have been... wouldn't wish that on anyone.
I will understand if you feel offended by anything I have said in this post, as I understand it the matter is extremely emotional for you, however, please do not regard what I have said with complete derision, as it does come from a well meaning place.
I am really sorry to hear about everything you are going through. It must be incredibly disheartening to see something that you have put so much creative energy into forming, be turned into a 'forgery', forgive the pun. I do hope that whatever decision you make on the matter, it brings you peace in the long run.
I would like to say that if you wanted to you could beat the BWF guy to the punch. No-one knows your code better than you do. Base class edits could be fixed up with a couple (okay little exaggeration, I have no idea how many base class edits you make) of ASM class overloadings for speed in transition, later you could easily reduce this to method transformers, and modloader hooks replaced with fml hooks. No speedy task, but mostly grunt work compared to the actual thought processes that have gone in to creating such a detailed mod.
So, and here is where I will likely get a ban despite using BTW since the hibachi was first released and chatting with you on MCF, I can only assume that the decision is rooted at a very personal level. I dont deem myself wise enough to comment on that, but all I have to say is that if BTW were my creation, its longevity would be above any opinions that I had formed. You have built up an excellent core community here, which as my post count would indicate I am not a part of (being, as you are, an isolationist), but delegating responsibility within the community would reduce the number of tech support requests, that were previously liable to overwhelm you, whilst still providing you with control over the project itself. To be honest, from both a consumer and developer point of view, I fail to see the negatives to adopting what is quickly becoming the new 'standard' in modding (my opinion only from an uptake and barrier to entry point of view there). You could even oversee the project but hand over the grunt work, giving you time to work on RTH whilst keeping your promise for continued maintenance. I dunno man, just not sure if 1 year down the line, when RTH *may* still be in development, you dont look over at what could have been... wouldn't wish that on anyone.
I will understand if you feel offended by anything I have said in this post, as I understand it the matter is extremely emotional for you, however, please do not regard what I have said with complete derision, as it does come from a well meaning place.
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
Your post isn't made with consideration of all the relevant information that has been already posted about it, and thus isn't pertinent.
-
- Posts: 4
- Joined: Wed Jul 06, 2011 4:12 am
Re: Flower's Dev Diary (Week of December 31st)
Understood man, I will return to lurking and re-read everything again. As I say, I do hope it works out for you in the long run.
-
- Posts: 175
- Joined: Sun Jun 03, 2012 5:30 am
Re: Flower's Dev Diary (Week of December 31st)
I think I'll help you a bit to understand the situation, summing it up to two points:theonewithgingahair wrote:So, and here is where I will likely get a ban despite using BTW since the hibachi was first released and chatting with you on MCF, I can only assume that the decision is rooted at a very personal level. I dont deem myself wise enough to comment on that, but all I have to say is that if BTW were my creation, its longevity would be above any opinions that I had formed. You have built up an excellent core community here, which as my post count would indicate I am not a part of (being, as you are, an isolationist), but delegating responsibility within the community would reduce the number of tech support requests, that were previously liable to overwhelm you, whilst still providing you with control over the project itself. To be honest, from both a consumer and developer point of view, I fail to see the negatives to adopting what is quickly becoming the new 'standard' in modding (my opinion only from an uptake and barrier to entry point of view there). You could even oversee the project but hand over the grunt work, giving you time to work on RTH whilst keeping your promise for continued maintenance. I dunno man, just not sure if 1 year down the line, when RTH *may* still be in development, you dont look over at what could have been... wouldn't wish that on anyone.
- Forge modding way is against FC modding philosophy, as they don't have any problem in edit base class edits when and are using as much as they want while FC tries to edit just the necesary ones.
- FC is against Forge philosophy of "You can become a Forge member... or you can become a Forge member... or we will copy your mod ideas".
S.W.
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
You know what? Today I feel like working on beacons.
It may not make much sense in my overall time-line, it may be a bit of a tangent, but I think I need a fun "little" (my plans for them are actually quite extensive) task like this to put a little joy back in this whole process.
So yeah...fuck it...I'm working on beacons :)
It may not make much sense in my overall time-line, it may be a bit of a tangent, but I think I need a fun "little" (my plans for them are actually quite extensive) task like this to put a little joy back in this whole process.
So yeah...fuck it...I'm working on beacons :)
Re: Flower's Dev Diary (Week of December 31st)
Sweet, I'm looking forward to seeing what your plans are for them!FlowerChild wrote:You know what? Today I feel like working on beacons.
It may not make much sense in my overall time-line, it may be a bit of a tangent, but I think I need a fun "little" (my plans for them are actually quite extensive) task like this to put a little joy back in this whole process.
So yeah...fuck it...I'm working on beacons :)
In the meantime based on some of your past hints, I think I'd better go get my soulforged steel factory upgraded and running. :-)
Re: Flower's Dev Diary (Week of December 31st)
Funny, earlier today I was wondering whether or not you were going to do anything with beacons before moving onto RTH and now I have my answer. Knowing you, you'll actually make them worth getting. And now to go fight the wither!
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
Yeah, vanilla beacons just suck. The one I have in the center of my base has been taunting me for awhile now :)ReaperT wrote:Funny, earlier today I was wondering whether or not you were going to do anything with beacons before moving onto RTH and now I have my answer. Knowing you, you'll actually make them worth getting. And now to go fight the wither!
My design makes them more interesting on multiple levels. They'll be both more difficult to use, and way more powerful overall. I also have some very interesting SMP interactions planned for them.
Anyways, the overall plan is to turn them into true "end game" content rather than the useless and almost entirely aesthetic feature that they are now. You'll have to work your ass off to get them, but they'll be incredibly useful if you do.
- Pseudosavior
- Posts: 97
- Joined: Sun Oct 23, 2011 5:32 pm
- Location: St. Louis
Re: Flower's Dev Diary (Week of December 31st)
I know it's been said before, but I still find it funny how, for once, Mojang added something that was too weak for the effort put into it. Kind of backwards of their norm.
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
Well, I think I just figured out why Mojang made the range on beacons so small. I had been scratching my head on this one, as it just didn't make a hell of a lot of sense.
It turns out that in checking the range, they basically create a massive bounding volume and then check if players are within it. The thing is, they use the standard MC collision test methods, which means that each individual chunk within that volume is checked, a list of ALL entities in each chunk is returned, then an "instanceof" test is made against each and every one within range (and yes, that's a potentially massive number), to check if it's a player.
This is obviously retardly expensive to do, so I suspect they made the beacon range extremely limited to prevent performance from tanking.
Now, what's super funny about this is that every world maintains a list of all the players in it. Thus, you can just iterate through that list, check the range, and be done with it with a mere fraction of the above performance cost. Instead of doing all those instanceof tests on potentially hundreds of entities, you can just test the distance against what is probably a maximum of what? 32 players on a really active server?
So of course, that's the method I'll be using ;)
Here's to Mojang and a total optimization fail on the beacons, which likely was the primary cause behind the blocks being totally useless.
It turns out that in checking the range, they basically create a massive bounding volume and then check if players are within it. The thing is, they use the standard MC collision test methods, which means that each individual chunk within that volume is checked, a list of ALL entities in each chunk is returned, then an "instanceof" test is made against each and every one within range (and yes, that's a potentially massive number), to check if it's a player.
This is obviously retardly expensive to do, so I suspect they made the beacon range extremely limited to prevent performance from tanking.
Now, what's super funny about this is that every world maintains a list of all the players in it. Thus, you can just iterate through that list, check the range, and be done with it with a mere fraction of the above performance cost. Instead of doing all those instanceof tests on potentially hundreds of entities, you can just test the distance against what is probably a maximum of what? 32 players on a really active server?
So of course, that's the method I'll be using ;)
Here's to Mojang and a total optimization fail on the beacons, which likely was the primary cause behind the blocks being totally useless.
Re: Flower's Dev Diary (Week of December 31st)
You have no idea how stoked I am you'll be buffing beacons. One of the most anticipated systems from mojang added, and they totally blew it.
But hey, if they hadn't done so bad, we probably wouldn't have gotten to see your more awesome take on it! :O
But hey, if they hadn't done so bad, we probably wouldn't have gotten to see your more awesome take on it! :O
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
And shazam...beacons with a max range of 160 blocks, that cover the full vertical extent of the world, with zero perceptible performance loss. Works exactly as I anticipated above.
Not sure how many people will recognize the full face-palm value of what I described above, and it's rare that I comment on such things in the code, but it's pretty frigging epic in this case.
Not sure how many people will recognize the full face-palm value of what I described above, and it's rare that I comment on such things in the code, but it's pretty frigging epic in this case.
- Extreme Boyheat
- Posts: 173
- Joined: Wed Aug 01, 2012 11:48 pm
Re: Flower's Dev Diary (Week of December 31st)
You'd think Mojang would have went with the simpler, less resource intensive thing in the first place. :S
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
I don't get the impression Mojang are very good at thinking in terms of optimization in general, and that the above probably didn't occur to them as a result.
Like, another minor face-palm from this code is that beacons only update every 4 seconds. This is good, to help minimize the performance cost, and is why the effect display in your inventory counts down from 8 seconds, and jumps back up to 8 if you're still within the area of effect.
BUT, they update *all* beacons on exactly the same tick, so what this means is that while the updates are periodic, since they're all happening at once, if they're actually a performance drain, then you'll get a drop in frame-rate in spikes (or lag spikes in SMP) once every 4 seconds, instead of spreading that performance hit out to be a constant but minimal effect.
So, of course this is something else I'll be fixing here. Honestly, I suspect my code just checking if players are within range is generally way faster at a range of 160 blocks than Mojang's was at a range of 40, so I doubt it's even necessary. However, I'm probably going to boost the update rate on them so that you get a more immediate feedback when you are within range or not, so I may as well perform the above optimization as well since it's trivially easy to do.
Like, another minor face-palm from this code is that beacons only update every 4 seconds. This is good, to help minimize the performance cost, and is why the effect display in your inventory counts down from 8 seconds, and jumps back up to 8 if you're still within the area of effect.
BUT, they update *all* beacons on exactly the same tick, so what this means is that while the updates are periodic, since they're all happening at once, if they're actually a performance drain, then you'll get a drop in frame-rate in spikes (or lag spikes in SMP) once every 4 seconds, instead of spreading that performance hit out to be a constant but minimal effect.
So, of course this is something else I'll be fixing here. Honestly, I suspect my code just checking if players are within range is generally way faster at a range of 160 blocks than Mojang's was at a range of 40, so I doubt it's even necessary. However, I'm probably going to boost the update rate on them so that you get a more immediate feedback when you are within range or not, so I may as well perform the above optimization as well since it's trivially easy to do.
Re: Flower's Dev Diary (Week of December 31st)
It's always nice knowing that not only will a pretty much useless feature be greatly improved upon, but that it will also increase performance. Thanks again FC for all the hard work you do!FlowerChild wrote: -snip- I may as well perform the above optimization as well since it's trivially easy to do.
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
Ah, that was satisfying.
Got most of the functionality I wanted in there for beacons today. The basic system is all setup and ready to go, and tomorrow I shall tackle the couple of "special powers" I have left that are planned for different beacon types.
Anyways, good stuff. It's working very well so far, and it's quite nice to have gotten the first real new functionality into the mod in about a month :)
Got most of the functionality I wanted in there for beacons today. The basic system is all setup and ready to go, and tomorrow I shall tackle the couple of "special powers" I have left that are planned for different beacon types.
Anyways, good stuff. It's working very well so far, and it's quite nice to have gotten the first real new functionality into the mod in about a month :)
Re: Flower's Dev Diary (Week of December 31st)
You'd think Mojang would be all about optimization considering the MC world is pure, dynamic data. That was very interesting to read actually, thanks for posting FC. Do you think they could have had any reason for doing it that way? Maybe they'll make it affect animals in the future?
- darahalian
- Posts: 578
- Joined: Mon Jul 04, 2011 9:57 pm
Re: Flower's Dev Diary (Week of December 31st)
This is really exciting to hear! I can't wait to see everything you've done to the beacons. And I'm glad you've finally been able to have some fun with the mod and its development after all the crap that's been going on. Here's to everything turning out better than expected.FlowerChild wrote:Ah, that was satisfying.
Got most of the functionality I wanted in there for beacons today. The basic system is all setup and ready to go, and tomorrow I shall tackle the couple of "special powers" I have left that are planned for different beacon types.
Anyways, good stuff. It's working very well so far, and it's quite nice to have gotten the first real new functionality into the mod in about a month :)
FlowerChild wrote:Remain ever vigilant against the groth menace my friends. Early detection is crucial in avoiding a full-blown groth epidemic.
Re: Flower's Dev Diary (Week of December 31st)
It feels good to see you doing the thing you like : making good content :D
Re: Flower's Dev Diary (Week of December 31st)
I'm puzzled by some choices mojang makes in the way they implement things. One would think they are not very good at engineering..
War..
War never changes.
Remember what the dormouse said
War never changes.
Remember what the dormouse said
Re: Flower's Dev Diary (Week of December 31st)
I think it just makes it more and more clear that Mojang is just a collection of friends doing fun stuff. It's not a company at all.MoRmEnGiL wrote:I'm puzzled by some choices mojang makes in the way they implement things. One would think they are not very good at engineering..
- Chomamonka
- Posts: 83
- Joined: Tue Nov 27, 2012 9:28 am
Re: Flower's Dev Diary (Week of December 31st)
hm, something I hadn't considered before. If RTH turns out to be it's own game in the end I imagine we can expect a much less performance wasting game, at least if this recent discovery is any indication of why MC is such a simple yet resource intensive game. I shouldn't need a hardcore gaming computer to play a simple block based game with rather spartan lighting effects to boot. Perhaps you should add that to your list of pros/cons in the make your own full game route. Perhaps I am exaggerating Mojang's incompetence in this matter as I don't have intimate knowledge of their code, but "food for thought" (or whatever ;])
- FlowerChild
- Site Admin
- Posts: 18753
- Joined: Mon Jul 04, 2011 7:24 pm
Re: Flower's Dev Diary (Week of December 31st)
That's easy to answer: MC is not a simple game. You just think it is based on "blocks is simple" with no real consideration of what MC is actually doing, and that more visually complex games don't operate in a fully dynamic world. In fact, visual simplicity is one of the major things that makes MC possible with modern technology.Chomamonka wrote:why MC is such a simple yet resource intensive game.
Don't mistake me criticizing a single portion of the code as a general statement about the code base. Notch did an excellent job of making this vision a reality when it had never been done before.
Re: Flower's Dev Diary (Week of December 31st)
This recent discovery is not a good indication, it is an outlier case - an example worthy of note because it is so far removed from normal. Minecrafts code is really good and it's DNA will be found in games for many years to come.Chomamonka wrote:hm, something I hadn't considered before. If RTH turns out to be it's own game in the end I imagine we can expect a much less performance wasting game, at least if this recent discovery is any indication of why MC is such a simple yet resource intensive game.
7 months, 37 different border checks and counting.
Re: Flower's Dev Diary (Week of December 31st)
A hand-shape is now permanently etched into my head. I'm suing you for the cosmetic surgery.FlowerChild wrote:And shazam...beacons with a max range of 160 blocks, that cover the full vertical extent of the world, with zero perceptible performance loss. Works exactly as I anticipated above.
Not sure how many people will recognize the full face-palm value of what I described above, and it's rare that I comment on such things in the code, but it's pretty frigging epic in this case.
(Not really)
There's only one V in my name, thanks.
<TaterBoy> I figured out why there's so much lag. We have too much iron.
<TaterBoy> I figured out why there's so much lag. We have too much iron.