SanAndreaP

Then they should use totalWorldTime, as the vanilla gamerule doDaylightCycle also messes with worldTime, as it's not incremented when doDaylightCycle is true. It's the only approach applicable w/o breaking compatibility with mods OR using ASM. As you've stated yourself: Thus introducing incompatibilities. Your approach is not wrong, and actually the right approach when we're talking about custom dimensions, I'm just saying that Failenders suggestion isn't wrong either.

Just do what Failender suggested. How will that break mods? Here have some pseudocode: int ticksUntilDaytimeIncr = 0 onServerTickPostEvent(event) if event.world Is Overworld then doTimeReset(event.world) end end onClientTickPostEvent(event) if event.world Is Overworld then doTimeReset(event.world) end end doTimeReset(world) if ticksUntilDaytimeIncr >= 3 then world.worldInfo.setWorldTime(world.worldInfo.getWorldTime - 1) ticksUntilDaytimeIncr++ else ticksUntilDaytimeIncr = 0 end end By the way: There are 2 fields actually responsible for world time, the worldInfo.getWorldTime() and worldInfo.getTotalWorldTime() The former is used to calculate the celestial angle, the second one to determine the "real age" of a world / used by the block tick scheduler. You shouldn't mess with the latter. Also gamerule doDaylightCycle actually stops WorldTime from being increased if set to false, whereas TotalWorldTime is always incremented.

The only way to see what mod causes this behavior is to binary-search those mods, meaning you take half the mods out, try again. If the problem persists, take another half of that half, and so on until you've found the mod causing that error.

Seems to be an issue with your graphics card not being able to render huge texture sheets properly. Anyways, can you give us the whole fml-client-latest.log inside the /logs/ folder? Use http://gist.github.com for that, please. Also, could you try to disable the new loading screen inside the config/splash.properties file? I know it's a very big assumption, since it shouldn't affect anything at all, but it's worth a try...

Seems like TooManyItems is crashing. Report to the author.

So, you only need that for the overworld then?

[*] de.ItsAMysterious.mods ... Please use the standard naming convention and make your package names ALL lowercase! [*]If you post code we'd prefer you using http://gist.github.com or similar services, since they offer syntax highlighting and proper intentions. [*]As far as I can see in your code, you check for the closest players and let them automatically ride the jeep!? Don't do that! interactFirst gets automatically called. What happens is you manually call interactFirst, which mounts the player to a seat, and then the interactFirst gets called again by Minecraft itself, effectively dismounting your player. [*] Minecraft.getMinecraft().displayGuiScreen(new GuiVehicleModification(this)); Do NOT have any reference to client classes in common code, EVER. It will crash your server! Instead use a Proxy. [*]The IInventory interface usually is not implemented in Entity classes. Instead I'd recommend making a seperate class for it.

How long did you wait? Try disabling the new loading screen in the config/splash.properties file and see if that works.

Problem with MC Helicopter. Talk to the mod author.

By the way, this is bad: entity.motionX != 0 since motion fields are all floats, they suffer from approximation errors. See here, it is a really good article on that topic: http://www.theregister.co.uk/2006/08/12/floating_point_approximation/ So I'd suggest you check for "approximately" 0, like entity.motionX > 0.0001 || entity.motionX < -0.0001

Updated tutorial, because: After experimenting with attributes for awhile I noticed that Attributes in on themselves don't get send to the client automatically. So I looked for the cause of this, because the netcode actually was there, and found out you need to call setShouldWatch(boolean) after initializing. Added this to Step 1 of the Create a new Attribute part.

If you create a new entity, you may have stumbled across the Attribute System, for example if you want a custom max. health value. Now a detailed explanation on what the Attribute System actually is can be found here: http://minecraft.gamepedia.com/Attribute Here I will show you how to create your own Attributes for your entity and modify all of them in code. NOTE: all attribute classes mentioned in this tutorial can be found in the package net.minecraft.entity.ai.attributes. Create a new Attribute Step 1: To create a new attribute, you first need to create a new IAttribute instance (preferably static final in your entity registry class or somewhere). Now you don't need to make a new class which implements that interface! Minecraft provides us with a standard class currently used for all its own Attributes called RangedAttribute. The constructor of that has the following parameters: IAttribute parentIn - a parent attribute if available, can be null String unlocalizedNameIn - the unlocalized name of the attribute. You can't add an attribute with the same name to an entity, so I usually precede the name with my Mod ID separated with a dot like TurretMod.MOD_ID + ".maxAmmoCapacity" double defaultValue - the default value of the attribute. This value is set as base value when the entity is first created. It can't be lower than the minimum nor higher than the maximum value or else it will throw an IllegalArgumentException double minimumValueIn - the minimum value of the attribute. This value is usually 0.0D. If the entity's attribute value falls below that, this value is used for it instead. It can't be bigger than the maximum value or else it will throw an IllegalArgumentException double maximumValueIn - the maximum value of the attribute. This value is usually Double.MAX_VALUE. If the entity's attribute value falls above that, this value is used for it instead. It can't be smaller than the minimum value or else it will throw an IllegalArgumentException Now at the end, my IAttribute instance variable looks like this: public static final IAttribute MAX_AMMO_CAPACITY = new RangedAttribute(null, TurretMod.MOD_ID + ".maxAmmoCapacity", 256.0D, 0.0D, Double.MAX_VALUE); But wait! If you want to share the attribute value and modifiers with the client, you'll need to call setShouldWatch(true) on that variable. The same way you can disable it, for whatever reason, with false instead of true as the parameter value. Conveniently it returns itself, so you can make a neat one-liner like this: public static final IAttribute MAX_AMMO_CAPACITY = new RangedAttribute(null, TurretMod.MOD_ID + ".maxAmmoCapacity", 256.0D, 0.0D, Double.MAX_VALUE).setShouldWatch(true); Step 2: Great, now you have this useless variable the entity doesn't know about. To make it useful and working with the entity, you first need to register it to the entity's attribute list. To do so, override applyEntityAttributes()(if you've not already done so while changing the entity's max. health) and call this.getAttributeMap().registerAttribute(MY_OWN_ATTRIBUTE_VARIABLE), where MY_OWN_ATTRIBUTE_VARIABLE is firstly an overly long name, but more importantly your variable of your attribute instance created in Step 1. Here's an example from my mod: @Override protected void applyEntityAttributes() { super.applyEntityAttributes(); // Make sure to ALWAYS call the super method, or else max. health and other attributes from Minecraft aren't registered!!! this.getAttributeMap().registerAttribute(TurretAttributes.MAX_AMMO_CAPACITY); } Step 3: The attribute is now instanciated and registered, but how do I use its value? Simple! Just call this.getEntityAttribute(MY_OWN_ATTRIBUTE_VARIABLE).getAttributeValue(). It returns a double. If you want it to be an int, just use the MathHelper from Minecraft, for example MathHelper.ceiling_double_int(doubleVal) Modify an Attribute Now, to modify an attribute, there are 2 ways of doing so: 1. modify its base value This is simple and straight forward, and as mentioned 2 times here so far, you may have already done this via the entity's max. health attribute. But to be complete, here's how you change the base value of an attribute with the example on the max. health: this.getEntityAttribute(SharedMonsterAttributes.maxHealth).setBaseValue(40.0D); //sets the entity max. health to 40 HP (20 hearts) Please note: this does NOT get synched with the client! If you need to edit the base value, make sure you use packets if you want it to be shared (or change it on both sides). Otherwise use modifiers! 2. add modifiers to the attribute This is a "reversable" way of changing the attribute value w/o messing with the base value. What we will do here is essentally this: http://minecraft.gamepedia.com/Attribute#Modifiers That said, much like the Attribute Instance, we need to create our own AttributeModifier instance variable. Conveniently, there is already a class for us to use called AttributeModifier. It's constructor parameters are as follows: UUID idIn - the UUID of this modifier, much like the Attribute name, this needs to be unique per Attribute. I usually give it a pre-defined, hardcoded Ver. 4 UUID via UUID.fromString("MY-UUID"), which was generated on this site. Mine looks like this: UUID.fromString("e6107045-134f-4c54-a645-75c3ae5c7a27") String nameIn - the Modifier name, can be anything except empty, preferably readable and unique for the Attribute. Since the "uniqueness" of the modifier is already defined in the UUID, you can have duplicate names. double amountIn - the Modifier value, can be anything. Note that the attribute, as prevously explained, has a min/max value and it can't get past that! int operationIn - the Operation of the Modifier (careful, magic numbers over here!). Have a direct quote from the Minecraft Wiki: Brief explanation: Operation number is the value you feed the parameter. I also made an enum for it complete with javadoc for you to copy (with credits of course) if you want: https://github.com/SanAndreasP/SAPManagerPack/blob/master/java/de/sanandrew/core/manpack/util/EnumAttrModifierOperation.java Now I've covered the parameters, it's time to make a new instance like this: MY_CUSTOM_MODIFIER = new AttributeModifier(UUID.fromString("e6107045-134f-4c54-a645-75c3ae5c7a27"), "myCustomModifier420BlazeIt", 0.360D, EnumAttrModifierOperation.ADD_PERC_VAL_TO_SUM.ordinal()); You have the new modifier instance, but what do do with it? You can add or remove modifiers from an attribute like this (method names are self-explanatory): entity.getEntityAttribute(MY_ATTRIBUTE_INSTANCE).applyModifier(MY_CUSTOM_MODIFIER); entity.getEntityAttribute(MY_ATTRIBUTE_INSTANCE).removeModifier(MY_CUSTOM_MODIFIER); Alright, you know now everything there is to know about attributes... wait, there's one more thing: attributes are saved and loaded automatically by the entity, no need to do that manually! Just make sure the client knows about the Attribute (register it properly as I've shown).

depends on what you mean with "control entities"

The second Push/Pop pair doesn't do anything. Read here what Push/PopMatrix actually do: http://www.swiftless.com/tutorials/opengl/pop_and_push_matrices.html And yes, first translate to its position, then scale it or you will scale the position as well.

if(world.isRemote) { setDead(); } You're telling the client to kill the entity on impact, not the server...

Nice, definitely using this

Try removing Chromaticraft as it's patching the End provider. [21:32:17] [server thread/INFO] [FML/]: CHROMATICRAFT: Patching class net.minecraft.world.gen.ChunkProviderEnd [21:32:17] [server thread/INFO] [FML/]: CHROMATICRAFT: Successfully applied ENDPROVIDER ASM handler! The server then tries to load the end, [21:32:17] [server thread/INFO] [FML/]: Loading dimension 1 (world) (net.minecraft.server.dedicated.DedicatedServer@7fcd3b8d) freezes [21:32:22] [server thread/DEBUG] [FML/]: Reverting to frozen data state. and ultimately shuts down. [21:32:25] [server thread/INFO] [FML/]: The state engine was in incorrect state SERVER_STARTING and forced into state SERVER_STOPPED. Errors may have been discarded.

The non-coincidence behind that is simply that the = sign acts as padding. It indicates that the last group had only 8 bit (2x =) or 16 bit (1x =) respectively. http://stackoverflow.com/a/6916831

Actually everything (even other mods) that get the biome for specific coords uses that method. It seems like one of those examples where Mojang didn't see the necessity (probably unintentional) to make it safe for multithreading...

... and where do you call your drawRect method (which is useless, since it's the exact copy of drawTexturedModalRect)? A fundamental question: What do you want to achieve with your advanced GUI that is different from a basic one? Also I suggest you setup a Github repo and host your mod code there so we can help you better.

I use the browser. For any kind of API for this forum you need to look over at http://www.simplemachines.org/

1. Please do not create a new ResourceLocation instance every frame, use a static (final) field for it. 2. The z value (or correctly, the z-index) is the "layer" your texture draws on. It is recommended to use the field provided in your Gui instance.

If you look at Gui#drawTexturedModalRect, it multiplies u and v by a static value, fitting a texture of size 256x256. If you want to draw a texture with a different size, you need to copy this method and adjust it to fit your texture resolution. If you do have a texture using this resolution, you're fine to use it, but be careful that in this case u and v are the exact pixel values. But your problem seems to be a different one: You don't bind your texture anywhere when drawing your rectangle, to do so, you need to call this.mc.getTextureManager().bindTexture(TEXTURE_RESOURCE_LOCATION); before you draw your rectangle.