Posts by Speiger

Since it could have beeing sunken down in the Chat i will post it here.

the IC2Exp api in recipes is still comparing items by ItemDamage. With the recently added (1.9 at least) getMetadata Function item damage & itemMetadata can be split
IC2Classic does that already and actually uses IRecipeInput in cases where it requires it to getMetadata instead of getItemDamage.

And i want you that you fix that. Either: Change it to getMetadata or add another hook with a IC2Bound API (only ic2 can add that hook) where you can say isItemEqual.
Because i can not fix it without causing Incompatiblity issues... (And i at least try to care)

Since i request it and nobody will care i point out that greg already said:

[Aug 24th 2016, 10:41pm] Speiger: Aroma another yelll... Could you fix IRecipeInputs prefabs because they are highly outdated & i can not update/fix them without causing incompatiblity
[Aug 24th 2016, 11:46pm] Speiger: could you switch please getItemDamage to getMetadata.
[Aug 24th 2016, 11:46pm] Speiger: because some components in ic2c have always a damage of 0
[Aug 24th 2016, 11:46pm] Speiger: and the meta is the only right thing
[Yesterday, 9:16am] GregoriusT: 'People other than Speiger who want that'++
[Yesterday, 9:17am] GregoriusT: metadata and item damage have been split, and even if the most common cases have those identical, its still a good idea to actually do it properly
[Yesterday, 9:19am] GregoriusT: so please get rid of "getItemDamage" and replace it with "getMetaData" and that everywhere in the Code

(show me that the people who send me: Ic2Exp is horrible at some points messages are wrong) xD

well first aroma you are wrong: Batboxes support the Teleporter. (Even Validated it)
Sulas chocohead is right. The teleporter is using quite a lot of energy but even that could be solved very easy.
Because the Teleporter also calculates a weight. A Player Has a Baseweight of 1000 and each full stack in your inventory has a weight of 100 (if it is not full devide stacksize by maxStackSize and that times 100).

And all that weight get included into the player...
So i suggest you to clear your inventory. (Math of cost: weight * ((block distance + 10) ^ 0.7) * 5).

I do not know who added that but someone bound the api for network fields to the IC2 Exp TEBlock.

Here is the function i am talking about:

https://github.com/TinyModular…rk/NetworkHelper.java#L56
(Iknow its 1.7.10 but the API is the same)

Here is the thing the API is now boud to the BlockTileEntityClass which does not allow the Function to be used unless you are using IC2 Core classes... Which makes these interfaces like INetworkProvider completly useless for IC2Exp.

Here is the code which prevents it:

Class: ic2.core.network.TeUpdate
Function: apply(TeUpdateDataClient.TeData update, World world)

This function is simply applying the Data From the Network Packet (which is sended by the updateTileEntityField) to the TileEntity. Normally it has no TileEntityBlock or BlockTileEntity requirement.
Since 1.10 & IC2Exps version: 2.2.6.40 it has a BlockTileEntity & TileEntityBlock Requirement

private static void apply(TeUpdateDataClient.TeData update, World world) {
    IBlockState state = world.getBlockState(update.pos);




    if (state.getBlock() != BlockName.te.getInstance()) {
      if (debug) IC2.log.info(LogCategory.Network, "Can't apply update to %d/%d/%d, invalid state %s.", new Object[] { Integer.valueOf(update.pos.getX()), Integer.valueOf(update.pos.getY()), Integer.valueOf(update.pos.getZ()), state });
      return;
    }




    TileEntity te = world.getTileEntity(update.pos);




    if ((update.teClass != null) && ((te == null) || (te.getClass() != update.teClass))) {
      if (debug) IC2.log.info(LogCategory.Network, "Instantiating %d/%d/%d with %s", new Object[] { Integer.valueOf(update.pos.getX()), Integer.valueOf(update.pos.getY()), Integer.valueOf(update.pos.getZ()), update.teClass.getName() });




      te = TileEntityBlock.instantiate(update.teClass);
      world.setTileEntity(update.pos, te); } else {
      if (te == null) {
        if (debug) IC2.log.info(LogCategory.Network, "Can't apply update to %d/%d/%d, no te/teClass.", new Object[] { Integer.valueOf(update.pos.getX()), Integer.valueOf(update.pos.getY()), Integer.valueOf(update.pos.getZ()) });




        return;
      }
      if (debug) IC2.log.info(LogCategory.Network, "TE class %d/%d/%d unchanged.", new Object[] { Integer.valueOf(update.pos.getX()), Integer.valueOf(update.pos.getY()), Integer.valueOf(update.pos.getZ()) });
    }




    for (TeUpdateDataClient.FieldData fieldUpdate : update.getFields()) {
      Object value = DataEncoder.getValue(fieldUpdate.value);




      if (fieldUpdate.field != null)
        ReflectionUtil.setValue(te, fieldUpdate.field, value);
      else {
        ReflectionUtil.setValueRecursive(te, fieldUpdate.name, value);
      }




      if ((te instanceof INetworkUpdateListener))
        ((INetworkUpdateListener)te).onNetworkUpdate(fieldUpdate.name);
    }
  }

This code should not be bound to the TileEntityBlock or to the BlockTileEntity!
It makes addons impossible to use that feature...
Make it not bound to the BlockTileEntity or the TileEntity Block!

Lol i just said my opinien on what i through about this idea... I never did speak for the IC2 Team ToadsworthLP.... I did not even know what the ic2 team did think about that idea...

i mean coal & gold are only usefull in early game... Its nothing else then scrap boxes...

Hahahahhaha Awesome!

LOL Item Duplicator gltich!!!! (maybe it is possible to dupe diamonds/netherstars with that)

Quote from Reoseah

It real gameplay have not changed as well and API had got most required things very early. So why API should have change?

But I agree that core package had really overgrown. IC2 Exp devs made whole hell of code... But in my opinion, they build a cage for themselves, instead of making code easily extendible and maintainable.
Or I'm just not enlightened ;3

Yeah a mod has not to provide an api... But when its a so old and big mod (and even now) other mod supported mod its api should be solid...
Also look at any TileEntity that has a gui and look if they call their gui class xD (they wont. All gui & container classes that are not bound to Dynamic gui are now junk)

Quote from Reoseah

Anyway, such thing should make anyone's eyes cry with blood, it's one method from IC2 code:

Yeah classic even had that too in 1.6.4 & 1.7.10. I tried to remove it and it caused so many issues that i decided to put it back in... (in 1.9 its removed because of the full rewrite)

Updated 1.6.4 links

I saw the video and its a epic way of how the progress is actually going...
But on the other hand if you have some behind the scene knowledge it shows also very drasticly what the errors are...
If you follow the whole video and look into the API area then you will see that it does not even grow, or change a lot... even so the core is constantly growing...

Edit: i wish i could make something like that too but sadly ic2c has no online state at all... For many reasons...

Well the title tells a part of it...

As You know aroma you solved your problem with IMetadelegate with: I just pick a random entry in the list of Possible Parts to send power to...

First thing that is wrong with that: With Multible connections on Multible blocks the power does not get distrubited equally anymore. So you go simply to Thermal Foundation level...
Second thing: Nuclear Reactors with multible connections on multible Sides start to waste power even so they could send it elsewhere...
Not in all cases but in a senario like this:

You power 2 MFSUs on 2 differend sides of a Full Chambered Reactor. (So the MFSUs are not connected to each other on the wire)
Both MFSUs have a constant drain of 20EU per tick, The reactor Produces 500EU per tick

Now because of Your Random Filling (bad idea i have to repeat that) the case of the first MFSU getting full and the second one gets filled only to 60%
Now because the 1st MFSU has a constant drain of 20EU the reactor still tries to inject power to it.
And when that happens the other MFSU gets no longer the rest of power. so 480EU go to waste every tick that mfsu gets filled and energy is left over...

Just asking what did you think when designing this enet? RANDOMNESS HAS NOTHING TODO WHEN CHOOSING TARGETS UNLESS ITS TO ENSURE THAT ALL TARGETS GET SOMETHING.
And your system does not enusre equal sending... It does ensure over time energy gets distributed to everywhere but only randomly...
Remove the TileClass and start from new... I Even help you designing a better compat with it... But do not make it like that... Its just wasting CPU resources & EU in bad cases like this...

Sneak Right Click on a BlockSide to copy a texture you want.
Rigthclick on a CFBlock or Foamed Cable to paste the Texture.

You know there is a Item called Obscurator which allows you to copy textures of any kind so you do not need to worry about these things...

Well just in case. Aroma i did make a calculation for the EnergyNet averaging out the energy tier of the getNodeStats function...
Its not based on the Tier of the Sended power its actually based of the tier of the Sources that send the power...
Its a bit of math but it would provide you with a almost exact tier of energy (rounding down thats why its not 100% exact because a tier of 3,75 would be a tier 3 still)
I threw it in the folder i made for you...

Welcome to IC2. Have fun xD

Quote

(Quoting Player)
You are wrong, inform yourself better or stop bugging us with poorly researched nonsense.

The warnings come directly from "if (Loader.instance().getModClassLoader().containsSource(this.getSource()))", which effectively just checks for coremods through the class loader differences.

Well to answer is actually wrong. What you are showing is simply a Duplication preventer in the ModAPI manager. So that a mod can not register the same APIPartName (VariableName: provides) twice, and the part you are showing is simply the preventation that if multible mods share the same API Files like RF API or IC2API that no error gets throwen.

Since all your packageInfo files did have the same Provides name it will throw the error because the mod was already added to the preventation System and it will throw then the error...

Instead of looking at this function:

public void validate(String providedAPI, String apiOwner, String apiVersion)
        {
            if (Loader.instance().getModClassLoader().containsSource(this.getSource())) {
                FMLLog.bigWarning("The API %s from source %s is loaded from an incompatible classloader. THIS WILL NOT WORK!", providedAPI, this.getSource().getAbsolutePath());
            }
            // TODO Compare this annotation data to the one we first found. Maybe barf if there is inconsistency?
        }

You should have lookt at the code behind it and you would have noticed the error you made in your head!

Here is the code that is actually throwing it:

public void registerDataTableAndParseAPI(ASMDataTable dataTable)
    {
        this.dataTable = dataTable;




        Set<ASMData> apiList = dataTable.getAll("net.minecraftforge.fml.common.API");




        apiContainers = Maps.newHashMap();




        for (ASMData data : apiList)
        {
            Map<String, Object> annotationInfo = data.getAnnotationInfo();
            String apiPackage = data.getClassName().substring(0,data.getClassName().indexOf(".package-info"));
            String providedAPI = (String) annotationInfo.get("provides"); //HERE IS THE THING WHERE THEY GET THE PROVIDES NAME!
            String apiOwner = (String) annotationInfo.get("owner");
            String apiVersion = (String) annotationInfo.get("apiVersion");
            APIContainer container = apiContainers.get(providedAPI); //HERE THEY DO CHECK IF THE NAME IS ALREADY PROVIDED
            if (container == null) //IF NOT HE IS ADDING IT!
            {
                container = new APIContainer(providedAPI, apiVersion, data.getCandidate().getModContainer(), VersionParser.parseVersionReference(apiOwner));
                apiContainers.put(providedAPI, container);
            }
            else
            {
                container.validate(providedAPI, apiOwner, apiVersion); //IF ITS ALREADY ADDED ITS CHECKING IF THE MOD IS ALREADY IN THE LIST
            }
            container.addOwnedPackage(apiPackage);
            for (ModContainer mc : data.getCandidate().getContainedMods())
            {
                String embeddedIn = mc.getModId();
                if (container.currentReferents.contains(embeddedIn)) 
                {
                    continue;
                }
                FMLLog.fine("Found API %s (owned by %s providing %s) embedded in %s",apiPackage, apiOwner, providedAPI, embeddedIn);
                if (!embeddedIn.equals(apiOwner))
                {
                    container.addAPIReference(embeddedIn);
                }
            }
        }
  }

So please tell me again that i am wrong player? Because you used all the time in the Package.info class the same name causing this issue!

I also do not think its a good idea to implement this. Yeah a Autocrafter is a good idea in itself but where a lot of mods already provide a autocrafter & modpacks are mostly a common based thing with a lot of mods. There are no modpacks under 30 mods out there... (I have not seen one since years) its pretty much unlikly to miss a modpack without an autocrafter. And if you miss one then its either intendet or not wanted to automaticly craft stuff...
Idea good in it self but useless nowdays...
We are already in a cycle based system we do not need to support that...

Quote from Player

Of course the splitting is NOT the cause of the warnings. If you looked at the source code of their origin for more than 30 seconds, it'd be blindingly obvious that you are plain wrong there too.

It is throwing errors becuase you are trying to register multible PackageInfos with the same name. I only knew how to fix it because i readed the code...

Quote from Player

It is not, this is a major design flaw in @API itself and you seem to have no idea how it actually works.

Awww...

Quote from Player

All it tells you is that the package is present, whether there are actually any classes besides package-info is completely arbitrary with zero guarantees. Thus using API mod containers in @Optional just as wrong as assuming that required-after:<some API mod container> allows you to expect any classes to be available on the class path. The system would have to use annotations on classes, not on packages, to represent the availability of classes.

Yeah and that is important. Its a TrustBased API that someone who copies a part of the API (the full part) out of a mod and intigrates that... And here is the thing: IF people would use ModContainers in the @Optional API then most of the things like RF API would not even work because every mod would have to inset every mod that supports RF instead of a API package info that is telling: Hey i found the RF API Package ok you guys can load...

If you are not able to understand such Trust based things then i am sorry for IC2Exp because these are basements... If you want to make modcompatiblity with anything or provide compat you have to trust that these mods do their thing right if you can not do that then you are at the wrong place for things like that. But you do not even need to answer that because so far everything API related that i saw from you is either mostly not fully useable or completly incompatible with userfriendlyness...
Best example: Removing World/Pos Access from IReactor and forcing people to TileEntity cast things.
Same goes for the IEnergyTile EnetAPI. Instead of making functions that convert IEnergyTile to world/pos you could have added these functions to IEnergyTile + a IsValid function (or isInvalid)... That would even remove the TileEntity Requirement of EnergyTiles which removes the Requirement of FakeTileEntities which is nowdays actually very dangerouse to use because a lot of access to Classes can be done now even before the Class is fully constructed...

Quote from Player

The warnings come from IC2 being a coremod and are bogus/unsubstantiated. I'll just delete all package infos/@API support since Forge refuses to fix its bugs and it's commonly misused.

I am thankfull that you took your broken usage of the IC2 API but it seems that you didnt understand how to use the package.info API.
Let me explain you what it is for.

The PackageInfo API (API API in short) is there to Split the API in 2 ways,

1: First that people are no longer forced to use all parts of an API and do not cause issues
2: Second and most important is that you can split the API from the mod so that mods can still use the interfaces and benefit from the things they provide.
Simply a Indirect OreDictionary.
Simply COFH API is based around that concept. COFH is not required but everyone can still use RF without having to check for specific mods. They search just for the API and thats it.
Its a very basic but well running & userfriendly system. The idea behind that is very good.

Also it seems that you have missunderstood the concept and did not even use it properly and call it bad on their side...
I told you how to use it right and you still say its used wrong on common bases?
No its the same thing as the getDisplayName issue i had to tell you to fix it, or the getUnlocalizedName that you had to change twice to make it work properly how it should has to be done (when you just could it done with one time fix)

It seems like more that you do not understand common based systems because FMLs PackageAPI system works as intendet & the idea is behind to split the API with these package API infos into components so you can ask for stuff with @Optional and do not require a mod for that is very good and people did think themseves something when they created something like that...

Edit: And FML Is throwing Errors because you used a Splitting system to mark all components as the same. Which is equal to not using it or using only 1 packageinfo. So you used it wrong.

ok i even accept this!