Topics - Dryym

This is a fairly simple idea to give some depth to the game. I think that each fuel should burn at a different temperature. Fuel temperature would determine 2 things. 1: What percentage of the furnace time to use when smelting something. So a really hot fuel will melt gold a lot quicker than a cooler fuel.2: Whether or not a certain fuel can actually melt something. So wood would not be able to melt Titanium.

This would add just a tiny bit of depth to crafting, And I think that bit of depth will improve things. Especially if it was made so that items with a furnace recipe could have a maximum fuel temperature for things like food. This way you can't just cook food with uranium, You'd have to cook it with wood or charcoal (Maybe add charcoal too?)

Currently, Uranium is too expensive to justify using it as a fuel source, And wood burns too fast to justify using it as a fuel source. This would give a reason to use these fuels if you needed to worry about which was the right temperature to smelt the thing you want to smelt.

It's recently come to my attention that HUD elements are based off pixel measurements still. While this was not a problem on 360, With all the possible resolution scales from people's different monitor setups, It could become problematic on PC.

To amend this, I suggest [res:x,y] to variables to retrieve the resolution of the player's screen.

This allows people to position and size HUD elements based on normalized values.

I think jump power should be a thing that is added to zones and possibly scripts with a command.

Before you go off saying "But Dryym, We have a gravity setting in zones", That is not the same thing. The gravity setting changes the gravitational acceleration of the player in the zone. Jump power would change the upwards velocity given to the player when they press the jump key.

Currently, The gravitational acceleration in TM is around 36m/sē, With the jump power being around 9m/s.

If I change the gravity to be that of earth, My character will jump really high because the jump power is really high, But they will fall down at the same rate as a human on earth would.

Conversely, If I increase the gravity, I will fall faster and jump lower due to the jump power being lower relative to the acceleration.

With a jump power option, You can change how high the player jumps independently of how much they accelerate downwards.

Perhaps this could even be set to allow the double jump to have a different power setting than the initial jump.

This idea is simple on paper but will probably require a lot of back end work, However I would imagine that a lot of the changes to terrain generation required for this to happen will need to be done for infinite worlds anyway.

In simple terms, A biome would be a set of localized terrain generator settings that can spawn in the world.

Currently terrain generator settings can only be applied to the whole world. This means that it is impossible to have shallow hills and mountainous mountains at the same time.

With biome generator settings, You could make a mountainous biome which has steep terrain which is mostly stone, And you could also have hilly terrain with gradual rolling slopes.

The terrain settings menu would have to have a new option called "Add Biome" where you could choose to add a new biome to the generator.

In addition to this, There would be a new group of biome specific settings which are as follows.

Biome Min/Max Size: The minimum and maximum size of a biome in blocks.

Biome Min/Max X/Z: The minimum/maximum X/Z coordinate in which this biome will appear. Useful for making colder regions to the north and south of the world whilst making equatorial areas more temperate.

Biome Frequency: The likelihood of this biome appearing compared to any others.

Biome Neighbour Whitelist: These biomes must be neighbouring for this biome to spawn. Useful if you have a multiple part biome like medium mountains and tall mountains.

Biome Neighbour Blacklist: These biomes must not be neighbouring for this biome to spawn. Useful for making sure deserts do not spawn directly next to snowy regions or anything similar.

Biome Ground Layer: Only available to creative worlds, Or limited to certain blocks for survival worlds. Determines the ground block for the biome.

Biome Ore Deposits: Only available for creative worlds. A group of settings that determine which blocks spawn in ore veins at what layers and how frequently.

This should be enough to allow for some complicated world creation whilst still being accessible.

First off, Let me state that I know sprinting is one of the most requested ideas by far, And it always gets shot down because we already move faster than MC sprinting.

I am not suggesting sprinting to increase our speed even further past that, That would be ridiculous. Instead I am suggesting that we reduce the default speed of the player and all mobs and make the current default speed be sprinting speed.

The reason for this is simple. Without a difference in speed, Chases in combat will get nowhere. If sprinting is added, Then this will allow defenders a chance to make a speedy getaway, And it will allow attackers a chance to close the gap. Assuming that sprinting has a limited timer, Chases will become more enjoyable because you will have to time your sprinting to either get away, Or close the gap.

Another side effect of this is that it gives you a limited chance to run away from mobs that are normally way faster than you. Eg. Werewolves and Trolls.

Combat in TM has potential with its unique weapons and armours, But the movement system totally kills that potential by making combat a jumping contest. This would be the first in many steps to fix that and make combat more interesting.

People have been complaining about the ice ring since 2.0, And since we are currently on the transitional state to the PC version, I think now is the best time to make a simple and fundamental change to it to make it more balanced.

The idea is that when wearing the ice ring, Upon a successful hit, The player is frozen as before, But in addition, Their defence stat is kicked up to max, Making them nearly impossible to hit. In fact, Hitting them would reduce the time that they are frozen for. They would also lose their ability to attack, And their health regeneration would be slowed dramatically. All of this is designed to simulate the player being actually frozen in a block of ice.

This turns the ice ring from an annoying offence item to a defence item. Say that you are losing a fight, You can put on the ice ring and freeze your opponent in place to give you a chance to run away and regenerate. You can already do exactly this, But with the defence boost to the person being frozen, As well as the fact that attacking them reduces the timer, It removes any and all offensive use for the ring.

The same can be applied to ice arrows (Oh, The ice ring shouldn't apply to arrows anymore either.) If you are an archer, You don't want a melee attacker getting close. So when they close the gap too much for your own comfort, You can switch to an ice arrow and run away.

Granted, This would still be slightly annoying if you are on the receiving end of it, But you will no longer have to deal with being completely helpless as someone whittles your health away with their wooden sword against your full titanium armour. Instead, You'll just need to accept that sometimes someone will freeze you and run away.

A Grue is a fearsome monster with slavering fangs, Razor sharp claws, And an insatiable hunger only rivaled by their fear of light.

Grues would be an uncommon random spawn in any dark area, Be it underground, On the surface, Or in someone's basement.

Grues would have really high strength, Attack, And Defence levels, With a medium health level.

Grues would also have no nameplate, Making it difficult to spot one. To spot a Grue, Watch for their movement, And listen for their horrible gurgling sounds.

If you are killed by a Grue, The death message displayed would be "[player] was eaten by a Grue." And the only way to retrieve your inventory is to kill the Grue.

The easiest way to deal with the looming threat of the Grue is just to light up your areas. Grues are terrified of even the smallest amounts of light, So holding a torch or standing on gold will be enough to keep them at bay. If a Grue is caught in light for more than a few seconds, It will instantly combust and die.

If a Grue is killed in combat, It will drop a Grue Heart item. This item can be worn and gives massive combat buffs when the player is in total darkness, But deals immense damage to the wearer if they are in light.

Guns with an ammo amount stored to the gun itself.Guns that do more damage when headshotting an enemy.Bullet particles that stop when they hit an enemy.A better reloading system.

This script is currently balanced around the default 148 HP of a player without skills. It takes 5 body shots to kill and one headshot.

The way guns store ammo is via durability. Durability is better than history for storing ammo because it means each gun has a unique ammo count. If you kill a player and pick up their gun with this system, Their gun will have the same amount of ammo for you as it did for them when they died.

If you used a history system, You would have the same ammo counter for all guns of the same type.

Another unique thing about this system is that if you have less than the max ammo of the gun and you reload, It will give you a gun with less than 100% ammo capacity. Ex. 6/7

This means no matter how much ammo you have, You can still reload your weapon.

This also does more damage with headshots. Though the headshot radius is based off of the zombie's fat head, So it could be balanced better for PVP.

One last thing to note, This script may not work exactly as shown here on future PC versions, It takes advantage of a small bug to cut down on intersect conditionals in the shooting script.

Craig has said he has no idea what causes the bug, But it could possibly be fixed in the future.

A state of eternal punishment and damnation into which a sinful and unpenitent person passes after death.

Perdition is a deathmine that takes place in Hell.I am sure most of you are aware of the deathmine world concept. I'm going to try to make it different enough for it to be somewhat enjoyable, But similar enough that people may actually play it.

The main "gameplay" of the map is mining rock to sacrifice to the lord of Hell, Nergal. In reward for your sacrifice, You gain Blood Points, Which can be sacrificed to obtain better gear, Potions, Etc.

Upon death, You will lose 10% of your Blood Points in order to create a new physical form for your soul to reside in. If you have less than 1000 Blood Points upon death, You will be cast into The Abyss where you must destroy the bodies of other lost souls to regain enough Blood Points to return to Hell.

Upon being killed by a player, You will lose 5% of your blood points, Which are then given to your killer.

For players not content with Deathmines gameplay, There is a side quest that can be played that may actually be somewhat fun.

You can choose to leave the underground portion of Hell and explore the plains of Hell. On the plains of Hell, You can find mobs such as Hell Spiders, And Lost Souls.

These mobs can be killed for Blood Points and additional gear.In addition to these, You may find Demons. Demons are tough mobs with advanced AI and magical attacks.

Upon killing a Demon, You can obtain its soul. Demon souls are sacrificed in exchange for demonic powers.

The plains of Hell are also entirely PVP enabled, Allowing you to test your equipment on other players, As well as mobs.

So, Yes. I am a hypocrite. I hate Deathmines, And yet here I am adding to the problem. But hey, I guess I am spending my time in Hell for it.

My reasoning behind making this map stems from the fact that my medieval map is unfeasible on 360.

I put so much work into that map that the fact that it won't work is kinda heart wrenching.

PWRBTTN said that I should be less ambitious, And I joked about the fact that that would make me a Deathmines host. So here we are.

I'm not doing this so that I can get Demis (Unlike some people...) I am doing this because in how many years I have played this game, I have never once hosted a playable map openly. I have tried, But that never worked out for me. With the 360 community on its last legs, The only shot I really have is a somewhat decent Deathmine to be honest.

It's the right balance of something people would want, And something that I can do quickly.

A super simple idea, It should be possible to use the ID of a block or item in scripts. This could be done by allowing [Block:ID] and [Item:ID] to be used anywhere where where blocks or items get input.

ID could accept a var, Which is where this gets actually useful.We would also need to be able to retrieve the ID of a block via vars.

This would be useful for things like storing the player's entire inventory, Or a block structure to memory, Etc.

I think it would be great if we had a conditional that simply checks if a set command can execute and make a change.

In some uses, This would just be a matter of convenience, In others, It would allow for entirely new conditions that wouldn't be possible otherwise.

Some examples include

"If CanExecute [Var [Health] = [Health:]] [True]Then Var [Health] = [Health:] // Player HP has changed since the last time this was executed. // Would normally require 2 vars to be created in order to detect a change.Else // Player HP has not changed since the last time this was executed."

"If CanExecute [CaveIn [x,y,z]] [True]Then // No caveins active on the map, And the coordinates are valid. // Determining whether or not a cavein is happening would normally require a conditional that doesn't exist."

"If CanExecute [CopyBlock [x,y,z] [x,y,z]] [True]Then // Checks whether or not two blocks match each other exactly, Or of the coordinates are valid."

MC has this in the form of comparitors facing off of a command block, It effectively turns all commands into conditionals if you decide to use them that way, And I think it could be really useful to people who are more creative with scripts.

I don't know if scripts can tell whether or not the command actually changed anything, But I know that they can tell whether or not the command is valid, And if not, What went wrong. So it feels like this is half way there.