spline movers?

(bani) #1

is anyone going to fix the mover scripting so curves arent jumpy?

the trains on railgun are really bad…

(sock) #2

snip snip from the documentation.

[i]The new spline path system allows entities to move smoothly between predefined points on a map. The system is based on Bezier splines which are the same system used by patches. Each map is limited to 512 spline entities. The new entities are stored independently by server and client and don’t add to the runtime entity count.

The spline path is defined by two new entities called “info_train_spline_main� and “info_train_spline_control�. All spline paths are calculated on the “fly� and visually look smoother the higher the frame rate.[/i]

Sock
:moo:

(chavo_one) #3

If this is an example of the documentation you guys are preparing for us, I can’t wait to read the rest! :drink:

(digibob) #4

They aren’t jumpy, unless you are jumping from one spline to anotehr, every second or so, which is exactly what the railgun ones are doing. No, this will NOT be addressed, as it cannot be. The Splines are normally as smooth as a baby’s bottoms :stuck_out_tongue:

(WolfWings) #5

But if the splines are based on bezier curves, why would you need a new one every second or so for the railgun train when it curves to one side or the other?

Now I’m confused, as on the one hand we’re being told that the spline system can handle curves, and now we’re being told that the curves done on Railgun had to be done in many little segments?

Which is the truth? Or were the Railgun tracks done ineffeciently, and that’s not worth going back for a full map recompile (not a big deal) and a QA cycle (the big deal I’m guessing) to fix?

(digibob) #6

They were done as lots of little bits for scripting reasons.

(sock) #7

The Railgun map required the tugs to be moved back and forth all the time by either team. The tug route had to be cut up into small sections because the system cannot stop mid flow between two spline points. The tugs where designed to be moved only when a player was at the controls, so the system had to be able to stop very quickly. This could only be achieved if the the path was cut into small sections.

Sock
:moo:

(WolfWings) #8

Ah, okay. THAT explains it nicely, and partially explains why the ‘proper fix’ in the code would be unfeasable. New bits of data to pass back and forth, more synronization issues, etc, etc. Thanks for explaining this, and PLEASE make sure that’s noted somewhere prominent at the first description of splines in the documentation? Forewarn folks that any scripting cannot pause in the middle of a spline, but only at the beginning or endpoint of it, don’t bury that bit of info two or three paragraphs down if you can avoid it.

(sock) #9

Its been added to page 25 - Spline path system.

Sock
:moo:

(wudan) #10

Its been added to page 25 - Spline path system.

Sock
:moo:[/quote]

Page … 25?

(G0-Gerbil) #11

I believe there’s also some jerkiness when you are i nthe cab of the trains due to the fact that the game engine does not update ‘properly’ as quickly as your game screen is drawn - the ‘spare’ frames are interpolated - I’d guess linearly.

Therefore the train pushes you in a straight line during the interpolated frames, which is only corrected visually on a full game engine update - hence why you seem to judder slightly to the outside of the curve when controlling the trains.

Right or wrong SD? :slight_smile:

(WolfWings) #12

Wrong, actually. They just explained why the jerkiness is there. You’re passing from one spline to another. Across any individual spline, it’s smooth. A great counter-example would be the tank in GoldRush. Notice how it takes a while to ‘wind down’ sometimes, when it’s moving? But how if you’re standing on it, it’s pretty damn smooth to ride that tank?

And as silly as this sounds… thanks, sock. I just know this would have bitten several mappers in the rump, myself included. =^.^=

(G0-Gerbil) #13

Wolfwings, I’m talking about an additional client-side ‘pushing / staggering’ effect, as well as the spline joins.

If you work for SD then you are in a position to confirm or deny what I said - if you aren’t, then you aren’t.

(sock) #14

Yeah the manual seems to have settled on 50+ pages atm. Plus there is plans to release one ET source map with the editor. The exact map name I will leave as a surprise. :wink:

But as I stated in another thread, the manual will not be aimed at brand new mappers. The manual will assume you are familiar with GTKRadiant and Q3 technology. (Like common entities, shaders etc)

Sock
:moo:

(G0-Gerbil) #15

‘Got’ to be fuel dump or bankraid for the moving objective.
If it’s to be a suprise then I’d say bankraid - fueldump would be too obvious :slight_smile:
Besides, bankraid has all the new stuff - moving objective, multiple collectible objectives, buildable thingies etc.

me bets £1.37 :slight_smile:

(digibob) #16

The paths for the tanks are generally more spread out, and due to the tank moving far slower, the slight lag upon changing between two different segments is far less noticable. The system does support (and i think i made all the tanks and other vehicles do this) blending across the edges of the splines, by providing a kind of “turning circle”, so you dont have to match the angles perfectly on spline boundaries. Hope that clears some more stuff up :slight_smile:

(bogs) #17

can spline points be moved based on a trigger of some sort?

(G0-Gerbil) #18

Kinda, but doesn’t answer my question about the interpolation between game engine updates - is the ‘pushing’ you get from the train / tank etc linearly interpolated for merely visual updates, or is it also spline-based?

(sock) #19

No, all spline points are fixed at compile time. If you started moving spline points each client would need to know about this update. Spline point entities do not contribute towards trackable entities because you would soon hit the map entity limits.

Sock
:moo: