quat1024 / cascade2 Goto Github PK

Right now in the "aura sending" system, aura is basically teleported from the emitter to the receiver capability.

Obviously this won't do. Thinking a more Botania-like "mana burst" will do nicely. I don't want to actually make this an entity, though, because it doesn't really need to be, right?

The plan is to tick the aura emitter capability, which keeps track of its own "aura burst" objects. Packet bullshit syncs this info to clients, who manually render it with fancy particles or something.

This is the fun part, too, because it means I can finally start implementing different aura colors, and different abilities for those colors, which is where things will really start to come together.

offtopic... wheres your scratch account?

also pm me ur scrath acount

There's basically no packets.

I want to avoid using vanilla tile entity update packets, because

• they send the whole tile's NBT, and I can do a lot better than that
• As a client, I hardly ever need to know the exact amount of aura in a node. That is only needed when my player hovers over it and a popup interface shows

Things that are in right now that need packets:

• Client needs to send a "subscribe for information" packet to the server when hovering over a node and an "unsubscribe" packet when that stops. (Enforce server-side rules on this like a basic distance check.)
• Server needs to send a packet whenever an aura burst is fired.
• Server needs to tell clients to show particles whenever a node eats an aura crystal.
• Re: that, also look into how I can fix the "mana pool problem" where the stack size doesn't update clientside

A node placed above another node will only try to balance its aura with the one below it; I want to push all the aura.

Will require a bit of refactoring of the aura emitter capability; I'm not really sure whether it's a good idea to bring the world into that section of the code, right now emitters and receivers don't have to know about the world at all. Which I kind of like, but on the other hand, the way power flows is somewhat tied into the shape of the system in the world in the first place, so.

At least maybe pass in an enumfacing or something. Oh, oh, maybe the facing could go into the constructor? Would it make sense to have five emitter capabilities, one for each non-top face?

First of all this is a nice thing that your working on here.

NOW PLEASE DONT SWEAR!

Ughh i wish I could report you but I guess your already deleted.

Any secondary acounts?

acounts is the way I spell accounts

• find out how the FUCC to use caps (pretty good guide, although focusing on entities: blop also just copy tesla)
• impl CapabilityAuraContainer to replace aura nodes scanning for TileEntityAuraNodes (edit: this turned out to be CascadeCapabilities.AURA_HOLDER)
• impl CapabilityAuraProvider for future use (ed: CascadeCapabilities.AURA_PROVIDER)
• impl CapabilityAuraAcceptor for future use (machines) (ed: CascadeCapabilities.AURA_ACCEPTOR)
• edit: impl some capability to handle connections - connections are common among everything that can handle and move aura, so it makes sense to abstract it into a cap instead of making a right mess of tileentityauranode
• Figure out aura crystals
  • Kinda-sorta-hardcode it as plain old CapabilityAuraCrystal?
  • CapabilityAuraDissolvable?
  • The problem with just making crystals some sort of general CapabilityAuraProvider, is that crystals are removed on dissolving, and you can't remove only a fraction of the aura from a crystal, either all or nothing

Wtf is going on

Throwing in stacked items seems to cause it to output tons of copies of the output item or something??? Idk I threw in 1 stack of redstone and got 6 stacks of moondust

In the refactor that removed haloblocks and haloitems (and most importantly haloblocktileentity, which handled a lot of the "magic" behind tile entities), the aura node tile entity stopped being properly joined to the block.

Still trying to work out how to properly register the tile entity in a much cleaner way w/o a HaloBlockTileEntity because I think that's a little kludgy.

Although; this is kind of a tricky thing to get right anyways. :V

Two solutions:

• Fix the problem
• Make the texture a solid color so the problem isn't noticeable

This bug was introduced in the commit which added working renderboxes, so they're probably just not being initialized correctly. (dirtyAABB was kinda hacked in.)