Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Woolie Wool on August 19, 2007, 12:34:43 am
-
Since I have some interesting ideas for deep recon missions and other creative uses of truly extravagant distances (with cutscene-based autopilot, of course), I decided to test the radius at which the desertion warnings will kick in.
I set out from the GTD Gayatea (no, that is not a typo) in a Horus, turned time compression up to 64x and engine power to maximum, and went out into the lonely void. I was smitten detonated by God Command about 600 kilometers out.
This leads to the question--why not make the radius 6,000 km? Or 60,000? Or 6.0 x 10100? Or not there at all? Or user defined? Having a hardcoded radius at which point you're blown up, despite the fact that objects can exist outside it, seems silly. Why not make the limits user defined, either as a definable radius (which can be eliminated by setting it to zero) or using a bounding box like asteroid fields, allowing a specific area to be carved out of space that is defined as the field of battle?
Besides, a single wing trekking out millions of kilometers in an enemy system to scout enemy movements is just really cool in ways that red-alert missions cannot possibly match.
-
Sounds cool to me... I always wanted a look at those 80 Saths... :drevil:
-
i always thought the desertion message/limited range was just a cheap fix to hide the limit on data types. you could change all the floats to doubles, but that will just hike the memory requirements and slow processing.
-
Sounds cool to me... I always wanted a look at those 80 Saths... :drevil:
You mean 6 SJDs?
-
Jr2 you know the Sathanas fleet at the sun is a background?
-
Jr2 you know the Sathanas fleet at the sun is a background?
Plus a few SJDs for the sensor blips. And I think it's obvious too.
-
Oh, rly? Hmm. I'd considered that before, until I found the SJD model. So, I thought that that must be what I saw.
-
How about a "set-desertion-radius" sexp, which allows the mission designer to designate the range? Setting it to -1 would eliminate the range altogether.
-
How about a "set-desertion-radius" sexp, which allows the mission designer to designate the range? Setting it to -1 would eliminate the range altogether.
why not zero?
-
then you would be "smited" instantly, for going 0 mters away form the battle zone. why not set it too 999,999,999,999,999,999,999? it would take a whole day to fly that far
unless your max speed was realy high
-
then you would be "smited" instantly, for going 0 mters away form the battle zone. why not set it too 999,999,999,999,999,999,999? it would take a whole day to fly that far unless your max speed was realy high
Bah. I am and idiot. :P
I say, screw the whole thing. If it only affects the player, then i see no point in it.
-
then you would be "smited" instantly, for going 0 mters away form the battle zone. why not set it too 999,999,999,999,999,999,999? it would take a whole day to fly that far unless your max speed was realy high
Either -1 or zero would probably work (e.g. setting the time limit in an FPS deathmatch to zero means no limit). I guess it depends on what kind of mathematics FS2 uses to calculate such things.
-
it would be useful for implementations of newtonian physics though. for those instances where youre going ludicrous speed
-
We need to whine to a coder...
-
The coders are having some issues at present... I wouldn't wine, and only ask them for a feature if you think it'd make a big difference...
You could try implementing it yourself :p
-
I think nuke posted the basic reason the limit exists anyway. I've not checked if he is correct but I definitely remember reading that the reason for the limit was to keep the game's footprint down.
-
Make it dynamic?
-
I think that since the footprint is being reduced greatly for 3.6.10, can we not afford a little more memory for a larger mission radius?
-
I think that since the footprint is being reduced greatly for 3.6.10, can we not afford a little more memory for a larger mission radius?
Ok, i guess I'm the only one wondering, but what exactly is the point of the desertion radius anyway? i meen, what player is actually going to fly as far as to get repeatedly spammed by command and eventually get blown up?
-
Since I have some interesting ideas for deep recon missions and other creative uses of truly extravagant distances (with cutscene-based autopilot, of course), I decided to test the radius at which the desertion warnings will kick in.
it would be useful for implementations of newtonian physics though. for those instances where youre going ludicrous speed
Sounds cool to me... I always wanted a look at those 80 Saths... :drevil:
-
:snipe:
-
In general I tend to feel that most of those ideas are already possible and simply lack FREDding creativity or in Nuke's example are the result of getting the engine to do something it can't do and then complaining about it being unable to do it.
-
"FREDing creativity" sounds to me like "unnecessary compromise". Doing these distances for real has a lot more impact than using red-alert, and there's no risk of running afoul of the red alert bug that cripples Inferno's Independence vs. Diablo mission.
-
Compared with forcing everyone to have higher memory requirements for a feature that isn't needed in the first place, it's sounds like a compromise you're going to have to make or ditch the idea for the mission.
And I wasn't talking about red-alert anyway. How's this for an idea. Say you have mission set around a double planet system. You want the first part round the first planet and then you want to autopilot to the second one. Instead of vastly increased memory restrictions why don't you simply check if during the autopilot cutscene you can just move the planets?
-
In general I tend to feel that most of those ideas are already possible and simply lack FREDding creativity or in Nuke's example are the result of getting the engine to do something it can't do and then complaining about it being unable to do it.
its not that the engione cant do it, i know for a fact that 2 ways to implement newtonian exist. the reason its unfeasible is 1, we dont have enough space, and 2, the ai is too stupid to fly newtoinian. the second one is maybe fixable with scripting. but the first reqiores the change stated in this thread.
however i totally agree with kara. the tedious process of converting all the games math functions, formats, physics and rendering code to work with doubles rather than floats would be too big of an undertaking for little or no real gain. also using bigger numbers would mean you could cram less into a processor cycle. this is not one of those things that can just be made dynamic. last i checked c/++ uses fixed data types, which cannot be made to grow as needed. making things dynamic only works with large arrays of data.
-
Compared with forcing everyone to have higher memory requirements for a feature that isn't needed in the first place, it's sounds like a compromise you're going to have to make or ditch the idea for the mission.
I hate to say it, but FSO is not that memory intensive an application, y'know? I can run it fine with multiple instances of EVE or a game of SupCom running in the background. This is not a high-end machine. (And totally ignoring winamp and the 5-6 MSWord instances that are almost always active on my computer, since those use nothing.) While I think you have a point, I also think you are inflating the problem here.
-
possible launcher flag?
-desertionradius [Variable]
-
possible launcher flag?
-desertionradius [Variable]
****ing awful idea. What happens if someone decides to run with a lower radius than the mission requires?
Launcher options should not lead to unplayable missions. We've gone to the trouble of removing -jpgtga for precisely that reason.
-
Compared with forcing everyone to have higher memory requirements for a feature that isn't needed in the first place, it's sounds like a compromise you're going to have to make or ditch the idea for the mission.
I hate to say it, but FSO is not that memory intensive an application, y'know? I can run it fine with multiple instances of EVE or a game of SupCom running in the background. This is not a high-end machine. (And totally ignoring winamp and the 5-6 MSWord instances that are almost always active on my computer, since those use nothing.) While I think you have a point, I also think you are inflating the problem here.
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?
-
Is the 600k from the nearest contact or from z0x0y0 ?
I've always wondered... :)
-
From 0,0,0
-
In other words you can have a combat zone of 1200KM in diameter...That's more than enough for me :D
-
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. :P
-
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. :P
Even a $370 Dell budget computer has 1GB RAM, so if you've got half that and can run FSO with all that stuff running, then memory footprint is a complete nonissue. My new computer (well, October '06 is fairly new) has 1GB only because I skimped on RAM in favor of an expensive video card. Really, FSO could afford to eat a lot more memory than it does now.
In other words you can have a combat zone of 1200KM in diameter...That's more than enough for me :D
It's not just about the combat zone. What if you want to portray actually traveling from base to the combat zone (via autopilot, of course)? You're going to need a larger radius for something like deep recon.
-
Not really. FRED has all the tools you need to simulate travelling a long distance without leaving the mission area or transitioning to a new mission.
-
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.
-
Well, SWC and WCS would be able to make use of this feature, correct? IDK how hard it would be to implement a bump in the limits though... and here's what I really don't get...
Correct me if I'm wrong, but this feature would use 0.0000 MB more memory, unless ships ventured outside of 120KM, correct? I'd like that answered (I have no clue).
-
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.
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. 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.
-
For the record, i don't think this feature would be all that innovative, i've never heard the desertion warnings or encountered the desertion debrief, In all honesty and as mentioned any desertion stuff could be emulated with distance operators.
I just wasn't sure of the origin of the radius, thats all :nervous:
-
In Solar wars, one mission has a bug that the destroyer you are protecting keeps on going instead of stopping. If you follow it more than 20k away from the node, you self-destruct.
-
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. :P
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.
-
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.
-
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?
-
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.
-
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?
-
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.
-
Hmm. Would Bobboau's (I think, or was is taylor?) fix & optimization of the collision code help this?
-
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.
-
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.
???
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Heck Original X wing didn't use a "to scale" DS and i thought it worked just cushty.
-
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.
-
If you're too lazy to do it yourself, even though you can with the abilities already in FRED, why are you expecting someone else to do it?
-
I have an idea.
What if you broke up the space you wanted (if it's bigger than 600killometer (radius) sections), and used a mechanism at a higher level of abstraction to basically "load dynamic input missions"?
I'm currently toying with this idea to create a more "universe" like environment.
-
Don't toy with it: I wanna see an experimental build! :p ;7
-
What?
-
I'm currently toying with this idea to create a more "universe" like environment.
Don't toy with it: I wanna see an experimental build! :p ;7
What?
:hammer:
:warp:
-
Locked for great justice!