Jump to content

hydroflame

Members
  • Posts

    1511
  • Joined

  • Last visited

Posts posted by hydroflame

  1. in your class extending itemFood, change the itemUseDuration thats wrong becase itemUseDuration is final

     

    try making a class that extends Item and copy the code of ItemFood, call this class ItemFoodCustom or wtv and remove final from the itemUseDuration THEN try to make a class extends ItemFoodCustom and change the itemUseDuration

  2. place a delay in the nbt of the itemstack

     

    then onItemUse check if it has been enough time since last shot

     

    ps: people will still be able to switch between 2 itemstack and still sortof spam, but itll limit the spamming becuase it would be kinda annoying to 1, right-click, 2, right-click, 1, right-click, 2, right-click, 1, right-click, 2, right-click, 1, right-click, 2, right-click

     

  3. what mazetar said, your client proxy is importing

    WayofTime.alchemicalWizardryCommonProxy

     

    which doesnt exists because its actually

    WayofTime.alchemicalWizardry.common.CommonProxy

     

    note the package declaration at the begining of both class.

     

    having different names causes the compiler to not understand wtf you're talking about

     

    pro tip and trick:

    in eclipse, pressing ctrl+O will fix all import problem

  4. Yes, but that also slows down the player quite a bit, which I don't want to happen :/

    well ... maybe you could ... i don't know .... NOT include that part of the vanilla bow code

    .......

    .........

    ......

    ....

     

    if that doesnt work i suggest you use the custom nbttagcompound on the item stack to keep track of the number of tick this was behing held for

     

    somehting like

     

    onUsingItemTick(args){
    this.nbtwtv.setInteger(this.nbtwtv.getInteger("tickheld")+1);
    }
    
    onPlayerStoppedUsing(args){
    this.nbtwtv.setInteger("tickheld", 0);
    }

     

  5. Hello Guys!

    I want to add a Mana-bar available for each player. It should have a maximum value of 250 Mana and should be rendered above the hunger-bar. The Mana bar should regenerate by one each second and should be increased by about 20 for each punch with a sword.

    Does anybody know, how to do this?

     

    you're gonna have to make a handler for RenderGameOverlayEvent to render the mana, to make it regenarate you're goign to need a TickHandler that ticks every second and regenerate the mana there.

    to store the mana you're goign to need some sort of data structure (hashmap) and store a relation between the players and the mana (String -> float[]{min, max} OR EntityPlayer -> float[]{min, max})

    to restore on hit just to a PlayerInterractEvent handler, you will also need to send the update on mana via packet handling

     

    How can I change the maximum Player Health to 250

    either make a base class change (making your mod incompatible) or do use a EntityLivingHurtEvent handler (or wtv its called) and transform the damage there (aka if you receive 5 dmg the end damage would be 5/250 of max hp) youll also need a RenderGameOverlayEvent handler for this as steve HUD health is based on a 20 basis (20 half heart) or you could just cancel the damage if its not close enough to be 1 after transform (aka if you receive 5 you would take technicly 5/250 of your hp but that not even 1/20, so just make the dmg zero and update whenever the damage pass a 1/20 threshold)

     

    how can I change the Armor-calculator (I want to use another Formula then Armor*0.04)?

    same as health, make basechange OR deal with it in a event handler

     

     

     

    ps:you're trying to do a lot...

    do what you want :P

  6. this calc need rly much perform.

     

    have you even tried it with every tick? are you expecting the results of ruby to be comparable to those of java, because ruby is an interpreted language while java is compiled to bytecode making it's speed WAY closer to native speed. If you don't trust me go ahead make it every 6000 tick, but at least try it

     

    EDIT: i tried it with my server (performance similar to yours) and this part of the code did not affect my performance even by the smallest amount. To check the difference, look at the average tick time on your server with and without, you should NOT see a difference as ~7 addition and ~12 multiplication/division is nothing for a machine these days, even with only a 1ghz cpu.

  7. ok, well 2 things, either this code is copy pasted, either you name your variable in very weird ways (f1, f2, f3, f4, f5, f6) in either case im not suuure exactly where the problem is because im not sure hat youre trying to do but honestly by looking at the code it seems that the picture is doign EXACTLY what you asked it to do...

     

    tessellator.addVertex(-8.0D, -2.0D, 0.0D);
    		tessellator.addVertex(8.0D, -2.0D, 0.0D);
    		tessellator.addVertex(8.0D, 2.0D, 0.0D);
    		tessellator.addVertex(-8.0D, 2.0D, 0.0D);

    ^ this is a pretty big rectangle actually

     

    GL11.glDisable(GL11.GL_TEXTURE_2D);
    	GL11.glDisable(GL11.GL_LIGHTING);
    	GL11.glEnable(GL11.GL_BLEND);

     

    ^ blending is enabled so you expect your bolt to be transparent, texture2D are DISABLED, so no image on your bullets and lighting disabled... result may vary since its LWJGL and opengl1

     

    i would try to play with glEnable/glDisable those 3 thing above.

    other then that, if you want to play if safe, remove a MAX ammount of code and add little by little

     

    and hum ..... if you dont know what the code is doing ... try understanding first ... usually copy paste dont get prople very far ..... sorry if its mean :\

  8. <troll> pic or it didnt happen </troll>

     

    no no just kidding, but srly can we have some pic / video so we can understand whats going on

     

    because since you are usign a renderer, the problem can now be anything, maybe its you graphic card, maybe your opengl 1 setting are in an odd state causing this effect etc etc

  9. you would have to 1 change the entity size and 2 make a renderer (like i said earlier). EntityThrowable will always be rendered in a way that will make them look like the image is facing the player, if you want to have more realistic bullet you're gonna have to make a class extends Render and register it in your client proxy

  10. //hides
    package com.hydroflame.mod;
    
    import java.util.EnumSet;
    
    import net.minecraft.entity.player.EntityPlayerMP;
    
    import cpw.mods.fml.common.ITickHandler;
    import cpw.mods.fml.common.TickType;
    
    public class ServerPlayerTickHandler implements ITickHandler{
    
    @Override
    public void tickStart(EnumSet<TickType> type, Object... tickData) {
    	// TODO Auto-generated method stub
    
    }
    
    @Override
    public void tickEnd(EnumSet<TickType> type, Object... tickData) {
    	EntityPlayerMP player = (EntityPlayerMP) tickData[0]
                    //do stuff with the player
    }
    
    @Override
    public EnumSet<TickType> ticks() {
    	return EnumSet.of(TickType.PLAYER);
    }
    
    @Override
    public String getLabel() {
    	return null;
    }
    }
    //hidee

  11. not compared to most problem, this time the right thing is happening on server side but not on client side

     

    so heres how it goes, im spawning an entity server side (some sort of AOE that will damage living inside it)

    it gets spawn client side too, but this entity will move itself client side because it doesnt like to be in collision with blocks (the aoe doesnt care about living)

     

    so i spawn the entity 1 block deep in the ground, server side will keep it there but client side will move it one block up to the surface.

     

    here my onupdate method, on the constructor i have noClip = true; but that doesnt seem to change anything

     

    @Override
    public void onUpdate(){
    	this.lastTickPosX = this.posX;
            this.lastTickPosY = this.posY;
            this.lastTickPosZ = this.posZ;
            updateEntity();
            ticksExisted++;
            if(ticksExisted > tickAlive()){
            	this.setDead();
            	return;
            }
            
            if (!this.worldObj.isRemote)
            {
            	if(caster == null){
            		this.setDead();
            		return;
            	}
                List list = this.worldObj.getEntitiesWithinAABBExcludingEntity(this, this.boundingBox);
                EntityLiving entityliving = caster;
                EntityLiving touched;
                for (int j = 0; j < list.size(); ++j)
                {
                    Entity entity1 = (Entity)list.get(j);
    
                    if (entity1.canBeCollidedWith()&& entity1 instanceof EntityLiving)
                    {
                    	onImpact((EntityLiving)entity1);
                    }
                }
    
            }

     

    im thinking maybe the game clinet side moves the bounding box around when he gets collision with block but i cant seem to find where, and more importantly, how to prevent it

     

    any help is appreciated, thanks ^^

     

    edit: by saving the posX/Y/Z at the begining of the update method and restoring at the end i have determined that thsi change does NOT happen during the update phase :\, which actually leaves me even more clueless as to why this is happening

     

     

     

    SOLUTION:

     

    so further investigation demonstrate that a packet sent from the server (Packet30Entity) was causing this change. now why this packet had different data then the actual server values that i cannot tell exactly but it seems that it has something to do with the function expand(double, double, double) that the physics engine calls on server side

     

    my solution was to simply Override the setPositionAndRotation2 method from Entity and leave it blank, anyway in my case the movement are very precise and should require sync between the server and the client

     

     

     

     

    ... 3 view only and 2 of them are mine for my 2 edits ... jeez was this question that retarded ?

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.