Posts by KingLemming

GregoriusT wrote:

I say it again, you quote a Version from October, we now have December.

That is ofcourse to fix Problems, and doesn't cause any Problems.

I do that to not have to fix those Problems, which I meantioned right above, so that it hopefully gets fixed at the Source.

I might not be professional, but should you really be in the Position to say that?

Well, I don't unregister things from the OreDict, and that would be the only thing where one could mess around with the OreDict aside from wrongly registering things.

I would not do something like that, I know vanilla Items will very likely be used for crafting something. But I have seen an unrelated (yes really unrelated to this Situation) Mod that removes the ON-State-Glowstone-Lamp from the Blocks List causing crashes with any Mod accessing them (and probably all vanilla Savegames containing ON Redstone Lamps).

Uhhm, why are you not going to be a Lawyer again?

It is a ton of work to keep maintaining that Support (That's why I did that System). I'm still far behind on fixing some Crossmod Support things, like BC or UE Energy.

Look into the OreDict.log, if it says "Mekanism --Late--> ingotBronze" (to find at the bottom of the File), then you have the reason for it, because the OreDict Unificator doesn't accept things, which have been registered after @Init has been happening.

The next Version will have that Code removed, because of the request and since the new EULA would prohibit it anyways.
But I doubt that Code ever corrupted a savegame, since I tested it two times on my TestWorld, which is full of random Machines.

Display More

For the record, I hate this quote system.

I know that you aren't abusing the OD in a horrible manner per se - you're actually quite good about what you're doing, all things considered. I also know you aren't removing vanilla blocks/items, although the log -> plank rebalance does drastically alter the progression of some mods, depending how rare their trees are, and if a specific wood is required for their recipe. But there are lots of ways that it can go south in general. Being the gatekeeper mod for that stuff makes some people uneasy. I still salute you for what you manage to pull off.

Also, I'm an engineer, not a lawyer. But it's amazing how often you have to deal with politicians as an engineer. Anyways, thanks for taking the code out.

Just a heads up - the TiCo IRC has had existing bans overturned.

Come in, speak your mind. Be respectful, please. This applies to both sides.

SirusKing wrote:

I can still think of less bias ways to say it. It doesn't matter the content actually given in the sentence.

For example, I could say that thanks to global warming, we have added more then a 1000 hiroshima bombs worth of energy to the earth every year. This makes our CO2 output seem horrific, even though the statistic of 1000 hiroshima bombs is absolutely nothing compared to the output of the sun onto the earth per year.
Thus, the statement is true but it is still biased.

The wording used in mDiyo's message is barely biased, but still could be less so. You would be suprised how a tiny bit of wording can altar the readers opinion.

@Above I also agree, the code is kinda pointless towards 1/2 of the people on their and is kinda silly anyway. It would be easier to test TCon on GT if mD could log in ;p

Note, my example above was actually based on someones article on global warming I read a while ago -_- Some people...

Display More

Here's the thing - GregTech is the sun in this case. It is the *major* source of OreDictionary and vanilla recipe altering. Your analogy would hold true if there were another mod shadowing what Greg does by orders of magnitude, but there aren't any.

So considering that, it is a completely fair warning. And again, I'm not "blaming" Greg here or even taking a side - he knows that he restructures and changes a lot of things - that's the entire point of his mod! And that's fine, there is nothing wrong with acknowledging that it does that. To his credit, Greg does an amazing job with all of the x-mod interaction that he does. But it's insane to say that he doesn't do more of it than anyone else, which is what you just implied.

SirusKing wrote:

much better, the wording is still meh but whatever. If you really want unbiasness, I can write a short paragraph for you :3

The current wording on it is actually both diplomatic and accurate. GT does do all of the listed things. The reasons for GT doing it are irrelevant, and it is factual that messing around in the OreDictionary can mess up other mods which expect certain things to hold true.

Same for vanilla recipes - if you remove Iron Tools from the game, you effectively remove the Sawmill from TE without actually doing that directly. (No, Greg isn't doing this, it's just an example.) So any rebalance of modded or vanilla content can drastically shift the vision of another modder. The wording on this is unbiased. The biased way would be saying "GT forces Greg's vision on all other mods."

Pwnie2012 wrote:

why does the tessellator corrupt the world on calling it a second time while drawing already?

It'll throw an Already Tessellating exception, and if this happens during the world load process, the NBT becomes unrecoverable more often than not. This is the nuclear option here. This isn't a simple CTD - the world won't show in the list anymore.

EDIT for emphasis: I haven't tested; I don't *know* that this code is still actively called. I'm assuming that it is. The implications of the Tessellator call are as I have stated, however. So if this codepath is still called, it's really brutal and unnecessary.

the-order wrote:

Does this code effect mod packs with both GT and TiC installed? Or is this only for certain people. I would like to know because I use a custom modpack with both these mods installed and I would hate to have my world ruined because these two authors can't come to an agreement.

The code, as far as I can tell (I have not personally tested) is basically:

if (user == <one of these three>)
{
<corrupt world forever>
}

That's not cool. And I've already worked with Diyo on further refining that message. The original pass got a C+ for effort on his part.

Alright, let's get this solved once and for all.

Greg, please remove the world-corrupting code in your ConnectionHandler that only affects 3 specific people, mDiyo being one of them. (Line 74, forcing a Tessellator redraw, which during a world load forever ruins it.) And no, I don't make a habit of going through peoples' code - I made an exception this time since an assertion was made that you were doing this.

So, I apologize for that and I won't make a habit of it. Even so, please remove the crash code.

mDiyo, let's tone the language down a bit and ensure the popup only happens once. It's fair to say "We won't field bug reports if you have GT installed." It's a bit slanted in its current state, however.

GregoriusT wrote:

I removed some of the Amplifiers recently. That is one of the things which need a rework.

What Problems?

The Alloy Smelter can do many reverse Recipes for Blocks and Items.

So it reverses the "9 Fluxed Electrcum Ingots -> 1 Fluxed Electrum Block" Crafting Recipe like it is supposed to do, not to mention that it ofcourse also adds a regular Furnace Recipe for that case.

Okay, please attach small Screenshots of the Recipes you think which are broken in NEI, because I think you are just confused, and that this isn't actually a bug, but a well known Feature.

You may notice that Fluxed Electrum and Enderium normally require Pyrotheum - they are considered to be "Blast Ores" and are not normally registered to the furnace.

I have given you an IMC call to register your "Blast Ores" with my Smelter, making them require Pyrotheum (which is way too expensive for serious use). Do not provide furnace recipes for my blast ores, or I will do the same for yours.

In general, if someone has NOT registered a dust -> ingot recipe in the furnace, then you can pretty well bet it's intentional.

I'm not trying to be too mean here, just pointing out the skewed nature of the relationship as it stands. Also, I'll get that ItemStack list posted somewhere for you.

PaladinOne wrote:

Additionally:
In the Thermal Expansion (3.0.0.b9) Induction Smelter, certain Dusts can be smelted that would normally require an Industrial Blast Furnace
Those dusts are:
Stainless Steel
Kanthal
Titanium
Tungsten
Chrome
Aluminium

All AllowRecipeOverwrite settings in the ThermalExpansion config file are set to true.

Display More

Yes, the Smelter auto-scans once again and adds all ores and dusts automatically. There is a new IMC call in b9+ called SmelterBlastOre. I'll get the template up on the website, but basically it flags an oreType as being a "blast furnace" metal. In this case, the normal Sand + Dust recipe will be replaced with Pyrotheum + Dust.

There is no option to remove the recipe outright at this time, as Pyrotheum Dust is pretty darn expensive just to smelt some dust.

GregoriusT wrote:

Uhhm, I already fixed that Cell Problem on my Side. I moved it to the @Init Phase a Version ago to fix this exact Problem.

And I guess you did the @ServerStarting thing you mentioned a few days ago (what is good for the special Furnace Recipes, so that you could for example smelt the dust only if there is an actual Furnace Recipe for it). Let's hope your NEI Plugin accounts for that, because the Client doesn't load this Phase in case of joining a Server (what was another Reason for me not to use that Phase for it, after I thought a bit more about it).

Pfft. Please. There are other ways.

AnodeCathode wrote:

Damn. Was sure I'd wake up to a new version of GT with the cells working with the fluid transposer. When the worlds most prolific mod updater doesn't update for a day or so I begin to suspect big things coming.

The cells thing should be fixed in the next beta release of Thermal Expansion. It now loads after GregTech. (Yes Greg, even with your PostInit hackery. No, I am not counter-hacking you.)

GregoriusT wrote:

This is because the Forge Config doesnt have any way of clearing deprecated Configs. I could use my other System for that, but then all your Forge Style Configs would be useless, and you would have to set every single Config again.

Oh, and look into the DynamicConfig.

https://github.com/KingLemming…h/util/ConfigHandler.java

There ya go. Wrapped for the Forge config system that gives you easy access to add/removal. I will probably add auto-deprecation as well. Yes, I believe I will.

Oh, and forever asked (wasn't Greg), as for the iron/gold/diamond/redstone/stick whatever in the OD, that is Forge adding those.

Pwnie2012 wrote:

catch the oredict? what do you mean with that

Basically loop through the oreDict and be absolutely sure that everything has been registered. If anyone registers something new after the server has already started, they are doing it WAY WRONG.

SirusKing wrote:

Quoted from "Pwnie2012"

Huh, apparently so: "(computing) Playful solving of technical work that requires deep understanding, especially of a computer system.
From hacker: "A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.""

Display More

Hacker is a very generic term. Some people do it professionally. >.> But in general, it does imply taking roundabout methods to acquire deeper understanding of a system, for whatever purposes. There's no inherent good/bad to it - we tend to refer to hackers as white/gray/black hats, depending on what their goals are.

<.< Not that I know anything about it. Professionally, that is. Probably. Hard to say.

GregoriusT wrote:

Let's hope mDiyo reads that too. I'm tired of his shit.

I add so much universal crossmod compatibility (mainly via OreDict), that it is best to load last, since I try to be compatible with all the Mods. I would like to use the "after:*" Method to let my Mod load last or at least very late, but that one got never fixed, and using it would cause Problems with UE-Basic-Components. I would've liked to use the fourth Load Phase (FML_LoadComplete) for adding/checking/nerfing the Recipes, but then again, that doesn't work either. All I do in that hacky Code (see this example from RawCode, where I copied it) is copying the Mod List except GregTech itself, then add GregTech as last element of that copied List, and then telling Mod Loader moreless "forcefully" to use the slightly sorted Copy of that List instead of the previous List, to take GregTech to the end of the Mod List to be the Mod loaded last, so that things like late OreDict Registration don't cause huge Lagspikes and random Console Spam during the load Phase.
I don't hack into it to do bad things, that was never my intention, I just did it, because it makes my Code much easier. Not to mention that if this Code causes any Problem to you (such as crashing, even though that cannot really happen), you can always disable it in the Main Config.
In addendum, there is an API in GT to do things after my own postload Phase, so if anyone ever needs to do something after GT, he can do that with my API very easyly.

For the people who think, "Why don't you just sort the original List instead of making a Copy?". If I do that, then the Mod, which loads directly after GT (Nuclear Control in case of my personal install) will loose its @preInit Phase and that would be bad, thats why I didn't use that Method.

@LinusPheonix: One can ofcourse also use "after:IC2" or "after:ThermalExpansion", also possible is "required-after:IC2", but that would involve knowing the ID of every single Mod in existence. And as of hacking breaking Security Features, the Modlist is a private Field within a private Class, so according to that it would be hacking.

Display More

There's one more option you have Greg - move all of your @PostInit code to @ServerStarting. Add a boolean to make sure you don't double-load it in SSP, should someone switch worlds.

It works. If I re-release OmniTools, it'll use this method to catch the OreDict.

DrRed wrote:

Wow, the new Autonomous Activator from ThermalExpansion is really cool. It is a deployer with the ability to synthesise sneaking, clicking the block above, below and in front and the normal left and right click.

EDIT: You can also lock the machines to everyone except your friends.

EDIT2: KL has unified all of the Tesseracts into one block, not sure how I feel about this.

EDIT3: Damn, the Tesseracts and Redstone Energy Cells don't look as cool as they used to, they are opaque now.

Display More

Glad you like it.

1: /cofh friend gui for an easier way to handle friends - we're working on documentation and maybe a keybind for this.

2: Tesseracts are pricier, although the recipe isn't final. It's probably going to get a bit more expensive.

3: They're still transparent for me and everyone else, though the texture may be more opaque than before.

GregoriusT wrote:

Quoted from "AnodeCathode"

GT Blast Furnace recipes appear to be working in the TE induction furnace. Anyway I can prevent/disable this?
Well, I will look into that.

Could be, I messed something small up. Are you sure you mean Blast Furnace and not Alloy Smelter? Because the Alloy Smelter is supposed to have corresponding Induction Smelter Recipes.

If it is accidentially added by me, then you just have to look into the Induction Smelter Config of GT, where all Recipes are listed by their Output.

Edit: I looked into my Code and according to that I didn't mess anything up on my Side. It is probably TE automatically adding Recipes for Dust->Ingot, what is completly legit, even though it slightly messes with my Blast Furnace Tech Tree. I need to download the updated Thermal Expansion API to fix these Recipes, like I did with the vanilla Furnace.

And I still wonder why the FML_LoadComplete Event doesn't work at all, or why it even gets sent, since it doesn't do anything.

Edit2: KingLemming : Is there any documentation on the Intermod Communication regards TE, since there is no API anymore?

Display More

I'll get some documentation up there this evening. ATM I am auto adding all dust -> ingot conversions. I probably need a sane way to do this. Sorry about that. No need to hack around it, I'll be sure you have a way to remove.

Also, MJ compat means that *Conduits* will send to your stuff, but it does not mean general RF compatibility. Cells, Tesseracts, and Dynamos won't work. And you can't deny that RF is a slick API. Ratio is 10:1 RF:MJ. or 4:1 RF:EU.

GregoriusT wrote:

Speaking of this "off chance", you registered an Item using a prefix but with no postfix/name/material to the OreDict, what has been detected by GregTech:

Code

1. WARNING: 'glass' is an OreDictionary Name which may cause Problems, due to being a Prefix, please use another one.
2. 2013-11-18 19:00:14 [SEVERE] Private Prefixes are a solution. Please use 'CoFHCore:glass' don't forget to insert the ':' inbetween the Mod ID and OreDict Name, that is the most important part.

My own System takes the OreDict pretty seriously, and says that whenever someone is doing things wrong. I guess you just wanted something for Crafting Recipes to use any Glass, so the private Prefix would indeed be a Solution.

I think there is a fourth load Event, which comes after Postload, called FML_LoadComplete or similar, this might help. You just need an additional Event Handler at the EventBUS because that is no normal @Mod Event.

Actually, I was told to register glass for TiCo compatibility, since apparently that is the standard. Apparently all glass types from TiCo are registered as "glass". I don't use private prefixes for anything like that. There's no prescribed or agreed upon requirement for vanilla names, which is a bit of a problem.

For example, "slimeball" is probably okay (and I register this). However, Blaze Powder should be what..."dustBlaze"? I think so. I think redstone dust should be "dustRedstone" as well. Blaze Rod is "blazeRod" or "blazerod" or "rodBlaze"? Hrm, hard to say. I'm probably going to go with "dustEnder" for pulverized Ender Pearl. Just one of those weird things.

DarkForce wrote:

offtopic : found some errors like "Null pointer exception", published on issue tracker:

offtopic : found some errors like "Null pointer exception", published on issue tracker: #134

This is a mod looking for the TE API. TE no longer has an API - it relies entirely on IMC. The parts where an API is necessary - interfaces - is now handled by CoFHLib.

DarkForce wrote:

Unknown material detected:

[STDOUT] Material Name: blockEnderium
[STDOUT] Material Name: dustEnderium
[STDOUT] Material Name: ingotEnderium
[STDOUT] Material Name: nuggetEnderium
[STDOUT] Material Name: dustBlizz

Enderium is legit. Blizz dust probably shouldn't be registered. I may change that.

Epic Lulz wrote:

Can verify, but apparently even without GregTech installed I can't melt Redstone Dust, only Redstone Blocks.

(EDIT: KL's explanation may fit, Redstone Dust is being registered as calclavica:wire (MFFS?), while the other items do not have any Ore Dictionary registrations without GregTech)

The long and the short of it is that I wrote an *extremely* clever piece of code which gets screwed up by late OD registration. Also, I need to change to doing ALL of my recipes in postInit now due to the off chance of people registering everything under the sun. Half my fault, half not.

GregoriusT wrote:

Does anyone else have this strange behavior that Redstone, Glowstone and Enderpearls are not meltable in a Magma Crucible only when GT is installed?

I think everyone does. And I believe I know the issue. I can fix it on my end. However, if you happen to be doing any OreDictionary registration later than init - ie, postInit, IMC, or serverStarting - please move it to Init or preInit.