Last couple days I've been buckling down and working on that pyramid wonder I promised to make a while ago. It's 25 blocks tall and has 4 'layers' which each consist of a randomly generated maze (so each time should be a unique experience). The structure naturally comes with plenty of dungeon chests (along with some sneaky mimics) and plenty of Mummy mob spawners.
Read more ...
Showing posts with label Desert. Show all posts
Showing posts with label Desert. Show all posts
Update on Bird AI, Mammoth, and Night Bloom
Today was a very productive day. I was honestly worried I wouldn't be able to solve the memory leak when the vultures were attacking. But when I woke up I systematically went through the code and managed to get it out. It seems minecraft was getting angry when I assigned a variable in the update loop to something in the class, it didn't have this issue for the following loop for some reason, even though it was the same variables being assigned. Instead of saving entity.pos - target.pos to one variable and then calling it, I just inserted entity.pos - target.pos within the code a shit ton of times. Go figure.
Anyway, vultures are setup as follows. They have three states, Idle, Following, and Attacking. The way the state check works it it evaluates whether the state should change, if it shouldn't this portion of the code will not effect the entity at all. So if its attacking or following, it'll check if it should switch to idle if the target is null or too far away. It'll then set the target to null (to make sure its not chasing anything) and set State to Idle.
If a player comes within a distance of 12 (along the XZ plane, y coordinates are ignored) the Vulture will move towards a point a distance of 12 blocks above its target. Once there it has a small distance its allowed to move in. I currently haven't actually got the vultures to circle yet. They kinda just cluster up and move randomly. I probably won't be able to get them to actually circle until I introduce some kind of pathfinding and a muti-point way point system.
Finally they will if the current health of the player is less than the number of nearby vultures multiplied by four. This means it takes 5 vultures to attack a player at full health.
And A video of that being demonstrated.
I also did some small work on some textures. Tried to do some work on the Palm Tree, but ultimately failed to find a suitable replacement. Did up some textures for a plant Idea I had for plains. Nightbloom. It'll have a chance every night to open, at which point it'll act like a torch.
Last but not least I managed to do up the model for the Mammoth. Still needs ears. But I should be able to do up a texture tommorow. Or maybe the day after if I want to update.
Read more ...
Anyway, vultures are setup as follows. They have three states, Idle, Following, and Attacking. The way the state check works it it evaluates whether the state should change, if it shouldn't this portion of the code will not effect the entity at all. So if its attacking or following, it'll check if it should switch to idle if the target is null or too far away. It'll then set the target to null (to make sure its not chasing anything) and set State to Idle.
If a player comes within a distance of 12 (along the XZ plane, y coordinates are ignored) the Vulture will move towards a point a distance of 12 blocks above its target. Once there it has a small distance its allowed to move in. I currently haven't actually got the vultures to circle yet. They kinda just cluster up and move randomly. I probably won't be able to get them to actually circle until I introduce some kind of pathfinding and a muti-point way point system.
Finally they will if the current health of the player is less than the number of nearby vultures multiplied by four. This means it takes 5 vultures to attack a player at full health.
And A video of that being demonstrated.
I also did some small work on some textures. Tried to do some work on the Palm Tree, but ultimately failed to find a suitable replacement. Did up some textures for a plant Idea I had for plains. Nightbloom. It'll have a chance every night to open, at which point it'll act like a torch.
Last but not least I managed to do up the model for the Mammoth. Still needs ears. But I should be able to do up a texture tommorow. Or maybe the day after if I want to update.
Labels:
Desert,
Minecraft,
Progress Report,
Project Zulu,
Vultures
Project Zulu v0.2.4 Released
Released v0.2.4 with the newly programmed vultures. Including a number of small tweaks/bugfixes.
ChangeLog for good measure:
-Added Armadillo Takecover
-Fixed Sandworm and Lizard spawning in larger than intended groups
-Fixed Lizard and Sandworm sounds
-Added Sandworm sand sound when 'walking'
-Added Vultures a new mob
-Increased palm tree sapling drop rate from leaves
Spent all day working on Flying AI. Encountered a weird bug where the Flying entity would get stuck on top of a block when it tried to fly down into it. This manifested in an odd manor (what bug doesn't) where the server would just let it sit there but the client would continue making it fly like normal. Which would appear tot he user as an ghost entity which would shoot back to the ground every time the server would update (read override like a boss) the client position. Setting !world.isremote arond the movement code solved the graphical glitch while forcing the entity to always fly up when below ground level +3 reduces how often the bug occurs.
I don't know how/if I'll ever be able to make them land, which was my hope for owls in the forest. I'll probably have to hold off on those till I can fix this because while nothing in the desert can obstruct the vulture, there is a whole forest of trees with no room between them. I'd have to hold off anyway until I implement some simple A* anyway I suppose. I could try making them able to fly through leaves, but I think that might not make for a fun enemy to fight.
Maybe I'll look into a onDall/onCollide with a block to set motionY up. Or maybe I'll jsut constantly try to move up by half-block. I think thats how Notch handled mobs encountering halfblocks.
Read more ...
ChangeLog for good measure:
-Added Armadillo Takecover
-Fixed Sandworm and Lizard spawning in larger than intended groups
-Fixed Lizard and Sandworm sounds
-Added Sandworm sand sound when 'walking'
-Added Vultures a new mob
-Increased palm tree sapling drop rate from leaves
Spent all day working on Flying AI. Encountered a weird bug where the Flying entity would get stuck on top of a block when it tried to fly down into it. This manifested in an odd manor (what bug doesn't) where the server would just let it sit there but the client would continue making it fly like normal. Which would appear tot he user as an ghost entity which would shoot back to the ground every time the server would update (read override like a boss) the client position. Setting !world.isremote arond the movement code solved the graphical glitch while forcing the entity to always fly up when below ground level +3 reduces how often the bug occurs.
I don't know how/if I'll ever be able to make them land, which was my hope for owls in the forest. I'll probably have to hold off on those till I can fix this because while nothing in the desert can obstruct the vulture, there is a whole forest of trees with no room between them. I'd have to hold off anyway until I implement some simple A* anyway I suppose. I could try making them able to fly through leaves, but I think that might not make for a fun enemy to fight.
Maybe I'll look into a onDall/onCollide with a block to set motionY up. Or maybe I'll jsut constantly try to move up by half-block. I think thats how Notch handled mobs encountering halfblocks.
Labels:
Desert,
Minecraft,
Progress Report,
Project Zulu,
Release
Project Zulu Officially Released
Project Zulu Officially Released on the minecraft forums.
I spent most of the morning fixing a bug I found testing the server last night where triggering the armadilo's 'take cover' mode caused the server to crash. The problem ended up being that the method to determine what item the player is using:
entityPlayer.getItemInUse().itemID != Item.bow.shiftedIndex;
apparently its only called clientside. isUsingItem(), however, is called server side. So I can know the player is using an item, but not what it is. So close, yet so far. At this point I pull out my hair and decide to take a break with some modelling.
The TreeEnt came out okay. Still gotta do some more work. Move the head up. Add long veins along various body pieces. Fingers. Toes on other side. I'm also thinking of small stick with a square block for leaves coming out the back. Not sure how it'll work out. But alas only so many hours in a day.
I spent the rest of the day tweaking oasis. I was going to change the current flat inline model to one where a sand dune wall formed around it but decided against it. Eventually I'll add the Dune Oasis as an alternative have one or the other spawn randomly.
Finally Packaged everything up and ran it on the server to see if anything caused it to crash. Success! Everything is working fine. I figure I can solve the armadillo problem by using EntityPlayerMP (should seem obvious but meh) as it has an itemstack and armor command. Which reminds me now to wonder how I can access the armorID for the exhaustion system but not the current item.
Anyway I don't feel like delaying the mod another day. I honestly never really cared for the take cover mechanic on a practical level. It seemed an illustration of 'look what I can do' than 'I wish it would do this'. It can still charge so it's more unique than a zombie.
Alas, Project Zulu was Officially Released on the minecraft forums. I sound my victory yodel and go watch some futurama to calm down before I go to sleep.
Read more ...
I spent most of the morning fixing a bug I found testing the server last night where triggering the armadilo's 'take cover' mode caused the server to crash. The problem ended up being that the method to determine what item the player is using:
entityPlayer.getItemInUse().itemID != Item.bow.shiftedIndex;
apparently its only called clientside. isUsingItem(), however, is called server side. So I can know the player is using an item, but not what it is. So close, yet so far. At this point I pull out my hair and decide to take a break with some modelling.
The TreeEnt came out okay. Still gotta do some more work. Move the head up. Add long veins along various body pieces. Fingers. Toes on other side. I'm also thinking of small stick with a square block for leaves coming out the back. Not sure how it'll work out. But alas only so many hours in a day.
I spent the rest of the day tweaking oasis. I was going to change the current flat inline model to one where a sand dune wall formed around it but decided against it. Eventually I'll add the Dune Oasis as an alternative have one or the other spawn randomly.
Finally Packaged everything up and ran it on the server to see if anything caused it to crash. Success! Everything is working fine. I figure I can solve the armadillo problem by using EntityPlayerMP (should seem obvious but meh) as it has an itemstack and armor command. Which reminds me now to wonder how I can access the armorID for the exhaustion system but not the current item.
Anyway I don't feel like delaying the mod another day. I honestly never really cared for the take cover mechanic on a practical level. It seemed an illustration of 'look what I can do' than 'I wish it would do this'. It can still charge so it's more unique than a zombie.
Alas, Project Zulu was Officially Released on the minecraft forums. I sound my victory yodel and go watch some futurama to calm down before I go to sleep.
Labels:
Desert,
Minecraft,
Project Zulu,
Release
Subscribe to:
Posts (Atom)






