I did a search for "leaving battlefield" but only found stuff about getting it working, not anything for modifying it. Well, I'm using maxflyheight to keep podracers low to the ground, and of course if you try to exceed the maxflyheight you kind of bounce back down, which is great, except that doing so also triggers the "leaving battlefield" message and the countdown to death. So, I'm wondering if it's possible to retain the bounceback while shedding the message and death (or at least the death, since I did succeed in relocalizing "leaving battlefield" to say "Warning: exceeding repulsorlift parameters!"...hmm actually if I recall correctly I'm also using minflyheight to keep the podracers off the ground, with the same effect.

Why not just set them up as hovers?

Tean, you've been around here long enough to know better than to ask questions that you should probably know have been already considered by the person you are asking, particularly when you make that the sum total of your post's contents and don't at all address the issue at hand. But since you asked,
-Hovers fly like they aren't powered by jet engines, while flyers fly like they are. Because podracers are powered by jet engines, that leaves only one option.
-Hovers cannot follow flyer splines. Flyers can--which is incredibly useful when making AI controlled podracers follow the contours of a particular racecourse.

But other than that, I take your lack of input as a sign that you have absolutely no idea. Correct?

What a great way to make sure you get no help in the future. Brilliant!

Saying you need to use Flyer splines so you can't use hovers probably would have sufficed.

My intent is to enlighten and streamline conversation, not to be offensive. Since I'm a slightly different sort, my intent is sometimes taken as being offensive. So, I suppose I could oblige you all by curling up in a corner with my head between my legs rather than trying to communicate, but on the flipside you all could oblige me by resisting the immediate urge to be offended by something that isn't and also wasn't intended to be a glowing compliment, and rather see if there's anything in the way of new knowledge to be gleaned from it. If you knew me well, which of course is rather impossible given the medium of communication here, you would know that I am not the bullying type and don't go insulting people without reason. Not that I was even insulting Teancum in the first place, per se. Although if that's how you choose to see it, I can't do anything to alter your perception.

But in an attempt to explain what I meant, well:
I saw Teancum's post and thought, "this seems like a knee jerk reaction and he simply responded quickly with the first thing that came to mind, rather than spending much time on the issue. I will point out to him that his contributions are usually much more in-depth, not only in the hopes of getting a more in-depth response but also in the interest of keeping off-topic and lightly-thought posts out of the conversation, for the sake of the site." So I guess I failed. Sorry.

Because THAT reply wasn't meant to be taken as offensive at all.

Jaspo wrote:My intent is to enlighten and streamline conversation, not to be offensive.

Timeout - intent and perception are divorced. Even assuming you have the noblest intent, you're a fool if you don't consider how people are going to take what you say/write. You wrote something pretty condescending. Communicate better in the future - end of discussion.

Jaspo wrote:I did a search for "leaving battlefield" but only found stuff about getting it working, not anything for modifying it. Well, I'm using maxflyheight to keep podracers low to the ground, and of course if you try to exceed the maxflyheight you kind of bounce back down, which is great, except that doing so also triggers the "leaving battlefield" message and the countdown to death. So, I'm wondering if it's possible to retain the bounceback while shedding the message and death (or at least the death, since I did succeed in relocalizing "leaving battlefield" to say "Warning: exceeding repulsorlift parameters!"...hmm actually if I recall correctly I'm also using minflyheight to keep the podracers off the ground, with the same effect.

i'm planning on helping you with this but i don't know the exact stuff that you must do. a friend of mine and i worked together to make a server mod for a no force server. i set up the sides and insta-death for gunners and he did the map magic. he was able to get people not to die if they go out of the battle field, he also deleted the barriers so that we could go out there.

i would go ask him now how to help you but he isn't contactable most of the time and the last time he was seen on steam was 5 days ago, on xfire over a week. as soon as he gets online i'll remember to ask him about it, untill then i can't really help much.

Jaspo wrote:Tean, you've been around here long enough to know better than to ask questions that you should probably know have been already considered by the person you are asking, particularly when you make that the sum total of your post's contents and don't at all address the issue at hand.

And you've been around long enough to consider that I wouldn't ask that question without an educated reason why. See below. Don't assume others haven't tried this. If it was a suggestion by someone who's spent a lot of time with modding the game there's likely a good reason.

Jaspo wrote:-Hovers fly like they aren't powered by jet engines, while flyers fly like they are. Because podracers are powered by jet engines, that leaves only one option.

Engine effects can be attached to anything. Additionally hovers can give you that buoyancy effect podracers have by messing with the spring settings. They will always stick to the surface as well, ensuring you don't have to constantly raise/lower the fly ceiling based on where a player/character is on the track, thus saving lots of complicated lua coding.

Jaspo wrote:-Hovers cannot follow flyer splines. Flyers can--which is incredibly useful when making AI controlled podracers follow the contours of a particular racecourse.

Hovers can follow pathing though just like a standard unit can. With CPs as checkpoints they'll easily follow the path and there's no need to have the player press a takeoff button, nor is there a need to create a Max/Min fly border as they won't leave the ground unless going off a sheer face. Additionally flyer splines are often much less reliable than standard pathing as the AI tends to take a little license in regards to the actual path. They also don't respond very quickly to things like danger regions, meaning that if you need them to take a sharp turn you're pretty much stuck.

Jaspo wrote:But other than that, I take your lack of input as a sign that you have absolutely no idea. Correct?

I believe I've shown the contrary.

Remaining off-topic:
Points well taken. However, correct me if I'm wrong here, but don't entities, when following planning, tend to sometimes kind of nose around aimlessly or just stall for a few moments when they come to a new hub, before choosing the next hub to go to? Or at the very least, have rather jerky movements when switching to a new connection? Not behavior particularly befitting a podracer. Plus, these things are going very fast, so any stopping would be extremely noticeable. As for how strictly entities will follow a path, there are various commands to alter this behavior, and preliminary testing seems to indicate that the way I have the paths set up, they follow them quite well. And as for height changes, I simply have a flat racecourse at the moment, though yes I suppose OnEnterRegion could be used to change the flyheights, though that wouldn't work for more than 1 AI controlled podracer, since it would change the flyheights for all of them and they wouldn't all be in the same part of the track.
You were talking about tweaking the hover odf properties, so, do hovers necessarily come to a stop when you let up on the gas, and reverse when you press back, or can they be reconfigured to be like flyers, so they fly normal when nothing is pressed, and fly slow when back is pressed? Because aside from the path vs planning issue, that's the most important characteristic that I'd like the podracers to have.

For the stopping, doesn't it take a while for a hover to slow down before stopping? Like the alliance hovertank, if going at a high speed, will take a while to come back to a complete stop, even if reverse is used.
Also, you could just make the deceleration rate of the hovers be really low, so you do slow down but take a long while to actually go to a stop.
Just some stuff if you want to use hovers.

as i see it a flier would be best. you could then turn the thing on and off like they do in the movies (ignition). also you can have the vehicle go at 3 different speeds and all of them being forward. from what i am reading it looks like he doesn't want the vehicles to be able to come to a stop, just like how fliers do.

Can you place an invisible, but collidable, object on the ground and in the sky to keep everyone at the right levels? You could put a region along side the object to give the warning message whenever the player enters that region. You might want a death region on the ground too to prevent players from getting out and walking on the air. It might be best to make the invisible object an invisible force shield that only prevents the flier objects from moving through. That way, the units won't be able to walk in the air and shots can pass through as well.

FYI: The more info about the whats, whys, and past attempts one puts in their posts the more targeted the responses will be. It's easy to overlook a different solution when you've spent so much time and effort going about things in their current way. It's often times best to first make sure that hasn't happened. :themoreyouknow:

By the way, that's the best use of the "The More You You Know" smiley. That's the first time it's been used in so neutral of a way.

Hmm, methinks Zerted may be on to something, so long as collision with the objects at such high speeds doesn't do damage (which it might--certainly flying into slightly inclining geometry now does damage, though that may be moreso due to the fly height restrictions (perhaps)...or I could maybe increase the HP of the flyers. On the Boonta Circuit, anyway, there shouldn't be much need for messages concerning leaving the track to the right or left, since cliff walls and boulders, etc. do a fairly convincing job of conveying the message all-throughout. The only other concern with the approach is object count, since the Boonta Circuit is very large.

One other thing that may well hinder the plan instead of path approach is that I actually have very little terrain (smallest chunk possible) and the racecourse terrain is instead made of low-poly models...I don't know that it's possible to place plans where there is no terrain (and having terrain throughout the entire track drops the framerate to around 1 fps)

offtopic: i must thank you sir. that last paragraph about terrain causing lag may very well solve the mistery of my laggy cave map. now to place mountains around the sides and cut down on the terrian.

offtopic in regards to the above: also portals and sectors could be useful to you, probably--read the stuff in the docs and then take a look at the FAQ topic for how to fix it (since by default it doesn't work, since there's nothing calling for it in the world's REQ file)...also keep in mind that resizing the terrain will make you start from scratch with it and if you make it the wrong dimensions it will screw up the object placement too (best to go with power of 2 X the same power of 2, such as 256x256, 512x512, 1024x1024, etc.