[colecampbell666]

This makes me wonder--is there anyone here who has less than 768 megs (512 + 256) of RAM and can't upgrade? Sometimes I think support for the absolute bottom end computers can be a liability rather than a bonus. Ever played any brand-new games that run on Windows 95 recently?

Considering I'm using 512 currently, that's not even the issue.

I'm using 512 on a six-year-old PC, with a 256 mb Radeon 9550, and the only things that give me trouble are the AdVPs.

[Nuke]

i actually did bump into the end of the mission bounds once while testing one of those newtonian implementations i ws testing (i forget whether it was glide or my script based implementation). i do remember going ludicrous speed and accelerating, the ship was shaking violently (the afterburn rumble effect seemed to amplify). command told me to return to the mission area, and i blew up before my finger could hit the z key. still, i had been accelerating for at least 5 minutes straight. i never bothered to check what my coords were.

the only reason i see this as acceptable feature is for a newtonian implementations or perhaps missions where you need to model something big, like a few planets. while its a pretty cool idea, i really dont see the point. if i wanted newtonian that bad id just learn to mod orbiter.

[jr2]

From what I understood it would use double the memory that is currently used (simply from the float to double transition) even before you actually increase the radius. Once you start increasing that the memory requirements would go up proportional to the cube of the extra length of the radius.   OK, good point there.

I'm going on memory here but if I'm right then you can see how fast that will turn into a very large drain on memory.

And as Goober pointed out I've yet to see proof that anyone actually needs the way this works changed. None of the teams mentioned in this thread have actually asked for an increase AFAIK. True.  I'm just pretty sure you're going to run into that limit if you go, say, escorting the Rebel evac transports from the surface of Hoth (? how far to escape the gravity well of a planet in space?) or say in a mod where we figure out how to implement tactical micro-jumps.  If changing the desertion radius is really that hard to code, then I guess we'd have to jury-rig something else together to get around that problem if we need it.  And I can tell that the claims that this feature is needed are complete bollocks because no one has actually stated the correct value for the desertion radius, something you'd surely know if you were actually bumping up against it.  Perhaps this has something to do with the fact that the player's distance from point 0,0,0 in a mission is not really a well-known value most of the time.  Is it displayed by default in debug / dev mode or something?

[Shade]

About the Hoth scenario: Move the planet. It's only the player that the desertion radius applies to, and it'll look the same as if it were the player moving away. As has been said, creative FREDding.

[jr2]

Wait a minute.  The desertion radius only applies to the player?  So, any other ship can go where it pleases, and still cause no problems, no increase in mem usage?  If that's so, can't there just be made a switch triggered by a SEXP that shuts the desertion radius off?  ie, something like set-desertion-radius 0 to turn it off, 1 to turn it back on?

[Shade]

Not quite. Any ship can go where it pleases, but that doesn't mean everything functions right at large distances. Far-off stuff is fine for eye candy, essentially as backgrounds (like the "Sathanas" objects in the final FS2 mission which are at around 170k on the X-axis, or the Earth model in the first Inferno release), but that doesn't mean everything works quite right out there. Been a long time since I even thought about this stuff, but as I recall collision detection for example takes a serious turn for the worse at extreme distances. So there are reasons why you don't want an observant player there.

[jr2]

Hmm.  Would Bobboau's (I think, or was is taylor?) fix & optimization of the collision code help this?

[Goober5000]

It was Kazan who fixed the collision code at large distances.  However, that was a fix for an autopilot-specific bug, not a general collision detection fix.  Also, "large distances" in autopilot are a few orders of magnitude less than what we're talking about here.

Aside from collision detection, there's also the floating point problem.  Objects that are far from (0, 0, 0) will "jiggle" in place because floating point numbers lose precision at large magnitudes.

[wolf]

From what I understood it would use double the memory that is currently used (simply from the float to double transition)

1. It is not certain that float->double conversion is needed. The precision of floats might be just fine for radius ten times bigger. Or it may be not.
2. Changing position-related variable data types for some objects will certainly NOT double the amount of memory needed. The memory requirements would be up by 1-100 KB, by my rough estimate.

even before you actually increase the radius. Once you start increasing that the memory requirements would go up proportional to the cube of the extra length of the radius.

???

[FSW]

All this hypothetical talk is interesting, but I have yet to hear of a feasible mission plan that would actually require such huge distances and not be incredibly tedious to play.

If you try to compensate by making the player's ship super-fast, they player will lose control and overshoot or go wide of their intended destination. If you try to compensate for that by using autopilot, then by taking control away from the player, you might as well make the mission a two-part red-alert.

If somebody wants to mess around with it, sure, but so far it doesn't sound worth putting an FS2open release's stability at risk.

[Woolie Wool]

First of all, the red-alert bug will be fixed in 3.6.10, so that's a non-issue as far as this topic is concerned.

Second of all, I'm really fed up with these threads that seem to pop up every few months or so.  We get two or three members lobbying heavily for a feature that 1) is unnecessary for the vast majority of situations; 2) can be reasonably approximated already with existing features; and 3) is practically guaranteed to never be used by the person who requested it.

On one side, we have established projects who request challenging features that will add a cool new gameplay aspect and that will be prominently featured in an upcoming release.  On the other side, we have these drive-by trolls who occasionally unite to make coders' lives hell because the SCP doesn't have a certain obscure feature.  It royally ticks me off.

I think you should be less quick to assume that I will not use this feature, when I have a very specific plan for a mission in chapter 1 of Twist of Fate that would use this exact feature, where the player leads a wing of Loki fighters to several very distant (>10000km) nav points to observe enemy positions. Using subspace to get there is not possible as the Vasudans would easily see them, so the player has to sneak in on autopilot. A modeled planet would be in the mission (probably the Galahad VI gas giant model from Over the Top) to make the distances being traveled more obvious, and the Lokis are on a telemetry link with the GTD Repulse, and one can target the Repulse at any time in the mission.  Furthermore, I very much like the idea of autopiloting from home base to a remote mission area to, say, escort a convoy. It makes the missions feel more like a real war and less like, well, a game.

[Shade]

autopilot

The thing is, the moment you use autopilot you have a free window to move stuff around without the player knowing any better. So you can have the player show up 10.000km away no problem as easily as using a few set-object-x/y/z sexps. No way to tell the difference, and trivial to implement.

Which is why Goober is annoyed. You're asking the SCP to spend time coding in stuff that can already be trivially achieved with current FRED features.

[Nuke]

i had an idea for a decaying orbit mission where you have to disable a transport, kidnap the pilot, and return to a stable orbit before getting within range of the moon's long range missile battery. of course the way i invisioned that mission it could probibly be done with the current grid.

[Woolie Wool]

autopilot

The thing is, the moment you use autopilot you have a free window to move stuff around without the player knowing any better. So you can have the player show up 10.000km away no problem as easily as using a few set-object-x/y/z sexps. No way to tell the difference, and trivial to implement.

Which is why Goober is annoyed. You're asking the SCP to spend time coding in stuff that can already be trivially achieved with current FRED features.

The idea of moving dozens of targets thousands of kilometers and accounting for any sequence the player may scout the nav points in does not sound "trivial". You would have to account for every possible choice the player makes. Furthermore, The idea of autopiloting to the combat zone of a large mission doesn't really work either. Is it "trivial" to move entire cargo depots? Fleets? Asteroid fields? Why not sacrifice a few dozen megs of RAM to do it all for real without the player being able to find a way to break the illusion? Besides, raising a limit is in itself trivial compared to complex new features like some of the stuff that's slated for future versions of FSO, like the "first person shooter" gameplay system that will be included in 3.7.

When you use smoke and mirrors to give the appearance of something happening that is not actually happening, there's almost always some way to tell.

[Hippo]

I personally find missions where you need to use time compression as an important part of the gameplay, such as moving extremely long distances, quite boring and poorly planned.

There were ways to simulate this effect in FRED1. An SCP addition as such is quite unnecessary.

[chief1983]

The Death Star 2 is over 900km in diameter.  While a campaign mission may never make use of a simulated DS2 run, I'm sure someone is going to be crazy enough to want to make a single mission involving a to scale DS2, including the flyup, etc.  This could probably require a size larger than the 600k radius, although not by a whole lot.  But, it's an example.  And, it's from the SWC.

[Hippo]

The Death Star 2 is over 900km in diameter.  While a campaign mission may never make use of a simulated DS2 run, I'm sure someone is going to be crazy enough to want to make a single mission involving a to scale DS2, including the flyup, etc. This could probably require a size larger than the 600k radius, although not by a whole lot.

To reach the limit with FS and even radical WEG ship speed estimates, you're going to spend a minute and a half on 64x time compression for absolutely no good reason.

  But, it's an example.  And, it's from the SWC.

So? It just seems like a stupid 'feature' to implement or change an obscure part of the code that isn't an issue just so you can increase mission footprints when there's been alternatives around forever.

[chief1983]

I'm just saying, we've got a lot of people who are looking for something a bit more 'simulation' like, and it was the first example I could think of that might make a decent use of a size bump.

[Colonol Dekker]

Heck Original X wing didn't use a "to scale" DS and i thought it worked just cushty.

[Woolie Wool]

To reach the limit with FS and even radical WEG ship speed estimates, you're going to spend a minute and a half on 64x time compression for absolutely no good reason.

Autopilot uses a cinematic instead of time compression if you set a flag in the table file. But there's a trick: The cinematic is shown with your ship halfway between your home base and your destination, so to pull a fake off successfully, you would have to move the entire goal area twice.

Plus this doesn't even address my idea of making a configurable mission area (like an asteroid field) so that the desertion radius actually does punish deserters.