Updated to 1.7.10
Added 2 new features.
-Reactor Components can be put into the ToolBox (config)
-Custom Damage Bar color can be applied to an ElectricItem. (Client config)
Updated to 1.7.10
Added 2 new features.
-Reactor Components can be put into the ToolBox (config)
-Custom Damage Bar color can be applied to an ElectricItem. (Client config)
Finally After 4 months (well 3,5-3,8 months) the big update is done and released. You can not imagine how happy i am...
Now we did test a lot and we found a lot of bugs so that the end of the testing people could not find much at all...
But before we get to the Changelog i want to put out to a lot of Special thanks.
Chocohead & Mine_Sasha: For the Helping for everything. Textures, Doctumentation, Testing, Ideas they helped out. And i can not be thankfull enough for their help.
Freezy: For helping out with Textures and testing. Without him this version would be still in progress.
Dr0n1k: For testing. He found some critical bugs even if he was not always around he tested in the hidden xD
McAztec: For Testing and giving suggestions to some features that were usefull... He did speed up the Final testing.
Robotia: For general Testing. Finding the Huge Lag Points, improving my Programming Skills by a lot and idea throwing outs.
KitsuneAlex: For the Final Textures that were nessesary to finish the IC2 Classic Update. We had a lot of quere and he did get ride of it so quick...
Myrathy: For allowing me to add the old Chargepads mod into IC2 Classic
Also thanks for the IC2 Team for supporting IC2 Classic. Without their permission this would be not existend.
And everyone i forgot i am really sorry about that ^^"
Without these people IC2 Classic 1.2.0.0 were not possible.
So that we have done that we can go to the important notes (If you did not read them then i will not bother helping you):
1: Texture Packs have to be dissabled if they contain IC2 Classic stuff. They will cause crashes.
2: You can update directly but i suggest to download the compat version and activating the: Dissable Luminators config.
3: Converting back is possible but very annoying since i switched blocks. Luminators are no longer 2 Blocks. Remove all types of luminators if you want to convert back.
4: Backup your world. If you follow the rule nr 2 or have no luminators placed it should not break anything. But still there can always something be... I tried to write it as compatible as possible
If anything happens outside i am here to helpout.
Also a note: MultiPart Luminators do not mean that i Support FMP... I never support something buggy like that...
Now to the Changelog: I wish you fun reading it because its almost as big as all changelogs together that were released before..
Changelog:
Please go to github link or curse link to get the changelog. Its to big for this page...
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...
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...
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 call this a bad joke + a bad PR Joke... And it makes me think really bad about all involved people...
Design-wise, sort of, but it was RF or death for us - our ecosystem is far smaller than IC2's.
No Asie. Buildcraft should have simply changed their EnergyAPI a bit and everyone would have supported it still..
The main reason why people left was because the API was simply: You have to do it our way and thats it...
If you wanted to make a converter you had to constantly drain the Energy out of the custom battery in the old system to make it work.
A simply IC2 API like thing: Receiver and Sender would have been enough... Switching to RF was the same solution but you got ride of what BC was worth for. Its own uniqe power system with Explosions...
The slime chunks method requires it to be harcoded and i dont want that. Everything is changeable in the config and although i call it a mob farm because that is the purpose the machine can generate any item you want, you just need to add it in the config. The powercost and duration need some tweaking but i'll probable just make it configurable in the config too.
only the detection of slime chunks have to be hardcoded but you could add simply a varible which says: Only on a Slime chunk in the config then you could simply add special drops that spawn only on slime chunks... Like the Biome config.
xD Cool idea powercost/duration need some testing in my opinen but its something partly new.
Only thing i would suggest: Enderpears in end should have 0.5 instead of 0.2
ans slimeballs should also spawn in slime chunks... These are not easy to find (without a tool) but give rng based things to the mobfarm.
After the last update is released and when the changelog says: final 1.7.10 version.
So please do not ask anymore.
Anyone who ignores my forum message here and still asks: I apply the ic2 forum rule: Release/Update ask=ban
reason is simple: the planted ones are analyzed while the freshbreaded ones aren't. You need to pick them to know what stats they are... The thing here is just that the normal analyzing via Rightclick on a Crop is completly powerfree...
Oh Ok. I get it. Ill wait for estebes (IC2 Dev) crop API updated and then i am adding a lang support then you can do a langfile insteadof makeing the mod new^^"
And whats that?
First what is MCBBS?
Second what do you mean by Reproduce?
Ok. Well as long it you respect both sides of Ic2 then i will be fine with that forestry change...
I have nothing against if you want to make a classic thing.
Only thing you need to care about is that you have to make yourself FluidEjector & FluidImport upgrades by yourself... API is there so you can use it.
Note about the forestry thing: Simply it will be automaticly removed after IC2 Classic loads. It will be replaced as soon i find time for it...
Even if that sounds weird but could you mark it as Exp only addon... So that people do not try to use it with IC2 Classic?
There is no real update date set yet. Stable is a term i try to use for all my IC2 Classic versions.
I know the crash bugs it has but still they count as stable...
No problem.
If something crashes. Make yourself a list what could cause it. Even if it is something stupid. Put it on the list and try everything out. With that you can fix almost every bug...