elevator blocks

[the_j0k3r]

ill start with this - apoligies if this has been discussed before, i couldnt find it in the forums.

ok, what if you made it so that you can have moving blocks. one might say this could get complicated, but you could always leave it at this. in the .bzw map file, you simply make something like the normal block, only instead of being specified as a block, it is called "moving block" or something, and you give its starting position (just like you would on a normal block), and then you have a line like "to" or something, then the z coordinate of the position it moves to. (you could always go more complicated if you like and set x, y and z coordinates).

perhaps also a /set _elevatorSpeed or something to set how fast it moves.

{edit} just clarifying, the idea is that it moves to the coordinate, then back, going to and fro forever

[Tanner]

Physics would work..

-Tanner

[L4m3r]

Maps in this game are static. It's a design decision, and an essential part of the game.

[meeba]

Yeah, physics would be the best way to do it.

[anomaly]

Tanner wrote:

Physics would work.

physics can move objects, like boxes or pyramids? I've never done that b4. could be cool.

[meeba]

No, physics can't move objects. But you can use them to make a player bounce up, sorta like an elevator.

[Tanner]

No, physics can't move objects. But you can use them to make a player bounce up, sorta like an elevator.

Perhaps saying elevator is the wrong word as thats what this was originally about and elevators move physically.

Like a trampoline.

-Tanner

[TD-Linux]

Maps in this game are static. It's a design decision, and an essential part of the game.

or a decision of easy coding

No.

This game is simple. Moving objects (that effect the tank) will never happen. Tim Riker's decision.

Really? That would sadden me if it were to be the case. Moving objects for scenery, etc would be neat, and being able to ride on them would be even cooler. I think Tim Riker (I hate speaking for other people... okay, so this is my opinion) things that will never be implemented in BZFlag are things that would affect ALL gameplay. Map elements don't affect ALL gameplay, just maps that contain the new objects. Therefore, it isn't forced on anyone.

The developers' main restriction I have found is time. What should they do? What has higher priority? Cheating prevention? Improving the forums? Networking and lag? Pretty shots?

Riding moving things would be a lag issue for sure... I suppose it can be worked around with some very fancy dead-reckoning code that takes physics into account.

There is already some code in BZFlag that allows moving objects to some extent - but nobody knows how to use it yet

[DTRemenak]

Maps in this game are static. It's a design decision, and an essential part of the game.

or a decision of easy coding

No.

This game is simple. Moving objects (that effect the tank) will never happen. Tim Riker's decision.

Can you please cite your source on that?

To the OP: please read the FAQ, in this very forum..."Moving Objects - There are a number of network related problems that prevent this. It also adds unnecessary complication to the game."

[Winny]

Lets see, "everyone" seems to say it... I assume it true?

Please inform me if I am using twisted logic.


EDIT: added "" around everyone to make myself more concise.

[DTRemenak]

If everyone says it, perhaps you can point me to where someone has said it?

There are a number of things which have been specifically prohibited. I don't recall this as being one of them. It's just really, really hard, for a very small benefit.

[asciimonster]

So let me recap
The problem is not in programming it:

Code: Select all

1. Poligon P moves according to rule R with vector v_R(t)  = (v_x(t),v_y(t),v_z(t))  [i][for laymans terms v_R(t) decribes the time dependant movement of the object through 3D.][/i]
2. If tank on/in poligon P than tank moves at same speed as object. i.e. if ((tank in P) == true) then v_tank = v_R(t) + v_t(t), with v_t(t) the speed input by the user (or the speed left from a jump). With the obvious exceptions that the resulting directions of v_tank into the moving objects are disallowed* (as you are now), with the exception of wearing the OO flag.
3. If not 2, use normal rules

I see 3 problems though:
1. How do you detect if the moving tank is jammed between two objects? If so, the server should destroy the tank. Calculating these possebilities would at least double the CPU load, since you will have to calculate every surface twice.
2. Since the movement of the tank is governed by both the sever AND the client**, how do you keep up the synchronisation between all clients and the server such that all see the world moving in exactly the same manor? We already have problems with hitting tanks that have lag, what kind of hell would be hitting a tank that lived in a delayed universe?
3. If a tank hits an object moving towards it, the refresh cycle may not be fast enough to prevent the tank from penetrating into the object (much like something flung at a jellow pudding). In other words, before it can be calculated that you've hit the object you've already moved passed the surface.

Unless these (major!) problems are not solved I see no point in implementing it.

* Is bzflag calculating the gradient (I mean the math operation grad/Del/nabla) of the surface and looks at the sign of the result in the different carthesian directions?
** How else can cheaters have their tanks moving faster than the server allows. Only if the client calculates the new position and feeds it to the server.

[DTRemenak]

The difficulty is not inherent in the problem, but inherited from the way bzflag currently does things.

[JeffM]

the current network protocol does not have any concept of lag or time compensation. So there is no way to ensure that the motion of a block is the same on all clients. There is also not a single authoritative game state, so if and when clients got out of sync there would be errors in the game states ( hit detection is done using those gamestates on the client ). Heck, right now we can't even ensure that a moving tank is in the same place on 2 clients at the same time.

If the networking, time syncing, and authoritative server issues were resolved, then putting in moving objects would be much more simple. At that point it would come down to a real game play decision.

[bzflaginator]

My take on this is simple. Like others have said here, it is too complicated for this game. This game was designed to be a simple game. Secondly I think if you want an "elevator" that bad, just get one of those things that when you roll across it, it launches you (sorry I am no map maker ) If you wanna know where to get one, I believe louman has it as well as a few others. Im pretty sure you can deviate the velocity it launches you so if you want it to shoot you up to a platform and have it act in an "elevator" type fashion, change the velocity to make is slower than the tankspeed so it shoots you more up than out.

[asciimonster]

Launching pads! That's the answer. If you hit a certain surface you suddenly get a boost in the right direction. If I can figure out how to build a level, I'll call it Cape Canaveral and make a launch pad in the middle that launces you into outer space. I will supply a lot of wings of course.

They also used the launching pad technique in Quacke Arena didn't they?

P.S. The fact that there is no "authorative game state" makes that this game runs so well on reasonably low-powered machines. I'd trade me 20 more players for elevator blocks...

[L4m3r]

P.S. The fact that there is no "authorative game state" makes that this game runs so well on reasonably low-powered machines. I'd trade me 20 more players for elevator blocks...

Um, no, the lack of an authoritative game state is a server-side thing. Adding server-side game state would only affect performance on, well, the server. And even then, it probably would not be much.