The Perfect Energy System

[Reika]

Ofcourse. But flexibility often come with a high tradeoff; resource consumption. I'm assuming you're going to test this extensively because sofar your power generators require a LOT more calculations than say a bunch of boilers for example. And it's just the 'heat' generator part, you also need some form of turbines (but that's hardly an issue, animations are mostly a client-side strain). Don't forget you want to be in modpack together with a lot of other mods that already take their share of CPU power to run. I would hate to see all your hard efforts be worthless because your mod got a reputation of being a resource hog.

Regarding what you're doing; it's a lot more complex than simple calculations. Counting is easy for CPU's, branching sucks for CPU's and you're doing a lot of branching. Misprediction leads to pipeline flushes. Pipeline flushes leads to the dark side.

My generators do require more calculation than many types of engines - especially the nearly-calculation-free "set the output to this (maybe with a simple condition) and then just sit there" type, but I am dubious about how much processing is really going on. These entities run almost no code - much less than something like a mob - and seeing as the game can easily handle large farms with hundreds (or even thousands) of mobs, I do not forsee that being an issue. As for the reactor code itself, even the fuel rods (the most complex) use a simple algorithm:
Test chance -> True:
Destroy neutron entity; Spawn 3 more, and set their directions to a random horizontal from ForgeDirection() (2+nextInt(4)); add heat;

Additionally, I have looked at the code from other mods' engines, and they are not as light as people seem to assume; BuildCraft engines in particular have a LOT of per-tick code.

Really, the only lag I am noticing seems to be related to (unrequested) block and lighting updates, and that is the vanilla code doing something I do not fully understand. Come to think of it, that seems to be the main overhead in RotaryCraft and ExpandedRedstone as well. (Well, RC also has somewhat heavy rendering load, from complex models).

 

[Eyamaz]

I really want to test your stuff with my jvm arguments for servers. I have them on StrayMavs server and he mucked up and had between 10k to 15k entities in one area, as well as a full running AE environment in the same place and the server never threw an exception.

Clients couldn't keep up with rendering, but, meh...

 

[Reika]

I really want to test your stuff with my jvm arguments for servers. I have them on StrayMavs server and he mucked up and had between 10k to 15k entities in one area, as well as a full running AE environment in the same place and the server never threw an exception.
Clients couldn't keep up with rendering, but, meh...

Rendering is something I cannot really design to; it is entirely dependent on computer power - and nearly entirely the GPU, at that - and as such varies enormously.

 

[Eyamaz]

Rendering is something I cannot really design to; it is entirely dependent on computer power - and nearly entirely the GPU, at that - and as such varies enormously.

This I know.

What I want to test is how well my JVM arguments hold up performance wise on a server IF a case of 10k+ neutron collisions needed to be calculated and how well they would help hold the stability of said server.

My goal, optimally, is to help players find at least a marginal bit of stability and performance while still being able to play large packs like unleashed.

At this point, I haven't had a mod that attempts to do the amount of calculations your doing (or maybe I have, and I didn't notice...) with your nuclear mod.

 

[Siro]

I really want to test your stuff with my jvm arguments for servers. I have them on StrayMavs server and he mucked up and had between 10k to 15k entities in one area, as well as a full running AE environment in the same place and the server never threw an exception.

Clients couldn't keep up with rendering, but, meh...

On a completely unrelated to the thread note, thank you so much for figuring out a robust set of jvm arguments for servers/clients. I had been testing to see if an old computer I had lying around could be used as an ftb server. While it did run, it was constant block lag and can't keep up messages. The poor thing only has 4G of ram, so I couldn't use the arguments as is and adjusted them downward a bit (halved). Runs totally smoothly now, no lag or can't keep up messages. Obviously I won't be running it with a bunch of people, but that's never what it was for anyway.

 

[King Lemming]

Rendering is something I cannot really design to; it is entirely dependent on computer power - and nearly entirely the GPU, at that - and as such varies enormously.

Actually, due to how (poorly) Minecraft is coded, you can do a LOT to speed your renders up.

TESRs fire every tick, ISBRH only have to recompute if the chunk is updated. The difference is HUGE. There's a lot of model optimization you can do as well to remove extra vertices, etc.

 

[Reika]

Actually, due to how (poorly) Minecraft is coded, you can do a LOT to speed your renders up.

TESRs fire every tick, ISBRH only have to recompute if the chunk is updated. The difference is HUGE. There's a lot of model optimization you can do as well to remove extra vertices, etc.

Building my models with an ISBRH would be unrealistically difficult, as I would be forced to do it manually, vertex by vertex, painstakingly ensuring every one is in exactly the right location, rather than using Techne, which makes modelling fast and easy, and comes with built in texture design support.

This is one of those cases where I would say the benefit in performance, however large, does not justify requiring the designer to do it, seeing as it would likely take many weeks and produce subpar results.

Plus, I have animations and other in-world rendering that needs to update dynamically. I do not want to just spam block updates.

 

[King Lemming]

Building my models with an ISBRH would be unrealistically difficult, as I would be forced to do it manually, vertex by vertex, painstakingly ensuring every one is in exactly the right location, rather than using Techne, which makes modelling fast and easy, and comes with built in texture design support.

This is one of those cases where I would say the benefit in performance, however large, does not justify requiring the designer to do it, seeing as it would likely take many weeks and produce subpar results.

Plus, I have animations and other in-world rendering that needs to update dynamically. I do not want to just spam block updates.

For any animated block, then yes I agree - TESR is the way to go. You can in fact hybridize, however.

Liquiducts themselves are ISBRH, but the liquid inside is handled by TESR. Lowest lag solution possible.

There are also some very simple libraries (CCC-Public) which allow for very easy model creation/importing, or the .obj reader which is now in Forge. Either option beats Techne from a performance point of view.

 

[Reika]

For any animated block, then yes I agree - TESR is the way to go. You can in fact hybridize, however.

Liquiducts themselves are ISBRH, but the liquid inside is handled by TESR. Lowest lag solution possible.

There are also some very simple libraries (CCC-Public) which allow for very easy model creation/importing, or the .obj reader which is now in Forge. Either option beats Techne from a performance point of view.

The problem is, often the majority of the vertices are animated. Gears - especially compound geartrains, worm gears, or other moving parts - often outnumber the static "base" by more than 10:1.

Also - obj files? I have never heard of them.

 

[CovertJaguar]

For any animated block, then yes I agree - TESR is the way to go. You can in fact hybridize, however.

Liquiducts themselves are ISBRH, but the liquid inside is handled by TESR. Lowest lag solution possible.

There are also some very simple libraries (CCC-Public) which allow for very easy model creation/importing, or the .obj reader which is now in Forge. Either option beats Techne from a performance point of view.

You can also do like Buildcraft Liquid/Kinesis Pipes and build display lists for your TESRs, which essentially makes them nearly as efficient as a world renderer.

 

[Eyamaz]

Wait, I want to make sure I'm reading right. TESR is the TileEntitySpecialRenderer and ISBRH is the ISimpleBlockRenderingHandler correct? I haven't been able to go through as much of forge as I've wanted yet, but I'm looking into modding, so I'm trying to make sure I keep up on what your talking about.

 

[Reika]

Wait, I want to make sure I'm reading right. TESR is the TileEntitySpecialRenderer and ISBRH is the ISimpleBlockRenderingHandler correct? I haven't been able to go through as much of forge as I've wanted yet, but I'm looking into modding, so I'm trying to make sure I keep up on what your talking about.

You are correct.

You can also do like Buildcraft Liquid/Kinesis Pipes and build display lists for your TESRs, which essentially makes them nearly as efficient as a world renderer.

What is a display list? Would it allow me to still have good animations, dynamic textures, and the like?
EDIT:
Thank you for answering my question; I will try this for the static rendering.

 

[Not_Steve]

Trust me when I say, lack of documentation is not something we had in mind at all. In fact, I started the website (in all it's horrendous flash glory) to ensure that players had some form of accessible documentation. I understand how it feels to look at a mod and have no idea where to start and that is what I was hoping to avoid.

At some point, we even started a basic wiki... but when I have to work two jobs to take care of my family, not only is it hard to find time to plan out a detailed road map for EDX, it's also hard to write up documentation and present it logically on a social media platform.

I'd like to say that we have arrived at a point where our team has all of the details laid out; we've connected all the dots and have a clear and logical path to follow for each of our future releases. Now it's a matter of putting the pieces into place.

We have big plans for Electrodynamics. We don't want to disappoint. Documentation will follow.

This is a bit of a necro but I just wanted to know if EDX is still in development

 

[epidemia78]

Honestly I think BC energy is already pretty close to being "perfect" in that if you only use BC, its a challenge to set up and maintain and if you want any "real" power, it will need to be fairly massive and complex...plus the animations bring your engine room to life. its just that nobody ever uses it the way it was meant to be used these days, myself included.

 

[SavannahMan]

This is a bit of a necro but I just wanted to know if EDX is still in development

--- Bit of a necro is a big understatement. The correct term sounds like 'bit ton'.

Also, I have been planning a basic power system in a mod currently in development Hell. The idea was to transfer heat from lava and flames into furnaces and other machines using pipes. (With 25 lava source blocks enough to permanently power one furnace) The pipes would form a multiblock with an internal heat capacity which would, when this was high enough, transfer half a smelts worth of heat energy into every furnace and machine on the line. Thus, if you had too many furnaces, you wouldn't be able to smelt anything (although changes to vanilla furnace functionality mean this won't work). To help organise this, there would be a block that could be used to break a link and one which would only transfer heat when one side had a large buffer. I'm not sure how to, apart from a list of such blocks, but it would useful to get this transferring into things like dynamo's and generators.