[asyikarea51]

Please note that altering spacecraft speeds alone wouldn't work. Weapons' speeds also need to be changed.

That's what Sushi did.

And why I used his old velocity mod as a base to mess around with things instead of doing all the changes from scratch... might as well since it's convenient enough XD

I probably mentioned vehicle speeds alone since it was the first thing I thought of when "top speed" was mentioned...

Then there's that huge argument about the big and slow FS ships in the atmosphere and references and canon and blah blah blah but I don't think it's appropriate here...

[Dragon]

I wouldn't have thought too much about top speed if it didn't affect actual fighter-fighter combat... it's extremely hard to hit anything going past 600m/s in FS in most cases...

I made a mod in which fighters had max speed over 600m/s as standard.
The biggest problem turned out to be interceptors ,which were nearly impossible to balance ,it was very hard to shoot one of them flying heavy fighter ,but when I was flying one of them I quickly got shot down.
Standard fighters handled moderatly ,they had autoaim to compensate difficulties with aiming and were good at nearly everything. (of course I also used AI Profile with nearly all additional features on)

I recently abandoned this gameplay model ,mostly because of autoaim ,which was unrealistic considering the external primary models I was using ,though I commented out all values ,so reverting all changes wouldn't be a problem.

I'm now using values from Sushi's velocity mod ,I would like to employ Newtonian fight model someday.
(for example when The Minbari Project comes out with bugless ,fully functional build)

[asyikarea51]

LOL yes I tried it myself once. Damn it man, in a 1v1 fight versus the AI at 400-1000m/s and above, it's a case of you, the player, getting flanked-sniped-instakilled! I couldn't even get a missile lock... but even if I did, the missile would just miss or aim the countermeasure instead...

I had Gatling weapons during the test so it was basically a guaranteed "IT HURTS!!!" session, and at the end of it I didn't even feel the... "feel" I wanted. And no auto-aim, to add (don't know how to do it + back then I don't think there was auto-aim yet or maybe I simply didn't discover it).


Well back on topic, I think that whoever really wants to "expand the space" in FS might need to put some serious thought into the flight and movement model first or something... at least that's now this simple mind sees it. Making FS look like X3 and/or FL is still a long way away I guess...

[Nuke]

well im currently looking to see what can be done with the existing useable space, roughly 1500km^3. although it should technically be less, because getting close to the boundaries of that you get shakey flight which reveals the limits of floating point numbers. this is enough to orbit small moons, ice dwarves, planetoids, and large asteroids. so my atmospheric flight simulation uses 2 modes. a planar mode, in which only one gravitational object is present in the game, and its acceleration is always to the -y. this is good for simulating large planets with dense atmosphere, gas giants, ect. while i was out in the woods i tried to come up with a highly loded representation of (about 1/50th) the surface of mars. and it sort of works, although i didnt set up the detail boxes correctly. i also have an atmospheric model for earth (but it needs a terrain model). im gonna start a complex terrain thread in modding in abit.

the other mode is represented as point sources, it can have atmosphere like the other mode, and requires a planet model rather than a flat chunck of terrain. thouh he same kind of loding technique can be us to create really complex planetary terrain. it doesnt support it yet but im gonna make it possible to place several of these in a mission. anything with a radius less than 500km can fit ok in freespace, but thats a hard limit and it doesnt give you any room to manuver, you can make orbit and fly around a little. smaller objects can be simulated better. and while the physics are mostly correct you can use less realistic figures for its atmosphere model.

an optional third mode allows you to set an ambient density, this can be used in nebula missions, but also can be used to cap speed while maintaining newtonian flight. to sort of give you a more realistic capped velocity. ive also been giving some thought as to how to liit your acceleration in space. since you need more thrust to fly in an atmosphere than you need in space. ive been toying with a few ideas for how to accomplish this. one idea is to make some engines air breathing, where thrust output is dependant on atmospheric density. so engines would have an atmospheric performance factor. so it woul be thrust+(thrust*performancefactor*airdensity), so if youre in a vacuum you get the base thrust value, and as you get into denser air, you get more boost. though im sure i can get a more accurate formula somewhere, something youd use for tubofan engines. another idea is having boost thrusters that use fuel, giving the player only enough fuel to make whatever velocity you need in mission.

ive also added some physics to weapons, though with varying sucess. flak weapons seem to work the best, lasers dont let you change their speed once created, though they do let you add the ships velocity to them for some reason. missiles just tend to crash the game. i had them set up to accelerate constantly accelerate during their life span, but this causes an assertion somewhere in vecmat.cpp. dumbfires crash the game less, but still do.

also the problems with collision detection might be partially solved by writing to the old velocity values within the engine. if you subtract the curent frames velocity from the last frames velocity, then that gives you a line with which to check for collisions. i think that by simply making theese values visible to scripting, and then writing the frame old values to them, this should make collision detction work up to the point where floating point precision falls off. then theres the problem of disabling freespace physics entirely (which might already be implemented).

id like to release something but there are so many bugs right now its not funny, and would like to have more terrain and planet models available. i might just post some vids on youtube for now.

[Bixel]

Well I am super intrigued by this. I wanted to use FS2 to make a mod somewhat based off of Independence Day 2, and Homeworld Cataclysm set in the year 2220ish. Because of the timeline the main ship will be more low tech and sluggish compared to FS2 ships. I am a pretty good modeller and texture artist and my plan was to create several Cockpit HUD scenes and you use key commands to switch between the views.

The trick I decided, was to keep most of the FS2 Fighter/Bomber ships performing normally with some major modifications - since my "other universe" is only 200 years from now, there is a special engine device that can be used on small mass hulls, its the Non-Spacial Grav Engine (NSGE). Since its fictional I cant really describe it - however its power give the smaller ships that Star Wars type performance... but its very fuel heavy. Once the fuel runs out you have to navigate your ship oldskool style (like Orbiter), and if you don't it will just drift...

The main flagship is operable, it requires several HUDS(cockpits), and most of its movement is adjusting drift speed and direction. Switch to another HUD and you get a 3d display map (like Homeworld) to plot your destination.

Here's where my mod idea comes parallel to this subject, make the space big - real big -, the fighters and bombers effectively can only navigate the immediate area - just like FS2, but unlike FS2 they will run out of fuel pretty quickly and they cannot travel long distances - cause it will take FOREVER. If you are concerned about the relation between movement and game speeds - just take the Fighter/Bomber displayed speed and divide it by half or more. The smaller craft will still perform like FS2 but it will seem their speeds are not very fast.

Why cant Fighter/Bomber not travel huge distances?? When their NSGE runs out of fuel, the flying ability decays swiftly - because the NSGE is no longer operating, the force it was extending from the ship retracts effectively slowing the small craft down a whole lot and then setting it into a vector drift. You the pilot must use the old conventional thrusters to get yourself back to fueling bay. When this happens the ship moves at such a crawl (fast enough to get to fuel bay however) that getting across the map would be incredibly tedious (maybe hours of drifting).

The main flagship however can use the Navigation HUD to plot a course, and it huge Long Distance Drives are empowered, this will increase the speed of the Frigate hugely (x100), and has a moderate acceleration speed and a equal to that deceleration speed. Getting across the map may take several minutes. During this time you cannot fly the ship, but you can use the HUDs to do RTS style stuff like research technologies, refining ores and such, and repairing fighters and bombers. I know its a huge fantasy of mine - but I do have some coding experience - mostly C# and I am really good at making game mechanics work - what I can't do is figure out how to upgrade the FRED and the game engine to use larger maps.

[ADDITIONALLY]

Oh and as some of you may have suggested - Sectors of space is the way to go - I've done 2d coding moving objects from one sector to another sector in relation of its directional path and its vector position before- doing it in 3d is definitely possible. I just don't know how to go about upgrading the Engine to recognize Sectors. A-1, B-2 etc...

The other thing about 3d models as Planets Moons, one trick I was thinking is that on the MAP view of things, your planet, moons, and such have a set position obviously, however - from the view of your HUD (cockpit) this position is changed drastically. What I mean is that - we a ll know 3d Model Planets and Moons typically look horrible up close, cause the textures gets stretched. However.. a planet the size of a Half Dollar on your screen looks pretty nice, and size double that or half of that look good too. Any sizes out side of that are either too small or too big (textures stretching). So instead create a slightly complex algorithm (method) to place the 3d model a set Perceived distance from the HUD at a vector originating from its actual Map position. Meaning, as you move closer to the Planet - it moves away from you. The 3d Model actually moves away from you as you come towards it - AT a slower rate of your top speed, so you will effectively get a little closer to it - just never enough to actually reach it. This is to make it look like that great distance you traveled brought you within planetary influence range. Does this make any sense??? May I should draw a picture...

[Tomo]

To be honest, I don't think the FSO engine is a sensible base to start from.

You appear to want to change everything about the FSO engine to create your game, which is probably going to be much more work than building your own engine based on a more modern 3D rendering framework.

C# experience isn't much help with C++ either - superficially, they might look similar, but C# really has more in common with Visual Basic than C++.

There are a lot of fundamental limitations of the single-sector, floating-point basis of the FSO engine, one of which being the aforementioned simulation accuracy once you get a significant distance from (0,0,0)(World)

My advice is as follows:
1) Look for a good, easy to use 3D rendering framework - given that you're happy with C#, a DirectX-based framework would probably suit you pretty well.

2) Build a rendering engine that is designe to handle your simulation requirements.
Eg: A sector-based, that limits sector size to something that allows equal simulation accuracy throughout every sector. A logical extension of this is to use a portal-based engine for sector culling and for invisible traversing between sectors.
- An alternative approach is to make the player always exist at (0,0,0)(World) and move everybody else around - this allows for perfect simulation 'close' to the player, getting progressively worse further away. Obviously this approach means that you cannot have a multiplayer option at all, and also means that if the player is 'too far' away from important events, they won't work properly.

[Bixel]

Good point, Tomo. You are quite right, I might still dabble with getting some ships into FS2 but yeh .. I don't thikn I wanna tackle the code here. I have discovered a really nice rendering engine and deals with incredibly incredibly incredibly incredibly HUGE distances, and renders stuff awesomely. Its called Celestia... http://www.shatters.net/celestia/index.html

The only problem is that I am trading off writing render code - to writing user control code - which will be pretty new to me. I was hoping to find a modifiable - engine that handles both the render and the user defined input but if it boils down to writing code I'd much prefer writing something I think I can actually accomplish and that is the user control (of the spaceship).

[Tomo]

User control code is almost trivial compared to rendering code.

The simulation routines are the complex part - but those are the bits that you're forced to write because that's what defines the 'feel' of playing the game. Free-flight simulations aren't as common as the Quake/Halflife style of FPS simulations.
FreeSpace is an 'aircraft'-style simulation (as is the Star Wars franchise), rather than an 'accurate' simulation.

So if you don't want that style of simulation, you'll have more trouble adapting it than starting your own.

[Nuke]

the thing that turns me off to a lot of other engines is the lack of source code. id love to use the orbiter engine (which from the outside seems to hbave an impressive sdk) but without the source its not as much fun. for example if you wanted to do something drastic, like weapons, or more accurate collision detection, id be sol.

[Aardwolf]

Wait wait wait... they made an Independence Day 2?

Or did you mean Independence War?