Bragging: MoH: Paintball, (56k warning)

[Cheetohs]

Wow. that map looks really cool.... One thing id like to point out is that it is CTF, like you said, well... there's going to be a lot of open space to cover! might cause a camping problem but whos really to judge... hasn't been tried yet!

[bighoss]

Well I myself have played paintball. And camping is actually part of the game. There are pretty much three positions for players. Front , Middle, and Back. Obviously the frontmen are the ones that sacrifice themselves to bring the enemy into the open for the middle and back players to take out. Ok well I'm not an expert but I've played enough to know some stuff bout paintball.

[Cheetohs]

aye, bighoss, i too play paintball (not officially or anything.. but more of recreational..) anyhoo.. All i'm saying is that in a vid game it wont be nearly as coordinated and teamwork 'compatible'. Its basically going to have to rely on one man doin the work.

Just the idea of Running all the way to their base through these hotspot-open spots, GETTING the flag, and than the idea of running through that crap all over again may prevent some people from .... charging and 'bunker'-ing them.. hehe. Dunno. Im really not saying 'add more stuff now!' just saying that it might be a bit camper friendly (yes, camping is part of paintball id say... but not if EVERYONE does it!).
I dunno..

[bighoss]

Yeah you do have a bit of a point about the open parts. In my experience the fields I've played on were a bit more filled up. There was much more to take cover behind while moving forward. Anyway if the projectiles to act like paintballs, it will be much harder to shoot at distances. Which would force some players to have to move to be able to do anything.

[jv_map]

I decided to give the rope bridge a try it's not of much more than experimental use though, as it will most likely lag horribly in mp (all them elements need to be sent across the network ).

Anyway for fun's sake it's still useful



Download map

P.S. you can cut the ropes with your use key

[wacko]

Jv, this is unbelievable

I didn't know what lizardkid was talking about when he mentioned ur physics thing, now I know.

This bridge does more than I've ever seen in any of those games with highly praised physics engine. I crossed the bridge, I cut the ropes in 3 different places and it did, well, what it had to do

But u're probably right, this is way too much for mohaa mp maps. I'll give it a try though. With the bridge well placed, the fun factor would be huuuge

Would u mind if I put it in the recycling bin?

[wacko]

I immediatly tried to change the bridge's dimensions and before telling all the things that happend, my Qs:

Is there kind of a readme for the script, about all the variables like local.STEPMASS or local.STEPINERTIA?

Could the rope vectors get a different colour? Or I try to do no ropes at all, but instead attach the rope pieces to the protostep. But what to do in the script, then? Would it sway without ropes? Ought to...

I'll try to do lets say 2 protosteps and make them out of 2 or 3 boards. This ought to reduce calculations?

[Mj]

Thats a sexy bridge o.O

[jv_map]

The script is a bit of a mess actually but that would be good for a recycling bin I guess

Anyway here is a list of all the vars and what they do, note that you need to be careful changing these as there is a chance the model will get unstable (steps flying everywere).. the reason for this is that the script cannot correct for all effects in time... an easy fix often is to decrease the time step (at the price of a higher server load).

So here goes:

Code: Select all

// timestep used in physics script (seconds)
// lower means more accurate
group.FTIME = 0.025

// this is used for constructing the bridge
// not the actual rope length when it sags
// (length of gap between steps)
group.ROPELENGTH = 8.0

// size of the steps in longitudinal (bridge) direction
group.STEPLENGTH = 24.0

// uhhhm... not used, shouldn't have been in the script	
group.STEP_BBOX_MINS = ( -12 -48 -4)
group.STEP_BBOX_MAXS = -1.0 * group.STEP_BBOX_MINS
	
// this is the distance between ropes in lateral (sideways) direction
group.STEPCONNECTIONWIDTH = 64.0

// ropes won't exert forces when they are <= than this length
// if longer they try to contract to this length
group.ROPENEUTRALLENGTH = 4.0 // pretensioning

// this controls the elasticity of the bridge
// higher number means stiffer (often needs a smaller timestep too)
// smaller number means ropes will extend more easily
group.ROPE_EA = 40000.0 // rope extensional rigidity, N

// mass of the steps (step weight = STEPMASS * GRAVITY)	
local.STEPMASS = 40.0

// mass moment of inertia of the steps
// assumed to be the same for all rotation axes
// (definately not the case for any real object
//   but it's 'ok'  for this simulation)
// basically this is the resistance to rotation
// don't make too small
local.STEPINERTIA = 30000.0

// 'mass' of players
// determines to what extend players can influence the bridge 
group.PLAYERMASS = 40.0

// below are the dampers that make sure we'll get an equilibrium (if possible)
// if both are zero the bridge will bounce up and down endlessly

// rope extension damper
// this limits the rope extension speed
group.SPRINGDAMPER = 200.0

// velocity damper
// this limits the speed of the steps
group.DRAGDAMPER = 10.0

// gravity.. controls how much the bridge sags and how fast it'll come down
group.GRAVITY = 200.0 // units/s^2

There's some more constants in other threads but I would advise not to change them much.

The ropes are just func_beams, you could change their color but as they use additive blending they don't show up if you make them black or any other dark color.

I'll try to do lets say 2 protosteps and make them out of 2 or 3 boards. This ought to reduce calculations?

Yes definately.

btw note that you can make the bridge under any angle (yaw) and that the start and end points don't have to be at the same height

[wacko]

thnx for that information, it'll be a big help for sure

'bout leaving out the ropes, well, I'll try myself

[Cobra {sfx}]

Awesome work as usual JV, very realistic feel to it

[At0miC]

wow, really incredible

[wacko]

changing the variables indeed can produce weird effects

changing a func_beams colour, errrm, I do how?:oops: like this:

Code: Select all

local.rope doActivate
local.rope color (0 0 0)
local.rope thread cut

Making them invisible would be okay, although I'd prefer to have no ropes at all if this would improve fps. Dunno how, though.

Funny thing: why is a higher group.ROPELENGTH causing a shorter bridge or a bridge which sags less (or both??)?

So far, I have two protosteps with 3 steps each. FPS are gettin better and better, I'm now trying to make its behavior more calmly but still realistic and to raise the FTIME as much as possible.

[jv_map]

Funny thing: why is a higher group.ROPELENGTH causing a shorter bridge or a bridge which sags less (or both??)?

Higher ROPELENGTH means fewer steps so less weight (it is assumed that the cables have no weight)

[wacko]

Higher ROPELENGTH means fewer steps so less weight (it is assumed that the cables have no weight)

lol, going from 4 to 8 units makes the bridge look 10 times as heavy. But anyway, doesn't matter.
How about having no ropes?