Jump to content

Recommended Posts

Posted

Hello, I would like some advice.. I want to add a variable to BlockAir of type Atmosphere, it's a custom class I have made. Basicly the block is going to store a bunch of gases.

 

I know I could add a substitusion alias for the air block, and make my air block be a tileentity, but that would cause serious lag issues. I know I could also created tons of different blockstates in multiple blocks, but that would take too much time.

 

Any ideas on a better way? I am really stuck...

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

I found out I can add a new BlockGas and add a TileEntity to that, and add a function for getting gases out of BlockAir..

But that could still potentially be a lag issue?

 

Any other ideas would be fantastic, but if not, I'd stick to the BlockGas idea.  :-\

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

What exactly are you using it for? It sounds like a resource hog in the making.

 

How many gases?

 

Will they be homogenized or pure block states?

I think its my java of the variables.

Posted

Okay, here's the deal:

 

I want to add a kind of atmosphere to my mod. I created a class called Atmosphere and made it store a list of the different gases. The gases are also a custom class I made, kind of like a Block. I tried storing the Atmosphere value on a per dimension basis, but I found out it was unrealistic and it didn't fit my needs.

 

I wanted to make the gases spread out for their sources, and combine with the other gases in the atmosphere. This could easily be done by adding the an Atmosphere instance in every single air block, but as there are a bunch of air blocks in the world, this will create a huge bunch of lag.

 

I then thought of another way, as explained in the post above, that would reduce the lag a bit, but still create some.

 

 

As for the amount of gases: probably at least 20 different.

 

Now the question is; do you have a better way, or is this the most efficient, best way of doing it?

 

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

Unfortunately, I don't think you can do this without severe, crippling lag. Basically what you're making is like a climate model and that is best done with massively parallel supercomputers.

 

What you have to realize is how many blocks of air there actually are. In a single chunk there is 65,536 blocks, with probably three quarters of those air blocks! If you want those blocks to be actively processed (like calculating spreading out, calculating mixing, etc.) it would be crazy. That is why Minecraft has TileEntities, because it simply can't make all blocks actively processing. (And TileEntity won't really help you because once you have enough of those it would be same performance issue).

 

I think if you really wanted to try to do this, you shouldn't do it block by block but rather much larger groups like per chunk. Then you might have a chance. Like you could have a map in your world data where the atmosphere of each chunk is stored, and you could do some simple calculations, like mixing with neighbors.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Posted

Yeah, that makes sense.

I thought about doing it chunkwise, but I was unsure how to add and modify variables in the chunck without ASM, which I'm trying to avoid.

 

Any ideas on how to do this?

 

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

Well one possibility is storing the gas in a per chunk array (like the light maps) and updating when necessary. Since the spread will hit a point that it's inert updating shouldn't be too computationally heavy.

 

Edit: to do it you'd want a Map of chunk coords containing the gas data. Listening for chunks unloading and being loaded to read and write respectively

 

The real issue is memory: either your doing a has gas_Argon flags in a bitset style set up which will utilize the least memory, or you'll have larger concentration values in nibble arrays like block meta which will chew that RAM up with 20 values per coordinate...

I think its my java of the variables.

Posted

I was planning on having the spread and gas storage, per chunkwise like jabelar suggested as that seemed to be a reasonable way to do it. I guess that would lower the memory and cpu cost.

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

Edit: to do it you'd want a Map of chunk coords containing the gas data. Listening for chunks unloading and being loaded to read and write respectively

 

How would I check if the neighbor chunk as updated it's gas value?

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

How would I check if the neighbor chunk as updated it's gas value?

Schedule updates: use a tickhandler and feed them into a list and update it's entries to try to prevent update locks. You'll have to throttle the maximum number of entries run through per tick

I think its my java of the variables.

Posted

How about associating each biome with a native gas? Then the mixing could follow the pattern for coloring grass.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Posted

How about associating each biome with a native gas? Then the mixing could follow the pattern for coloring grass.

That's a really good idea...

 

How would I check if the neighbor chunk as updated it's gas value?

Schedule updates: use a tickhandler and feed them into a list and update it's entries to try to prevent update locks. You'll have to throttle the maximum number of entries run through per tick

 

So I create a giant Map, store it in the world, and check every chunckcoord for a neighbor blockupdate every scheduled update?

Won't that cause serious lag?

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

Yes and no

So basically you hold your own map with ChunkCoordsPair as the key and your atmosphere as a value per chunk, like how normal chunks work.

 

Scheduling updates is adding chunk coords to a 'to update next tick' list so that only chunk's that need updating get updated (basically a mark dirty method). Throttling just means optimizing the update methods so they don't continually spam more update entries.

 

 

I think its my java of the variables.

Posted

Thanks for the clear answer!

 

I'll try doing this at this! This was the advice I was looking for! Thank you RANKSHANK, jabelar, and jeffryfisher.

 

Anybody else who wish to provide some advice, feel fred free. I'm sticking with RANSKSHANK's idea.

 

;)

 

EDIT:

Fixed spelling issue. :P

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Posted

Anybody else who wish to provide some advice, feel fred.

 

I'm not into that sort of thing. Not sure Fred is either. ;D

I'm great at typing.

I might be terribly wrong.. Like really, really wrong. But I'm just trying to help.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.