an idea ive been playing around im my head

[demthon]

so I had an idea for a map a volcano with digitalis rivers and every thing but as I was making it I found a problem. the height limit. I wanted something with a massive basin and i couldn't get the amount of creeper I wanted in the basin and if i could there was the problem of making an good sized hill for the creeper to flow down anyone else running to this kind of problem

[teknotiss]

are you asking for more terrain heights?
ie more than 10?
if so, i have wanted more, but i don't know if it's something CRPL could add, or if it's a game global limit, sorry, perhaps V can answer that part.
but straight question of anyone else want more height = yes, just not enough to start a topic on it :D

if you need HUGE amounts of Creeper to be held in one place there will be/is a CRPL script for that.
if you need C to be released to flow in a particular way, there will be/is a CRPL script for that.
have a look and if you don't see what you need, or get a bit lost by the jargon (i'm no code monkey myself) ask one of the dudes in "The Coders Corner" and they'll get you going in the correct direction.
hope that helps  8)

[Grauniad]

The number of terrain levels are intrinsic to the game and cannot be changed. Putting an emitter on void adjacent to terrain will create an appearance of an emitter at height 500.

[knucracker]

Right near the very end of development I slipped in these CRPL commands:
SetTerrainOverride(x y height) and GetTarrainOverride(x y).

With the Set command you can make a cell of terrain have an effective height that is much greater than 10.  That's how I prevent the Creeper from overflowing the walls in the credits mission.

Now it isn't perfect... terraforming gets axe'd since you can terraform the terrain all you want but the terrain override remain in effect.  But if you don't  allow the Terp or the mass driver in a mission, this problem can be avoided.

So, you could paint a map however you like, then write a script that runs once at game start.  That script would scan over every cell in the map and set a terrain override that is 100 times the actual terrain height.  So terrain height 1 becomes 100 and 10 becomes 1000.  That will allow for really large values of Creeper to pile up before overflowing.

[teknotiss]

just to be clear, that means still 10 terrain "heights" but the "height" of each terrain is increased?

[Grayzzur]

I've been playing with this. Think of it as the terrain height doesn't change, but there's an invisible glass wall that goes as high as the override height. You can terp the terrain level, but that glass wall stays put.

Virgil, call me a noob, but I'm not sure what you mean by mass drivers.

[knucracker]

I'm talking about the artifact of Odin that gives you a mass weapon. It gets dropped from orbit and leaves a crater. It won't affect the terrain override either.

[4xC]

It is however the only way to affect the terrain levels of totems.

[Grayzzur]

I'm talking about the artifact of Odin that gives you a mass weapon. It gets dropped from orbit and leaves a crater. It won't affect the terrain override either.

Aha. I've only played a couple Prospector/Tormented maps. I didn't realize those artifacts did anything. That's going to open up some possibilities.

[egos]

With a linear adjustment to the height, as V suggested, it is the equivalent to allowing the map designer to change the gravity of the world. With a higher gravity, the creeper would require more depth/density to make it to the next terrain step.  This gives the opportunity for complete control of gravity when with with the use of moons, or adjusting the gravity on certain parts of the map. 

I am curious if it would be too computationally intensive to run/rerun a terrain override script regularly, so that one could allow for the use of terps.
If not regularly, maybe once every 30 or 60 seconds. If the player was aware of this, it could introduce some interesting timing sensitive strategies to defeating a map. 

[kwinse]

Could also be used to create creeper-free zones of the map, if there's not already a better way to do it...

[Grauniad]

Terrain scripts are computationally very, very expensive.

[Grayzzur]

My understanding is changing terrain is expensive due to the changing textures. I'm guessing changing the terrain override height isn't that way, and I'd guess that the Get commands don't create that penalty either. So, regularly changing the override height at the rate player terps are modifying the terrain sounds to me like it wouldn't be too bad, the terps are doing the computationally expensive change already. You wouldn't want to do it every update cycle, but could probably do it often enough that the player couldn't take advantage of the lag.

Loop through the terrain cells, Get both height and override height, if it doesn't match your linear scale, Set the override height.

[Kingo]

My understanding is changing terrain is expensive due to the changing textures. I'm guessing changing the terrain override height isn't that way, and I'd guess that the Get commands don't create that penalty either. So, regularly changing the override height at the rate player terps are modifying the terrain sounds to me like it wouldn't be too bad, the terps are doing the computationally expensive change already. You wouldn't want to do it every update cycle, but could probably do it often enough that the player couldn't take advantage of the lag.

Loop through the terrain cells, Get both height and override height, if it doesn't match your linear scale, Set the override height.

Changing a texture isn't too taxing on the program... I imagine having many projectiles flying around would lag the game down more then overriding the terrain.
Of course, I didn't build the CW engine, so maybe I am wrong. In the game I am programming, though, changing textures every update cycle doesn't seem to make much difference in terms of performance.

[eduran]

I did some testing and SetTerrainOverride is way faster than SetTerrain. Even when looping through every cell on a 150x150 map I didn't notice any lag (do that with SetTerrain and the game takes several seconds per frame). So using it regularly shouldn't be a problem.