Now i just wanna know how far along they are in their 1.8.9 update process. I'm dying to get this updated to 1.8.9. I haven't seen anything on their progress or if there even planning on updating to 1.8.9.
April fools joke.
-
-
As someone who does not know, can someone please explain to me how EU differs from RF, and how the IC2 power system differs from other tech mods?
I do have familiarity with Reika's RotaryCraft, if that helps.
Well, a big difference between RF and EU is that EU can overload machines since it comes in packets. You can see these as the voltage of the cable.
For example, you can have packets of 512eu/t or 32eu/t. You can also transport RF at xxxRF/t, but these packages have no influence on the machine they are connected to.
An important thing to keep in mind is: without upgrades/transformers, you can blow up your machines, smelt your cables, etc.
RF on the other hand is a pretty consistent flow that doesn't have any impact on the machines.
In short: EU challenges the player to set up a proper electricity net, where he/she has to think about things like losses (higher voltage = lower losses), right voltages for the right machines, the correct energy buffers, etc. RF is just creation > storage > usage and for each (including the transportation) you can use pretty much whatever you want and connect it to whatever machine you want. This requires no real thinking. -
First Everyone who Says: RF is the Answer to all the problems. That would Save IC2 from being dead answer me these questions:
1: How does that solve the EnergyNet problem? IC2 Would merge the Broken Enet over to RF and then it would be there.
2: How does it work with the Old IC2 MultiBlock API?
3: How do we balance the Energy? And no 1EU - 4RF Balance is not enough because the original devs did not think of the time factor (intentionally or not but still they did not think of it)
4: How do we make Voltages? I mean yeah its possible with RF but still most of the weak RF Stuff would not work with the HV stuff since its capacty would be two low. And you guys would be annoyed.
5: How do we support the IC2 Color API? I know classic has that implemented only but still IC2 Cables can be split by using Colors on cables.. The Problem is the RF API is to simple to support something like that... How do we do that?
6: How do we support RF without losing any IC2 Feature? (EU Excluded)I bet almost nobody of the RF Hypers (even modders will have trouble) can answer good on these questions...
And i do not want: A GOOD Answer... Not a hype answer...Second: RF is not the Solution. For me RF is Equal To AOL the old program when you installed it you had to completly reinstall your pc to deinstall it...
-
First Everyone who Says: RF is the Answer to all the problems. That would Save IC2 from being dead answer me these questions:
1: How does that solve the EnergyNet problem? IC2 Would merge the Broken Enet over to RF and then it would be there.
2: How does it work with the Old IC2 MultiBlock API?
3: How do we balance the Energy? And no 1EU - 4RF Balance is not enough because the original devs did not think of the time factor (intentionally or not but still they did not think of it)
4: How do we make Voltages? I mean yeah its possible with RF but still most of the weak RF Stuff would not work with the HV stuff since its capacty would be two low. And you guys would be annoyed.
5: How do we support the IC2 Color API? I know classic has that implemented only but still IC2 Cables can be split by using Colors on cables.. The Problem is the RF API is to simple to support something like that... How do we do that?
6: How do we support RF without losing any IC2 Feature? (EU Excluded)I bet almost nobody of the RF Hypers (even modders will have trouble) can answer good on these questions...
And i do not want: A GOOD Answer... Not a hype answer...Second: RF is not the Solution. For me RF is Equal To AOL the old program when you installed it you had to completly reinstall your pc to deinstall it...
I see you're putting yourself on a pedestal. It's not very wise to consider oneself the smartest who has beaten all other minds.
1. Easily. The Enet problem is only on the side of the cables - if another mod provides its own, working cables, IC2's issue is solved.
2. This would likely require a small tick handler, but it is doable.
3. 1EU - 10RF was what the April Fools version did. 1EU - 4RF was achieved in a rather easy way - by comparing energy generation output and making sure it's equal. The time factor was not taken into account for power conversion.
4. Have you watched Direwolf20's BC8 April Fools spotlight? This would be a bit more annoying with other RF mods (but can probably be solved on the pipe's side), but you can just use time as your second parameter. The amount of calls you can do to receiveEnergy() is not at all constrained.
5. Have you ever used a Paintbrush on a BuildCraft Kinesis Pipe since BuildCraft 6.1.5 released in November 2014?
6. Like what? Vague fearmongering "hype questions" are as bad as "hype answers".You seem to combine the API with the mods which typically implement such API. This is a terrible mistake, and not one I would expect from a reasonably experienced modder - an API is usually just an interface, really.
-
Oh thank all that is unholy.
-
1. Easily. The Enet problem is only on the side of the cables - if another mod provides its own, working cables, IC2's issue is solved.
2. This would likely require a small tick handler, but it is doable.
3. 1EU - 10RF was what the April Fools version did. 1EU - 4RF was achieved in a rather easy way - by comparing energy generation output and making sure it's equal. The time factor was not taken into account for power conversion.
4. Have you watched Direwolf20's BC8 April Fools spotlight? This would be a bit more annoying with other RF mods (but can probably be solved on the pipe's side), but you can just use time as your second parameter. The amount of calls you can do to receiveEnergy() is not at all constrained.
5. Have you ever used a Paintbrush on a BuildCraft Kinesis Pipe since BuildCraft 6.1.5 released in November 2014?
6. Like what? Vague fearmongering "hype questions" are as bad as "hype answers".1: True but then IC2 Could not run by itself. So that solution is invalid.
2: So a laggy way of doing it.
3: that convertion is fine to me but i would increase it and make it a double sided thing (so two differend convetion ratios)
4: Yeah partly true but still its not easy to do.. Also max Input can not be done by RF since it has no Transferlimit api...
5: I AM TALKIN ABOUT THE API NOT INTERNAL STUFF FROM BC AND BC STUFF IS NOT COMPATIBLE TO OTHER MODS. Also for every connection request it has to access the tileEntities and compare them. With a TileEntity Parameter (which could be provided with this) would it be much easier...
6: How much energy went through cables (average per tick, or average in total or average in a since active), Entity Damage, and burning all parts if to much energy sends through? Because even in the April version it exploded only the first part of the grid that had to much. In IC2 it burns all parts that the energy flows through and they are to weak... -
RF can't handle multiblocks, not even energy sources with multiple output faces/connections, with a fixed output power. An individual block doesn't know the proportional energy demand for each connection. It doesn't even know if anything is connected somewhere - there's no API for conductors.
The best one can do is coming up with a heuristic splitting the output based on previous transfers. The power per face/connection concept, as used by e.g. TE energy cells, is really just a workaround for a technical problem that's hard to solve. IRL you can't increase the power of a generator by plugging more cables in, likewise it makes little sense for IC2.
Regarding voltage+current on RF.. well it'd be solely relying on conventions with practically all implementations not respecting them, good luck transferring more than a "packet" per tick through a foreign conductor. Even if you can, your current is limited to integer multiples, which isn't practical for IC2's use.
-
1: True but then IC2 Could not run by itself. So that solution is invalid.
2: So a laggy way of doing it.
3: that convertion is fine to me but i would increase it and make it a double sided thing (so two differend convetion ratios)
4: Yeah partly true but still its not easy to do.. Also max Input can not be done by RF since it has no Transferlimit api...
5: I AM TALKIN ABOUT THE API NOT INTERNAL STUFF FROM BC AND BC STUFF IS NOT COMPATIBLE TO OTHER MODS. Also for every connection request it has to access the tileEntities and compare them. With a TileEntity Parameter (which could be provided with this) would it be much easier...
6: How much energy went through cables (average per tick, or average in total or average in a since active), Entity Damage, and burning all parts if to much energy sends through? Because even in the April version it exploded only the first part of the grid that had to much. In IC2 it burns all parts that the energy flows through and they are to weak...1. So IC2 could make their own cables.
4. Of course it has a transferlimit API! It's called "simulate".
5. Sure it is! All RF mods care about is whether they get energy from itself, or to itself, or nothing. RF does not care what the cable is, it can even be an entity flying through the block (Geko's Lasers). Also, what connection request? BC caches everything.
6. The April version had a bug. In Complication, everything burns. Entity damage can be done very easily and "how much energy went through cables" is easy to do, as BuildCraft already calculates the average per tick for rendering. -
1. So IC2 could make their own cables.
4. Of course it has a transferlimit API! It's called "simulate".
5. Sure it is! All RF mods care about is whether they get energy from itself, or to itself, or nothing. RF does not care what the cable is, it can even be an entity flying through the block (Geko's Lasers). Also, what connection request? BC caches everything.
6. The April version had a bug. In Complication, everything burns. Entity damage can be done very easily and "how much energy went through cables" is easy to do, as BuildCraft already calculates the average per tick for rendering.1: Yeah but as player said the API does not provide enough for multiblocks so without EnergyNet you can not do that properly
2: My machine from SpmodAPI had the problem (until i made the converter accept micro amounts) that it could be charged only be hige amounts and it never got charged full because of that simulate function... So you need to have a micro handler to handle the stuff like that properly while i can do it with the IC2 API very easy. And their converter had just a double to int + converter config conversion. No microhandler.
3: You have to do a caching system that has to be updated in a constant tick or a blockUpdate which means every now and then it has to read the data... So laggier way of doing something... So adding a TileEntityParameter would make much more sense then a int / byte / Enum parameter alone.
4: True but think of that: Is it laggier to do a entity shock damage by a TileEntity or a by a grid manager?
I would call the GridManager is way faster since it checks for Entities only once for every packet while a Grid of TileEntities has to check per TileEntity if a Entity is nearby... That can be especially through Multi Chunks pretty laggy...
About Explosion. Well the thing is: Energy Stops with the Explosion right? Because when it explode it is not supposed to send energy...So yeah...
-
Well, a big difference between RF and EU is that EU can overload machines since it comes in packets. You can see these as the voltage of the cable.
For example, you can have packets of 512eu/t or 32eu/t. You can also transport RF at xxxRF/t, but these packages have no influence on the machine they are connected to.
An important thing to keep in mind is: without upgrades/transformers, you can blow up your machines, smelt your cables, etc.
RF on the other hand is a pretty consistent flow that doesn't have any impact on the machines.
In short: EU challenges the player to set up a proper electricity net, where he/she has to think about things like losses (higher voltage = lower losses), right voltages for the right machines, the correct energy buffers, etc. RF is just creation > storage > usage and for each (including the transportation) you can use pretty much whatever you want and connect it to whatever machine you want. This requires no real thinking.
This is false and has been false for at least two years now. You've described how EU used to work, but not how it works now. The way it works now is pretty much identical to RF, except not interoperable with RF.