WIP Beta released Avalanche Climb 0.8.2.1

Does this by chance use the portals? Like on Simple Map?

 

I like the idea, I hope to see more like it in your future scenarios!

 

Nice little concept ! It's quite fun to mess around with
But the fact that the car is also teleported up the cliff when falling down bothers me...

I think you could prevent this by adding a new condition for the trigger to teleport the vehicles : that it's not the player vehicle
This would look like this :

Code:

local function teleportPlayer(data)
    local vehicleName = data.subjectName

    if data.event == 'enter'  and data.subjectName ~= 'scenario_player0' then
        TorqueScript.eval(vehicleName..'.position = "101 -59.6 1061.003";')
    end
end

return teleportPlayer

 

I love when people play with experimental stuff, I think it starts encouraging other mod creators to push the envelope a bit

 

Oh yeah, just to clearify I meant; I couldnt get the berrel idea to work with the new version but everything does work fine before I mess with the files. I just replaced the rock references from the first scenario wih barrels. Im only a "copy and paste programmer" so I couldnt debug it.

 

Great idea @HighDef, thanks for making this. I'm going to take a look into whether anything can be done about the physics engine freak-outs that can happen during resets. I didn't really enjoy the large concrete blocks or the tiny stones - I completed the rest with the default pickup and also played with the offroad Sunburst. Plenty of fun!

I noticed that your teleporter code may be a bit of a pain to do maintenance on because you can't see where each one comes out. Here's a script that establishes a target such as a waypoint. That way you can use the script and have a tangible target to work with. It also means that you can bulk select targets and move them around, etc.

These examples/notes are really focused on moving the player around but I'm sure you'll easily see how to hook the code up for your purposes.

Here it is as a one-liner to play with from the console on Gridmap, targeting Waypoint 2:

Code:

local subject = 'thePlayer' local target = scenetree.findObject('wp_2'):getPosition() target = tostring(target):gsub("[,]", ""); TorqueScript.eval(subject..'.position = "'..target..'";')

Or formatted a little:

Code:

local subject = 'thePlayer'
local target = scenetree.findObject('wp_2'):getPosition()
target = tostring(target):gsub("[,]", "")
TorqueScript.eval(subject..'.position = "'..target..'";')

If the player's vehicle is selected/in-focus you can use getPlayerVehicle(0) instead of a name/label. That could look like this for example:

Code:

local subject = 'getPlayerVehicle(0)' local target = scenetree.findObject('wp_2'):getPosition() target = tostring(target):gsub("[,]", ""); TorqueScript.eval(subject..'.position = "'..target..'";')

Other thoughts on your scenario format:

1. The snaky path up is a little simplistic and with some of the obstacles it results in pretty predictable flow. There's also a tendency for some objects to start sliding instead of bouncing. Maybe a rockier surface with LESS drastic contouring but more aggressive lips and crannies would result in more chaos.
2. This is likely something you've already considered: I'd like to see a scenario where the obstacles have MORE stopping power, but do LESS damage to the vehicle. I imagine that it would have an effect similar to the plants in Utah.
3. I think that all of these could be converted to quickraces so that people could change vehicles while competitive scenario conditions is turned on. This would also give you a local high scores table as a bonus...
4. A downhill one could be fun. I tried it with the big rocks. I think that hotlapping (one of the QR formats) with big rocks and a lighter grade would be great... you'd be rocketing downhill with boulders bouncing around you and everything repeatedly warping to the top. I've attached a quick and dirty pair of files for that as a scenario, but it would work much better as a quickrace w/ hotlapping. What I think would be best would be to maintain similar teleportation targets for the boulders but filter out the player into a set of targets which is closer to ground level in order to make it easier to maintain control. A lighter grade might necessitate some extra tricks to keep the momentum up on those big rocks.
5. You can just drive straight up the hill outside of the obstacle-chute. Obviously this spoils the fun, but it seems best to fix that. Just add a wall, ledge, etc.
6. Naming your map "hill" is asking for trouble with name collisions.
7. You've got some errors in your hatch configs and info jsons. Please check the log (~). Looks like you forgot to put quotes around a string here and there, eg NA should be "NA".

--- Post updated ---
PS:

• Really we should probably break all of that Lua out of those triggers and into a function, extension, or something. That would be much cleaner - you'd just pass the subjects and targets as arguments. Then changes to the Lua could be made in a central location.
• Similarly, the teleport triggers and (hypothetical) target objects can all be moved to a single prefab. Each scenario can load as many prefabs as you need. This way you can centralize your management of these items as well!

--- Post updated ---
PPS:
I'm a bit out of date! We can now achieve a teleport with an all-Lua script:

Code:

local subject = 'thePlayer' local target = 'wp_2' scenetree.findObject(subject).position = scenetree.findObject(target).position

or

Code:

local subject = 'thePlayer'
local target = 'wp_2'
scenetree.findObject(subject).position = scenetree.findObject(target).position

pretty simple...

 

No problem. I've only worked with triggers a little bit in the past, but I don't think it will be a big deal to get this implemented. Some official content uses triggers so we've got something to refer to.

 

Wahoo!! I cannot wait to fire the bad boy up again!