Posts by OvermindDL1

    boxMenu

    Must be a glitch or something. :P Are you in debug mode? only tails the box boy can do the expert engineering with expolit jazz. :Advanced Machine:


    Remember: blue bolded text meaning the original was swearing, so i replaced it with a not a swearing text instead. ;)

    No, it is trivial to reproduce, I just did it myself. It looks like there is some javascript swapping things around at load that is causing it.

    I basically just need to have a Version of GT that doesn't contain the "gregtech" Folder inside (in order to remove the Main Mod), but still has everything else (just with another mcmod.info), and I don't really know how to make that fully automatic, since it would need to be an obfuscated Version. My tries always made a Dev Version of the API (I might need that one too).


    Basically I just need two more download Options, one for an obfuscated Version of the API Base Mod thing, and one for its Dev Version. Or just a whole new Mod on the same Page with main, dev and src jar without having to change my code setup. I just have absolutely no Idea how I am supposed to do this ;)


    I will be available on IRC in about 8 - 9 hours from now.


    We just finished there, new build feature complete. :-)



    The API itself works properly (aka no crashing) without GT by now. I didn't test the thing without IC2 though, what I should do next time.

    I just use the Forge Calls for injecting the Data into the Bars, I don't render it. So if Forge disables the Bars in order to prevent the Crash (since Forge uses it, I presume it does fix it that way), it would disable my Part of the Bars too, right?


    Forge does not because, sadly, on those really crappy Intel cards there is no way to find out but testing, and the act of testing can hard crash the process, no way to recover. It is just really really crappy old Intel cards, hence the disclaimer for people that try it. It should work perfectly fine for most people. if their systems are even somewhat modern (or even *ancient* ones if ATI/Nvidia will work fine).


    EDIT: Greg, change the reobf to:

    Code
    1. reobf {
    2. reobf(coreJar) {
    3. spec -> spec.classpath = sourceSets.main.compileClasspath
    4. }
    5. }


    That should fix it! ^.^

    Quote

    [API] You can remove the GT Code (gregtech Folder) from the jar to have just the GT API loaded. I need to contact OvermindDL1 for updating the Download Page in a proper automatic fashion.


    Soooo, what is it the server would need to do? Only thing it does is parse out the maven data. :-)


    EDIT:

    Quote

    [ADDED] Progress Bars to Mod Loading. I know that there is a big ass warning that it may not work right above it (even though Forge itself uses it), but I have made wrappers that should prevent any damages, aka crashes.


    The crash happens on older Intel GPU's because they say they are capable of certain OpenGL features, but if you try to use them it crashes, just not found out which features that is yet. Sadly this is an OpenGL Intel GPU crash, unsure if any try/catch's will help there... Just crappy old hardware.


    People seem to think that being able to abuse shaders is all it takes to make something good, even though it ends up with water that looks like a mass of wriggling slime.


    Indeed, that is with environment on too high, environment is a multiplier, on 'off' it is 0, thus no movement, on high it is... more than a blocks size worth of movement. I like low, it looks good, barely movement so the world does not look dead, but not fake either.


    And yeah, by default there is bloom and all the stuff, I usually play with that off too, thankfully it is all highly configurable, plus I will likely be making changes to that engine core since I am rewriting chunks of Terasology at the moment.

    He described 1.8 adventure mod behaviour, which is totally wrong for 1.7.10, so your point is totally valid. Adventure mode was always designed for map makers, so a lot of modders just presume that it is solely designed for that. Shame really, the breaking blocks with the right tool mechanic is fun.


    It is actually not hard for a mod to do that, as I recall there is a some hook (or mutate the block list) that lets you make it so you can handle whatever, such as not being able to break things without the right tool if the block takes a tool.


    <offtopic> Side note on an engine I have been contributing to lately, low-quality screenshot, high-quality screenshot, with a gamut in-between. I just added custom block shape rendering per-block code, thus I can now make ores out of any other block with overlaid textures. Copper ore in stone, sure; iron ore in sand, sure; tin ore in wood, uh, sure...
    </offtopic>


    Wouldn't an ASM transformer coremod be easier?


    The fact that forge reveals variables is a horrible mis-design, but a lot of forge is in general. One great thing about Scala is that *everything* is a method call, even what 'looks' like a direct variable call in scala is still going through a getter/setter and can be overridden at any time.

    Hrrm what should I add next?


    A Mini 1 Block Smeltery capable of smelting up to 9 Material Units, so that I can go and kill the vanilla Furnace?
    Or finally a Machine to use the Power on my Stuff is generating?
    Or another power generator (Steam Turbines, Dynamos etc.)?


    A then B then C.



    The vanilla Furnace would still do Food Items, Cobblestone->Stone and Stuff, only Metals will be very limited.


    Exactly what I did, though I took cobble->stone and such out of my variant, as well as all metals, but yep, sounds perfect.

    There's a joke in there that you didn't dig up. If you want to get technical, the thermal energy of a substance is usually the resting burn, and almost any flammable substance can push out much more heat than that. You can melt copper with sawdust if you really want, but you're gonna need a lot.
    ---------------
    Greg, when you play a sound at x,y,z, add 0.5 to each of the location variables so the sound plays in the center of the block. Otherwise if you're standing directly in front of a block with headphones on, it will always come out of one ear only, since it is playing in the corner of the block right now.


    I did this by putting the playSound in my proxy and adding the 0.5 there, so I can call it later and just send it a location without shifting it over every time.


    Code
    1. public void playSound(World world, float x, float y, float z, String soundName, float volume, float pitch) {
    2. world.playSoundEffect(x+ 0.5, y+ 0.5, z+ 0.5, soundName, volume, pitch);
    3. }


    I told Greg about that in GT4, is it still not fixed? ;-)

    I'm personally okay with never seeing a 24 bit paintbrush for GT.


    There are already have enough storage management issues, you don't need to compound it with "Did I color this machine 0, 255, 255 or 0, 254, 255?".


    Personally I would like 16-bit rgba, 4-bits per value. Or 3-bits per, gives 4-bits leftover then...


    Edit: Would be nice to paint a layer of white first to not let the normal machine color show through by not mixing its vertex color value in, there is a use for a bit. ;-)

    Interfaces have their place, but it is *never* to give functionality to a root object, like what TileEntities are. Personally, if I were to redesign TileEntities then I would do something like:


    And internally the getInterfaceImpl can do something like look up the type in a set and if exists then return it, if it does not exist then see if it can be converted to a type that does already exist in it, say different mods have different crowbars, but GT registers a converter from the RailCraft crowbar interface to its own, which then handles it as normal. The converter is only used when the exact match does not exist, and converters are used in a priority order or something simple like that.



    Or going further away from Interfaces altogether, how about something like:


    This is even more generic and hides whatever internal structure the TE wants to use. If there was a Crowbar event for example then its event could just be a Crowbar subclass of Event, which passes in location information and strength or whatever, and the Crowbar item could be in it to allow health damage, or it can return the damage in the event back to the caller. In addition that there could also be a global converter type from 'other mod' types to your own, say, GT_Crowbar Event that you could register and handle as well. This style is called the Actor model, it is an 'opaque' container with a singular call point for data and functionality. You can still do something like the getInterface in the previous one by using this as well, just pass a message asking for some interface back that you can make calls to,like the above whether it is 'this' casted or a proxy or so it does not care. In addition to you can pppost messages to a TE and forget about them if you do not care about a responsive, and it can do whatever it wishes. This like the above has a tiny bit of overhead on the calls, but it is fairly trivial in normal usage, and asking for an interface to call against for high efficiency can be done too if there is such an event made.



    Or you can go even more generic and get rid of the TE/TileEntity altogether, instead moving all internal data to the largest atomic unit, in MC's case this would be a chunk. Let mods register new data types to be stored with chunks, and consequently they can be made as high efficient as possible, and instead of directly acting on what used to be a 'TE' you act on ID's registered to block coords in what used to be the TE Chunk map. Say you want to make a block 'host', any arbitrary block, so you choose a vanilla stone block, you give it a new incremented free ID, just a short is all it is. This short ID can be used as a key to look up in other type lists, so say you make a type called, say:

    Code
    1. classTemperature extends ChunkTEType {
    2. getTemp(ChunkCoord c, short id);
    3. }


    And internally that could be a map, an array, whatever is most efficient for it, it could even change between maps and arrays depending on how many exist for best lookup speed. For the entire running MC game you would have Systems, these Systems would then iterate over the types, or multiple types, say you have a system that is called BurnEntitesBasedOnTemp that gets a callback on to it when an entity touches a block that has a 'Hot' datatype with it, it could then set the entity on fire based on the temperature an how resistant the entity is to heat. Or you could have another system that listens for registrations of types and acts only on the ones that have a certain set of component types, say if something both a component type called EUStorage and RFStorage and it auto-balances between them to let a device use either, or a system that operates over all Blutricity component types and performs an auto-cell balancing model of energy distribution, but it ferries it off to another thread for fast processing while other Systems are run that do not depend on the Bluetricity component, thus giving you free threading. Or another System that operates over all CraftingMachine types that also have one of or more of EUStorage, Blutricity, or TEStorage component types and takes a little enegy from them to add to the crafting in the machine itself, or if there is not enough it does whatever else, perhaps based on other components that are run when, say, a CraftingMachine has not enough power, and also has a CraftingMachineExplodes component too so when no power it explodes or something. This here is Terasologies design, except it takes it out to all blocks and mobs and everything. It could still be well emulated in MC though if modders would work together on such an API.


    P.S. Please excuse grammar/spelling, on phone again and I ran out of time to be able to proofread too, which really sucks on little laggy keyboard...

    Ah, Greg said about what I was going to say, sorry for the delay. But yeah, proper design would exclusively use a unified type system instead of multiple object types, MC's design is by an idiot, few mods actually try for betterment like I did, I had a quite good component item system in 1.4.


    I'll stand by the OreDict thing, The oversight was oredicting Pyro in the first place. It risks throwing the balance off, and in the events where something is the only thing in the OreDictionary, it actually slows the crafting process down, simply because of the matching process. It really didn't make sense for Pyro at the time.


    As far as the Fluid thing, I don't necessarily disagree with you. I wrote that in 1.6, when certain things were *guaranteed* - namely that client/server mods matched up, period end of story. I wanted to change it up for 1.7 but didn't get the chance due to RL obligations. It was on a big TO-DO note for Lex to implement in my stead, and well, he didn't do it. He hasn't done it for 1.8 either and can't be entirely blamed - he's a great coder but he's not a modder. He doesn't actually use a lot of the systems he has to support.


    Understatement, Forge really should be more like Terasologies API, it is more like a hobby for him instead of something to make mods with.


    P.S., Still phone... >.<