Posts by cpw

Quote from FenixR

But you should remember that (Once again) unlike solar arrays, placing nearby solar panels didnt affect their funtion unless they were put one on top of other, with Water tower their total eu generation gets affected if you place these watergenerators too close to each other and the cable wiring also reduced the amount of valid water blocks nearby for the energy generation.

There is still some rules bending with the water arrays.

(Forgive any misspelling or confusion, im kinda tired right now sorry)

(Also this is just me laying out the logic of the process, if CPW wants to do so there is literally nothing that can stop him)

Display More

No plans for water gens - pretty much because of this logic. Unlike solar which is just "canblockseesky" water gens are "how many water around me". That equation changes dramatically as you try and scale it. Even if you were to make a giant inventory - that would be absurd. No I'm not doing water. Or wind. Oh and I like being "unstoppable"

I have some ideas for upgrade items- so that I can get people off their Advanced Machine dependency. Unfortunately at present it looks like there's no way to hook TileEntityMachine when there are upgrade items.

What I would like to be able to do is create new "Upgrader" items, probably event driven, with visibility into the base TileEntityMachine.

Here's a simple proposal.

public interface MachineUpgradeItem {
 /** Called with the current itemstack when the upgrade stack is modified 
 * Returns true if this is now a locked slot (cannot have more inserted)
*/
  public boolean installUpgradeItem(ItemStack upgradeItemStack, TileEntityMachine machine);
/** Called to compute the current effect of this stack on the machine. Generally would set the overclock rate and maybe have other effects.
 * Returns maybe a new value for some parameter?
*/
  public int evaluateOverclock(ItemStack upgradeItemStack, TileEntityMachine machine);
/** Called whenever an operation cycle is about to start (new item being smelted or something)
* This should come before the machine decides if it wants to smelt something - so I could insert something into the machine at the last second.
* Returns true if the operation can proceed.
*/
  public boolean beforeOperation(ItemStack upgradeItemStack, TileEntityMachine machine);
/** Called after an operation cycle is complete. (Item has finished smelting for example).
* This allows for me to e.g. remove the item from the machine and put it somewhere else.
*/
  public boolean afterOperation(ItemStack upgradeItemStack, TileEntityMachine machine);
}

This is just a sketch of an idea for a new API to support modders creating new upgrade items without having to hack base IC2 code. Thoughts?

Quote from Player

From a quick look you seem to have left the EnergyNet.removeTileEntity() call out, without it the EnergyNet code will leak memory over time. The best place to call it is in TileEntity.invalidate(), don't forget to call super.invalidate() afterwards.

@all: Stop complaining about whether an addon might be overpowered from your point of view, you aren't forced to use it.

You're right. Thanks for the pointer. New version incoming shortly to fix that..

Compact Solars is now done. Hopefully...

I see I've been threadjacked by the eternal debate over the merits of compacted solar panels. *sigh*

My opinion, solar is OP full stop. This is strictly a server efficiency issue- the CPU cost of large quantities of solars in a world is frightening. If you don't like solars, turn them off. There's an option right in the bukkit port to do it. Compact solars are no different. If space and TIN (LOL!) are really the reason this is OP compared to vanilla IC2 solars, well, I don't get it...

Anyway, SSP is done and working. SMP is being a bit of a pig. Hmmm. Anyway, not long now.

So, I'm rewriting advanced machines from scratch as promised. Phase 1 is nearing completion- it's the bit that's really critical for servers- the compact solars. Check my other thread for more details.

Since this thread was long abandoned by CPW but still has updated downloads (here), i'm keeping this thread here. ~SpwnX
CompactSolars, universal is ready.

It is now open source licensed under the GPL v3, review it here: https://github.com/cpw/compactsolars.

Version 4.1 is now available. Updated for Forge 7.7 (required!), minecraft 1.5.1 and IC2 1.115. Requires latest forge!

It uses the latest in MCP and FML technology to be reasonably version independent..

Version 4.0: new thing! Solar Hats. Sport the latest in smart hatwear, with built in solar array. Be careful though, all those EUs pulsing around your brain might make you feel a little bit weird. Mix your solar array with an iron helmet.

There is a production rate scaling factor: specify an integer greater than 1 for slower EU generation. Please don't abuse this setting- it's meant to maybe help server admins encourage other types of generation rather than solar array farms. This scale factor basically acts as a tick divider, but is deliberately slightly random as well.

This is a clean rewrite of the Compact Solar Arrays from Advanced Machines, using pure IC2 API. It's also a darn sight more CPU efficient.

A little spotlight by Techninja117. I love the pyramid at the end, showing how much you get in an HV array. Thanks!

https://www.youtube.com/watch?v=hASvy2uDPvE

Recipes:

Low Voltage Solar Array

require: 8x Solar Panels and LV Transformer

Medium Voltage Solar Array

require: 8x Low Voltage Solar Arrays and MV Transformer

High Voltage Solar Array

require: 8x Medium Voltage Solar Arrays and HV Transformer

(Thanks SilentSpy for the recipe images!)

Hats:

Thanks very much to Soaryn for the hat textures, they're really stylin'

It works well that I can tell, though I welcome bug reports.

Downloads:
All builds:
http://files.minecraftforge.net/CompactSolars/
Generally, grab the most recent listed build there.
The recommended build will update for each official IC2 release.
The latest build will generally be against latest forge and IC2 api and might be beta.

1.4.5 link: http://files.minecraftforge.ne…rs-universal-3.1.3.18.zip

Minecraft 1.3.2 and IC2 1.106 (or later, probably):
Universal: http://www.mediafire.com/file/…tsolars-main-3.0.1.13.zip

Forge 118+:
Client: http://www.mediafire.com/file/…olars-client-2.3.2.10.zip
Server: http://www.mediafire.com/file/…olars-server-2.3.2.10.zip
Bukkit: http://www.mediafire.com/file/….10-bukkit-mcpc-1.2.5.zip

Minecraft 1.2.5 and IC2 1.95:
Client: http://www.mediafire.com/file/…solars-client-2.2.0.5.zip
Server: http://www.mediafire.com/file/…solars-server-2.2.0.5.zip
Bukkit: http://www.mediafire.com/file/…0.5-bukkit-mcpc-1.2.5.zip

Minecraft 1.2.4 and IC2 1.90:
Client: http://www.mediafire.com/file/…solars-client-2.1.0.2.zip
Server: http://www.mediafire.com/file/…solars-server-2.1.0.2.zip

Minecraft 1.2.3 and IC2 1.81:
Client: http://www.mediafire.com/file/…ctsolars-client-2.0.0.zip
Server: http://www.mediafire.com/file/…ctsolars-server-2.0.0.zip
Bukkit: ...

Minecraft 1.1 and IC2 1.71:
Client: http://www.mediafire.com/download.php?dshebaxah5ae4v1
Server: http://www.mediafire.com/download.php?dj1sua292lw4q6r
Bukkit: http://www.mediafire.com/download.php?lob7k8f7sudy807

These are independently block textured from IC2 so I welcome texture pack offerings better than my slightly naff blending effort.

Many thanks go to Zipp for the inspiration for this- it wouldn't have happened without your kickstarter. Also, Zipp, buddy, if you ever return, I'm sorry for taking over, but I think there was a strong demand for this and I hope you can forgive me.

OK, I've found the problem: the server side Containers need to override onCraftGuiOpened and update the state of the client by using icrafting.updateCraftingInventoryInfo for the three progress counters. If you refer to the vanilla furnace you can see that it has this behaviour.

I suspect that under the covers ModLoader.OpenGUI was doing something similar prior to your changing to not use that on the server side.

Note updateCraftingResults is not going to update in precisely the case we see it bugging out- namely when there is no work going on, because the container's progress fields will match the tileentity's in that case, and so won't send the updateCraftingInventoryInfo, and that's probably why the furnace works and your containers don't.

I confirm that this is a bug in the vanilla server- I suspected an issue with the bukkit port at first, but a completely clean vanilla server suffers from this as well..

However, I can't see why this happens. It looks like everything is practically identical between say IronFurnace and the regular furnace.

Well, I think I'm going to embark on a quick rewrite, similar to what I done for IronChest. I'll see what happens though- it'll take a bit of time.

Quote from Kane Hart

I assume since zippinus has quit someone is going recode this from the ground up and fix some the major issues or I hope they will anyways.

Has he?

Quote from 7H3LaughignMan

The API does contain everything you need to make a functional machine block, just because your to lazy to actually check to see how it works doesn't mean the developers have to go out of there way to help you out.

Ok i'll bite. The API is not missing anything that could allow you to integrate AM I agree. However I invite you to try and build just the macerator without decompiling IC2. I suspect you will fail. Understanding how to integrate to the rest of the energynet, how you block/tile/whatever is suppsed to work in response to the different energynet API calls, how to find out how kuch power the net is giving me - the complex code to allow you to power from battery directly- the API says nothing about any of this. Note that the only IC2 mods that have updated have either their own powernet (bcic engines, forcefield) or are owned by a dev team member (chargebench). Zipp is very much on a limb here trying to replicate core machine appearance and function.
To those wondering i will let zipp have until after i have ported ee to bukkit then i'll release a patch fixing these machines (hopefully), assuming both no return or other objection from zipp and the capability to do it..

Quote from xKillerbees

So what is the status on SMP? It's getting to be extremely frustrating that this the only thing holding us back from updating 1-2 weeks ago.

I do appreciate the work that has been done so far. But if you need help with the API or fixing issues, please let us know so we can help. Sitting here with nothing to work with as a server owner is frustrating.

To be completely honest. If the solars didn't help our server the way they do, I would have removed the mod to update. But I can't force people to lose thousands of solar panels. I would even go to the point of paying someone to take the advanced solar part of the mod and make a different mod as that is the only part we care about.

Hey man, you should go easy on us you know. Zipp has been given a very unenviable task here you know. It's not like there's any core IC2 developer willing to try and actually make the API useable in the way Zipp needs it to be. If Zipp wants me to I can give it a go at fixing up the remaining issues this weekend (I am away from my developer machine for the week, because work has made me travel to Detroit - lucky me), but this is Zipp's baby, I'm not going to just come in and take over, and given the state of the IC2 API, I'm hesitant that I would want to.
The best way you could help is by hassling the core team to actually make an API we can use to add this stuff. We need an extendable tile entity that provides the core power functions in an overrideable way, and compatible block code. Or you know what - get them to add the compressed solars to the core itself - man it's about 20 lines of code for the core dev guys. Sadly, it's not quite that way for us outsiders. It's a few hundred/thousand lines of code copied from partially decompiled classes built against obfuscated minecraft core code. If you get it slightly wrong, well, you can see what happens, because guess what, that's what Zipp, under much pressure from you all, released.

Quote from 7H3LaughignMan

Well the API for IC2 has gotten a lot better in its implementation and what it does contain, however I do have to say that the API isn't 100% straight forward and would require some better documentation along with example to explain everything. On the other hand Advanced Machines should of never of relied so heavily on the TileEntities from the core of IC2, trying to decompile a massive project like IC2 is always going to have issues.

I hate to sound so mean but there have been some statements on how this new Advanced Machines is rewritten from the ground up and from what I can see it doesn't seem to be like that, from the looks of it Zipp has taken a lot of the coding from IC2 and made some changes and is implementing that instead. My thoughts is that Zipp should of written his own TileEntity that implements everything he needs from the API and written it from scratch and have all the machines extend that. Most of the issues at the moment is because of the minor rewrites of the copies from IC2's base files. This style of coding just seems like it was hacked together and is failing because IC2 is expanding in leaps and bounds that are to advanced for any addons to be dependent on the core of IC2.

To stsnd in Zipp's defence here when I temporarily took the reigns I hooked the core a lot more because I was confident I could keep up with it. Zipp has had to revert to the older code base that was basically decompiled everything up to NMS. The problem is that the API doesn't tell you how to use any of it so either you guess and copy the code from up the stack ( hoping the core doesn't change drastically in the mean time ) or you try and build it all yourself. I know that given those two choices I 'm just walking away. Which is sad because I have some ideas but they're not going to happen unless the API becomes useable.

Quote from Player

That's not how you're supposed to do it.

The API provides everything required to create a fully functional adv. machine addon (EnergyNet/battery/wrench interaction, recipe import, recipe ingredients) without linking to core files. The addon does need to duplicate some of our code ofc, but as soon as you've done that it doesn't matter at all if/how our internal TEs/structures change.

We'll try to create some example code for how to use the API correctly and probably also add some of our utility stuff to the API (networking code, client/server abstraction, audio (after the rewrite), keyboard synchronization, gui handling etc.) once it's stable enough and time allows to do so.

Yeah thats the problem - that little 'utility' list is all the stuff you can't just guess at. I was thinking about building a "block addition kit" so that all that pain could be centralized but to be honest it needs to be part of the API so I don't think I'm going to do that. In the meantime poor Zipp has to decompile IC2 . I've decided against writing another mod (and removed Iron Chest's dependency on IC2) because of this lack of transparency and extreme difficulty for maintainance.

Quote from Oxygene

Hopefully the changes will be minimal between versions for mod hooks and people can upgrade quickly

Nah, looking at what's going on there, it looks like there's going to be a pretty big tile entity update, which means Zipp is going to have to rewrite his TE code again, and that's the bit that's HARD. Sadly. I wish the API could get us some base Tile Entities so we didn't have to deal with this crapfest on every upgrade. It's pretty frustrating. I note that they do it for the Crop stuff so I think I'm going to request a base "electric machine entity and block" for the API so that we don't have to keep dealing with this every time an upgrade comes down the pipe.

The other possibility is that IC2 doesn't want us adding custom machines to the game. That's a possibility I suppose.

Quote from Oxygene

Yeah thats the one according to the mcportcentral which is version r1.

Beta1 had errors such as no working config file and shift click problems didnt it? Beta2 which is the current version fixed those.

There are two versions of the client. But the bukkit port is not a port of the client. It's a port of the server. Of which there only exists ONE version. THIS ONE: http://forum.industrial-craft.…ad&postID=39264#post39264

There may or may not be config file issues in any version of this code. I suspect the config file issue exists in all versions to be honest.

Here is a sample config file, put it in config/IC2AdvancedMachine.cfg and edit to your heart's content.

# Configuration file
# Generated on 09/02/12 9:21 AM




###########
# General #
###########




general {
   guiIdCentrifuge=42
   guiIdHVArray=43
   guiIdLVArray=45
   guiIdMVArray=44
   guiIdRotary=40
   guiIdSingularity=41
}




#########
# Block #
#########




block {
   blockAdvancedMachine=193
   blockSolarArray=194
}




########
# Item #
########




item {
}

Quote from Oxygene

Yeah I just realised the ported version is beta 1, the one which doesnt have a working config. Thats a pain cause I was midway through building my server and client jars before I realised lol. Might wait a few more days.

Huh? There's only one "version" of SMP and it's the one I ported.

Hi Zipp
So the problem with your inventory not quite working is pretty simple:

In TileEntityMachine you're missing a few calls to onInventoryChanged(). Here's the code from IronChests so you can compare and hopefully fix it up. I have already fixed it up in the attached bukkit port.

Hope this helps

public ItemStack decrStackSize(int i, int j) {
        if (chestContents[i] != null)
        {
            if (chestContents[i].stackSize <= j)
            {
                ItemStack itemstack = chestContents[i];
                chestContents[i] = null;
                onInventoryChanged();
                return itemstack;
            }
            ItemStack itemstack1 = chestContents[i].splitStack(j);
            if (chestContents[i].stackSize == 0)
            {
                chestContents[i] = null;
            }
            onInventoryChanged();
            return itemstack1;
        }
        else
        {
            return null;
        }
}




public void setInventorySlotContents(int i, ItemStack itemstack) {
        chestContents[i] = itemstack;
        if (itemstack != null && itemstack.stackSize > getInventoryStackLimit())
        {
            itemstack.stackSize = getInventoryStackLimit();
        }
        onInventoryChanged();
}

Quote from zippinus

Somewhere in that file it states ModLoaderMP 1.0.0. You need ModLoaderMP 1.1.X for it to work

I will try and upload a bukkit port to mcportcentral in the am ok zipp?