krid are using technic?
Technic and Tekkit.
Lemme guess. They tweaked it, didn't they.
Posts by Krid
-
-
uranium/other dangerous ores
Uranium is pretty harmless IRL. I mean, I wouldn't eat it or anything, but up until it's refined and and put in a reactor or something you don't need any radiation protection. -
Somnia does exactly what you want.
-
a series of electromagnetic coils
That's a coil gun. It works on entirely different principles from and is far less efficient than a rail gun. -
Chest plate makes you almost completely invincible.
If that's not special, then nothing is.
You're also completely invincible while wearing a suit of nano armor. I'd rather have it be that total invulnerability requires the set instead of just the chestplate.
-
it always annoyed me that i can't go mining with bodyarmor. a way to combine armor with lap, bat, cf, jet packs
/ 
/ 
/ 
+ 
/ 
would be great! or at least quantum armor that works as power supply for your tools (just like the lappack)I do like the idea of using the Quantum Chestplate like a lappack. I can survive building a house out of nukes and detonating it; I think using it to power tools would hardly be crippling.
Also, it would bring it in line with the other Quantum items, as it's the only one without a special function that drains power:
Helmet trades power to get rid of eating, breathing, and poison.
Chest plate has no special function.
Leggings trade power for very fast movement.
Boots trade power for massive jump height. -
No, it should pass through lily pads like they aren't even there, mimicking the Lily's behavior of floating out of a boat's path.
-
That's a bit more advanced than I was thinking.
I was thinking that the scaling ratio should be set in the config files and only able to change via reboot.Machines need to either be running on every MC tick or capable of processing multiple items per tick.
EU can update once or twice a second with a negligible impact on player experience, but as things work now a stack of 64 items can be processed in as little as 3.2 seconds. If machines ran at a lower tick rate without being able to process multiple items per tick then that same stack would take 32 or 64 seconds to process.Personally? I favor the multiple items per tick solution, as that both removes the cap on overclocker returns and further reduces overhead.
-
He wants an admin device that provides unlimited power to machines as fast as they can possibly use it so admins can have demo machines in spawn to show off the mod's features and how things work.
-
Your Idea has a small problem: The Machines can only store a limited amount of EU, if you come with a 320EU-Package (every ten ticks) then it will not enter the machine and flows farther => Machine more Energystorage => Machine runs longer if full charged => inbalancement between Server and Client if the configs are not identical (but that can be fixed easyly).
In the grand scheme of things, increasing machine buffer sizes is a very minor change that won't make much of a difference. In practice a system would need to have highly variable production which exceeds its storage capacity in order for a small buffer increase to have an impact. A system with a power deficit would see no change, nor would a system with a power surplus.
Your Codeidea is good but it has a few MINOR problems, which makes it more complex than you think.
1. Adding Code for enabling EU-Packets to Split (into the normal Values), that they can get into Machines
You don't split the packets, you just have the machines accept the larger ones.
2. Adding Code for the EU/tick change you suggested TO EVERY SINGLE ENERGYEMMITING BLOCK.
...which would be less than one line of change.
Also, wasn't there already a power scaling factor coded in so admins could adjust power production rates?3. Adding Code for Cables that they can hold the configurated EU-Packets
OR just multiply the the cable's packet size limit by the scaling factor.
None of this needs to be visible to the player since it's all back-end changes anyway. Copper cable would still be labeled as 32EU/T since it would still be 32EU per minecraft tick; the player doesn't need to know if that's 32EU twenty times per second or 640EU once a second.
-
That's why you don't change MC's tick rate. Instead you have IC2 only update every so many ticks.
If it's scaled at a 10:1 ratio, then you have IC2 only update EU when the tick counter is a multiple of 10.
-
Ideally the code would be altered to allow more than one operation per tick, but if not then machines will have to be working on a MC tick basis.
Otherwise a properly OCed a machine could consume extra power with no actual benefit. -
It's actually really easy to do. You just have IC2 only process the network if the current MC tick is divisible by the scaling factor.
Bam, instant tick rateIn pseudocode:
if(!(curTick%energyNetScaling))
{
energyNetUpdate();
}More advanced code would have it update different networks on different MC ticks to smooth usage out, but this is just a quick and dirty example.
-
I would like for EU transportation to have a configurable tick rate, such that it can be set to only update every N minecraft ticks. For example, a scaling factor of 10 would result in 1 EU tick every 10 minecraft ticks.
To maintain similar machine utility, other factors would have to be scaled as well. An MFSU, for example, would output 5120EU packets every IC2 tick with a scaling factor of 10. Glass fiber cable would likewise have a capacity of 5120UT per IC2 tick.Machines would continue to work at normal speeds, although their internal buffers may have to be changed to match.
-
Doing calculations for a lot of packets is very demanding on a server, and can one to its knees with ease.
Until we get a more efficient EU system, I propose the introduction of a Network Segmenter.Here's how it would work:
The segmenter only allows EU to pass in one direction.
When placed on a wire, the segmenter determines which side is the "source" and which is the "sink" by looking for machines that take EU. The "source" side is whichever one has zero machines that consume EU.
Once the "source" side has been determined, the Segmenter finds the shortest route to every machine on the "source" side and determines the per-packet loss for each. It then stores a list of all the machines and the loss from each.
From then on the segmenter retrieves the power generated by each machine directly, deducts wire losses, and outputs the power it onto the "sink" network segment directly using the largest packet size the "sink" segment can tolerate. This skips all further network calculations for the "source" segment and minimizes the number of packets.
If the "sink" segment is a directly connected device then the power is added directly without the use of packets.Such a machine would allow, for example, a field of 512 solar panels connected to an MFSU to involve zero packets, and thus a negligible server load.
A hypothetical "version two" would involve the segmenter mimicking the power production aspect of all "source" machines and simply deactivating the originals.
The segmenter would not function without a source network, nor would it function with a source network containing a nuclear reactor. In both cases it would block the transfer of EU between segments.
