Railgun.oxp v 1.3 now available

[Commander Wilmot]

I tried it, but have a few bugs "features". I fly a Vampire MK.V Diamondback and whenever I fired a round, it exploded (the round, not my ship, thankfully. My ship wasn't damaged.) I am testing the fer de lance 3G oxp and it crashed when I launched once, it didn't have a rail gun installed on it, I tried launching again with a rail gun, no problems other than the blowing up error.

By the way, the game tends to lag a bit, it was worst when I first booted up Oolite after installing the oxp, but that's not surprising with all the scripts it's running. So no complaints there.

As for the maintenance idea, I think that a high-power laser would require more maintenance than a rail gun. Current technology has allowed construction of rail guns, the problem is cooling them and finding somewhere to store the tractor trailer sized generator to power them. High power laser weaponry has to contend with issues like the requirements for a gas or other chemical injection system that is required for a high power Gas Dynamic Laser or other chemical lasers, that a large power source is used in a electrical solid state laser, and finally the fact that when a laser hits metal, it creates a cloud of superheated metal (also known as plasma) around the target, which infers with the laser beam's coherence. Laser weaponry sounds cool, but has a lot of problems attached.

...However with regards to the power issue, we have Quirium, a super-fuel and the weirdest stuff in the Ooniverse, also known to some of us as magic sunshine.

In all seriousness, I think the current requirements for the rail-guns are good, the rail gun currently works best as a back up weapon for when the forward laser is overheated. I think the trade-offs: only a hundred rounds of ammunition, which I think you could burn through quickly, the low damage, and the low fire rate compared to a laser (I tried the light rail-gun and it had a cycle rate roughly equal to that of a pulse laser, if not slower;) balance the fact that it is a weapon that does not overheat.

[Commander McLane]

I tried it, but have a few bugs "features". I fly a Vampire MK.V Diamondback and whenever I fired a round, it exploded (the round, not my ship, thankfully. My ship wasn't damaged.) I am testing the fer de lance 3G oxp and it crashed when I launched once, it didn't have a rail gun installed on it, I tried launching again with a rail gun, no problems other than the blowing up error.

I've just tried it with a Diamondback and it worked, both when standing still and when flying with top speed. However, the projectile is indeed created very close to the ship and it is possible that with a lower frame rate you would perhaps crash into it within one frame. Can you please try the following:

Open the file railgun-1-firing.js inside the Scripts-folder of railgun.oxp (this is for the small railgun) and find the line

Code: Select all

        this.projectile.position = player.ship.position.add(player.ship.heading.multiply(player.ship.collisionRadius + 10));

Then replace the '10' with a greater number. I'd suggest 20 or 30. This will make the projectile to be spawned further away from the nose of your ship.

Save the file and restart Oolite while pressing SHIFT. Then try to fire the small railgun again. If you want to make the same change to the medium and heavy railgun, you have to make the same change in the files railgun-2-firing.js and railgun-3-firing.js.

By the way, the game tends to lag a bit, it was worst when I first booted up Oolite after installing the oxp, but that's not surprising with all the scripts it's running. So no complaints there. ...

(I tried the light rail-gun and it had a cycle rate roughly equal to that of a pulse laser, if not slower;)

A small lag due to script execution is indeed to be expected, especially the moment when your target is destroyed. I have the same here, especially for asteroids.

I am a little surprised about the firing rate, though. On my computer the small railgun fires just as fast a I can hit the 'N' key, 10 rounds per second. That should be far quicker than a pulse laser.

What is your average frame rate? You can find out by pressing 'SHIFT-F' any time. This toggles a display in the upper right corner of your screen. The very first row of that display gives you your current frames per second (FPS). Which number do you get there?

[Commander McLane]

Would it be possible to make the projectiles much longer than they actually are, but only texture the front, centre, rear portion of the the projectile (so it looks like bursts of 3) - would collision detection then occur if some portion of the whole projectile, invisible bits included, intercepted the target?

It would probably be easier to place two identical subentities in front of and behind the projectile. And of course their density would have to be adjusted, because being longer (= more mass) would make them more deadly.

I have done this now, and discovered an Oolite oddity along the way.

The projectile in versions 1.0 and 1.1 is actually a model of an alternative cargopod (nubarrel), just shrunk a little and with a neutral texture. As a projectile it has a diameter of 1.28 m and is 7.68 m long. Oolite gives it a mass of about 102.

Now I have designed a smaller and simplified model with much less vertices, 1 m in diameter and only 3 m long. Together with two identical subentities I thought it could be longer but still have a comparable volume and therefore mass. It turns out, however, that the end result has a mass of 480. And indeed, one single of my new simplified projectiles has a mass of 160!

That's a little odd, I think:
- diameter 1.28 and length 7.68: mass 102
- diameter 1.00 and length 3.00: mass 160
Why does it get heavier when it gets smaller? Even the total volume of three of the smaller barrels should be smaller than the volume of the bigger barrel. Strange.

For the OXP it's not a problem, though. It just means that I'm tweaking the density until the new projectiles have about the same mass as the old ones.

[JensAyton]

As I’ve lamented on several occasions, mass is based on “volume”, and volume is based on the number of filled nodes in the collision octree, which is actually a voxel model of the surface of the model. Fixing this is non-trivial, since many models (including built-in ones) are nonmanifold (i.e., don’t have a well-defined inside), and changing the calculation would change all mass relationships.

[Switeck]

How about a flag in the unit's settings "simplified mass calculation = yes;", where everything else defaults to no?
Otherwise a Möbius strip type object might cause problems?
http://en.wikipedia.org/wiki/M%C3%B6bius_strip

[JensAyton]

Yes, I’m going to implement a bunch of new computational geometry code, change the default behaviour of all existing ships, rebalance the mass lock calculations to deal with the new situation and then add a flag to get back the previous behaviour, during a feature freeze.

We’re talking about a major revision of game physics here. As I mentioned before, I’ll be looking into physics libraries to handle collision detection for 2.0. It’s quite likely this will also provide us with a sensible way to calculate volume. On the other hand, I might end up making mass a mandatory shipdata.plist property and providing an offline tool to suggest an appropriate mass.

[Commander Wilmot]

Until Oolite 2.0, Could the oxp be simplified by a script which would perform a hit scan detection? (I think this is how the oolite weapons work in the source code) Maybe a script could project ahead where the target ship will be, so that the player would still be required to lead the target. (or the hitscan trajectory could be an arc. [wp]Hitscan[/wp]

[Commander McLane]

Until Oolite 2.0, Could the oxp be simplified by a script which would perform a hit scan detection? (I think this is how the oolite weapons work in the source code) Maybe a script could project ahead where the target ship will be, so that the player would still be required to lead the target. (or the hitscan trajectory could be an arc. [wp]Hitscan[/wp]

Why?

For starters, projecting ahead where the target ship will be by script strikes me as a massive, no, actually strike that, as a gargantuan complication.

Why try to simulate something by a script which the engine does all of its own anyway by actually flying the target ship to where it actually is when hit (or missed) by the projectile?

[JensAyton]

I think he means a method for scripts to use.

It might be worth investigating, but for relatively slow-firing weapons with slow-moving, visible projectiles firing over large distances, actual simulation seems a better choice. A “hitscan” approach would be more appropriate for, say, machine guns. (I actually want to move away from the single-ray model currently used for lasers and instead simulate them on a frame-by-frame basis, although they’ll still be infinitely fast.)

[Spartan]

Every railgun design I have seen (few enough as those have been) the rounds never touch the rails, being magnetically suspended.

While I am dropping another two cents here, I would be interested in seeing a mining version, perhaps a slower velocity with a more massive payload for splitting big rocks into little rocks. Not like they try to evade or even move very fast normally.

[JensAyton]

Every railgun design I have seen (few enough as those have been) the rounds never touch the rails, being magnetically suspended.

In that case, you’ve never seen a railgun design. :-) By definition, a railgun uses a conductive projectile which closes the circuit between the two rails. Magnetic suspension is used in Gauss guns (coilguns).

[Commander McLane]

While I am dropping another two cents here, I would be interested in seeing a mining version, perhaps a slower velocity with a more massive payload for splitting big rocks into little rocks. Not like they try to evade or even move very fast normally.

All current versions are perfectly usable for mining. As a matter of fact I noted explicitly somewhere at the beginning of this thread that they are almost too good mining tools. So much so that I raised their prices, because mining becomes ridiculously successful if you use any of them.

[Switeck]

On the other hand, I might end up making mass a mandatory shipdata.plist property and providing an offline tool to suggest an appropriate mass.

Probably the best choice. There's just too many strange shapes that won't get nice volume results.

[Spartan]

Every railgun design I have seen (few enough as those have been) the rounds never touch the rails, being magnetically suspended.

In that case, you’ve never seen a railgun design. By definition, a railgun uses a conductive projectile which closes the circuit between the two rails. Magnetic suspension is used in Gauss guns (coilguns).

Silly me, yes I was getting confused there. I have seen both but my brain was locked onto the gauss design apparently.

While I am dropping another two cents here, I would be interested in seeing a mining version, perhaps a slower velocity with a more massive payload for splitting big rocks into little rocks. Not like they try to evade or even move very fast normally.

All current versions are perfectly usable for mining. As a matter of fact I noted explicitly somewhere at the beginning of this thread that they are almost too good mining tools. So much so that I raised their prices, because mining becomes ridiculously successful if you use any of them.

Perfectly usable as long as the collision is detected, sure. Apparently I have issues in that department, hence the request for a slower heavier round. I don't mind if it's too slow for combat, it just has to hit the asteroid.

[Commander McLane]

While I am dropping another two cents here, I would be interested in seeing a mining version, perhaps a slower velocity with a more massive payload for splitting big rocks into little rocks. Not like they try to evade or even move very fast normally.

In response to customer calls there is now a pure mining version (starting with v 1.2), featuring slower but massive projectiles. Two of them are usually enough to crack an asteroid, and the boulders only need one hit each.

Downsides: long reload time and huge energy needs, the gun will set you back 12,500 credits, and the projectiles are so massive that they come only in bundles of 50. And if we could make equipment actually take cargo space, I would've done that as well. So be happy that you got lucky, and don't complain about the other downsides.

While experimenting with it I noticed that the current projectiles give too much bounty for boulders. In version 1.2 this will be corrected. In case you're wondering: the difference is only 0.5 credits per boulder, so you're not getting really rich currently. I am wondering, though, why whom.bounty /= 10 results in 1 if whom.bounty was 5. Seems bounties are stored in integers.

Version 1.2 will only work with current trunk, however. Therefore it doesn't make too much sense to release it right now. So you'll have to wait a little more.

EDIT: Hmmm, considering that a mining laser costs only 800 credits, perhaps I've gone a little overboard. On the other hand you can use the railgun as a weapon against big, slow-moving ships, and its firing rate is slightly better than a mining laser's. It's a difficult decision... Okay, I reduce the price to 7500, same as the heavy railgun, and adjust the firing rate to the same as the mining laser's.