Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kazan on July 12, 2002, 03:48:19 pm
-
Ok, i started screwing around with the asteroid code today.. met it with mixed success
I tried adding two new asteroid types and increased the max number of asteroids.
The test is set to 1500 asteroids, collisions were broken, weapon sounds would play but nothing would come out. The increased number of asteroid types prevented it from crashing with the new table, but i didn't see any instances in which the larger asteroids where used
I could definantly use your help dave with the collision thing if you're reading
my changes to the header
#define MAX_ASTEROIDS 16384
// DEBRIS TYPES
#define MAX_DEBRIS_TYPES 14
#define ASTEROID_TYPE_SMALL 0
#define ASTEROID_TYPE_MEDIUM 1
#define ASTEROID_TYPE_BIG 2
#define ASTEROID_TYPE_HUGE 3
#define ASTEROID_TYPE_COLOSSAL 4
//
#define DEBRIS_TERRAN_SMALL 5
#define DEBRIS_TERRAN_MEDIUM 6
#define DEBRIS_TERRAN_LARGE 7
//
#define DEBRIS_VASUDAN_SMALL 8
#define DEBRIS_VASUDAN_MEDIUM 9
#define DEBRIS_VASUDAN_LARGE 10
//
#define DEBRIS_SHIVAN_SMALL 11
#define DEBRIS_SHIVAN_MEDIUM 12
#define DEBRIS_SHIVAN_LARGE 13
// END DEBRIS TYPES
from what it origionally was
and in the asteroid.cpp
void asteroid_create_all()
{
int i, idx;
// ship_debris_odds_table keeps track of debris type of the next debris piece
// each different type (size) of debris piece has a diffenent weight, smaller weighted more heavily than larger.
// choose next type from table ship_debris_odds_table by rand()%max_weighted_range,
// the first column in ship_debris_odds_table random number *below* which the debris type in the second column is selected.
int ship_debris_odds_table[3][2];
int max_weighted_range = 0;
if (!Asteroids_enabled)
return;
if (Asteroid_field.num_initial_asteroids <= 0 ) {
return;
}
int max_asteroids = Asteroid_field.num_initial_asteroids; // * (1.0f - 0.1f*(MAX_DETAIL_LEVEL-Detail.asteroid_density)));
int num_debris_types = 0;
// get number of ship debris types
if (Asteroid_field.debris_genre == DG_SHIP) {
for (idx=0; idx<3; idx++) {
if (Asteroid_field.field_debris_type[idx] != -1) {
num_debris_types++;
}
}
// Calculate the odds table
for (idx=0; idx int debris_weight = get_debris_weight(Asteroid_field.field_debris_type[idx]);
ship_debris_odds_table[idx][0] = max_weighted_range + debris_weight;
ship_debris_odds_table[idx][1] = Asteroid_field.field_debris_type[idx];
max_weighted_range += debris_weight;
}
}
// Load Asteroid/ship models
if (Asteroid_field.debris_genre == DG_SHIP) {
for (idx=0; idx asteroid_load(Asteroid_field.field_debris_type[idx], 0);
}
} else {
if (Asteroid_field.field_debris_type[0] != -1) {
asteroid_load(ASTEROID_TYPE_SMALL, 0);
asteroid_load(ASTEROID_TYPE_MEDIUM, 0);
asteroid_load(ASTEROID_TYPE_BIG, 0);
asteroid_load(ASTEROID_TYPE_HUGE, 0);
asteroid_load(ASTEROID_TYPE_COLOSSAL, 0);
}
if (Asteroid_field.field_debris_type[1] != -1) {
asteroid_load(ASTEROID_TYPE_SMALL, 1);
asteroid_load(ASTEROID_TYPE_MEDIUM, 1);
asteroid_load(ASTEROID_TYPE_BIG, 1);
asteroid_load(ASTEROID_TYPE_HUGE, 1);
asteroid_load(ASTEROID_TYPE_COLOSSAL, 1);
}
if (Asteroid_field.field_debris_type[2] != -1) {
asteroid_load(ASTEROID_TYPE_SMALL, 2);
asteroid_load(ASTEROID_TYPE_MEDIUM, 2);
asteroid_load(ASTEROID_TYPE_BIG, 2);
asteroid_load(ASTEROID_TYPE_HUGE, 2);
asteroid_load(ASTEROID_TYPE_COLOSSAL, 2);
}
}
// load all the asteroid/debris pieces
for (i=0; i if (Asteroid_field.debris_genre == DG_ASTEROID) {
// For asteroid, load only large asteroids
// the above comment was depricated by Kazan's changes, now selects between BIG [probably], HUGE [kinda probable], Colossal [unlikely]
int MainType = rand() % 9;
// get a valid subtype
int subtype = rand() % 3;
while (Asteroid_field.field_debris_type[subtype] == -1) {
subtype = (subtype + 1) % 3;
}
switch (MainType)
{
case 9:
asteroid_create(&Asteroid_field, ASTEROID_TYPE_COLOSSAL, subtype);
break;
case 8:
case 7:
asteroid_create(&Asteroid_field, ASTEROID_TYPE_HUGE, subtype);
break;
default:
asteroid_create(&Asteroid_field, ASTEROID_TYPE_BIG, subtype);
break;
}
} else {
Assert(num_debris_types > 0);
int rand_choice = rand() % max_weighted_range;
for (idx=0; idx<3; idx++) {
// for ship debris, choose type according to odds table
if (rand_choice < ship_debris_odds_table[idx][0]) {
asteroid_create(&Asteroid_field, ship_debris_odds_table[idx][1], 0);
break;
}
}
}
}
}
void asteriod_explode_sound(object *objp, int type, int play_loud)
{
int sound_index = -1;
float range_factor = 1.0f; // how many times sound should traver farther than normal
switch (type) {
case ASTEROID_TYPE_SMALL:
case ASTEROID_TYPE_MEDIUM:
case DEBRIS_TERRAN_SMALL:
case DEBRIS_TERRAN_MEDIUM:
case DEBRIS_VASUDAN_SMALL:
case DEBRIS_VASUDAN_MEDIUM:
case DEBRIS_SHIVAN_SMALL:
case DEBRIS_SHIVAN_MEDIUM:
sound_index = SND_ASTEROID_EXPLODE_SMALL;
range_factor = 5.0f;
break;
case ASTEROID_TYPE_BIG:
case ASTEROID_TYPE_HUGE:
case ASTEROID_TYPE_COLOSSAL:
case DEBRIS_TERRAN_LARGE:
case DEBRIS_VASUDAN_LARGE:
case DEBRIS_SHIVAN_LARGE:
sound_index = SND_ASTEROID_EXPLODE_BIG;
range_factor = 10.0f;
break;
default:
Int3();
return;
}
Assert(sound_index != -1);
if ( !play_loud ) {
range_factor = 1.0f;
}
snd_play_3d( &Snds[sound_index], &objp->pos, &Eye_position, objp->radius, NULL, 0, 1.0f, SND_PRIORITY_MUST_PLAY, NULL, range_factor );
}
void asteroid_maybe_break_up(object *asteroid_obj)
{
asteroid *asp;
asp = &Asteroids[asteroid_obj->instance];
if ( timestamp_elapsed(asp->final_death_time) ) {
vector relvec, vfh, tvec;
asteroid_obj->flags |= OF_SHOULD_BE_DEAD;
// multiplayer clients won't go through the following code. asteroid_sub_create will send
// a create packet to the client in the above named function
if ( !MULTIPLAYER_CLIENT ) {
switch (asp->type) {
case ASTEROID_TYPE_SMALL:
break;
case ASTEROID_TYPE_MEDIUM:
asc_get_relvec(&relvec, asteroid_obj, &asp->death_hit_pos);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_SMALL, &relvec);
vm_vec_normalized_dir(&vfh, &asteroid_obj->pos, &asp->death_hit_pos);
vm_vec_copy_scale(&tvec, &vfh, 2.0f);
vm_vec_sub2(&tvec, &relvec);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_SMALL, &tvec);
break;
case ASTEROID_TYPE_BIG:
asc_get_relvec(&relvec, asteroid_obj, &asp->death_hit_pos);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_MEDIUM, &relvec);
vm_vec_normalized_dir(&vfh, &asteroid_obj->pos, &asp->death_hit_pos);
vm_vec_copy_scale(&tvec, &vfh, 2.0f);
vm_vec_sub2(&tvec, &relvec);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_MEDIUM, &tvec);
while (frand() > 0.6f) {
vector rvec, tvec2;
vm_vec_rand_vec_quick(&rvec);
vm_vec_scale_add(&tvec2, &vfh, &rvec, 0.75f);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_SMALL, &tvec2);
}
case ASTEROID_TYPE_HUGE:
asc_get_relvec(&relvec, asteroid_obj, &asp->death_hit_pos);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_BIG, &relvec);
vm_vec_normalized_dir(&vfh, &asteroid_obj->pos, &asp->death_hit_pos);
vm_vec_copy_scale(&tvec, &vfh, 2.0f);
vm_vec_sub2(&tvec, &relvec);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_BIG, &tvec);
while (frand() > 0.6f) {
vector rvec, tvec2;
vm_vec_rand_vec_quick(&rvec);
vm_vec_scale_add(&tvec2, &vfh, &rvec, 0.75f);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_MEDIUM, &tvec2);
}
case ASTEROID_TYPE_COLOSSAL:
asc_get_relvec(&relvec, asteroid_obj, &asp->death_hit_pos);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_HUGE, &relvec);
vm_vec_normalized_dir(&vfh, &asteroid_obj->pos, &asp->death_hit_pos);
vm_vec_copy_scale(&tvec, &vfh, 2.0f);
vm_vec_sub2(&tvec, &relvec);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_HUGE, &tvec);
while (frand() > 0.6f) {
vector rvec, tvec2;
vm_vec_rand_vec_quick(&rvec);
vm_vec_scale_add(&tvec2, &vfh, &rvec, 0.75f);
asteroid_sub_create(asteroid_obj, ASTEROID_TYPE_BIG, &tvec2);
}
break;
// ship debris does not break up
case DEBRIS_TERRAN_SMALL:
case DEBRIS_TERRAN_MEDIUM:
case DEBRIS_TERRAN_LARGE:
case DEBRIS_VASUDAN_SMALL:
case DEBRIS_VASUDAN_MEDIUM:
case DEBRIS_VASUDAN_LARGE:
case DEBRIS_SHIVAN_SMALL:
case DEBRIS_SHIVAN_MEDIUM:
case DEBRIS_SHIVAN_LARGE:
break;
default:
Int3();
}
}
asp->final_death_time = timestamp(-1);
}
}
(http://www1.cedar-rapids.net/Kazan/Ast00.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast01.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast02.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast03.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast04.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast05.jpg)
-
Wow it looks really dense and pretty atmospheric. i wouldn't like to escort a large ship through there. :)
Great work Kazan :nod:
-
Nice. :yes:
At least when/if it will be fully functional.
Larger (huge) asteroids would be very nice. ;)
Edit: Huge asteroids... fighter cannons wouldn't do much, and you'd need beams or bombs to destroy them. Now that would be something I'd like. :nod:
-
ok, the larger asteroids ARE working, i just need to improve the odds for the COLOSSAL asteroid
-
hmm... that made it more interesting
collisions were working but i didn't change anything to make them work... weird - i'm tweaking the Colossal asteroid odds
weapons fire still borken - even the 10% damage cheat code was non functioning [after enabling cheats]
(http://www1.cedar-rapids.net/Kazan/Ast06.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast07.jpg)
(http://www1.cedar-rapids.net/Kazan/Ast08.jpg)
-
OK, the collision detection/firing problems etc is just from the number of objects on the screen - the same problem you see with asteroid fields of size 256 with the existing executable, we need to figure out how to fix that
-
:yes: Very nice. :yes2::yes:
Those seem to be pretty big now, but do they do more damage when they impact?
But what about destroyer (or so) sized asteroids?
-
i think there are too many objects on the screen for weapons fire to register. just my guess
code/object/object.h line 316
#define MAX_OBJECTS 1000
-
Perhaps thats sort of like when too many bitmaps are being rendered somewhere...the gun bitmaps stop showing up.
Happened in OTT with one of Venom's guns and a particular ship. Too many bitmaps being rendered and they stoped being rendered.
-
that fixed it a bit phreak, but it quickly crashed
-
Originally posted by Kazan
that fixed it a bit freak, but it quickly crashed
Are you running a debug build? Is it spewing out anything useful before it dies? Try turning Log_debug_output_to_file on and see what gets dumped to fs.log, if anything...
-
no i was running a release, hoping for performance
-
Hmm... I'm looking for the smaller asteroids to be in there, too. We need humongous and smaller ones there.
We know the average asteroid speed is applied to every asteroid, right? Is there any way for larger asteroids to move slower while small ones zip around?
-
I'm getting a buch of weird errors from osapi.h all of the sudden after trying to turn that Log_debug_output_to_file thing on (still getting it after I turn it off),
D:\Games\projects\freespace2_public\code\OsApi\OsApi.h(57) : error C2146: syntax error : missing ';' before identifier 'os_get_window'
D:\Games\projects\freespace2_public\code\OsApi\OsApi.h(57) : error C2501: 'uint' : missing storage-class or type specifiers
D:\Games\projects\freespace2_public\code\OsApi\OsApi.h(57) : fatal error C1004: unexpected end of file found
I haven't changed anything in here so why did this just start hapening
and this is the line it doesn't like
uint os_get_window();
-
Impressive work! Nice one!
What are the chances of being about to do some small asteroids that spawn when the larger ones are destroyed? And by small I mean tiny. I know the game already makes slightly smaller asteroids when a large one is destroyed but it doesn't really feel like chunks of rock. I'd love to see about 50 something small (read, about a meter) large chunks of rock flying off away from destroyed asteroids. It'd make taking asteroids out a lot more interesting since those things can be bad for your shields if you let them hit you...
(I'm just getting heavily inspired from the asteroid field scene in SW2:AOTC).
-
mabey if the asteroids were far lower poly count, or a far away lod was 2d, it might be easier for the game to handle. that is definatly a more realistic asteroid field. lower polyed asteroids might make it work better. *guess*
-
Originally posted by Thunder
Impressive work! Nice one!
What are the chances of being about to do some small asteroids that spawn when the larger ones are destroyed? And by small I mean tiny. I know the game already makes slightly smaller asteroids when a large one is destroyed but it doesn't really feel like chunks of rock. I'd love to see about 50 something small (read, about a meter) large chunks of rock flying off away from destroyed asteroids. It'd make taking asteroids out a lot more interesting since those things can be bad for your shields if you let them hit you...
(I'm just getting heavily inspired from the asteroid field scene in SW2:AOTC).
It always looked to me like the mass of the two smaller ones that spawned from the destroyed larger one was actually greater than the original larger one.
-
btw: if you want to make planetary rings instead of asteroid fields - it's kinda doable with this code - you just have to replace the POFs for the asteroids
-
im still having problems with collision detection... ideas?
-
Did the crashes stop?
-
apparently
-
Oh, excellent. Sorry, asleep at the switch on that discussion :)
-
hehe
-
hmmm, i`m getting the same kind of problem when i put to many ships in a single mission like 398 fighters and 1 demon. what are your frame rates?.
collision and weapon damage(i assume some form of collision dont work here) is not working until i order all the fighters 1to leave.
It may be depending on hardware vs frame rates. Well just my idea.
regarding reading out FPS.
in freespace.cpp
you will find this
#ifdef RELEASE_REAL
int Show_framerate = 0;
#else
int Show_framerate = 1;
#endif
change 0 to 1, ofcourse. as if you did not know :)
but Maybe tampering with one of the MAX_X
will solve this.
Glancning at
#define MAX_PAIRS 8000
MK does comment this regarding a mission with an asteroid field.
or MAX_FRAME_COLLISIONS 5. dont know how to understand this one.
-
i tried increasing max pairs, didn't have an effect [maybe i didn't increase it enough? i quadrupled the max object count... hmmm]
-
increasing things didn't help
here are the Framerates i got
Max: 30.0 fps [looking at nothing but background], it appears to be the highest framerate FS2 will produce, *shrug*i often average 70 fps in Unreal Tournament at 1024x768 high detail
Min: 5.4 fps [looking down the major axis of the asteroid field, with a NTF asteroid base in view]
-
well, a suggestion to make it more realistic: edit the source so that when any asteriod is destroyed, it references 2 other asteriods to be spawned by refering to the asteriods tbl. This will allow someone to create very realistic spawns by having the 2 spawned asteriods as peices of the larger asteriod :nod:
and i do realize that you have to get the basics working first, but this is just something for you to look at as a possible goal eventually :D
-
that's already how it works
-
Originally posted by Kazan
that's already how it works
in that case we need someone to replace the current asteriod models with more appropriate ones
-
have you tryed giving asteriods a quicker colision detection, like using the radius for them and just seing if something comes within that distance of the center of the rock, most of them are fairly shpereoid
also try slowly racheting up the asteroid count untill one of the problems start
-
physical ship to ship collisions work, but no weapon collisions work
-
isn't there weapon<->asteroid colision spesific code
-
it's not just weapon-asteroid
it's weapon-anything
and if i decrease the number to 150 the problem goes away
-
what happens at 151 ?
everything break, or just some things
-
it was a rought number - i don't know the exact number at which it breaks
-
it might be easier to find what max value you're over shooting if you know the number of asteroids at wich it breaks
-
it's dependant on TOTAL objects in the scene, not just asteroids
-
Hmm - Whilst I admit to knowing nothing of this sort of thing, would it be easier to re-write the code so that a weapon fired always hits when it collides with an object? I can't see a reason for it not to hit. And it makes things a lot easier than guessing the number that will be a balance between hitting and the number of objects on the screen etc... Especially if we're going to be upping the poly count, model on screen number etc....
But meh - I know nothing.
-
What about jump nodes, though?
-
Would it be possible to add in another style of asteroids?
This one being a nebular type field, but instead of taking up the whole screen and battlefield it would be limited to the same bounding box that you would assign a regular asteroid field...
This way you could have missions that are on the fringes of a nebula instead of in the smack-middle of it.
-
before suggesting more features let me fix the bugs in this
thunder: to fix a bug, you have to first understadn the bug
-
True, but (whilst I re-state my lack of knowlege) you might be able to forget the bug all together if you ripped out the relevant code and put in a new system.
Of course, it's not as easy as that methinks...
-
i meant i don't understand the bug, i could do all the ripping out and rewriting of things as i want, i'd probably just make it not work as well. I need to understand the bug before i can do anything about it
We need DaveB's input
-
Is all your code up in the thread? There are a decent group of people here, might be able to help, Dave will have to want to help, and recent events may not make him inclined to do so.
So, this works as designed if there are fewer than 150 objects in the scene (refresh my memory, is the scene defined in your mind as on screen)?
What kind of hardware are you on, out of curiousity?
Also, not that it matters much, but are you working from released code, code you have been personally working on, or the fs2_open build from the warpcore CVS?
Question for the group: Has anyone else tried this? A community project only works if we're working together ;)
-
the origional release code is what i have
i can post my changes up on here, what i posted at first has been revised
the number is not exactly 150 - i know know 150 asteroids + 8 herc IIs + 1 deimos doesn't break it
this collision detection breakage occurs in the origional game if you put too many asteroids in
-
Originally posted by Kazan
increasing things didn't help
here are the Framerates i got
Max: 30.0 fps [looking at nothing but background], it appears to be the highest framerate FS2 will produce, *shrug*i often average 70 fps in Unreal Tournament at 1024x768 high detail
Min: 5.4 fps [looking down the major axis of the asteroid field, with a NTF asteroid base in view]
There must be an adjusteble setting somewhere. as i recall the standalone lets you cap FPS. and the max is 100 FPS.
the 30 FPS might be the default client_master cap.
but a quick glance did not reveal anything
-
Originally posted by Inquisitor
Dave will have to want to help, and recent events may not make him inclined to do so.
Clarify for those of us who have been living under a rock?
-
Take my advice and forget it.
-
actually ask me in private
[edited]
-
Could be as simple as a bug in the collission code that only occurs at that (rough) number... or exceeding memory bounds.
Where's the collission detection defined again?
I can't really understand most of the maths, but I might as well try and look at this stuff for myself :)
EDIT... just glanced (I emphasis the glanced part :D ) at void_weapon_area_apply_blast.... maybe the pointer's overrunning allocated space or soemthing... dunno. Not really too clear on all this, unfortunately. (But at least it gives you something to brutally criticise and dismiss ;7 )
(or weapon_hit... sod this, I'm off to bed)
-
So, back to the point, let us know when the code snippets are updated, maybe one of these kind folks (I know phreak looked at it briefly) can help solve the insoluble.
-edit-
(aldo replied when I did, so this is a bit out of context ;))
-
if the pointer runs off the end of the array you get a crash
-
Originally posted by Kazan
if the pointer runs off the end of the array you get a crash
IIRC, you can sometimes overrun assigned area into a random block of different memory and just fetch random data... doesn't the FS2 code ignore any event causing a crash? i.e. simply ignoring the collisison if it causes an error?
Ne'ermind....
-
while it is true that sometimes running off the end of the array may stay within a programs memory page, it would crash once in a while
and to ignore any situations like that you have to have code in place to catch situationhs like that which would slow down the game, so you avoid checking code and just make sure you never pass data that does that
if they had checking code in place a 380K ships.tbl wouldn't crash fs2, it would just prevent it from running
-
Originally posted by Kazan
while it is true that sometimes running off the end of the array may stay within a programs memory page, it would crash once in a while
and to ignore any situations like that you have to have code in place to catch situationhs like that which would slow down the game, so you avoid checking code and just make sure you never pass data that does that
There could be an implicit assumption that certian conditions will never be met in the code - you could have 'broke' that with your changes.
If the error handling was too great a problem, it could simply be ingored and the data set being limited by either those using the program, or the other interacting modules... and by ignore, I mean simply using a default value if the memory locaiton is out of 'synch' of expected values... i think stuff like moemnt of inertia does this - i remember some related stuff in the physics section along these lines.
BTw, I'm not sure, but if Windows references memory as 'wraparound', you could easily go off the edge of actual memory addresses and simply be tweaked onto the side... i've never looked at the Windows stuff in my courses last semester (primarily Unix and broad OS concepts), but it could be that the kernel prevents (or ties to) that sort of memory related error.
I don't really know... it's just that the only thing that immediately jumped out (for me) with C and pointers is exceeding defined bounds. Unfortunately, I don't have the experience to make a more educated 'guess' :)
-
Originally posted by aldo_14
BTw, I'm not sure, but if Windows references memory as 'wraparound', you could easily go off the edge of actual memory addresses and simply be tweaked onto the side... i've never looked at the Windows stuff in my courses last semester (primarily Unix and broad OS concepts), but it could be that the kernel prevents (or ties to) that sort of memory related error.
hehe, Windows (and most intel-based OSes) use a 4GB virtual memory layout. You'd have to be pretty far off to wrap that :D
-
it's very easy to walk off the end of a program's own memory page- what do you think a General Protection Fault or a Page Fault is?
each program is given it's own "region" in memory, windows doesn't enforce it very well, but walking off the end of your region - either end - results in a crash
-
Assuming the number of objects in the mission is the deciding factor about whether the code will work, it might be worth adding a bit of code to display on the HUD the number of objects currently in the mission. Then if you have a mission where you can "add" more ships (reinforcements for instance) you may be able to find out exactly when the code breaks and that could give you an idea what to look for.
One other note, it may not be related to thisv but I have seen missions where the number of ships and stuff on the screen seemed to be the deciding factor on whether the program would crash or not.
-
what about replacing the asteroids in the distance ( in fact LOD3 ) with sprites ( like explosions, engine glows, space debris etc )? I guess it's a no go, but take this as a suggestion anyway.
-
that might help speed, but I don't think it would help stability becase you would still have to many asteroids, even if they were just sprites,
you see it's the number of objects that seems to be the problem
-
I made a HUD debug line that displayed the current input from the command line in regard to -almission X (autoload mission), where x where the filename of the mission.
it should be easy to add the number of objects in the mission to the HUD, it might even be more mission developer friendly to add a command line switch that shows information like this.
I assume I could make that and put here what I did.
But only if you fell it is worth the trouble kazan. Just let me know
-
I'm probably off on a tangent here, but assuming the nature of this bug is that Freespace can only deal with x amount of collision testable objects at a time, a possible fix would simply be to stop testing distant non-ship (i.e. asteroids) objects.
[EDIT] Or better yet, stop collision tests on distant asteroids and then pump up the numbers and see if you still get the bug [/EDIT]
-
I think it's the number of objects period, nothing to do with colision testable objects, though I havn't realy looked into it
-
Wouldn't not counting collision detection break anything that goes on at long range? IE. Derelict's beam fights?
-
yeah it would
that's not the solution
-
I've been lurking about in the AI code for a bit. Though I'd share my $0.02 about my interpretation of the collision detection routines...
From what I understand, as each object is created (cargo, ship, weapons fire, asteriods...) it is added to the global "pairs" list. The Pairs list is itterated through to check for collisions between thos two objects. If it is not on the list, no collision detection is performed.
A new "pair object" is created for each combination of that object with every other object that it can collide with. So, if there are, say, 8 ships, with each ship having 10 "shots" flying about, for a total of 88 objects, the number of "pair" objects would be nCr(88,2) or "88 choose 2" combinations, which comes to 3828 pairs.
Acutally lasers to not collide with lasers so this may not be quite accurate; but close enough!
There are exceptions though. Asteroids do no collide with each other and so, do not form pairs.
So, extending our example, with 8 ships, 10 shots each, and 200 asteroids, we get nCr(88,2)+88*200=21428 pairs. (It's "88*200" since asteroids do no collide with one another; 80 shots in the air + 8 ships). The problem is that MAX_PAIRS is set to 8000.
There was some discussion about pointer overruns and such. I've found that, in general, the code is quite robust. The routine that creates and adds pairs checks the MAX_PAIRS limit. Once the limit is reached, it stops adding to the pairs list and so, all remaing objects are not checked for collision detection. Since ships and asteriods are created first, they are likely to be on the list before it overflows. Weapons fire is added as it is generated. If the list has overflowed, collision with the weapons fire will not be performed and, hence, has effect anywhere. However, the player ship can still collide with the asteroid since they have been added to the list before it overflowed. The rendering of the objects is handled completely separately so is not affected by the list state.
It seems that the simple solution would be to increase MAX_PAIRS to some large number, say what's MAX_INT again? 16- or 32- bit? So, putting maybe 4 ships, each having 10 shots in the air, and 500 asteroids: nCr(44,2)+44*500=22000, which is way under 65535. I can't comment on performance though...:doubt:
Conclusion? Somone has already tried to increase the MAX_PAIRS define but I suspect that it should be increased by a large amount. I don't have my development environment setup so someone will need to try it and correct me.
In addition, it may be kinda neat of asteroids can collide with one another can explode into smaller pieces. Easy to do, but you can imagine the number of pairs ( nCr(500,2)=124750)...
AI is *much* more fun than collision detection:D
-
a while ago i increased it to 35000 and it freespace 2 promptly crashed
-
This is probably a topic for another thread, but I wonder how tough it would be to make the various sizes more dynamic...
With some it would be easy: stuff from tables, for instance -- you can tell how many are in the table, then dynamically allocate the array. For stuff like this (number of obejcts and number of pairs) it would obviously be much more difficult...
-
Originally posted by rambler
I've been lurking about in the AI code for a bit...
rambler:
:D;7:eek::cool:(http://members.cox.net/~wmcoolmon/images/welcome.gif):cool::eek:;7:D
Shotguns are located under the seats, exits to the left and right. However, the shotguns are out of service and are being upgraded; talk to Thunder about the reported problems with the exits :D
Damn, I've always wanted to say that...
-
oh yes, welcome, it's good to see someone who learns the ways of the board before posting
-
Originally posted by rambler
There are exceptions though. Asteroids do no collide with each other and so, do not form pairs.
Actually, I think I've seen asteroids collide with each other.
-
yes asteroids collide w/ e/o
-
Originally posted by Kazan
yes asteroids collide w/ e/o
I can't remember either way but take a look at:
void obj_add_pair( object *A, object *B, int check_time, int add_to_end ) [\code\object\objcollide.cpp, line:307]
Asteroid-with-asteroid collisions aren't enumerated.
Looking at \code\asteroid\Asteroid.cpp, asteroid_check_collision() is called only from:
\code\Object\CollideDebrisShip.cpp\collide_asteroid_ship() and
\code\Object\CollideDebrisWeapon.cpp\collide_asteroid_weapon()
If they do collide with each other, it must be magical or there is some kludge to implement this behavoir that I can't find.
Asteroids are affected by explosions so maybe this is the behavior that we are seeing...
-
asteroids are most defininantly affected by expolisions
asteroids are a type of debris so the debris coollision functions take care of them
-
wow, double post, how did that happen... someone right it down on the calendar, the second time in history kazan has double posted
-
Looking through the code again, it turns out that the number of collision pairs estimates I had made were probably too high. The code seems to cull-out much of the weapons fire collision pairs that are not directed to a particular asteroid. So going through the excercise again, 4 ships, 10 shots each, and 500 asteroids may come to about (I'm guessing here) 5000 pairs. Maybe the problem is not with the Object Pairs list afterall.
As an additional note of trivia, it looks like there is no friendly fire in FS2; at least you can't receive friendly fire from small, friendly ships. I've always been worried about those wingmen firing from behind me....
-
According to the FRED2 docs (which could be wrong, of course):
FreeSpace 2 does not check for collisions between asteroids, so they pass right through each other. Don't make your field too dense, or this will be noticeable.
Haven't looked into the code to confirm one way or another :o
-
weird
anyway increasing the collision pair count doesn't fix it, look for the solutuion elsewhere
-
asteroids don't collide: just make a very small astroid field with the max asteroids, and look at the pieces of rock flying happily through each other.
-
max asteroids [256] is enough to break the collision code, try it with about 100
-
I'm not sure that it is a simple "hard" number when collision starts breaking; probably other factors involved...
I'm running "A place of chariots " with asteroids bumped up to 500. It would be great to get this working as 500 small asteroids can get close to looking like being in a planetary ring.
At first, some asteroids can be destoyed while others have no weapons collision detection. The first wave of ships can be destoyed but then the second wave cannot. However, the AI hostile ships seem to be able to destroy my wingmen while my wingmen cannot damage the hostiles. Missiles always seem to work though...
This is really weird. I've put code so that the target display dumps the object structure as you target them. All values seem reasonable even for objects with no collision detection...
Debugging is now reduced to scattering Asserts all over. Maybe it's time to bring in BoundsChecker...
-
ok, i just ran a 500 density asteroid mission. using my own build beta 0.3.
what i did was i opened the missionfile in an text editor, and set density to 500. My guees is i could set it to 2048, since i have not changed max asteroids.
and that should work, and give you the collision erros. right ?.
and now the weird stuff. my weapon collision where working.
which leads me to beleive, either i fixed something in relation to this when doing my earlier builds.
OR
when framerates are below those worst case 5 frames pr second for more than 1 or 2 seconds, then the collision code starts acting wacky, the worse the frame rates, the worse the collision errors.
I ran this on a Debug build hoping to get some debug msgs output to the debug spew window, but got an error on the linking so no debug info regarding PAIR_STATS where outputted.
My frame rates where near 5, but never actually got below 6 frames pr second.
Something i will test in that 399 ships + one demon mission i made earlier. making ships leave one by one until collision starts working again. and then reading out if the FPS is below or over the magical 5 frames pr second.
There are actually checks in the objcollide.cpp if framerates are below 5 fps.
my system is top tuned and is a AMD K7 Thunderbird 800 mhz 128 MB of 133 mhz SDRAM with a GF2MMX card.
and i had them moving at the default speed at 120, now that is funny :). but in a multiplayer mission, only one type of asteroid is allowed :(.
so kazan,
you could you send me your excuteble + that mission(campaign) of yours, to let me test if this realy is a hardware matter.
direct it at [email protected]
btw here are some pics.
(http://home19.inet.tele.dk/dtp/images/asteroid50001.jpg)
(http://home19.inet.tele.dk/dtp/images/asteroid50002.jpg)
(http://home19.inet.tele.dk/dtp/images/asteroid50003.jpg)
(http://home19.inet.tele.dk/dtp/images/asteroid50004.jpg)
(http://home19.inet.tele.dk/dtp/images/asteroid50005.jpg)
-
framerates don't appear to be it, because even whemmy framerates were aroudn 30fps it was happening [weapons not collding at all]]
dammit dave, we're BEGGING for help here
-
I doubt he is reading this post
-
what happened to dave? he got so quiet...
-
probly programing new dance rutines for V/THQ's new Britny Spears console dancing game
-
Hey.. hey.. come on now. Dave's only working on the sequel. He had nothing to do with the original... :D
-
Originally posted by Bobboau
probly programing new dance rutines for V/THQ's new Britny Spears console dancing game
I doubt that... THQ is publisher for pretty many game companies, not only for [V].
I think you were being sarcastic, but anyway...
-
yes but 98% of those other developers are making things like spunge bob and rugrats games
-
Red Faction 2, I'd guess.
-
well hey, would you look at that, I derailed the topic
-
must.... rerail..... topic..... for..... great.... justice.....
-
Rerailing,,,
Ok so it is not frame rates that are causing it.
But my point is that my build with 500 asteroids in one mission, in view and with the default type of asteroids work.
Have you tested of your mission works in a multiplayer mission?
Of course I cant know what you have changed apart from you have listed at the start, but here is what some of what I have changed regarding the hard defines MAX_X, Don’t know how relevant they are regarding the asteroids. Note I have not changed max_asteroids or max_objects.
MAX_SHIPS 400, (means max Individual named ships, and max 400 fighters, max_model_subsystems is to be considered to)
MAX_SHIP_TYPES 200(don’t exceed over or net code will break).
MAX_SHIP_SUBOBJECTS 2100. (average 7 subsystems pr ship multiplied with 400 = 2100).
MAX_ROTATING_SUBMODELS 200 (never figured why this one was so restricted, this could be of interest to the TBP people)
MAX_MODEL_SUBSYSTEMS 200 (somebody’s Death-star wish)
MAX_EXITED_SHIPS 400 (because of MAX_SHIPS)
MAX_SUBSYS_LIST 200 (because of MAX_MODEL_SUBSYSTEMS)
-
have you tried disabling you'r new asteroid types, and just bumping up the number of asteroids (just to be sure they arn't the problem)
-
grr
bobboau- this bug happens with the unmodified source - it happens with the origional executeable, turn the asteroids up to max 256 put some fighters and maybe a capship in, and bang the problem shows up
-
Ok, problem postponed.
Release your asteroid code and we can start looking for a root cause ;)
-
MAX_ROTATING_SUBMODELS 200 (never figured why this one was so restricted, this could be of interest to the TBP people)
is that in one of your releases???
must have....must have....
-
Originally posted by Vasudan Admiral
is that in one of your releases???
must have....must have....
some of the MAX things are changed. to many to list. but i will, eventually.
im just not telling, so that ppl dont go break something.
anyway KAZAN.
plz read this. this was played with the original fs2.exe file.
If I fly a mission with 256 asteroids. with 12 ships and 1 destroyer to protect. the Weapons collision is working all the time.
---
anybody else please fell free to confirm my findings.
-------
what is your system.
-------
mine is a 800mhz Athlon tbird, GF2 mmx.
All these weapons collision errors happens only when i go near 500 asteroids with an modified exe with 12 ships and 1 destroyer.When the destroyer eventual dies, which i will in a density 500 field. with near normal bounds. then the Weapon collision starts working again.
so i still wonder if this is a hardware specific question.
-
i've seen this problem in the origional executable, many times, and ages ago [when i was working on Unholy Alliance even]
many different incarnations of my computer the current is
P3 600mhz, Radeon 32 DDR, SB Live! Value, 0.5GigaBytes RAM, ..