0.6 plans

[klauss]

Collisions are designed in VS to have the bigger unit check for the smaller (something required by the spatial sorting in use). Missiles are the smaller, so no matter how high their priorities are, they won't collide with the ships. They only hit the ship when locked, if you check, and that's probably because then you lock a unit, it's popped into the high-priority slot too (assuming you're going to fire on it).

Bah, so that's why dumb fire rockets are so unreliable. Do "bolt" weapons have the same issue?

No, bolts have the ray test.

Actually, there isn't a high-enough priority slot for them to work. Missiles need ray testing.

Just curious, will you run the ray test between the positions of the missile last frame and present frame to check for between-frame impacts with units?

That's the general idea.

[safemode]

the idea is not to check for missed collisions that happened in the past. it is to check if any will occur in the coming translation and then if found, modify the translation so it collides at the first intersection point rather that the nth, or miss it altogether

[Deus Siddis]

That's the general idea.

So then you have to run a separate collision check to see if any point defense beams have hit the missile? Because obviously two rays would never collide.

And then is there any solution for making a bolt or missile hit an oncoming unit moving at a moderate "travel mode" velocity like 4000 m/s? Or will the unit now "pass through" the missile without a collision when its position is updated in a big way?

the idea is not to check for missed collisions that happened in the past. it is to check if any will occur in the coming translation and then if found, modify the translation so it collides at the first intersection point rather that the nth, or miss it altogether

My bad, that is the way to do it of course.

[safemode]

missiles are units, like any ship in the game. They have a mesh of their own. (should anyway).

They aren't rays. A collider exists outside of "reality" in the game. We can use a number of different methods to detect collision. We have sphere colliders, mesh colliders, and ray colliders currently in use. Sphere colliders basically look to see if any units radius * multiplier is intersecting with any other units radius * multiplier. If found we move to the mesh colliders to see where if at all, the two units intersect. We then are supposed to fix their translation and offer if valid, a force in a new direction as a result of such an impact.

Ray colliding is a bit of a parallel to sphere colliding. With ray colliding we send out a ray in the direction of the unit (in this case a missile) and see i it intersects with any meshes (ray colliders only work against mesh colliders). If found, we can then act on that in some way appropriate or move to mesh colliding at the point of the ray collision.

But missiles have models, meshes and all that that a normal ship has. Bolts and Beams are the only things in the game that dont but still interact with units that do. This is why it's difficult to terminate beams at the point of impact. The proper sequence for a beam would be for the Unit firing a beam to create a ray collider in the direction firing, then to create a draw for the beam that reflects the results from the ray collider. Since beams are effectively instant, this is a totally valid way to handle them. Energy Bolts also should behave in the same way as beams but they have a pulse to them. so the same method will work for them as well.

Projectiles are a different story though. They travel much slower than light and so you can't work out a collider at the time of firing. I haven't really looked into how they are handled but they would have to be handled totally differently from energy bolts and beams.

[Deus Siddis]

Interesting...

So beams and bolts work the same way but only look different then? Seems redundant...

Projectiles are a different story though. They travel much slower than light and so you can't work out a collider at the time of firing. I haven't really looked into how they are handled but they would have to be handled totally differently from energy bolts and beams.

Well unless point defense is supposed to work against the "Ball" projectile weapons as well as missiles, it seems like a ray test is all you would need for them. I mean they are so small and still traveling quite fast in many cases, so it is hard to imagine what else would be appropriate for them.

[log0]

As the velocities in VS are rather large compared to unit size, imho all collision tests(ship, missile/projectile, beam) should use swept sphere checks(ray segment with nonzero radius) for time of impact estimation followed by narrow phase collision test(mesh-mesh, ray-mesh, sphere-mesh). This is how bullet physics lib is dealing with tunneling btw.

[klauss]

As the velocities in VS are rather large compared to unit size, imho all collision tests(ship, missile/projectile, beam) should use swept sphere checks(ray segment with nonzero radius) for time of impact estimation followed by narrow phase collision test(mesh-mesh, ray-mesh, sphere-mesh). This is how bullet physics lib is dealing with tunneling btw.

Although it's easy to test capsules vs capsules (swept sphere = capsule), the complication lies in what to do once you get a hit. For missiles, I'd say just snap the position into the contact point and make it explode. For units, it's not so simple, since there are many cases in which a capsule would intersect but a collision wouldn't happen, and we wouldn't want to err in those cases (for the missile case, since missiles go so fast, it's another story).

[safemode]

As the velocities in VS are rather large compared to unit size, imho all collision tests(ship, missile/projectile, beam) should use swept sphere checks(ray segment with nonzero radius) for time of impact estimation followed by narrow phase collision test(mesh-mesh, ray-mesh, sphere-mesh). This is how bullet physics lib is dealing with tunneling btw.

That's how it works. Which is what i said. Not sure exactly how what you said differs from what i said.


Edit:
The difference between what you said and me is that you want sphere for everything. That's incorrect and wasteful and plain impossible in other situations. Sphere is used correctly in all the places it needs to be. What's missing is utilizing ray correctly and how we decide what size to make spheres and when to check.

edit2:

What i'd like to see is the game time the draw frame, and then loop physics to consume the remainder of every 60fps time slice so cpu is always at 100% use. Then what i'd like to see is a list of units not within drawing range of the screen. This list can be looped by a second (third/fourth, Num cpus) physics thread that joins back to the main thread every draw frame.

This wouldn't make the units move faster per draw frame, but it would cut the slices of the time frame up into smaller pieces, which reduces the chance of screwing up a collision.

Also, it would be really cool if we could code up "missile time" Camera can pan out to third person trailing view and the game stops simulating everything else when the missile gets within a certain distance of the player's ship... Only the missile and the player and we make time slow way down. Giving the player a few (5 real time) seconds to evade the missile and giving us a chance to really render some good good impacts when they dont Oh that would be so cool. We could implement it for all near unit collisions. Really we dont take advantage of the camera at all to showcase any sort of action.

[loki1950]

Really we don't take advantage of the camera at all to showcase any sort of action.

I've been thinking for quite a while that the engine would make a great space studio for cut scenes and lots of FX shots. pre-program ship tracks and maybe various weapons firing with the camera manually controlled or on a track as well.

Enjoy the Choice

[klauss]

Also, it would be really cool if we could code up "missile time" Camera can pan out to third person trailing view and the game stops simulating everything else when the missile gets within a certain distance of the player's ship... Only the missile and the player and we make time slow way down. Giving the player a few (5 real time) seconds to evade the missile and giving us a chance to really render some good good impacts when they dont Oh that would be so cool. We could implement it for all near unit collisions. Really we dont take advantage of the camera at all to showcase any sort of action.

Because it's a sim, and not an arcade. That's arcade stuff. In a sim, you really don't want the game pulling you out of the cockpit unexpectedly.

That doesn't mean you couldn't do that in the frame of cutscenes...

[safemode]

I tweaked the config file out a bit. It's quality settings were absurdly outdated. On the plus side, now missiles hit their targets even on my 16fps software rendering setup. I've also reworded the descriptions for the computer presets to be somewhat logical. However, ideally we should really just have a little benchmark test that sets up most of these things automatically. Users dont know what half this crap does or means.

It's not much of a change. These settings groups dont really include many options that they should that effect performance.

[klauss]

I tweaked the config file out a bit. It's quality settings were absurdly outdated. On the plus side, now missiles hit their targets even on my 16fps software rendering setup. I've also reworded the descriptions for the computer presets to be somewhat logical. However, ideally we should really just have a little benchmark test that sets up most of these things automatically. Users dont know what half this crap does or means.

It's not much of a change. These settings groups dont really include many options that they should that effect performance.

Oh... thanks. I've been meaning to do that for a while but haven't found the "priority" to do it (ie: always last on the todo)

I gather you increased physics frequency to make missiles hit?

[safemode]

i decreased the simulation atom 5x what it used to be for the top end. Bottom end is now what top end used to be as far as that goes. Each "computer" drops 1/5 the time. so it goes 0.05, 0.04 -> 0.01 ... 0.01 being for the faster computers. I can't tell how aggressive it is with software rendering, so if anyone is running a somewhat (less than year old) computer with decent graphics, can tell me what their cpu usage is with that setting that would be great. it is very possible to make it even more aggressive.

Decent graphics is like 7700 series ati, or whatever the eqiv is for nvidia. 7800 series ati/amd would be even better of a test. We want top end to really be top end.

[safemode]

I'll have a commit within a day or so of the re-designed Cephid 17 system. I have to re-touch dynamic generation of units to not get spawed into the voids of the system. But it's prettty cool looking launching from atlantis and having so much right in front of you without having to spec anywhere.

[klauss]

I'll have a commit within a day or so of the re-designed Cephid 17 system. I have to re-touch dynamic generation of units to not get spawed into the voids of the system. But it's prettty cool looking launching from atlantis and having so much right in front of you without having to spec anywhere.

I imagine so.

Don't worry about the spawning. Spawning happens around significant units. If you have significant units away from the jump hub, it's OK to launch ships around them. What ought to be retouched a bit is the characterization of "significant" to exclude planets, without breaking other stuff. Like shadows. Right now, only significant units produce "forced" shadows. That has to be turned into significant or planet. Just OTOMH.

Another tweak is to make the combat AI not engage in huge travel segments, but let cargo ships do so. And have SPEC-having ships not engage SPEC unless going really far.

[safemode]

i was taking a shortcut to test things... since i have all the jumppoints near eachother and all the bases near jump points, i was just changing the dynamic universe code that handles spawning from using a list of sig units into a list of jumppoints. it wouldn't be enough to just do that though. I would also need to tweak the ai codes a bit to not consider units very far away as something interesting to travel to. Then we wont have to change any of the code downstream in the engine. It should all be /data oriented.

[log0]

...The difference between what you said and me is that you want sphere for everything. That's incorrect and wasteful and plain impossible in other situations. Sphere is used correctly in all the places it needs to be. What's missing is utilizing ray correctly and how we decide what size to make spheres and when to check ...

sphere != swept sphere and toi calculation

[safemode]

OK, Couple things. I fixed an issue with the universe module that i caused when i ported over to py3. Now units are spawned where they're supposed to.

second thing, I have a rough draft of the consolidated system idea that has been thrown around by me for 0.6. It needs work but i think the best way to get that work done is by pushing it forward. When you start the game, you launch from atlantis. I have nearly every base and wormhole within 25km of that starting point, and almost all the regular units launch closely around wormholes ...hence nearly every unit in the system is around you. It looks pretty awesome. Unfortunately, my graphics situation means this is an impossible scene to render. But it looks pretty damn cool.

Now, 20km is not very far, but at 150m/sec it's still taking pretty long and there is currently not much to do still but to sit back and wait. Granted, there are tons of units you can play with, but currently there is no or little effect to communicating with other ships and there are really no fixers in-flight currently programmed except the tutorial ship.. But that should be remedied eventually.

In the meantime, i've devised a workaround to the spec-less universe. We get rid of all the interdiction and spec-inhibiting warp zones. And thus also, the complicated autopilot... and tone spec down to roughly 2000m/sec max velocity. Spec then makes much more sense working the way it does. We warp space, but not a whole lot, and we dont get anywhere near C so there are no weird physics problems with that... Also, we still lose shields because that interferes with spec and since we're less than C we can be interacted with without logic holes. Hence, collisions make sense and there is a downside to utilizing spec ...since you can still be targeted and shot at by many weapons (and you have no shields). 2000m/sec is still plenty slow for the new simulation atom for physics to catch collisions and we will treat spec like what it is.... an instant warpage of space, so no additional inertial force.

In any case, a spec limited to around 2000m/sec is doable without so much of the issues that current spec has ....and in this new cephid system i have made, it's _more_ than sufficient to get everywhere.

Let me know if anyone is interested in testing it out (all /data modifications so far) ...I want to iron out some of the spec interactions a bit before pushing. Also, i think now that we are consolidating the system, we dont need to generate like 5000 units .... my piece of crap video setup cries so hard trying to render what's on screen. No idea if a hardware setup can even handle it.

[klauss]

In the meantime, i've devised a workaround to the spec-less universe. We get rid of all the interdiction and spec-inhibiting warp zones. And thus also, the complicated autopilot... and tone spec down to roughly 2000m/sec max velocity. Spec then makes much more sense working the way it does. We warp space, but not a whole lot, and we dont get anywhere near C so there are no weird physics problems with that... Also, we still lose shields because that interferes with spec and since we're less than C we can be interacted with without logic holes. Hence, collisions make sense and there is a downside to utilizing spec ...since you can still be targeted and shot at by many weapons (and you have no shields). 2000m/sec is still plenty slow for the new simulation atom for physics to catch collisions and we will treat spec like what it is.... an instant warpage of space, so no additional inertial force.

Well... that's what I said with making it slower. Maybe 2kps is a bit on the slow end, but maybe we can have many kinds of SPEC drives, faster, slower, etc...

[safemode]

2kps is all you need with the new setup for cephid17. We dont really want units going any faster and wandering away. What would work though would be to have targeted campaign - type fixer initiated missions that temporarily allow the player to venture deep into a system but to a predetermined (at least determined at the time of running by the game) location where we can set something exciting up.

But the idea is we can work with less units, but they would be infinitely more densely packed in each system and the player would be surrounded by them all the time (more or less).

We definitely need to tweak ai though to deal with a densely packed setup. They just goto war at the moment. ...which while entertaining doesn't seem very likely to be a sustainable occurrence

[Deus Siddis]

Well... that's what I said with making it slower. Maybe 2kps is a bit on the slow end, but maybe we can have many kinds of SPEC drives, faster, slower, etc...

Ultimately...

I think what you need is fast spec drives for big ships and then no spec drives for small ships. There should be almost nothing in between. Otherwise you muddy the waters with this the whole "spec is special" direction.

If you buy or board a larger ship, like something in the range of 100 - 200 meters for a minimum, then the onboard SPEC drive should be taking you to the distant interior parts of a system at no less than the speed of light. And interdiction should happen automatically when you get close to a mass as it did in v0.4.x; but this time it won't be a problem due to the small traffic density in a system interior. In fact you want this to happen because each interior system encounter can be as potentially dangerous and rewarding as it is rare.

[safemode]

If you board (i don't believe you should be allowed to buy massive ships, they aren't piloted in any similar fashion as small ships are) a larger ship then you dont need to worry about spec at light speed, or interdiction or anything. The player will be in base-mode and the game can just place the mothership wherever it needs to and when the player launches again, he'll be at the intended destination.

[Deus Siddis]

(i don't believe you should be allowed to buy massive ships, they aren't piloted in any similar fashion as small ships are)

I'm not talking about massive ships, just big ones. The game's current balance of ship scales leaves a huge gap in the range of 100 - 1000 meter vessels, which I intend to fill in. Then you will have an arsenal of ships in the 50-200 meter range that will be flyable under the current control scheme, albeit with some extra skill needed. And many of them should have enough space and cost enough to justify fast SPEC. And the larger ones will be able to carry fighter fleet into battles.

It gives the early game player something to save up for and look forward to. It gives the late game player something new to do (slow, skillful and perhaps manual SPEC flight into "unexplored" system interiors) and puts full control of travel, in their hands.

If you board a larger ship then you dont need to worry about spec at light speed, or interdiction or anything. The player will be in base-mode and the game can just place the mothership wherever it needs to and when the player launches again, he'll be at the intended destination.

And that's okay, but it is static and dependent on someone someday doing a lot of scripting and being halfway decent at engaging you with their talent for storytelling.

But even if that ever happens, it is not alone what gives VS potential. With it's large, dynamic universe and sandbox-iness, this game is at least as much about letting the player go places and do stuff to see the dynamic, semi-unpredictable consequences of those actions unfold. I mean, IIRC, you can influence the tides of war by chipping away at an invading aera battle fleet with out any prompting from a fixer or specially scripted events. That kind of game play is at least as important as a hand written campaign, no matter how clever the writing or how many branches you give it.

And it may be VS' only (more or less) exclusive selling point. It makes VS the battlefield to everyone else' call of duty.

[safemode]

I would think that the lack of activity in vs, both in users and development would be indicative of how the way vs has been has failed to work. people don't enjoy wandering around and doing nothing. we need to stop kidding ourselves that what vs brings are these huge do what you want universes (systems). it isn't a feature in itself if nobody apparently enjoys it.

we need to get involved in the scripting and make NPC interaction with the player a primary goal and stop waiting for a real game to magically write itself into existence. what is holding things back are the huge mostly empty systems and all the crap we introduced to deal with them. games that are fun == players == development interest == artists == better game. which is what our goal should be.


edit: I'll have a new cephid system to showcase this change soon. I've been side tracked by a flood in my bedroom

[Primordial]

From a player standpoint, the problem with the sandbox as it stands is that nothing you do seems to affect anything. You can blast away at one faction until the end of time, but they'll just keep spawning and nothing seems to react, apart from some auto-gen news articles and a minor update on who is trying to kill you at what time. Unless something has changed, you can blow up a mining base in an enemy system, but it doesn't matter: a replacement spawns immediately a little way away. You can trade one thing from one system to another and it doesn't affect anything apart from who is trying to kill you at what time.

Occasionally something interesting will happen, seemingly by pure chance, but in general the rest of the ships in universe feel like props or cannon fodder, without any aim or impact.