[Kazan]

Yes i am volunteering to do most of this myself - some of it i cannot do myself because i simply wouldn't know how

Fundamental features of the fields themselves would be:

• More than one field can be defined in a mission (so you can make narrow navigation channels, etc)
• Depth-fogging
• More allowable asteroids
• Distant asteroids (that are still vis through the fog) as sprites, not models
• Asteroid "classes" with associated effects
• Asteroid "classes" distributed radially outward in shrouds from major-axis of field (IE class A statistically closest to major axis, D statistically furthest out)

Asteroid classes:

• Class A "Massive" Asteroids - Effects:
  • Total EM shadow
  • sensors, communications, IFF cannot penetrate
  • all ships obscured by a class A asteroid are undetectable
• Class B "Large" Asteroids - Effects:
  • partial EM shadow
  • sensors scrambled for ships in motion
  • ships sitting still are obscured completely.
  • IFF scrambled incapable of establishing solid lock (so flips between known and unknown),
  • communications garbled
• Class C "Medium" Asteroids - Effects:
  • minimal EM shadow
  • ships sitting still are scrambled and hard to detect
  • IFF identifiable
  • communications fine
• Class D "Small" Asteroids - RETAIL ASTEROIDS - No EM shadow

I could do everything but distance-fogging and the actual Observed->observer ray check (needs to find the LARGEST obscuring asteroid along the path)

[Shade]

Sounds interesting. I'd have liked to see those effects assignable to classes through a table or even something like checkboxes in FRED instead of hardcoded for specific asteroid classes though, but I can see how that would complicate things massively when figuring out which effects to apply in each case.

For the ray check, this is kindof a long shot, but you might be able to reuse/modify the existing collision code for beams to do the job for you along the observed->observer path. If a collision happens, check the asteroid type and either stop there if it's the biggest type, or continue checking for collisions until there are no more along the path.

[Kazan]

assignable effects would require a modification to asteroids.tbl to add the classes, then assign different asteroids to each class

I realize i'll have to let people statically position asteroids as well within the field for setting up ambushes, etc

[Nuke]

is there any possibilities to use pof files to define asteroid areas. the pof files merely are volume definitions to where asteroids are spawned and serve no other purpose. have a series of objects, all invisible textured, which defins where asteroids may spawn. object names determine the class of asteroids that will apear within the volume (fieldA01 or fieldC02 for example). that way you could very easily and accurately define an astroid area, complete with clear areas, dence areas, mush as freelancer does it. also you might want to consider adding a new ai behavior such as hide behind (evasive) or ambush (offensive) to accomidate the mood.

[Kazan]

that's not a bad idea

[Starman01]

While this all sounds great, could you take one feature more into consideration ? Can you alter the field from a cubic form (x,y,z-axis) to a spheroid one (which has still x-y and z-axis and would also allow ellipsoid forms) ? It really sucks flying towards or on the side of a cubic field.

[Nuke]

well a pof defined field could assume any shape your modeling skills could create.

[aldo_14]

Taylor added in dynamic collision pair limits, didn't he?

Imposter-use sounds a great idea for distant asteroids, indeed.

[Kazan]

even if i didn't do mesh-defined regions i planned on doing spheroid regions - IE a sphere that can be streched on various axis - as well as square regions, etc

[DaBrain]

Great idea. The asteroid fields should be way cooler than they are now.

The multiple asteroid thingy, should be great for WC:Saga. And the peformance should also increase.

[Kazan]

asteroid motion will be almost nill above class D - may get slow rotation above class D but i don't think anything larger should really be moving

and total-asteroids will be for all areas enclosed in asteroid boundries in a mission

[Colonol Dekker]

I'm thinking, falcon scene fromempire........

[Kazan]

you're thinking well - as you approach the center of the asteroid field it gets denser and obscures sensors

[Colonol Dekker]

I'm also thinking SAAB where the 158th engage in the battle fo the belt, (the bit where the noob gets squished)


Seriously though, the chances would be pretty sli m on making a giant cave-worm using the animation code i'm guessing?

[Kazan]

cave-worm is beyond my interest
and yes the S:AAB battle would be another nice one - i'm sure BSG will love this too

[Mefustae]

How much slowdown would having seriously massive fields create? By seriously massive, I mean up to the size of a few small planetesimals, in case I someone wanted to make a campaign in an early-forming solar system...

[Kazan]

no idea until i try and write this - i first need to get autopilot working on multiplayer (which requires time compression on multi to function)

[Flaser]

IMHO we should keep in mind that we are creating an illusion....therefore we don't have to model,draw or even know everyting. We only have to know and render what's around the player and the other ships.

For that reason I really like the whole field aproach especially the pof one, that way the code doesn't have to handle all calculations of n-number asteroids, merly the statistics of n-number asteroids.

Let me further explain what I mean: when modeling gases physicists can't and don't have to model each and every single gaseous particle:

Instead they use physical factors that define the gas as a whole instead the sum of its parts, things like volume, pressure, and temperature, number of particles.
We should take the very same approach.

We should separate the 'virtual modelling' and the actual 'visible rendering' of the fields.

Initially we should model asteroid fields with such variables:
-number of asteroids in the field
-volume of the field
-average asteroid momentum

When a ship enters a field it is pitted against the statistics and its own statistics wage war against them determining wheter it can evade, shoot its way through and take damage meanwhile in calculated rate.

This can take place without ever rendering a single asteroid, resolving a single collision detection or even calculating tracking data for turrets.
It's cheating....but if it works it could make all our Falcon chase dreams and endless 'Roid 'Bolero dreams true.

That way we have a backup simulation that could go on in the background.

Actual rendering that way would only have to take palce around the player(s), greatly reducing the calculation and memory cost of the whole ordeal.
Said rendering could exploit a number of tricks to give the impression of depth and density of the field using sprites as Kazan suggested and demonstrated in the BTRL video.

Using this aproach we could even have endless asteroid fields by defining the game area as one of the fields instead empty space.

[Kazan]

never, EVER type my name as "Kazaan"

and what you're talking about is far too calculation expensive and duplicating effort, and vastly more difficult to simulate than my idea - we can prevent having to calculate collision data on distant asteroids by forcing their motion to be nill while they're at sprite-level rendering and then we can safetly ignore them

[Flaser]

Typo corrected.

Meh...all I was pondering was how to calculate interactions between ships and asteroids when the player is not present....and I didn't even consider collision checks BETWEEN asteroids, since they are already ignored...

....chaning which will be a new development though, since it was present in FS1 but not FS2.