Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kazan on July 27, 2006, 12:07:54 pm
-
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)
-
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.
-
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
-
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.
-
that's not a bad idea
-
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.
-
well a pof defined field could assume any shape your modeling skills could create.
-
Taylor added in dynamic collision pair limits, didn't he?
Imposter-use sounds a great idea for distant asteroids, indeed.
-
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
-
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. ;)
-
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
-
I'm thinking, falcon scene fromempire........
-
you're thinking well - as you approach the center of the asteroid field it gets denser and obscures sensors :D
-
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?
-
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
-
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...
-
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)
-
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.
-
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
-
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.
-
This is slightly OT, but could this proposed revamp of the asteroid code, include future support for minefields? I won't go into extensive details regarding what kind of options I think minefields should include, but if you have access to the collaboration forum, you can check out my posts on the matter in the TBP request thread.
-
Wow funny co-incidence. Only today I took the time to have a good look at this thread and after a page I was going to ask the same thing Triv. It seems we have lots of asteroid specific features here but I would be more interested in a flexible "object field" editor. I want to be able to distribute collision or proximity mines. Really I'd like to have the freedom to distribute anything in a field without having to worry about different size classes, or EM interference, or stuff like that.
-
size classes are for asteroids, we could add other objects to the field types - could add varies mine types - then you could have a hybrid field of asteroids and mines if you want, or just one or the other.
-
Debris fields would be cool too.
-
Debris fields are already available in stock...:wtf:
The models for them are pretty bad though.
Anyway, any chance of this being implemented some time soon?
-
Well it can't go in before 3.6.9.
-
It seems the other thread in FS modding is sinking too fast, so I'll just repost here:
----
Ok, I'm pretty much ready to convert them - 24 rocks in all. Before I do though, here's a test pack: here (http://sectorgame.com/ti-file-dump/VasudanAdmiral/AsteroidsPreview.zip)
In the pack is one of each asteroid size class - small (around the 50m size mark, 1088 polys), medium (120m mark, 1520 polys), large (200m mark, 1890 polys), and huge (320m mark, 2860 polys). There are 6 variations of asteroid in each class.
So, have a look and see if there's anything else they need - including any pof data (will they need MOI data for example?). If those are fine I'll go ahead and convert the rest.
Edit: Changed d/l link.
-
Badabump!
http://www.hard-light.net/forums/index.php/topic,41294.msg864995.html#msg864995
-
sorry i'm slow responding guys.. busy with school work and martial arts (and getting ready for my wedding)
-
It'll be for after 3.7 anyway right? No rush - no worries. :)
And congrats. :yes:
-
Please take a look to Mantis 1003 (http://scp.indiegames.us/mantis/view.php?id=1003).
It shows an actually "undocumented feature" of FS2 about ship debris fields. You can't use it through FRED but you need manual fs2 file editing. It should have full support in future versions.
This feature allows the use of brown asteroids in ship debris fields, so you can:
- Make a mixture of ship and rock fields.
- Make an asteroid field with diferent sizes for rocks. (Sorry no active field).
Maybe, it is useful for some Fredders.
(I discovered the function while testing about the solved described bug).