Moving [Constants] to other ini's and [Encounters] to Constants.ini
-
Hello All,
To my pleasant surprise, some bright hackers have found ways to add custom DLLs that alter how the game behaves.
I haven’t tested it yet, but M0tah created a MultiCruise.dll, that allows to cruise_speed to be added to the engine, instead of being a constant (there are side issues to this, but I don’t wanna go there here).
My questions are:
1. Could it be possible to have certain [Constants] be redefined in the star system’s .ini files? E.g. it would be cool to be able to lower the maximum cruise speed in certain star systems. Or to have differences in bumpiness of asteroids, per star system. Leaving the system should of course have the game use the defaults (as defined in Constants.ini) again.
2. Could it be possible to move all the [Encounter] references to Constants.ini? Although not all systems feature all the encounters, the [Encounter] references are allways the same. It would save space to not have them in each star system’s .ini.
Btw, I have no clue how to make custom DDLs, so if the answer to both question is “Yes, that can be done”, there would still be a bright modder required to actually create it
-
Well, I guess it cannot easily be done. Thanks for reading it anyway
-
You can add a drag modifier in zones which slows the movement of ships (in cruise, or just with thrusters? I forget). So I suppose you could have a system with one large zone in it that has this parameter defined in it.
As for moving the encounters to constants.ini, I don’t see the need for it. It really wouldn’t save much space, maybe a few hundred kb in total, which is nothing if you add a new ship or something.
-
Ogu wrote:
You can add a drag modifier in zones which slows the movement of ships (in cruise, or just with thrusters? I forget). So I suppose you could have a system with one large zone in it that has this parameter defined in it.If I remember correctly, that is thruster speed only. It would be nice to also limit cruiser speed in a system, maybe by using to anom_speed_limit parameter…
As for moving the encounters to constants.ini, I don’t see the need for it. It really wouldn’t save much space, maybe a few hundred kb in total, which is nothing if you add a new ship or something.
Your probably right when you talk about resource space. Actually it’s more that I find it annoying having to scroll to all the encounter stuff in every starsystem .ini. Expecially while all encounter types are always the same: e.g. area_bh_scout always points to missions\encounters\area_bh_scout.ini.
But it’s not really a problem, more an inconvenience
-
You could write a utility to scan all your system ini files and ensure only the encounters that are used in that system are declared at the top.
At least that would automate it and also cut down the file sizes.
-
StarTrader wrote:
You could write a utility to scan all your system ini files and ensure only the encounters that are used in that system are declared at the top.At least that would automate it and also cut down the file sizes.
I could, but I can’t :lol: Write utilities, I mean.
If I could write utilities, I would write a patrol_path calculator that would generate a path between a given number of coordinates.
-
Well that is not so hard, I use Excel for that type of calculation, and the formulae are fairly easy.
Have a go and you will surprise yourself, the only changing thing is the size of each system.
So start with your two cells for the x and y start-point co-ordinates, add the two for the destination, and put in your formula to give you the rotation, and… build it up to be what you want.
-
But the math becomes quite heavy when you start thinking 3D. 2D rotation calculations are simple, but 3D ones enter the realm of rotation matrices and yaw/pitch/roll ordering, which is… Meh.
-
FriendlyFire wrote:
But the math becomes quite heavy when you start thinking 3D. 2D rotation calculations are simple, but 3D ones enter the realm of rotation matrices and yaw/pitch/roll ordering, which is… Meh.Yet, for all practical purposes, patrol paths are 2d, right?
StarTrader wrote:
Well that is not so hard, I use Excel for that type of calculation, and the formulae are fairly easy.Have a go and you will surprise yourself, the only changing thing is the size of each system.
So start with your two cells for the x and y start-point co-ordinates, add the two for the destination, and put in your formula to give you the rotation, and… build it up to be what you want.
Thx for the encouragement
Yet, I think I could do that for the length (using pythagoras), but for the angle I would need to get into the whole sinus / hypotenuse thing. That’s a looong time ago for me. I don’t even know if the sinus function is available in Excel?Thinking of it - I still don’t have a working Office package on this laptop. The compuer branche at my work had this offer that I could order a acopy for 12 euro’s! (Apparently they made a deal with MS) I didn’t bother but maybe I should. I 'll call them tomorrow and see if it’s still available.
Anyway, installing FLExplorer and using it as suggested prolly will do fine.
-
OpenOffice is free and would do what you need. Heck, Google Docs would do fine.
And while patrol paths are 2D in vanilla, why would systems always strictly be 2D? We’re in space! Why restrict to a plane when you have a whole other axis to explore?
PPs, just like anything, could have a pitch other than zero and it would be a good thing for variety.
-
FriendlyFire wrote:
OpenOffice is free and would do what you need. Heck, Google Docs would do fine.And while patrol paths are 2D in vanilla, why would systems always strictly be 2D? We’re in space! Why restrict to a plane when you have a whole other axis to explore?
PPs, just like anything, could have a pitch other than zero and it would be a good thing for variety.
Playing with 3D systems was one of the first things I did when I started modding. I remember several issues, some of which were also reported on LancersReactor. Setting up tradelanes is messy, and the same goes for Jump Gates. It has been a long time, can’t reproduce the exact details. But the game seems to expect that things are in the Z=O plain or at least parallel to it.
Btw, the planets in the solar system tend to orbit in the same plane. Pluto is an exception; the transneptunian planetoids seem to be less bound by this.
-
They also tend to be thousands of kilometers in diameter, billions of kilometers apart and actually orbit and rotate. Let’s not enter in the realm of realism when FL is concerned, shall we?
To me, systems in FL are far more of an art than a science. You make something that looks good; screw how realistic or believable it is, because you’ll NEVER make it realistic anyways. If it looks good, people will like it and all will be fine. If you strive for realism, people will pick every single fault they can find and criticize you for it.
-
FriendlyFire wrote:
They also tend to be thousands of kilometers in diameter, billions of kilometers apart and actually orbit and rotate. Let’s not enter in the realm of realism when FL is concerned, shall we?To me, systems in FL are far more of an art than a science. You make something that looks good; screw how realistic or believable it is, because you’ll NEVER make it realistic anyways. If it looks good, people will like it and all will be fine. If you strive for realism, people will pick every single fault they can find and criticize you for it.
That is all very true. Yet I think it’s cool to strive for some degree realism, not as much for the sake of getting it scientifically right, but, and now I’m getting silly, I’ll never actually get to fly around a planet. This might the closest I’ll ever get. So, partly I like the game engine because it’s like Celestia with a cool sci-fi interface
That having said, I must admit there is little room to increase reality. The game’s asteroid fields and nebula’s probably don’t come close to those in the real universe. Also, realistic sizes and distances would render the game boring.
I once worked on some kind of remake of Sirius, where an in-game system would not represent a single complete star system but rather a jump node within one star system. Liberty would be one star system, and New York, Colorado, California and Texas would be jump nodes - separate .ini files - orbiting the same star. That way the (non-targetable!)star could be made much bigger and placed farther away, depending on how far that jump node was supposed to from the star system’s center.
Of course, this is hardly more than background cosmetics.
-
Oh, it’s definitely possible to transform FL into a near-realistic game. Newtonian physics, true scale, etc. It works great, but… It can’t be adapted to the vanilla game. You need to wipe everything and design the whole experience around the new criteria, otherwise the game feels clunky and unplayable. There are also large issues with NPCs with such distances.
-
It would be cool if gravity could be added to the game…
But I should be sleeping already.
-
