Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on April 27, 2002, 09:59:19 pm
-
OK the first majore thing I, and many here are fighter beams, to this end I have looked and found the code dealing with the targetting laser and found the bug that makes it only fire only from the first weapon point,
I made the following change to the function
void ship_process_targeting_lasers()
{
ship *shipp;
beam_fire_info fire_info;
ship_obj *so;
polymodel *m;
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
// interate over all ships
for ( so = GET_FIRST(&Ship_obj_list); so != END_OF_LIST(&Ship_obj_list); so = GET_NEXT(so) ) {
// sanity checks
if(so->objnum < 0){
continue;
}
if(Objects[so->objnum].type != OBJ_SHIP){
continue;
}
if(Objects[so->objnum].instance < 0){
continue;
}
shipp = &Ships[Objects[so->objnum].instance];
// if our trigger is no longer down, switch it off
if(!(shipp->flags & SF_TRIGGER_DOWN)){
ship_stop_targeting_laser(shipp);
continue;
}
// if we have a bank to fire - fire it
if((shipp->targeting_laser_bank >= 0) && (shipp->targeting_laser_bank < 2)){
// try and get the model
m = model_get(shipp->modelnum);
if(m == NULL){
continue;
}
// fire a targeting laser
for ( int j = 0; j < num_slots; j++ ){
fire_info.accuracy = 0.0f;
fire_info.beam_info_index = shipp->weapons.primary_bank_weapons[shipp->targeting_laser_bank];
fire_info.beam_info_override = NULL;
fire_info.shooter = &Objects[shipp->objnum];
fire_info.target = NULL;
fire_info.target_subsys = NULL;
fire_info.turret = NULL;
fire_info.targeting_laser_offset = m->gun_banks[shipp->targeting_laser_bank].pnt[j];
shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
// hmm, why didn't it fire?
if(shipp->targeting_laser_objnum < 0){
Int3();
ship_stop_targeting_laser(shipp);
}
}
}
}
}
when I compiled the ship.cpp, I got a warning about the shipp not being properly initalised, I'm building with these changes now, but it takes two hours before I'll know if it works, and I don't realy know what I'm doing
anyone who does know what there doing know if I broke something and tell me how to fix it, or want to do it your self
this seems to the line it doesn't like, I don't know what it means not initalised
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
-
Er. That's uh, some pretty incorrect code. You're referencing some data from a random point in memory. That'll crash every time. You're gonna want to move that polymodel_get() inside the loop past where shipp gets setup. You're also ignoring a potential -1 for shipp->targeting_laser_bank.
But aside from all that - beams on fighters is a harder problem than you might expect. A lot of the beam code expects to be able to find turret subsystems on ships that are firing beams. What this basically amounts to is crashy crashy for most non-cap ships. If memory serves me right it works ok on bombers because some of them have turrets.
I think what you need to realize is that there is no 2-line fix for about 99% of the "wishlist" features people have been proposing (not just this specific case). Most significant changes to systems require a lot of work. If you don't do this and you just plow ahead you're going to end up with a pile of randomly crashing unmaintainable code. Even in a non-official version that's going to be unacceptable for most people. That's the perspective from the view of the grizzled game programmer, anyway.
-
well I saw there was an offset, and I saw in the code it just referenced one firing point, I figured if I just told it to fire a beam from for each firing point from each firing point it might work
well I'm an idiot who has no Idea what he is doing :)
-
Originally posted by daveb
I think what you need to realize is that there is no 2-line fix for about 99% of the "wishlist" features people have been proposing (not just this specific case). Most significant changes to systems require a lot of work. If you don't do this and you just plow ahead you're going to end up with a pile of randomly crashing unmaintainable code. Even in a non-official version that's going to be unacceptable for most people. That's the perspective from the view of the grizzled game programmer, anyway.
Momentarily discouraging but realistic. I guess this is all us non-programming plebs will be able to meddle with for now. Who knows, we might all end up learning some of this by just playing around with the source: just like the other features of FS modding. Perhaps I should have taken that programming course last year after all. :D
-
Most definitely. A big part of being able to make serious changes to the code is being familiar with it first. When we hire a new guy, he doesn't show up on day one and start writing rendering code :) Most fresh-off-the-street rookies start out with something hard to screw up, like interface code or something like that. This goes triple if he's coming into a project that's already well in progress.
The same sort of thing applies here. Its tempting to make quick changes that may appear to work at first. But because lots of code is interdependant you may cause a really obscure crash or some odd behavior down the road. And you guys don't have the "luxury" of having everyone in one building and being able to run around and debug stuff when its broken.
The bottom line is, if you want to do something cool, pick _one_ thing and be prepared to spend a week or more on it (or, for lots of the graphics stuff people seem to want - months). _Then_ you'll see progress and you won't be disheartened.
-
Originally posted by daveb
The bottom line is, if you want to do something cool, pick _one_ thing and be prepared to spend a week or more on it (or, for lots of the graphics stuff people seem to want - months). _Then_ you'll see progress and you won't be disheartened.
Or, for that Python scripting host to replace SEXPs that I want, YEARS. ;)
-
Yeah, that'd be an interesting one :)
-
Originally posted by mikhael
Or, for that Python scripting host to replace SEXPs that I want, YEARS. ;)
Hah! Python rocks! :)
Thanks for the words, Dave. Remind me again how long you've been coding?
-
I wasn't expecting to get it to work, just playing around for my own amusement, maybe I'd get lucky and it'd work, more likely it would crash in some horable way, was hopeing to get the attention of someone who knows what they are doing and they'd get it working, or have some discusion on th subject
I'm actually kind of embarrassed that you saw my pseudo-code, I'm sure you got a good chuckle out of it :)
this code is just so well organised, logical, and well documented, it made it seem easier than it realy is
-
this code is just so well organised, logical, and well documented, it made it seem easier than it realy is
I'm not entirely sure I agree with that. There's some pretty horrifying stuff in the FS2 codebase.
-
Originally posted by Bobboau
I'm actually kind of embarrassed that you saw my pseudo-code, I'm sure you got a good chuckle out of it :)
this code is just so well organised, logical, and well documented, it made it seem easier than it realy is
Heheh, I know what that's like... I was once playing around with one of my brother's Python scripts which synchronises his bookmarks for him back home and at work. I thought it was pretty cool, so I started to do a pseudo-code design for a similar script that would instead update my backups off our database here at HLP... when my brother got home and read it, he burst out laughing. :D
And yes, that's true. It's kinda elegant... well, it is to me, anyway. ;)
-
what does this daveb know he has only posted 10 times, newby...
Just Kidding Dave... Hey remember how you said you wanted to make a Freespace RTS...your dreams becoming reality!!
http://www.hard-light.net/forums/index.php/topic,7194.0.html
-
ok so if I move the
shipp = &Ships[Objects[so->objnum].instance];
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
bit into the loop it won't crash ?
makes sense with that
so = GET_FIRST(&Ship_obj_list)
bit there
.. eh, I probly should just read more of this before I screw it up
am I totaly clueless, and should just give up on this now :)
-
Originally posted by daveb
I think what you need to realize is that there is no 2-line fix for about 99% of the "wishlist" features people have been proposing (not just this specific case). Most significant changes to systems require a lot of work. If you don't do this and you just plow ahead you're going to end up with a pile of randomly crashing unmaintainable code. Even in a non-official version that's going to be unacceptable for most people. That's the perspective from the view of the grizzled game programmer, anyway.
That's what I have tried to told most of you non-programmers since the source was released... :doubt:
Sup all! 4r3 joo r34dy 2 l34rn 411 4b0u7 7h15 5k1ll? Wh3n u r d0n3, joo w111 PWN 7h15 5k1ll!!!
:headz: I need to grab that MS Visul c++ enterprise edition somewhere...
-
i never said it was gonna be easy, just that you have no choice :D
-
Hope you, uh, like the new title there Dave. :D :v:
-
hey, he's a V god again
couldn't you have thought up a more origonal title
hey wait a second, you just derailed this thread
quit it!!!
-
Originally posted by Shrike
Hope you, uh, like the new title there Dave. :D :v:
And the nice image you got there. ;)
-
Naaa, I’m not as clueless "I think", but once I was. I Screwed a lot when I fumbled around with the Q2 code and the LCC-32 bit compiler. No luxury of a debug utility here.
I totally understand why ppl are using MS dev C++ or Borland cause it just don’t crashes, at actually gives you the reason, when you are doing debug builds. Pretty neat.
There is still stuff I don’t understand, and still stuff I use that I don’t understand fully either, but unless I don’t use it, I will never learn what I’m doing wrong.
Let me Quote from the creator of c++; Bjarne Stoustrup, book.
THE C++ programming LANGUAGE
Third edition
Page 43
You don’t have to know every detail of c++ to write good programs.
And
Page 20 chapter 2
"The first thing we do, lets kill all the language lawyers"
-henry VI, part III
You make of this what you like.
i can recommend this book, at first i thought bogus, but what i had then was an outdated compiler. MS VS 5.0
Using namespace std:: crap :)
so if any are interested in this book, it published by Addison Wesley
Even beginners can start with this book, and even professionals can learn new things from it too, at least they claim that.
Title
"The C++ programming Language"
Author Bjarne Stroustrup
ISBN 0-201-889543
$44.95 (“when I got it”)
-
I'll take a look at that
and
HOLY **** IT WORKED!!!!1!!!111
the targetting beam now comes out of all weapon slots and uses energy!!!
I can't beleve it worked :jaw:
I am SO happy and exited
I'll do a little more testing then I'll post the EXE, and the new function def, actualy I'll post the def right now
void ship_process_targeting_lasers()
{
beam_fire_info fire_info;
ship_obj *so;
ship *shipp;
polymodel *m;
// interate over all ships
for ( so = GET_FIRST(&Ship_obj_list); so != END_OF_LIST(&Ship_obj_list); so = GET_NEXT(so) ) {
// sanity checks
shipp = &Ships[Objects[so->objnum].instance];
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
if(so->objnum < 0){
continue;
}
if(Objects[so->objnum].type != OBJ_SHIP){
continue;
}
if(Objects[so->objnum].instance < 0){
continue;
}
// if our trigger is no longer down, switch it off
if(!(shipp->flags & SF_TRIGGER_DOWN)){
ship_stop_targeting_laser(shipp);
continue;
}
// if we have a bank to fire - fire it
if((shipp->targeting_laser_bank >= 0) && (shipp->targeting_laser_bank < 2)){
// try and get the model
m = model_get(shipp->modelnum);
if(m == NULL){
continue;
}
// fire a targeting laser
for ( int j = 0; j < num_slots; j++ ){
fire_info.accuracy = 0.0f;
fire_info.beam_info_index = shipp->weapons.primary_bank_weapons[shipp->targeting_laser_bank];
fire_info.beam_info_override = NULL;
fire_info.shooter = &Objects[shipp->objnum];
fire_info.target = NULL;
fire_info.target_subsys = NULL;
fire_info.turret = NULL;
fire_info.targeting_laser_offset = m->gun_banks[shipp->targeting_laser_bank].pnt[j];
shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
// hmm, why didn't it fire?
if(shipp->targeting_laser_objnum < 0){
Int3();
ship_stop_targeting_laser(shipp);
}
}
}
}
}
that goes into the ship.cpp
can someone with pro edition compile that in relese build, please
with upped tbl limets if you can
:D:D:D:D
-
Originally posted by Bobboau
HOLY **** IT WORKED!!!!1!!!111
the targetting beam now comes out of all weapon slots and uses energy!!!
I can't beleve it worked :jaw:
I am SO happy and exited
I'll do a little more testing then I'll post the EXE
:jaw: :jaw: :jaw:
-
one little bug, it still fire's when you're out of energy :)
it will only fire out of one bank at a time, but it will fire out of the entire bank
AI still won't use it
as soon as I fix the first two problems, I'll post the fix
and thanks Dave for pointing out that stupid little mistake of mine :)
-
I forgot to mention a little bit I had imediatly after the ship_start_targeting_laser(shipp); line 5121 or there abouts
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
shipp->weapon_energy -= num_slots*winfo_p->energy_consumed;
if(shipp->weapon_energy < 0.0f){
shipp->weapon_energy = 0.0f;
this is were I'm about to add the bit that says not to fire it if you're out of energy
-
I think I fixed the two bugs I'm likely to be able to fix anytime soon
were it called ship_start_targeting_laser(shipp);
I put this in,
if((winfo_p->wi_flags & WIF_BEAM) && (winfo_p->b_info.beam_type == BEAM_TYPE_C)){
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
shipp->weapon_energy -= num_slots*winfo_p->energy_consumed;
if(shipp->weapon_energy < 0.0f){
shipp->weapon_energy = 0.0f;
}
else{
ship_start_targeting_laser(shipp);
}
continue;
}
I'm sloppy I know, I'll try moving this into the ship_start_targeting_laser() function latter
the processing function is now
void ship_process_targeting_lasers()
{
beam_fire_info fire_info;
ship_obj *so;
ship *shipp;
polymodel *m;
// interate over all ships
for ( so = GET_FIRST(&Ship_obj_list); so != END_OF_LIST(&Ship_obj_list); so = GET_NEXT(so) ) {
// sanity checks
shipp = &Ships[Objects[so->objnum].instance];
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
if(so->objnum < 0){
continue;
}
if(Objects[so->objnum].type != OBJ_SHIP){
continue;
}
if(Objects[so->objnum].instance < 0){
continue;
}
// if our trigger is no longer down, switch it off
if(!(shipp->flags & SF_TRIGGER_DOWN)){
ship_stop_targeting_laser(shipp);
continue;
}
// if we have a bank to fire - fire it
if((shipp->targeting_laser_bank >= 0) && (shipp->targeting_laser_bank < 2)){
// try and get the model
m = model_get(shipp->modelnum);
if(m == NULL){
continue;
}
// fire a targeting laser
if (shipp->targeting_laser_bank != 2){
for ( int j = 0; j < num_slots; j++ ){
fire_info.accuracy = 0.0f;
fire_info.beam_info_index = shipp->weapons.primary_bank_weapons[shipp->targeting_laser_bank];
fire_info.beam_info_override = NULL;
fire_info.shooter = &Objects[shipp->objnum];
fire_info.target = NULL;
fire_info.target_subsys = NULL;
fire_info.turret = NULL;
fire_info.targeting_laser_offset = m->gun_banks[shipp->targeting_laser_bank].pnt[j];
shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
// hmm, why didn't it fire?
if(shipp->targeting_laser_objnum < 0){
Int3();
ship_stop_targeting_laser(shipp);
}
}
}
if (shipp->targeting_laser_bank == 2){
for (int q = 1; q<0; q--)
for ( int j = 0; j < num_slots; j++ ){
fire_info.accuracy = 0.0f;
fire_info.beam_info_index = shipp->weapons.primary_bank_weapons[shipp->targeting_laser_bank];
fire_info.beam_info_override = NULL;
fire_info.shooter = &Objects[shipp->objnum];
fire_info.target = NULL;
fire_info.target_subsys = NULL;
fire_info.turret = NULL;
fire_info.targeting_laser_offset = m->gun_banks[q].pnt[j];
shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
// hmm, why didn't it fire?
if(shipp->targeting_laser_objnum < 0){
Int3();
ship_stop_targeting_laser(shipp);
}
}
}
}
}
}
I'm sure there is a more eligent way of doing this, actualy I know there is becase I realised it a few seconds after I started the build, but it's 5:00 am and this isn't ever going to be used in anything but me playing around (I'm sure Kaz will have REAL beams, that being a new type with warmup and down and everything in a few days) so to hell with it
now I'm gona look at the AI code and see if there is something simple like
if(WIF_BEAM)
then_don't_fire_stupid()
that I can alter
don't think it'll be that simple though
-
oh, and I made a small change to the starting func
void ship_start_targeting_laser(ship *shipp)
{
int bank0_laser = 0;
int bank1_laser = 0;
// determine if either of our banks have a targeting laser
if((shipp->weapons.primary_bank_weapons[0] >= 0) && (Weapon_info[shipp->weapons.primary_bank_weapons[0]].wi_flags & WIF_BEAM) && (Weapon_info[shipp->weapons.primary_bank_weapons[0]].b_info.beam_type == BEAM_TYPE_C)){
bank0_laser = 1;
}
if((shipp->weapons.primary_bank_weapons[1] >= 0) && (Weapon_info[shipp->weapons.primary_bank_weapons[1]].wi_flags & WIF_BEAM) && (Weapon_info[shipp->weapons.primary_bank_weapons[1]].b_info.beam_type == BEAM_TYPE_C)){
bank1_laser = 1;
}
// if primary banks are linked
if(shipp->flags & SF_PRIMARY_LINKED){
[b] if(bank0_laser && bank1_laser){
shipp->targeting_laser_bank =2;
return;
}
[/b] if(bank0_laser){
shipp->targeting_laser_bank = 0;
return;
}
if(bank1_laser){
shipp->targeting_laser_bank = 1;
return;
}
}
// if we only have 1 bank selected
else {
if(bank0_laser && (shipp->weapons.current_primary_bank == 0)){
shipp->targeting_laser_bank = 0;
return;
}
if(bank1_laser && (shipp->weapons.current_primary_bank == 1)){
shipp->targeting_laser_bank = 1;
return;
}
}
}
-
Originally posted by Bobboau
I'll take a look at that
and
HOLY **** IT WORKED!!!!1!!!111
See, that's why I didn't enable the language filters. You can't have 'oh ****' moments without the ****. ;)
And Bobboau? Nice work. :) I'm gonna post the news.
-
I would post a pic, but the VW servers are down
do you want me to mail you a few and have you upload them some were
-
Go ahead. [email protected]
-
Originally posted by Shrike
See, that's why I didn't enable the language filters. You can't have 'oh ****' moments without the ****. ;)
:D:ha: Noted.
-
This was sent to me by Bobbau. Very cool stuff.
(http://www.3dap.com/hlp/images/temp/fighterbeams01.jpg)
-
Now, make a tag that makes allows non shield piercing beams.... I wonder if that's even possible (without some major work that is)
-
That is nice!! :D
-
Obviously, fighter beams will have to be carefully balanced.... they are extremely powerful due to their shield-piercing abilities.
-
Originally posted by Shrike
Now, make a tag that makes allows non shield piercing beams.... I wonder if that's even possible (without some major work that is)
Uh, can't you just edit the Targetting Lasers tbl entry to do that?
-
AFAIK there is no way to make a beam non shield piercing, currently anyhow.
-
I'm sure it would be one of the easier things to do, but well beond my abilitys,
I barely have any idea what I'm doing realy
I'll take a look at it though
-
Originally posted by Shrike
AFAIK there is no way to make a beam non shield piercing, currently anyhow.
Can't be that hard. Just steal the code from the normal weapons and tweak it.
-
The problem is, beams might have the code ignore shields completely integral to their operation. Again, it might be fairly easy, it might not.
What would be nice would be a simple tag 'shield piercing' that makes any weapon go through shields..... weapons without it do not ignore shields.
-
looks like I could add a "ignore sheild" flag fairly easily, for pulse weapons
-
Originally posted by Bobboau
looks like I could add a "ignore sheild" flag fairly easily, for pulse weapons
That'd be pretty flash. :) But I have a feeling that the initial problem of the beam would still be a problem... man, I really gotta get into this code summore. :)
-
It might sound totally daft but how are beams actually repesented in the engine? just a simple line?
If so..would it be possible to use a SPLINE with n number of CVs..that way it would be a possiblity to have beams doing cool curves etc.
Its a little crazy and would be a helluva lot of work..but i just thought about it while reading this thread.
Great work bobbau (I dont understand code at all, so ill shut up)
-
arhg
there was an error
I must have tuched something in the AI code while looking at it,
yup
got to recompile again to see if the new stuff works :rolleyes:
-
wow i just look at that code and my brain frezes :confused:
-
Interesting... most interesting indeed.
-
very, very nice
-
:jaw: Very, very nice indeed. :jaw:
-
He he he.... Time to upgrade the Thor.... 3 beams at once....
-
Do these beams have a warm-up and warm-down sequence? And they make noise when fired? We'd want these things to be as close to the other beams as possible after all. :D
-
other questions: do they shot till you release the trigger, or do they only make a zap? Is the AI able to use them?
-
Originally posted by Bobboau
looks like I could add a "ignore sheild" flag fairly easily, for pulse weapons
Wow Cool beam, I want to play
i think the ignore shield flag cant include spaces to be simular to the others:
e.g. "ignore_shields"
-
bobboau can you make two versions of the fighter beam, one with SSM enabled and one with out, why not add a "SSM" flag.
-
good job on the research bob... i'll take it and make another beam type entirely one i get looking at it... and hey - i thought you couldn't code :D
-
wow, that bobboaus clever, first of all he makes some of the best models around then he codes somthing in a rather complex computer language, with only minimal knowlege. :D
Kazan does that mean that you are going to add a "SSM" flag
-
no warm up\down
it works just like the targeting laser, in fact all I did was told it to go throught and make a targeting laser for each gun point at each gun point, were it used to just say fire a laser from the first
have yet to figure out why the AI doesn't fire it
-
could also make it so it damages friendlys and asteroid/debris?
-
Please, someone code a cycling feature.
I am looking for similar effect like in Babylon 5: Minbari Nial and Flyer. Also, all weapons should not be shield-piercing by nature, but instead using such flag in tables to define whether it is shield-piercing weapon or not.
This feature would be useful when someone finally modifies the source to support capital ship class shield meshes (without crashing), similar to current fighter class shield meshes.
-
I'd have to learn how to use those timestamp functions to do that
-
Unsurprisingly, our ambitions are still above the ability people have to modify the code. :)
So Bobb, is this fighter beam basically the targeting laser but with AAAf beam data attached to it instead of the targeting laser's info? And as a result it lacks warmup/down and so on...
-
all I did was I took the targeting laser code, found the bit that said fire the beam from here then told it to repet this for each firing point
-
Does it do damage?
--TurboNed
-
yes :rolleyes:
-
Originally posted by Bobboau
all I did was I took the targeting laser code, found the bit that said fire the beam from here then told it to repet this for each firing point
I asked because if memory serves (been a while since I played - and I've done minimal modding) the targeting laser doesn't do any damage. So I wasn't sure if you made a mod that just looked pretty (which it does) or was actually functional....I hadn't read anything in this thread that indicated one way or the other, so I out-and-out asked. (-:
--TurboNed
-
well in the table it does no damage, but if you put in some small number, like 6, it becomes supar leathal, especaly now with all baterys firing
-
Originally posted by Bobboau
well in the table it does no damage, but if you put in some small number, like 6, it becomes supar leathal, especaly now with all baterys firing
Yep, all beams are like that... in case you didn't know, Ned, beams distribute damage by how long they are in contact with the target - measured in counts per second, or something like that...
-
Originally posted by Mr. Fury
Please, someone code a cycling feature.
I am looking for similar effect like in Babylon 5: Minbari Nial and Flyer. Also, all weapons should not be shield-piercing by nature, but instead using such flag in tables to define whether it is shield-piercing weapon or not.
This feature would be useful when someone finally modifies the source to support capital ship class shield meshes (without crashing), similar to current fighter class shield meshes.
I take it you've tried to add a shield mesh to caps? What about smaller ships, like cruisers or freighters? :sigh:
-
Originally posted by _argv[-1]
I take it you've tried to add a shield mesh to caps? What about smaller ships, like cruisers or freighters? :sigh:
cap ships= cruisers, corvettes, frigates, destroyers and any larger warship
at least in my books ;)
Anyways, so far all attempts to put shields on capships have failed, FS2 crashes sooner or later. You can howewer put shields on subsystems, as bobboau(?) did with his special deimos.
-
Originally posted by _argv[-1]
I take it you've tried to add a shield mesh to caps? What about smaller ships, like cruisers or freighters? :sigh:
Lilltle rant-
is it so hard to use search functions and such.
little rant over.
I see this question popping up again and again.
I have already put a Conformed shield on The Lucifer, that will be released with the next fs1port update.("WHEN Galactic Emperor returns from real life")
www.3dap.com/hlp/hosted/fsport
this shielded ship is rock steady, i had the game run for 1-2 hours while the lucifer took no-beam bombardment from 30 fighters, 3 Destroyers, and one juggernaut. sure FPS was low at 25 on AMDk/3 400mhz, and 55 on Tbird 800mhz, but what mission would not have a slow fps with 30 fighters 3 caps and 1 jug.
Optionally you can enter the thread Lucifer shields found via the search functions. no more handing on silver plait from here. in there you will find pics from the early development stage.
-
I think I figured out why sheilded caps cause crashes, FS seems to expect the sheild to be entirly within the bounding box of the ship, this isn't something I just saw in the source, but something I figured throught trial and error
-
Interesting theory Bobboau...
But then again, if it is doable, why didn't :V: use it on Shivan cap ships at least? Too huge performance loss or something?
-
becase they didn't want to :)
there are several medium sized capships from fs1 that have sheild meshes (mostly transports and freighters)
-
Originally posted by Bobboau
there are several medium sized capships from fs1 that have sheild meshes (mostly transports and freighters)
WHA...?! Never saw any of the freighters/transports having shields... :jaw:
-
there not enabled, but look at the Elisium pof
-
there is some other odd stuf in some of those older transports
-
Originally posted by Bobboau
there not enabled, but look at the Elisium pof
I am not a modeller even though I have descent manager kit and model viewer, looking at models is beyond my interest. I trust your word on it. But then again, it would be cool if advanced shivan cap ships would have shields.
Beams ignores shields anyways, and you can always increase bombs shield piercing ability or make it shield-piercing altogether.
That would prevent simple fighters from destroying cap ships so easily. (I hate that 10% cap in cap ships resistance for fighter weapons)
-
Well, on that GTBC Titan and USS Raptor models I made a while ago, there was working shields. One was classed as a corvette and the other as a cruiser and I never had problems with crashing. It did tend to have flak rip it's shields apart though....
-
Originally posted by Bobboau
I think I figured out why sheilded caps cause crashes, FS seems to expect the sheild to be entirly within the bounding box of the ship, this isn't something I just saw in the source, but something I figured throught trial and error
Hmm, the shield I use on the Lucifer is bigger, not much but it is than the bounding box of the model given the hypothesis that the bounding box of the model is not larger than the most extreme points on the mesh.
-
Originally posted by Setekh
Yep, all beams are like that... in case you didn't know, Ned, beams distribute damage by how long they are in contact with the target - measured in counts per second, or something like that...
I didn't. Thanks. (-:
-
Hello forum!
Originally posted by Bobboau
no warm up\down
it works just like the targeting laser, in fact all I did was told it to go throught and make a targeting laser for each gun point at each gun point, were it used to just say fire a laser from the first
have yet to figure out why the AI doesn't fire it
Ummm, ok well I have an idea. I'm no C++ programmer, but I know this will be fairly easy, and it will give a more authentic version of a Beam weapon. Look at my crappy and hard-to-understand flowchart.
1. Pilot depresses trigger. Go to 2.
2. Is there enough energy to charge beam? If yes, go to 3. Else, go to 4.
3. Do warmup. Is trigger depressed again? If yes, go to 4. Else if abort button pressed, return energy to weapons subsys and do warmdown, else go to 2.
4. Fire weapon for duration given (x milliseconds?), do warmdown.
warmup: Damage + 1, Duration + 1, Radius + 1, play warmupsnd.
warmdown: Damage = 0, duration = 0, Radius = 0, play warmdnsnd.
In english: When the pilot presses the trigger, start creating a beam warmup, with particles, beamglow, etc. When the pilot presses the trigger again, or if energy is depleted, fire the weapon for x number of seconds/milliseconds. After firing, or if the pilot aborts firing, let the beam warmdown. If aborted, the energy returns to the subsystem. Simple, eh?
-
I'll work on that when I fix the bugs I have now
-
scuddie, just for reference we don't use 'goto's.. that's basic *shudder*
-
there are several medium sized capships from fs1 that have sheild meshes (mostly transports and freighters)
Cool; I never noticed that. :)
-
Originally posted by Scuddie
Hello forum!Ummm, ok well I have an idea. I'm no C++ programmer, but I know this will be fairly easy, and it will give a more authentic version of a Beam weapon. Look at my crappy and hard-to-understand flowchart.
1. Pilot depresses trigger. Go to 2.
2. Is there enough energy to charge beam? If yes, go to 3. Else, go to 4.
3. Do warmup. Is trigger depressed again? If yes, go to 4. Else if abort button pressed, return energy to weapons subsys and do warmdown, else go to 2.
4. Fire weapon for duration given (x milliseconds?), do warmdown.
warmup: Damage + 1, Duration + 1, Radius + 1, play warmupsnd.
warmdown: Damage = 0, duration = 0, Radius = 0, play warmdnsnd.
In english: When the pilot presses the trigger, start creating a beam warmup, with particles, beamglow, etc. When the pilot presses the trigger again, or if energy is depleted, fire the weapon for x number of seconds/milliseconds. After firing, or if the pilot aborts firing, let the beam warmdown. If aborted, the energy returns to the subsystem. Simple, eh?
that's very good I suppose, I'd just prefer to keep the trigger pulled than having to push it twice... it's just not natural in terms of handling. say, you have a beam with 1 sec warm up and 1 ec warm down, and it lasts till you have no energy left. if you keep the trigger pulled for 3 seconds, the first sec, it will charge up, then for two seconds the beam will fire, then auto warmdown. warm down triggered too if you run out of power.
-
Originally posted by venom2506
that's very good I suppose, I'd just prefer to keep the trigger pulled than having to push it twice... it's just not natural in terms of handling. say, you have a beam with 1 sec warm up and 1 ec warm down, and it lasts till you have no energy left. if you keep the trigger pulled for 3 seconds, the first sec, it will charge up, then for two seconds the beam will fire, then auto warmdown. warm down triggered too if you run out of power.
It seems to me like you are thinking of a continuing beam weapon, where the warmup is independant of the firing time/damage of the beam, and the beam is firing while still holding onto the trigger. That isn't exactly what I meant. IIRC, the way the beams are handled in the FS2 universe, the beam breadth/time/damage is totally dependant upon how much energy was stored. The way I explained it is that the pilot holds (or whatever) the trigger only while the beam is being warmed up, and whenever the energy is gone, or the trigger is released, the computer would fire the beam, and take over from there. In other words, the trigger is for storing energy.
One more thing, though... Beam weapons should have a limit as to how much energy they can store. like in the fs2 campaign, the super-destroyer (cant think of the name) blew it's weapons after overuse. I think that should be implemented in ships as well. Maybe a tolerance gauge?
-
Not quite, its heat sinks could handle only so much energy in a certain amount of time.
-
Originally posted by Scuddie
It seems to me like you are thinking of a continuing beam weapon, where the warmup is independant of the firing time/damage of the beam, and the beam is firing while still holding onto the trigger. That isn't exactly what I meant. IIRC, the way the beams are handled in the FS2 universe, the beam breadth/time/damage is totally dependant upon how much energy was stored. The way I explained it is that the pilot holds (or whatever) the trigger only while the beam is being warmed up, and whenever the energy is gone, or the trigger is released, the computer would fire the beam, and take over from there. In other words, the trigger is for storing energy.
Basically, something like the Nova Cannon from Starlancer.
-
well, that's only useful against capships, excepted for hotshots...
-
Originally posted by venom2506
well, that's only useful against capships, excepted for hotshots...
Well, I hope so, cause otherwise it would totally screw up the balance of gameplay. The weapon should only be for bomber+.
-
Originally posted by Scuddie
Well, I hope so, cause otherwise it would totally screw up the balance of gameplay. The weapon should only be for bomber+.
why? depends of the power of the weapon. Works well in Iwar2, so why not in FS2?
-
Originally posted by venom2506
why? depends of the power of the weapon. Works well in Iwar2, so why not in FS2?
I was actually hoping to make all laser weapons into beams. That's more realistic. :D Damage would have to be toned down so it does the same damage/time as the original weapon, and they would have to be non-shield-piercing.
I hate that shield piercing aspect of beams, mostly because I doubt it will be a trivial fix. :mad:
-
Originally posted by Scuddie
IIRC, the way the beams are handled in the FS2 universe, the beam breadth/time/damage is totally dependant upon how much energy was stored.
Nope. The values for warmup time, firing time, warmdown time, damage, breadth, etc. are all just numbers in a table entry. There is no "energy" being stored somewhere.
-
Originally posted by Kazan
scuddie, just for reference we don't use 'goto's.. that's basic *shudder*
No we dont use goto`s, but it is there it is a key-word.
but it is not like in basic.
10 print"hello world!"
20 goto 10
but rather
goto indentifier;
indentifier:statement
As i understand it it is rarely used, but when it is, it used to break out of from a nested loop or switch-statement instead of a break that only breaks out of only the innermost enclosing loop or switch statement.
-edit :D, **** happens
-
It was a flow chart silly :p.
-
Originally posted by DTP
As i understand it it is rearly used...
:confused::D
-
Dave, when you meant by interface code, things such as how the weapon loadout system are handled in FS would be more or less simple to rebuild?
Because with a few graphics tweaks and interface changes such as that, the FS engine would be perfect for one idea of mine ;)
-
I'm messing with the Graphics interface, right now. It looks fairly easy. especially text, ingame and so. it looks like it is just a matter of putting in numbers(posistion), and texture names.
-
Originally posted by _argv[-1]
I was actually hoping to make all laser weapons into beams. That's more realistic. :
hurgh! not for me, thx :p
-
all weapons to beams = bad usage for AI = really high-end comp. needed = stupid looking battles. = bad gameplay.
Go figure.
-
Originally posted by Stunaep
all weapons to beams = bad usage for AI = really high-end comp. needed = stupid looking battles. = bad gameplay.
Go figure.
The AI needs to be fixed, obviously.
Are beams really that slow?
I was thinking narrow little beams, not the huge things on caps. The fighter beams should probably also only have a life of a half second or so, and have no warmup/down like bigger ones. Go play MechWarrior 3 (not 4, whose lasers look like ass) and check out the laser weapons (not pulse lasers, but regular or ER) there to see what I think would be a great fighter beam.
-
Wouldn't it be easier to create a new type of weapon?
It is something between normal pulse/laser/plasma weapon and anti-fighter beam.
Basically it is very long tailed pulse weapon or a pulse with trail but looks like anti-fighter beam that disappears after certain range. You could even code in transparent values, it becomes more and more transparent until it disappears, damage is also reduced as it becomes more transparent.
Well, beam code is very unsuitable for fighters/bombers, so why don't we do a new fighter beam code from scratch making it only for fighters?
I don't know how well FS2 engine could handle this kind of weapon without major performance loss in bigger battles.
-
Originally posted by venom2506
well, that's only useful against capships, excepted for hotshots...
What, like how I used the Nova Cannon in Starlancer? Bzzt, one shot kills on Basilisks! Even when the bastards are in the middle of cloaking to get away. :D
And why would you need to make a 'pseudobeam' for fighters? Sure having a focal distance to reduce damage at long range for weapons would be neat, but really...... beam and pulse. What else can you really do? A 'hybrid' is merely a pulse with a very long trail, which can be done as it is.
-
Originally posted by Shrike
And why would you need to make a 'pseudobeam' for fighters? Sure having a focal distance to reduce damage at long range for weapons would be neat, but really...... beam and pulse. What else can you really do? A 'hybrid' is merely a pulse with a very long trail, which can be done as it is.
Yes, but that effect sucks. Just look at TBP Nial fighter, it does not look good.
-
But in reality a Nial would use a true beam. So we remove that problem.
-
Originally posted by Shrike
But in reality a Nial would use a true beam. So we remove that problem.
True. I just suggested that if it could be easier to make a pulse weapon that is exactly like beam after it is fired, not ****ty looking trail or stretched pulse than modifying existing beam code and make it perfectly working (energy, AI).
-
Well, if the TBP wants beam-firing fighters, they'd better get started on fixing all the problems, nyet? ;)
-
well I fixed the energy bug,
sort of, I need to figure out how to use the timestamp functions, it stops firing when out of energy the only thing wrong is it won't lock you out of firing it for a short delay after depleteing the reserves, but this is minor
I realy want to know why the AI won't fire these
-
Is there some seperate AI section that you have to fill in. :)
-
the targetting beam section is triggered in the same function for normal primary weapons
-
Originally posted by Bobboau
the targetting beam section is triggered in the same function for normal primary weapons
Just to remind you: Did you check the TBL to make sure that there aren't any flags on the weapon (eg, 'huge') that are telling the AI not to fire it? Also, did you try making a mission that does beam-free-all on the AI fighters carrying it?
-
it's the targeting laser with damage and a hit explosion, I cnaged nothing else, I'll try the beam free all, but it looks like type c beams are freed apon creation
-
Originally posted by Bobboau
it's the targeting laser with damage and a hit explosion, I cnaged nothing else, I'll try the beam free all, but it looks like type c beams are freed apon creation
can you make it so your killcount goes up when you shoot someone down with it :p
-
I'll look into it
-
Could you mount something like this on a capital ship?
A TRACKING continuous beam weapon I mean?
-
well if you set the fire wait to 0 this thing will do that, I think
-
Originally posted by Alikchi
Could you mount something like this on a capital ship?
A TRACKING continuous beam weapon I mean?
Type 0 beams already do this. The beam's aim is adjusted whenever the target moves.
-
Hmm, so it would track fighters? Continuously? Like an AAAf that doesn't "blink"?
-
Originally posted by Alikchi
Hmm, so it would track fighters? Continuously? Like an AAAf that doesn't "blink"?
Correct.
-
That sounds like one mean weapon
-
An AAA that didn't "blink" would be easy. Just change the number of shots to one instead of three.
-
Originally posted by Raa Tor'h
That sounds like one mean weapon
That's why it's used against capships. ;7
It also applies damage in the usual 'n times per second' manner, instead of once per blink on type 3 beams.
The disadvantage that type 0 beams have when compared to type 3 is that, if they miss, they miss for the entire shot, whereas type 3 beams that miss may still hit on the next blink.
Despite this disadvantage, I suspect that :V: created the type 3 beam to use as anti-fighter upon realizing that shaking a type 0 beam is pretty impossible -- once it's got you, you're going to take all of its damage unless you move out of range or duck behind something to avoid it. Outmaneuvering it simply doesn't work. Of course, outmaneuvering type 3 beams isn't exactly easy either, and they could have just toned down damage and life on a type 0 to make it a reasonably balanced anti-fighter beam.
P.S.: This smiley is cool: :snipe:
-
Originally posted by Sesquipedalian
An AAA that didn't "blink" would be easy. Just change the number of shots to one instead of three.
It's still type 3, and it still does all of its damage at once, unlike type 0 beams which do damage continuously.
-
all beams do damage continuously
-
Originally posted by Bobboau
all beams do damage continuously
If you're certain of this, then type 3 beams must stay on for only one 'count', because I know I don't take continuous damage from them in missions.
Are you sure about this? Can you verify it?
-
Originally posted by _argv[-1]
If you're certain of this, then type 3 beams must stay on for only one 'count', because I know I don't take continuous damage from them in missions.
Are you sure about this? Can you verify it?
I can, and easily. Just look from the tables how little damage an AAA beam does, it's way less than an average primary weapon shot.
So it has to do continuous damage, it just blinks so quickly that it does the same damage almost always, especially because it throws your fighter around a bit after the hit.
-
her, have you really tried type0 beams? don' think it works, actually
-
Originally posted by venom2506
that's very good I suppose, I'd just prefer to keep the trigger pulled than having to push it twice... it's just not natural in terms of handling. say, you have a beam with 1 sec warm up and 1 ec warm down, and it lasts till you have no energy left. if you keep the trigger pulled for 3 seconds, the first sec, it will charge up, then for two seconds the beam will fire, then auto warmdown. warm down triggered too if you run out of power.
If you have a fully filled up weapon energy, the beam powers up it drains the energy to the glow then forms a beam from that power colected by the powerup:) when fired it dumps the remaining engery back into the weapon energy bank sounds good?:)
-
I challenge you to shoot any fighter down with such a weapon :p
-
OK, I have gotten it to fire from all slots in all banks if they are linked,
this is the targeting beam procesing function, replace the exsisting one with this
void ship_process_targeting_lasers()
{
beam_fire_info fire_info;
ship_obj *so;
ship *shipp;
polymodel *m;
// interate over all ships
for ( so = GET_FIRST(&Ship_obj_list); so != END_OF_LIST(&Ship_obj_list); so = GET_NEXT(so) ) {
shipp = &Ships[Objects[so->objnum].instance];
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
//if (shipp->targeting_laser_bank != 2)
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
// sanity checks
if(so->objnum < 0){
continue;
}
if(Objects[so->objnum].type != OBJ_SHIP){
continue;
}
if(Objects[so->objnum].instance < 0){
continue;
}
// if our trigger is no longer down, switch it off
if(!(shipp->flags & SF_TRIGGER_DOWN)){
ship_stop_targeting_laser(shipp);
continue;
}
// if we have a bank to fire - fire it
//for nonlinked
if((shipp->targeting_laser_bank >= 0) && (shipp->targeting_laser_bank < 2)){
// try and get the model
m = model_get(shipp->modelnum);
if(m == NULL){
continue;
}
// fire a targeting laser
for ( int j = 0; j < num_slots; j++ ){
fire_info.accuracy = 0.0f;
fire_info.beam_info_index = shipp->weapons.primary_bank_weapons[shipp->targeting_laser_bank];
fire_info.beam_info_override = NULL;
fire_info.shooter = &Objects[shipp->objnum];
fire_info.target = NULL;
fire_info.target_subsys = NULL;
fire_info.turret = NULL;
fire_info.targeting_laser_offset = m->gun_banks[shipp->targeting_laser_bank].pnt[j];
shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
// hmm, why didn't it fire?
if(shipp->targeting_laser_objnum < 0){
Int3();
ship_stop_targeting_laser(shipp);
}
}
//for linked
//if primarys are linked and we have already fired the first bank
//and the second bank is also a fighter beam, fire fighter beams
//from all fireing points in the second bank
if((shipp->flags & SF_PRIMARY_LINKED) && (shipp->targeting_laser_bank == 0) && (shipp->weapons.primary_bank_weapons[1] >= 0) && (Weapon_info[shipp->weapons.primary_bank_weapons[1]].wi_flags & WIF_BEAM) && (Weapon_info[shipp->weapons.primary_bank_weapons[1]].b_info.beam_type == BEAM_TYPE_C)){
int num_slots = po->gun_banks[1].num_slots;
for ( int j = 0; j < (num_slots); j++ ){
fire_info.accuracy = 0.0f;
fire_info.beam_info_index = shipp->weapons.primary_bank_weapons[1];
fire_info.beam_info_override = NULL;
fire_info.shooter = &Objects[shipp->objnum];
fire_info.target = NULL;
fire_info.target_subsys = NULL;
fire_info.turret = NULL;
fire_info.targeting_laser_offset = m->gun_banks[1].pnt[j];
shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
// hmm, why didn't it fire?
if(shipp->targeting_laser_objnum < 0){
Int3();
ship_stop_targeting_laser(shipp);
}
}
}
}
}
}
also, I have changed part of the fire primary functin wich is what calls the start_targetting_laser function, and in an (failed) effort to get AI ships to fire it I moved it to line 5121, or thereabouts, you can probly put this in were it is suposed to be, most stuff that may not make sence in this is all trying to get AI to fire,
// if this is a targeting laser, start it up
//fighterbeams
if((shipp->flags & SF_TRIGGER_DOWN)){
if((winfo_p->wi_flags & WIF_BEAM) && (winfo_p->b_info.beam_type == BEAM_TYPE_C) ){
shipp->weapons.flags |= SW_FLAG_BEAM_FREE;
if(shipp->weapon_energy > 0.0f)
swp->next_primary_fire_stamp[shipp->targeting_laser_bank] = timestamp(0);
if(shipp->weapon_energy < 0.0f)
swp->next_primary_fire_stamp[shipp->targeting_laser_bank] = timestamp(1000);
if( (shipp->weapon_energy > 0.0f) && (swp->next_primary_fire_stamp[shipp->targeting_laser_bank] == timestamp(0))){
ship_start_targeting_laser(shipp);
if ( sound_played != winfo_p->launch_snd ) {
sound_played = winfo_p->launch_snd;
if ( obj == Player_obj ) {
if ( winfo_p->launch_snd != -1 ) {
weapon_info *wip;
ship_weapon *swp;
// HACK
if(winfo_p->launch_snd == SND_AUTOCANNON_SHOT){
snd_play( &Snds[winfo_p->launch_snd], 0.0f, 1.0f, SND_PRIORITY_TRIPLE_INSTANCE );
} else {
snd_play( &Snds[winfo_p->launch_snd], 0.0f, 1.0f, SND_PRIORITY_MUST_PLAY );
}
// snd_play( &Snds[winfo_p->launch_snd] );
swp = &Player_ship->weapons;
if (swp->current_primary_bank >= 0) {
wip = &Weapon_info[swp->primary_bank_weapons[swp->current_primary_bank]];
joy_ff_play_primary_shoot((int) ((wip->armor_factor + wip->shield_factor * 0.2f) * (wip->damage * wip->damage - 7.5f) * 0.45f + 0.6f) * 10 + 2000);
}
}
}
else {
if ( winfo_p->launch_snd != -1 ) {
snd_play_3d( &Snds[winfo_p->launch_snd], &obj->pos, &View_position );
}
}
}
}
/*
if ( !timestamp_elapsed(swp->next_primary_fire_stamp[shipp->targeting_laser_bank]) ) {
if (timestamp_until(swp->next_primary_fire_stamp[shipp->targeting_laser_bank]) > 5000){
swp->next_primary_fire_stamp[shipp->targeting_laser_bank] = timestamp(1000);
}
}
*/
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
//if (shipp->targeting_laser_bank != 2)
int num_slots = po->gun_banks[shipp->targeting_laser_bank].num_slots;
//if (shipp->targeting_laser_bank == 2)
//int num_slots = po->gun_banks[0].num_slots +po->gun_banks[1].num_slots;
/* if ( ship_weapon_maybe_fail(shipp) && !force) {
if ( obj == Player_obj ) {
if ( ship_maybe_play_primary_fail_sound() ) {
}
}
continue;
}*/
shipp->weapon_energy -= num_slots*winfo_p->energy_consumed;
if(shipp->weapon_energy < 0.0f){
swp->next_primary_fire_stamp[shipp->targeting_laser_bank] = timestamp(1000);
if ( obj == Player_obj )
ship_maybe_play_primary_fail_sound();
shipp->weapon_energy = 0.0f;
ship_stop_targeting_laser(shipp);
}
continue;
}
}
I still want to get a bit of a delay after the primary weapons energy runns out, but I can't figure out how to use the timestamp stuff, havn't realy given it as much atention as the AI problem, wich is starting to piss me off, I hear the other ships weapon sounds, so I know it's getting at least as far as ship_start_targeting_laser(shipp); meaning the AI is trying to fire it but I can't figure out were exactly it screws up, it should work, it works for the player ship, might be fun to se if this works in multi-player, I think I need some more experienced programer to at least find were the AI ships are messing
-
Originally posted by Pera
I can, and easily. Just look from the tables how little damage an AAA beam does, it's way less than an average primary weapon shot.
So it has to do continuous damage, it just blinks so quickly that it does the same damage almost always, especially because it throws your fighter around a bit after the hit.
Instead of talking about it, why don't you go play the damn game, get attacked by a AAA beam, and notice how your hull drops by 5% or so all at once? I'm tired of trying to convince people.
-
isn't it funny how in my version of the game you get damaged less by the beams if you are hit and move out of there way than if you arnt able to, each shot lasts for a certan amount of time anything it hits during that time gets damage per second, most of the time you only get a few frames worth becase you're trying to doge them
-
When a ship fires an anti-fighter beam at another larger ship though, it does not fire it in three bursts; it all goes off in one long shot. Would that imply that the damage is done the same way as with the other beam types?
-
Originally posted by Bobboau
isn't it funny how in my version of the game you get damaged less by the beams if you are hit and move out of there way than if you arnt able to, each shot lasts for a certan amount of time anything it hits during that time gets damage per second, most of the time you only get a few frames worth becase you're trying to doge them
Well, since there are so many disagreements with me, I think I'll go play and see if I missed something earlier. I don't have time right now, though -- sorry.
-
can we say somewhat on topic
-
Screeeeeenies.
-
(http://freespace.volitionwatch.com/blackwater/fighterbeams01.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams02.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams03.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams04.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams05.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams06.jpg)
-
(http://freespace.volitionwatch.com/blackwater/fighterbeams07.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams08.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams09.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams10.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams11.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams12.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams13.jpg)
(http://freespace.volitionwatch.com/blackwater/fighterbeams14.jpg)
there how's that
-
God damn! :jaw:
You named the enemy wing "bad". Excellent.
-
that's my standard fighter/weapon combat stability test mission, a
and this (http://freespace.volitionwatch.com/blackwater/FS3.zip) is the executable, I was playing
YES, I've got my FTP back!!!
-
Holy **** is more like it bro..............:jaw: :eek: :eek: :bump:
-
I assume that when you turn in flight, the beams continue to emanate in a straight line from your gunpoints along the normals, correct?
-
um,... they fire strait
-
133+ness! :jaw:
-
A little teenie, tiny question that I have (and a point that's probably too little-needed and difficult to implement to be worth it, but I have to ask anyway)....is there any way to affect dynamically the focus of the beams?
For example, in X-Wing Alliance (the previous three didn't do this), certain ships (dependant upon the technology level of the ship) had the ability to set in-flight focusing points for the lasers.
While flying an X-Wing, I can set the lasers to converge at 150, 100, 50, "automatic" meters from my ship. (It's also possible to set "no convergence") At "automatic" the lasers simply converge at the same distance as my current target.
Anyway, I'm wondering if that's possible or not, seeing as Freespace has a system of firing along the normals of the weapons...one could calibrate a POF to converge its weapons at a specific distance, but that convergence cannot be changed within the game, right?
--TurboNed
-
Originally posted by Bobboau
and this (http://freespace.volitionwatch.com/blackwater/FS3.zip) is the executable, I was playing
FS3? :D
-
stoopid question number 5464346:
would it be possible to give charge up glows ( of, dunno, 1/8 second) to regular lasers thnks to the source?
-
posable... ya
do I know how to do it...
I'm more concerned with getting the AI to use this at the moment
-
Originally posted by Bobboau
posable... ya
do I know how to do it...
I'm more concerned with getting the AI to use this at the moment
this is a good concern :)
-
Originally posted by _argv[-1]
shaking a type 0 beam is pretty impossible -- once it's got you, you're going to take all of its damage unless you move out of range or duck behind something to avoid it.
Which is why the beam should follow you for 3 seconds, and then, say do 5 damage per second. It wouldn't kill you, but if you were critical, or a slow bomber, and 3 of these turrets find you... Buh-bye.
-
Originally posted by Pera
FS3? :D
I assume its called this so it can coexist in the same directory with the original executable.
-
i, erm,... uhg... yes :nervous: :nod:
-
Hmmm... Is there a way for the fs3 to actually run? We might need that test mission.
-
the test mission is simply a player ship (Alpha 1), and three "bad" ships
-
I did a little digging around in the code, looking for a way to cause beams to not pierce shields. I've found something interesting.
In code/Model/ModelCollide.cpp line 291 is some code for checking if a pulse weapon hit a shield, and doing things appropriately. Much of this stuff can be used with beams as well, with some modifications.
In code/Weapon/Beam.cpp line 2315 is some code for checking if a beam weapon hit an object. Notice that test_collide.flags has MC_CHECK_MODEL. To make it check shields, change MC_CHECK_MODEL to MC_CHECK_SHIELD. You need to MC_CHECK_MODEL afterwards, if the target has no shields or if its shields in that quadrant are down. You also need to do shield damage and make shield effects, which go in some functions below there, probably near line 2787.
Anyone who is interested in doing this stuff will hopefully find this information useful. Good luck, guys.
-
Could be useful for any Star trek mods. Particle Weapons vs Shields. But not for FS2-modextended campaigns because if even the shivans could not build a shield to protect against beam fire, then the Terrans & vasudans certainly can' t, And i think we have to keep some kind of consistency with the FS universe.
But ofcourse for MODS not having anything to do with the FS universe this is useful.
-
I think it would be usefull for making a flag that sets a beam as non shield piercing, such as the anti fighter beams
and I have seen that code, I didn't do anything becase it looked like it would be a bit of a restructuring of the beam coliding code, and it would have to pas quadrants and such
-
Originally posted by DTP
Could be useful for any Star trek mods. Particle Weapons vs Shields. But not for FS2-modextended campaigns because if even the shivans could not build a shield to protect against beam fire, then the Terrans & vasudans certainly can' t, And i think we have to keep some kind of consistency with the FS universe.
But ofcourse for MODS not having anything to do with the FS universe this is useful.
Actually, I was hoping to change the FS universe, such that all shields (Shivan, Terran, and Vasudan) protect against beams. It's more realistic that way, I think.
-
Originally posted by Bobboau
I think it would be usefull for making a flag that sets a beam as non shield piercing, such as the anti fighter beams
and I have seen that code, I didn't do anything becase it looked like it would be a bit of a restructuring of the beam coliding code, and it would have to pas quadrants and such
Near the location I gave in ModelCollide.cpp, there is a call to a function which figures out which quadrant was hit. Doesn't get much simpler than that.
-
Originally posted by _argv[-1]
Actually, I was hoping to change the FS universe, such that all shields (Shivan, Terran, and Vasudan) protect against beams. It's more realistic that way, I think.
Except that GTVA designed beams to penetrate Lucifer's shields.
Yes, they managed to destroy the Lucy, but cost was high.
They designed the Colossus class and anti-cap beams to be Lucy-killers.
But that doesn't matter much since cap ships does not have shields anyway...
-
hrhrhrhr ;7
http://www.hard-light.net/forums/index.php/topic,6339.0.html
-
Originally posted by _argv[-1]
Actually, I was hoping to change the FS universe, such that all shields (Shivan, Terran, and Vasudan) protect against beams. It's more realistic that way, I think.
How would that be more realistic? I thought shields would only protect against matter-based weapons(or whatever, just not purely energy based).
-
Originally posted by YodaSean
How would that be more realistic? I thought shields would only protect against matter-based weapons(or whatever, just not purely energy based).
Last time I checked, lasers (ML-16, Prometheus, Disruptor, Disruptor Advanced, Akheton SDG, Flail, Morning Star, etc), xasers (Subach/Mekhu HL-7), and fluctuating EM emissions (Banshee, Shield Breaker, Circe) were purely energy based.
The best example here is the ML-16. Despite it being purely energy based (it's a laser), shields are effectively impervious to it (since they regenerate faster than the ML-16 can damage them).
Also, the Lucifer's shields are impervious to everything, including the pure-energy weapons listed above. The way it was done in FS1 (ship-invulnerable), not even beams could puncture it.
-
Originally posted by _argv[-1]
Also, the Lucifer's shields are impervious to everything, including the pure-energy weapons listed above. The way it was done in FS1 (ship-invulnerable), not even beams could puncture it.
Actually, they did that only because putting shields on something that big, and then hammering it with blobs all the time would slow any computer to a crawl :)
-
Don't forget, we've got much better computers than we did at the time of FS1. It would probably be a lot more feasible this time.
-
Originally posted by Boct1584
Don't forget, we've got much better computers than we did at the time of FS1. It would probably be a lot more feasible this time.
I just said that's why Volition didn't put shields in Lucy in FS1.
-
Originally posted by _argv[-1]
the Lucifer's shields are impervious to everything, including the pure-energy weapons listed above. The way it was done in FS1 (ship-invulnerable), not even beams could puncture it.
except for the banshee. the tech room said they can puncture any known shielding system. they made it so you never got to use them on the Lucy while not in subspace, so you couldn't prove them wrong.
-
Originally posted by Carl
except for the banshee. the tech room said they can puncture any known shielding system. they made it so you never got to use them on the Lucy while not in subspace, so you couldn't prove them wrong.
But the GTA and PVN were very desperate to find a way to blow the reactors on the Lucy, so presumably someone would have tried that, even if the player couldn't...
-
Originally posted by Pera
Actually, they did that only because putting shields on something that big, and then hammering it with blobs all the time would slow any computer to a crawl :)
Why? The shield mesh for a ship that big would have not many more polys than the ship model. Any computer that can't render two or three Lucifers at the same time should be running Doom or something, not FreeSpace. :rolleyes:
-
Actually, on the shielded Lucy(my version), even when being attacked by 30 fighters & 3 capships and 1 juggernaut, no more than 10-25 polies light up at the same time.on all settings HIGH i fell no slowdowns on a 800 mhz GF2 mmx 32 mb ram, 128 SDRAM.
-
Originally posted by DTP
i fell no slowdowns on a 800 mhz GF2 mmx 32 mb ram, 128 SDRAM.
that probably because you have a 800 mhz GF2 mmx 32 mb ram, 128 SDRAM :rolleyes:
-
A test where i included to original Lucy with invulnarble tag
and same mission with the shielded version there where no time difference, hence no slowdown of the machine for the lucy to travel from 1 point to another , and i clocked this using a watch.
If there had been any slowdowns then the mission would have lasted longer in real time.
I really need to get a FPS into the screen. & maybe some FPS option like -drawfps.
-
no it wouldn't, fs uses a time ticker, not much is just cycled every frame, most things use the proper x + timestamp() = y
-
Originally posted by Bobboau
no it wouldn't, fs uses a time ticker, not much is just cycled every frame, most things use the proper x + timestamp() = y
And it's a good thing too - if someone were running, say, a 5 GHz with a GeForce6 (512 MB RAM - the low end model), and it were designed so that framerate dictated gametime, you'd either...
a)be like most of humanity and not be able to play the game 'cause it's so freakin' fast.
b)be able to beat the game in 8 minutes flat.
Not many people would fall in category B.
--TurboNed
-
Originally posted by TurboNed
And it's a good thing too - if someone were running, say, a 5 GHz with a GeForce6 (512 MB RAM - the low end model), and it were designed so that framerate dictated gametime, you'd either...
a)be like most of humanity and not be able to play the game 'cause it's so freakin' fast.
b)be able to beat the game in 8 minutes flat.
Not many people would fall in category B.
--TurboNed
mmh... some old games are actually very fun and still playable easily with the new comps. try the first Screamer some day :D.
You thought Wipe Out was fast? bwarf :D
-
Originally posted by _argv[-1]
Actually, I was hoping to change the FS universe, such that all shields (Shivan, Terran, and Vasudan) protect against beams. It's more realistic that way, I think.
So how do they kill each other then? Flack them to death?
And i know what u mean about Wipeout, Venom. Its the "wow, im going, like, 180mph man!". Then Wipeout 2097 came along, and "wow, im going 300mph!". :jaw:
Then came Pod racer, and you felt slow at the 600mph the game claimed to recreate relistically.
I actually got up to over 1400mph in pod racer, it was in one of the vacum tubes on the mining colony, and i had my super-modded Neeva Kee pod. Thing is since the landscapes in podrace were huge, it never felt that fast.
pete
-
Originally posted by _argv[-1]
Actually, I was hoping to change the FS universe, such that all shields (Shivan, Terran, and Vasudan) protect against beams. It's more realistic that way, I think.
Maybe. I think of it as the beams just being such a quick outpouring of energy that they just puncture the shield. By the time the shield can form back over that spot to protect your ship, the beam has finished doing its damage.
-
Originally posted by NotDefault
Maybe. I think of it as the beams just being such a quick outpouring of energy that they just puncture the shield. By the time the shield can form back over that spot to protect your ship, the beam has finished doing its damage.
The rate of damage (and, hence, energy output) of AAA beams is much lower than conventional pulse weapons. Said pulse weapons are closer to being the quick outpouring you speak of.
-
Originally posted by _argv[-1]
The rate of damage (and, hence, energy output) of AAA beams is much lower than conventional pulse weapons. Said pulse weapons are closer to being the quick outpouring you speak of.
Heh, that's a good point. :o
-
not really. it's just a matter of balance issues. if they were to make it realistic, all the shivans weapons would be much more powerful than GTVA ones for exemple, I suppose.
-
The thing is, the damage dealt by a beam is dealt every few milliseconds, instead of once per shot.
-
Originally posted by venom2506
not really. it's just a matter of balance issues. if they were to make it realistic, all the shivans weapons would be much more powerful than GTVA ones for exemple, I suppose.
I actually went and changed weapons.tbl to that effect. Much more fun that way...
-
When the beam hits a ship it calls ship_apply_local_damage (line 2788 of code/Weapon/Beam.cpp). If you check the parameters it passes, the beam passes a -1 to the function under shield quadrant.
In code/ShipHit/ShipHit.cpp on line 2284, the comment tells you that a -1 passed through in the shield quadrant parameter makes the hit ignore the shield. It also tells you that the ship_apply_local_damage function assumes that whoever called the function knows if the shield got hit or not.
So what we need to do is find the shield facing that is hit. Well, as _argv[-1] noted, the beam weapon passes the MC_CHECK_MODEL rather than the MC_CHECK_SHIELD flag. Looking at mc_check_subobj (line 821 of code/Model/ModelCollide.cpp), there is code for both shield and model hits. So the if the shield flag is sent, it MIGHT check the shield first. However, I can't find anyplace that checks shield first, then model if no shield, so I'm not sure if more code is needed...
Anyway, we need to determine shield face struck before the ship_apply_local_damage is called...
-
Welcome r0nin I hope you have a good time here at HLP :nod:
-
Originally posted by Maeglamor
Welcome r0nin I hope you have a good time here at HLP :nod:
Thanks! :D I've been modding other stuff for a while (my C++ is a little rusty), but the Robotech Freespace2 Mod got me interested in modding for Freespace.
BTW, by changing the MC_CHECK_MODEL flag over to MC_CHECK_SHIELD, I got the beam to check for the presense of shields, but it would no longer do damage to the hull/subsystems (unfortunately, I have the Robotech mod on and none of those models HAVE shields... so someone with shielded ships let me know if the beam does damage to them with that flag). I will be trying to write some code to check if no shield is hit, so that the beam will then check for model hits afterward...
-
Originally posted by r0nin
When the beam hits a ship it calls ship_apply_local_damage (line 2788 of code/Weapon/Beam.cpp). If you check the parameters it passes, the beam passes a -1 to the function under shield quadrant.
In code/ShipHit/ShipHit.cpp on line 2284, the comment tells you that a -1 passed through in the shield quadrant parameter makes the hit ignore the shield. It also tells you that the ship_apply_local_damage function assumes that whoever called the function knows if the shield got hit or not.
So what we need to do is find the shield facing that is hit. Well, as _argv[-1] noted, the beam weapon passes the MC_CHECK_MODEL rather than the MC_CHECK_SHIELD flag. Looking at mc_check_subobj (line 821 of code/Model/ModelCollide.cpp), there is code for both shield and model hits. So the if the shield flag is sent, it MIGHT check the shield first. However, I can't find anyplace that checks shield first, then model if no shield, so I'm not sure if more code is needed...
Anyway, we need to determine shield face struck before the ship_apply_local_damage is called...
I have determined that it will check the shield if there is one. I'm pretty sure it'll check the model if the shield wasn't hit (or there is no shield), but I'm not sure. Why not make the change (ie, pass MC_CHECK_SHIELD), test that it works on shields as expected, then make a mission in FRED where your target has no shields?
-
Originally posted by Maeglamor
Welcome r0nin I hope you have a good time here at HLP :nod:
Harumph. I didn't get that wonderful nice greeting when I started posting here a few weeks ago. :mad: :snipe: :headz:
(Just playing. :lol: )
-
Originally posted by _argv[-1]
I have determined that it will check the shield if there is one. I'm pretty sure it'll check the model if the shield wasn't hit (or there is no shield), but I'm not sure. Why not make the change (ie, pass MC_CHECK_SHIELD), test that it works on shields as expected, then make a mission in FRED where your target has no shields?
Actually, I have. :( The Robotech mod (way cool, btw) has no ships with any shields (not even the shield mesh in the pofs). Since I pretty much picked up FS2 in order to play around with those guys' mod, I would hate to have to uninstall and reinstall in order to test out a ship that has shields.
As for the ship without shields, the beam weapons have NO effect on the ship when I change the flag to MC_CHECK_SHIELD. This leads me to believe (though I haven't tested it) that the beam would do damage to shields but needs some additional coding to have it check for both. Still working on it...
-
I would hate to have to uninstall and reinstall in order to test out a ship that has shields.
D00d...if I had to uninstall to check something on another MOD, I would have to do that several times a day!
Just rename your /data directory to /data_RT (Robo Tech or whatever) and start the game and it will make you a new data directory. Then you can test yourself.
-
Originally posted by _argv[-1]
Harumph. I didn't get that wonderful nice greeting when I started posting here a few weeks ago.
"Gunnery control, commence plasma injection-"
(http://members.cox.net/~wmcoolmon/images/welcome.gif)
-
Have you tryind copying and pasting from one of the other files that is similar to the original setup?
-
Hmmm. Well, I've found out several things. First off, the flags don't seem to do what I thought. They just deterime the collision model tested against, but they don't generate the hit facing.
What is interesting is that all that I needed to do was change the final number in line 2788 of code/Weapon/Beam.cpp from -1 to any other number corresponding to a shield face (1-6 or 0-5, I believe):
ship_apply_local_damage(&Objects[target], &Objects[b->objnum], &b->f_collisions[idx].cinfo.hit_point_world, beam_get_ship_damage(b, &Objects[target]), -1);
Then, the target takes damage to #2 (or whatever number you choose) shield every time it is hit, until the shield drops. Then it takes damage to the hull, etc., as usual. The only trick now is to figure out what the correct code is that represents the shield facing hit.
Unfortunately, the beam functions use a radically different code structure than the other weapon functions, so cutting-and-pasting doesn't work (and believe me, I've tried!)...
More later (when my brain stops hurting)...:sigh:
-
Originally posted by IceFire
D00d...if I had to uninstall to check something on another MOD, I would have to do that several times a day!
Just rename your /data directory to /data_RT (Robo Tech or whatever) and start the game and it will make you a new data directory. Then you can test yourself.
Thanks a ton! That makes things muuuch easier...:yes:
-
have you found a way to make it count the kills you make?
last time i played it refused to count kills when i used a beam weapon. And can the color be made something NOT blue? Like say green.
-
Easily. Just change the name of the beam texture file in the TBL.
-
I have tried that. the beam stays blue or it instead fires little red pulses.
And how do you make it record kills?
-
; Targeting Laser
;
$Name: @Targeting Laser
+Title: XSTR("Targeting Laser", 3306)
+Description:
XSTR(
"", 3307)
$end_multi_text
+Tech Description:
XSTR(
"", 3308)
$end_multi_text
$Model File: none
;
;
;
@Laser Bitmap: newglo6
@Laser Color: 190, 150, 250
@Laser Length: 10.0
@Laser Head Radius: 0.90
@Laser Tail Radius: 0.30
$Mass: 0.2
$Velocity: 450.0 ;; speed of the weapon (initially) -- may or may not change
$Fire Wait: 0.2 ;; in seconds
$Damage: 0
$Armor Factor: 0.9
$Shield Factor: 0.7
$Subsystem Factor: 0.3
$Lifetime: 0.0 ;; How long this thing lives
$Energy Consumed: 0.20 ;; Energy used when fired
$Cargo Size: 0.0 ;;
$Homing: NO
$LaunchSnd: 115 ;;
$ImpactSnd: 27 ;;
$Flags: ("beam")
$Icon: iconKayser
$Anim: Kayser
$Impact Explosion: none
$BeamInfo:
+Type: 2
+Life: 0.0
+Warmup: 0
+Warmdown: 0
+Radius: 1.0
+PCount: 0
+PRadius: 0
+PAngle: 0.0
+PAni: particleexp01
+Miss Factor: 0.0 0.0 0.0 0.0 0.0
+BeamSound: 115
+WarmupSound: 0
+WarmdownSound: 0
+Muzzleglow: thrusterglow01
+Shots: 0
+ShrinkFactor: 0.0
+ShrinkPct: 0.0
$Section:
+Width: 0.5
+Texture: beam-white
+RGBA Inner: 255 255 255 255
+RGBA Outer: 150 150 150 10
+Flicker: 0.1
+Zadd: 2.0
$Section:
+Width: 0.75
+Texture: beam-dblue2
+RGBA Inner: 160 160 0 255
+RGBA Outer: 60 60 0 10
+Flicker: 0.1
+Zadd: 1.0
$Section:
+Width: 1.0
+Texture: beam-dblue
+RGBA Inner: 255 0 0 255
+RGBA Outer: 60 0 0 10
+Flicker: 0.1
+Zadd: 0.0
Change the things in bold to change the look.
-
But you have to specify another color and be sure to look through the VP effects folder to make sure you get it right...OR....specify your own.
-
I totaly reworked the way I am handeling the fighter beams and got it (http://freespace.volitionwatch.com/blackwater/FS3.zip) to work, as in got I it to work on AI fighters,
damn I need to get the sheild hitting code to work now, cause it's insane!! you go after the lead fighter and you get all these beams and they all just converge on you're ass,
and makes 1 on 1 fights with AI ships an actual chalenge
this also has the glowpoint code, with the default blinking values I put in untill I get a POF editor capable of makeing the necisary data
oh, and this is almost untested, so ther'll probly be some bugs, and I am going to rework the way it handels energy usage
-
case sensitive...
-
usually is...
something to do on case sensitive stuff is to convert whatever your gettting in from the file (as text) to upper case. If your using charachter arrrays than just use toupper on each array possition.
-
no I meant my url, I had to edit my post
-
k... maybe you didn't cach it the first time,
so here is a bit of intel the GTVI has just receved on new weapons the shivans have started useing
(http://freespace.volitionwatch.com/blackwater/beam01.jpg)
(http://freespace.volitionwatch.com/blackwater/beam02.jpg)
(http://freespace.volitionwatch.com/blackwater/beam03.jpg)
(http://freespace.volitionwatch.com/blackwater/beam04.jpg)
(http://freespace.volitionwatch.com/blackwater/beam05.jpg)
(http://freespace.volitionwatch.com/blackwater/beam06.jpg)
seems were screwed, but wait Alpha 1 has them too
(http://freespace.volitionwatch.com/blackwater/beam07.jpg)
(http://freespace.volitionwatch.com/blackwater/beam08.jpg)
-
(http://freespace.volitionwatch.com/blackwater/beam09.jpg)
(http://freespace.volitionwatch.com/blackwater/beam10.jpg)
(http://freespace.volitionwatch.com/blackwater/beam.jpg)
that's when you know you're screwed :nod:
(http://freespace.volitionwatch.com/blackwater/beam12.jpg)
(http://freespace.volitionwatch.com/blackwater/beam13.jpg)
and my personal favorite
(http://freespace.volitionwatch.com/blackwater/beam11.jpg)
remember, it's right here (http://freespace.volitionwatch.com/blackwater/FS3.zip)
note: it seems something is now broken in the capship code :rolleyes:
-
What's the exact tbl entry for it ?
-
Originally posted by Bobboau
note: it seems something is now broken in the capship code :rolleyes:
What seems wrong?
-
well in a test mission any time a capship entered, the game crashed
-
Is your source in that zip?
-
Originally posted by Bobboau
well in a test mission any time a capship entered, the game crashed
Did get it fixed?;)
-
hey bobboau, i have a bunch of beam graphics, glow points and fighterbeam table entries if you want to use them for testing pouposes, the zip is only a few k so i might just email it to you.
i spent the last couple days messing with the new executable. i wanted to explore the special effects possibilities of fighterbeams so i put together several new graphics plus the ones i used in my mod. there are a few things that i think could make the fighter beams better.
first off make the fighterbeams a new beam type. id like to see the ssm to be completed.
second, i think the beams have some issues when it comes to keeping them all on the target, it would be cool if the beams could eighter converge on the target, or operate as a blindfire system that has the beams chase after targets. i noticed that you have removed the lead indicator when beams are in use, i wonder if it would be posible to make the lead indicator show where the beams (if under a blindfire system) are currently pointed. if the lead indicator is over the ship, it means a sure hit. even under blindfire, the beams should all converge on the target (or the position of the lead indicator + the weapon range tag)
i was thinking that the game seemed kinda like elite whith the fighter beams. i kinda think that the way elite cycled its beams, and i think it would be cool in freespace. make it so beam 1 charges up, fires and discharges, and beam 2 begins charging when beam one begins firing. this is also similar to how beam cannons in b5 operate (b5 mod, duh).
another thing that needs to be done is to make the beams not vaporize the fighters, it looks kinda weird. fighter beams shouldnt have that much power. im not sure about shields. aaa beams dont care about your shields, im not sure if fighterbeams should or not. perhaps make it an option.
if you are going to do a total overhaul of all beam cannons in the game i have a few sugestions.
make type 4s (or whatever the mjolnir's number is) a little more intelegent. make them turnable only if they are on a turret (i think they already do this). i was using them on my ragnarok corvette and i found that they would continue to fire even if they turned away from the enemy. this is another thing that would be good for the b5 mod. alot of b5 ships have forward firing beams. minor changes to type 4s could make them more suitable for the b5 mod (and my corvette). this and a few new sexps would make frontal assaults alot cooler.
turret linking is another thing that could be done. this is less beam related, but i think its still relevant here. you could set group names in the subobject properties of the turets. turrets that share a group name will work together and converge on the same point. their firing would also be linked, though they could go through a cycleing patern (as mentioned above). this could also allow beams to converge and form a big beam. it would require extra table entries and so on, but it would be cool.
-
if you want those graphics you can get them from nukewar download section (http://www.angelfire.com/ak3/nukewar/dl.htm)
they are good for testing and playing around. have fun.
-
I'm going to seperate the SSM code from the fighter beam code completly, getting things like TAG triggered SSMs, multable SSM types, SSM from other beam types, I was even thinking of takeing targeting beams out of the primary weapons all together alowing a seperate system that would fire a targeting beam from a seperate firing point useing a seperat button, that you could use for linking to laser guided bombs, laser TAGing, and stuf like th
that diuculty in hitting things is actualy a balinceing thing so, I'm not going to change that, yet
I will sooner or later make a cycling flag that fires a weapon from one point at a time, this wil include fighter beams (look in the one topic on the TBP forum to see a simple code test for cycling beams)
I keep meaning to fix the vaporisation thing, but I always get distracted
type E (4) beams will always fire in a strait line (you knew that) I think they use the same code for figuring if they should fire as the other beams, so if you have a turret that will have type E beams try giving it a narow FOV, there will need to be a ship flag for capships saying that there main weapons are in the front so they use the fighter atack rutenes.
-
Originally posted by Bobboau
I'm going to seperate the SSM code from the fighter beam code completly, getting things like TAG triggered SSMs, multable SSM types, SSM from other beam types, I was even thinking of takeing targeting beams out of the primary weapons all together alowing a seperate system that would fire a targeting beam from a seperate firing point useing a seperat button, that you could use for linking to laser guided bombs, laser TAGing, and stuf like th
that diuculty in hitting things is actualy a balinceing thing so, I'm not going to change that, yet
I will sooner or later make a cycling flag that fires a weapon from one point at a time, this wil include fighter beams (look in the one topic on the TBP forum to see a simple code test for cycling beams)
I keep meaning to fix the vaporisation thing, but I always get distracted
type E (4) beams will always fire in a strait line (you knew that) I think they use the same code for figuring if they should fire as the other beams, so if you have a turret that will have type E beams try giving it a narow FOV, there will need to be a ship flag for capships saying that there main weapons are in the front so they use the fighter atack rutenes.
so basically how will all this affect capitalship performance in game? also, what does this mean for fredders? (sorry, i didnt understand that)
-
I was responding to mr. nukebomb
-
ah, sorry...i've been trying to follow whats been going on with the source code but unfortunately, i have no idea what you guys are talking about most of the time...
-
Originally posted by Bobboau
this also has the glowpoint code, with the default blinking values I put in untill I get a POF editor capable of makeing the necisary data
describe the chunk specifications
-
this is what I want my loading code to look like
case ID_GLOW:{ //start glowpoint reading -Bobboau
//
char props[MAX_PROP_LEN];
pm->n_glows = cfread_int(fp);
pm->glows = (glow_bank *)malloc(sizeof(glow_bank) * pm->n_glows);
Assert( pm->glows != NULL );
for (int q = 0; q < pm->n_glows; q++ ) {
glow_bank *bank = &pm->glows[q];
bank->glow_timestamp=timestamp();
bank->disp_time= cfread_int(fp); //[b]new thing[/b] time displacment so you can have things blink in sequence
bank->on_time= cfread_int(fp); //[b]new thing[/b] how long it will be on
bank->off_time= cfread_int(fp); //[b]new thing[/b] how long it will be off
bank->is_on=1;
bank->submodel_parent= cfread_int(fp); //[b]new thing[/b] submodel that this is a child to, for not rendering if it is destroied and rotating subobjects, not implemented yet, might use a string so it can be linked to a SPCL point
bank->LOD= cfread_int(fp); //[b]new thing[/b] lod level this bank belongs to, not implemented yet
bank->num_slots = cfread_int(fp);
cfread_string_len( props, MAX_PROP_LEN, fp );
// look for $glow_texture=xxx
int length = strlen(props);
if (length > 0) {
int base_length = strlen("$glow_texture=");
Assert( strstr( (const char *)&props, "$glow_texture=") != NULL );
Assert( length > base_length );
char *glow_texture_name = props + base_length;
if (glow_texture_name[0] == '$') {
glow_texture_name++;
}
bank->glow_bitmap = bm_load( glow_texture_name );
if (bank->glow_bitmap < 0) {
Error( LOCATION, "Couldn't open texture '%s'\nreferenced by model '%s'\n", glow_texture_name, pm->filename );
}
}
for (j = 0; j < bank->num_slots; j++) {
cfread_vector( &(bank->pnt[j]), fp );
cfread_vector( &(bank->norm[j]), fp );
bank->radius[j] = cfread_float( fp );
//mprintf(( "Rad = %.2f\n", rad ));
}
//mprintf(( "Num slots = %d\n", bank->num_slots ));
}
break;
} //end glowpoint reading -Bobboau
-
bah, define that as a structure
ie
struct GLOW
{
int numglows;
.....
}
i'm not familiar with where that coems from the code, etc
how does FreeSpace 2 handle unrecognized chunks? if it ignores them :P
-
hows this, it's the internal glow_bank structure
currently, it uses basicly the thruster structure, anything with the "//old thing" behind them are curently covered buy this
things with the "//new thing" behind them are new things that will need code writen for them
anything with the "//nothing loaded from file" behind them are internal and you don't need to wory about wrighting anything for them
typedef struct glow_bank { // glow bank struckture -Bobboau
int glow_timestamp; //nothing loaded from file
int on_time; //new thing
int off_time; //new thing
int disp_time; //new thing
int is_on; //nothing loaded from file
int submodel_parent; //new thing
int LOD; //new thing
int num_slots; //old thing
vector pnt[MAX_THRUSTER_SLOTS]; //old thing
vector norm[MAX_THRUSTER_SLOTS]; //old thing
float radius[MAX_THRUSTER_SLOTS]; //old thing
int glow_bitmap; //old thing
} glow_bank;
-
while I'm putting up code snipets I'll put up the modifyed ship_fire_primary function for the fighter beams seeing as that is what this topic is about,
note it makes a clear diferental between fighter beams and targeting lasers, and it bypasses the targeting laser functions
// fires a primary weapon for the given object. It also handles multiplayer cases.
// in multiplayer, the starting network signature, and number of banks fired are sent
// to all the clients in the game. All the info is passed to send_primary at the end of
// the function. The check_energy parameter (defaults to 1) tells us whether or not
// we should check the energy. It will be 0 when a multiplayer client is firing an AI
// primary.
int ship_fire_primary(object * obj, int stream_weapons, int force)
{
vector gun_point, pnt, firing_pos;
int n = obj->instance;
ship *shipp;
ship_weapon *swp;
ship_info *sip;
ai_info *aip;
int weapon, i, j, weapon_objnum;
int bank_to_fire, num_fired = 0;
int banks_fired, have_timeout; // used for multiplayer to help determine whether or not to send packet
have_timeout = 0; // used to help tell us whether or not we need to send a packet
banks_fired = 0; // used in multiplayer -- bitfield of banks that were fired
int sound_played; // used to track what sound is played. If the player is firing two banks
// of the same laser, we only want to play one sound
Assert( obj != NULL );
if(obj == NULL){
return 0;
}
// in the case where the server is an observer, he can fire (which) would be bad - unless we do this.
if( obj->type == OBJ_OBSERVER){
return 0;
}
Assert( obj->type == OBJ_SHIP );
Assert( n >= 0 );
Assert( Ships[n].objnum == OBJ_INDEX(obj));
if((obj->type != OBJ_SHIP) || (n < 0) || (n >= MAX_SHIPS) || (Ships[n].objnum != OBJ_INDEX(obj))){
return 0;
}
shipp = &Ships[n];
swp = &shipp->weapons;
//if (shipp->targeting_laser_objnum != -1)
//shipp->targeting_laser_objnum = -1; // erase old laser obj num if it has any -Bobboau
// bogus
if((shipp->ship_info_index < 0) || (shipp->ship_info_index >= Num_ship_types)){
return 0;
}
if((shipp->ai_index < 0) || (shipp->ai_index >= MAX_AI_INFO)){
return 0;
}
sip = &Ship_info[shipp->ship_info_index];
aip = &Ai_info[shipp->ai_index];
if ( swp->num_primary_banks <= 0 ) {
return 0;
}
if ( swp->current_primary_bank < 0 ){
return 0;
}
sound_played = -1;
// Fire the correct primary bank. If primaries are linked (SF_PRIMARY_LINKED set), then fire
// both primary banks.
int num_primary_banks;
if ( shipp->flags & SF_PRIMARY_LINKED ) {
num_primary_banks = swp->num_primary_banks;
} else {
num_primary_banks = min(1, swp->num_primary_banks);
}
Assert(num_primary_banks > 0);
if (num_primary_banks < 1){
return 0;
}
// if we're firing stream weapons, but the trigger is not down, do nothing
if(stream_weapons && !(shipp->flags & SF_TRIGGER_DOWN)){
return 0;
}
for ( i = 0; i < num_primary_banks; i++ ) {
bank_to_fire = (swp->current_primary_bank+i)%2; // Max supported banks is 2
weapon = swp->primary_bank_weapons[bank_to_fire];
Assert( weapon >= 0 && weapon < MAX_WEAPONS );
if ( (weapon < 0) || (weapon >= MAX_WEAPON_TYPES) ) {
Int3(); // why would a ship try to fire a weapon that doesn't exist?
continue;
}
weapon_info* winfo_p = &Weapon_info[weapon];
// if this is a targeting laser, start it up ///- only targeting laser if it is tag-c, otherwise it's a fighter beam -Bobboau
if((winfo_p->wi_flags & WIF_BEAM) && (winfo_p->tag_level == 3) && (shipp->flags & SF_TRIGGER_DOWN) && (winfo_p->b_info.beam_type == BEAM_TYPE_C) ){
ship_start_targeting_laser(shipp);
}
// if we're firing stream weapons and this is a non stream weapon, skip it
if(stream_weapons && !(winfo_p->wi_flags & WIF_STREAM)){
continue;
}
// if we're firing non stream weapons and this is a stream weapon, skip it
if(!stream_weapons && (winfo_p->wi_flags & WIF_STREAM)){
continue;
}
// only non-multiplayer clients (single, multi-host) need to do timestamp checking
if ( !timestamp_elapsed(swp->next_primary_fire_stamp[bank_to_fire]) ) {
if (timestamp_until(swp->next_primary_fire_stamp[bank_to_fire]) > 5000){
swp->next_primary_fire_stamp[bank_to_fire] = timestamp(1000);
}
have_timeout = 1;
continue;
}
//nprintf(("AI", "Time = %7.3f, firing %s\n", f2fl(Missiontime), Weapon_info[weapon].name));
// do timestamp stuff for next firing time
float next_fire_delay = (float) winfo_p->fire_wait * 1000.0f;
if (!(obj->flags & OF_PLAYER_SHIP) ) {
if (shipp->team == Ships[Player_obj->instance].team){
next_fire_delay *= Ship_fire_delay_scale_friendly[Game_skill_level];
} else {
next_fire_delay *= Ship_fire_delay_scale_hostile[Game_skill_level];
}
}
next_fire_delay *= 1.0f + (num_primary_banks - 1) * 0.5f; // 50% time penalty if banks linked
// MK, 2/4/98: Since you probably were allowed to fire earlier, but couldn't fire until your frame interval
// rolled around, subtract out up to half the previous frametime.
// Note, unless we track whether the fire button has been held down, and not tapped, it's hard to
// know how much time to subtract off. It could be this fire is "late" because the user didn't want to fire.
if ((next_fire_delay > 0.0f)) {
if (obj->flags & OF_PLAYER_SHIP) {
int t = timestamp_until(swp->next_primary_fire_stamp[bank_to_fire]);
if (t < 0) {
float tx;
tx = (float) t/-1000.0f;
if (tx > flFrametime/2.0f){
tx = 1000.0f * flFrametime * 0.7f;
}
next_fire_delay -= tx;
}
if ((int) next_fire_delay < 1){
next_fire_delay = 1.0f;
}
}
swp->next_primary_fire_stamp[bank_to_fire] = timestamp((int)(next_fire_delay));
if ((winfo_p->wi_flags & WIF_BEAM) && (winfo_p->b_info.beam_type == BEAM_TYPE_C))// fighter beams fire constantly, they only stop if they run out of power -Bobboau
swp->next_primary_fire_stamp[bank_to_fire] = timestamp();
}
// Here is where we check if weapons subsystem is capable of firing the weapon.
// Note that we can have partial bank firing, if the weapons subsystem is partially
// functional, which should be cool.
if ( ship_weapon_maybe_fail(shipp) && !force) {
if ( obj == Player_obj ) {
if ( ship_maybe_play_primary_fail_sound() ) {
}
}
continue;
}
polymodel *po = model_get( Ship_info[shipp->ship_info_index].modelnum );
if ( po->n_guns > 0 ) {
int num_slots = po->gun_banks[bank_to_fire].num_slots;
if(winfo_p->wi_flags & WIF_BEAM){ // the big change I made for fighter beams, if there beams fill out the Fire_Info for a targeting laser then fire it, for each point in the weapon bank -Bobboau
// fail unless we're forcing (energy based primaries)
if ( (shipp->weapon_energy < num_slots*winfo_p->energy_consumed*flFrametime) && !force) {
swp->next_primary_fire_stamp[bank_to_fire] = timestamp(swp->next_primary_fire_stamp[bank_to_fire]);
if ( obj == Player_obj ) {
if ( ship_maybe_play_primary_fail_sound() ) {
}
}
continue;
}
// deplete the weapon reserve energy by the amount of energy used to fire the weapon and the number of points and do it by the time it's been fireing becase this is a beam -Bobboau
shipp->weapon_energy -= num_slots*winfo_p->energy_consumed*flFrametime;
beam_fire_info fbfire_info;
//int j = (timestamp()/100)%num_slots; // fireing point cycleing for TBP
for ( int j = 0; j < num_slots; j++ ){
fbfire_info.accuracy = 0.0f;
fbfire_info.beam_info_index = shipp->weapons.primary_bank_weapons[bank_to_fire];
fbfire_info.beam_info_override = NULL;
fbfire_info.shooter = &Objects[shipp->objnum];
fbfire_info.target = NULL;
fbfire_info.target_subsys = NULL;
fbfire_info.turret = NULL;
fbfire_info.targeting_laser_offset = po->gun_banks[bank_to_fire].pnt[j];
beam_fire_targeting(&fbfire_info);
//shipp->targeting_laser_objnum = beam_fire_targeting(&fire_info);
}
}else{ //if this insn't a fighter beam, do it normaly -Bobboau
//Assert (!(winfo_p->wi_flags & WIF_BEAM))
// fail unless we're forcing (energy based primaries)
if ( (shipp->weapon_energy < num_slots*winfo_p->energy_consumed) && !force) {
swp->next_primary_fire_stamp[bank_to_fire] = timestamp(swp->next_primary_fire_stamp[bank_to_fire]);
if ( obj == Player_obj ) {
if ( ship_maybe_play_primary_fail_sound() ) {
}
}
continue;
}
// deplete the weapon reserve energy by the amount of energy used to fire the weapon
shipp->weapon_energy -= num_slots*winfo_p->energy_consumed;
// Mark all these weapons as in the same group
int new_group_id = weapon_create_group_id();
for ( j = 0; j < num_slots; j++ ) {
pnt = po->gun_banks[bank_to_fire].pnt[j];
vm_vec_unrotate(&gun_point, &pnt, &obj->orient);
vm_vec_add(&firing_pos, &gun_point, &obj->pos);
// create the weapon -- the network signature for multiplayer is created inside
// of weapon_create
weapon_objnum = weapon_create( &firing_pos, &obj->orient, weapon, OBJ_INDEX(obj),0, new_group_id );
weapon_set_tracking_info(weapon_objnum, OBJ_INDEX(obj), aip->target_objnum, aip->current_target_is_locked, aip->targeted_subsys);
// create the muzzle flash effect
shipfx_flash_create( obj, shipp, &pnt, &obj->orient.fvec, 1, weapon );
// maybe shudder the ship - if its me
if((winfo_p->wi_flags & WIF_SHUDDER) && (obj == Player_obj) && !(Game_mode & GM_STANDALONE_SERVER)){
// calculate some arbitrary value between 100
// (mass * velocity) / 10
game_shudder_apply(500, (winfo_p->mass * winfo_p->max_speed) / 10.0f);
}
num_fired++;
}
}
if(shipp->weapon_energy < 0.0f){
shipp->weapon_energy = 0.0f;
}
banks_fired |= (1< // mark this bank as fired.
}
// Only play the weapon fired sound if it hasn't been played yet. This is to
// avoid playing the same sound multiple times when banks are linked with the
// same weapon.
if ( sound_played != winfo_p->launch_snd ) {
sound_played = winfo_p->launch_snd;
if ( obj == Player_obj ) {
if ( winfo_p->launch_snd != -1 ) {
weapon_info *wip;
ship_weapon *swp;
// HACK
if(winfo_p->launch_snd == SND_AUTOCANNON_SHOT){
snd_play( &Snds[winfo_p->launch_snd], 0.0f, 1.0f, SND_PRIORITY_TRIPLE_INSTANCE );
} else {
snd_play( &Snds[winfo_p->launch_snd], 0.0f, 1.0f, SND_PRIORITY_MUST_PLAY );
}
// snd_play( &Snds[winfo_p->launch_snd] );
swp = &Player_ship->weapons;
if (swp->current_primary_bank >= 0) {
wip = &Weapon_info[swp->primary_bank_weapons[swp->current_primary_bank]];
joy_ff_play_primary_shoot((int) ((wip->armor_factor + wip->shield_factor * 0.2f) * (wip->damage * wip->damage - 7.5f) * 0.45f + 0.6f) * 10 + 2000);
}
}
}
else {
if ( winfo_p->launch_snd != -1 ) {
snd_play_3d( &Snds[winfo_p->launch_snd], &obj->pos, &View_position );
}
}
}
} // end for (go to next primary bank)
// if multiplayer and we're client-side firing, send the packet
// if((Game_mode & GM_MULTIPLAYER) && (Netgame.debug_flags & NETD_FLAG_CLIENT_FIRING)){
if(Game_mode & GM_MULTIPLAYER){
// if i'm a client, and this is not me, don't send
if(!(MULTIPLAYER_CLIENT && (shipp != Player_ship))){
send_NEW_primary_fired_packet( shipp, banks_fired );
}
}
// post a primary fired event
if(Game_mode & GM_DEMO_RECORD){
demo_POST_primary_fired(obj, swp->current_primary_bank, shipp->flags & SF_PRIMARY_LINKED);
}
// STATS
if (obj->flags & OF_PLAYER_SHIP) {
// in multiplayer -- only the server needs to keep track of the stats. Call the cool
// function to find the player given the object *. It had better return a valid player
// or our internal structure as messed up.
if( Game_mode & GM_MULTIPLAYER ) {
if ( Net_player->flags & NETINFO_FLAG_AM_MASTER ) {
int player_num;
player_num = multi_find_player_by_object ( obj );
Assert ( player_num != -1 );
Net_players[player_num].player->stats.mp_shots_fired += num_fired;
}
} else {
Player->stats.mp_shots_fired += num_fired;
}
}
return num_fired;
}
-
from the read function the binary file format is
struct HullLightPoint
{
vector point; //bank->pnt[j]
vector norm; //pant->norm[j]
vector radius; //bank->radius[j]
};
struct HullLights // pm->glows[q]
{
int disp_time; //bank->disp_time
int on_time //bank->on_time
int off_time; //bank->off_time
int obj_parent; //bank->submodel_parent
int LOD; // bank->LOD
int num_Lights; // bank->num_slots
HullLightPoint* lights;
};
struct GLOW
{
int num_glows_arrays; // pm->n_glows
HullLights *lights; //pm->glows
};
all i need to know: how does FreeSpace 2 handle unknown chunks? does it skip them? you';re the one that's been playing aronud in that section of the code
or atleast where is that code
becasue if i read my own code correctly [it's been a year since i wrote this code!] the POF Chunk header is
4-byte ASCII chunk ID
then
4-byte int length
-
oh bobboau i need to talk to you on ICQ or Yahoo if you have it
and INQUISTITOR TOO
if i add this chunk to POF Constructor Suite i want it to be added to the official fs2_open
-
ok i found the volition code
default:
mprintf(("Unknown chunk <%c%c%c%c>, len = %d\n",id,id>>8,id>>16,id>>24,len));
cfseek(fp,len,SEEK_CUR);
break;
}
if i read that correctly it skips unkown chunks
-
K, post the code, fighter beams is something people are hot for.
I'll edit it in myself if I have to ;)
37097749 is my ICQ. I just had a power outage, so I got knocked offline for a while (need to find a way to back up the power to the cable in my 'hood ;)).
-
I think I see two errors in that
struct HullLightPoint
{
vector point; //bank->pnt[j]
vector norm; //pant->norm[j]
float radius; //bank->radius[j] <<<< float not vector
};
struct HullLights // pm->glows[q]
{
int disp_time; //bank->disp_time
int on_time //bank->on_time
int off_time; //bank->off_time
int obj_parent; //bank->submodel_parent
int LOD; // bank->LOD
int num_Lights; // bank->num_slots
HullLightPoint* lights;
int glow_bitmap;//bank->glow_bitmap <<<< don't forget this it goes to the texture index of the texture used by this bank
};
struct GLOW
{
int num_glows_arrays; // pm->n_glows
HullLights *lights; //pm->glows
};
I guess I should have mentioned this diference to the internal thruster structure, were the thruster code has the subsystem string for the engine it belongs to, my loading code expects to find the name of a texture file, in this format
$glow_texture=xxx
xxx is the name of the texture file, with no extension
it then loads it and puts the texture index number into bank->glow_bitmap
unknown chunks look like they have an mprintf error mesage wich I think gets knocked out in relese builds, then it looks at the next chunk
so basicly it ignors them
oddly enough :), pof loading is covered in the read_model_file function in ModelRead.ccp
edit: I need to type faster :rolleyes:
another edit: and I don't remember if that is the only change I made for the new fighter beam code or not, but I think it is
-
I just cleaned house and reinserted that code and the crashing bug died, unfortunately I forgot to post the glow point blink code so I have to remember how I did it
-
I'm uploading a new copy of the FS3.exe, the blink code still isn't working again, but the fighter beam code is and it doesn't crash with capships,
note I made one small change that I havn't tested yet if the game crashes after a ship gets killed by a fighter beam, this is what is causeing it, but if fighter beam kills are now being recorded it means I found the bug in that :)
only thing I think I have to fix yet is the sound code, make it a real looping beam sound
-
Originally posted by Bobboau
I'm uploading a new copy of the FS3.exe, the blink code still isn't working again, but the fighter beam code is and it doesn't crash with capships,
note I made one small change that I havn't tested yet if the game crashes after a ship gets killed by a fighter beam, this is what is causeing it, but if fighter beam kills are now being recorded it means I found the bug in that :)
only thing I think I have to fix yet is the sound code, make it a real looping beam sound
w00t! good work man, keep it up!
-
So, are you gonna post your source as well?
Or is it all here in this thread?
-
i need to know the ASCII 4-byte for the GLOW's ID
[if you paste the #DEFINE ID_GLOW .....] that would work
-
Originally posted by Kazan
i need to know the ASCII 4-byte for the GLOW's ID
[if you paste the #DEFINE ID_GLOW .....] that would work
This is the "little-endian" (Intel) version, which I assume you want:
#define ID_GLOW 0x574f4c47 // WOLG (GLOW): glow points -Bobboau
-
ty, i also just got it on ICQ
btw. im adding it to as output priority 16, and moving PINF to output priority 17 therefor the chunk output priority is now
POF Constructor Suite:POFDataStructs.h
/* Chunk output priority
1 TXTR
2 HDR2
3 OBJ2
4 SPCL
5 GPNT
6 MPNT
7 TGUN
8 TMIS
9 DOCK
10 FUEL
11 SHLD
12 EYE
13 ACEN
14 INSG
15 PATH
16 GLOW // fs2_open chunk, technically not part of version 2117
17 PINF */
-
Originally posted by Bobboau
I guess I should have mentioned this diference to the internal thruster structure, were the thruster code has the subsystem string for the engine it belongs to, my loading code expects to find the name of a texture file, in this format
$glow_texture=xxx
xxx is the name of the texture file, with no extension
it then loads it and puts the texture index number into bank->glow_bitmap
tell me that's in the ships.tbl, because the TXTR chunk is EXPLICITLY for the textures indexed in the BSP data in the OBJ2 and to use it for the GLOW data would make it so i have to allow people to change the number of textures, which is needless to say EXTREMELY HAZARDOUS
how about we change
"int glow_bitmap"
to
"POFString glow_bitmap"
[POFString is defined as 4-byte int length + length chars with no null-terimnator]
-
int glow_bitmap is internal to FS in the POF file it is the same as whatever the string in the thruster section is is what this should be
no I'm not useing the model texture list, though it might be a good idea to do that way, as I have the loading code now the texture name is in the GLOW chunk,
if you have the three test models I was useing and you rename the GLOW chunk to FUEL (and remove the FUEL chunk already in the model) you can open it as thruster data, and see everything
the data structure should be basicly the same as the thruster code but wth a few added ints
-
doh. it's already that way, ie in my structures where i have int glow_bitmap i need to have string properties! gotcha! bingo!
that just leaves one thing - what's the default glow texture
-
I didn't set a defalt, if the code can't find the texture it just sets the index as -1, and gives an error mesage, if you want a default to put into the dialog just do the $glow_texture= and leave it without a file name
-
im going to make the default thrusterglow01
-
ya, that'd be a good one
-
now that i think of it this would be one hell of an easy thing to add into the COB hierarchy, once i get the POF Class GLOW functions finished AUTOGLOW HERE WE COME :P
-
So.....can we make them blink? :D
-
ask bobboau, from the data it looks like YES
-
I had it working untill yesterday, when I accidentally eraesed all the blinking code :headz:
I just have to remember wich timestamp function I used
-
A couple little suggestions, which may or may not be easy to implement...
1) When a ship's hull strength drops to the level where it starts arcing, flicker any lights randomly.
2) If the on or off delay is a negative value, interpret it as the maximum time for a random delay.
-
damned blinking code, it took me five minutes to rewrite it, and five hours to figure I forgot the damn "if (bank->is_on)" before the rendering code
**beats head for being such a moron**
anyway
1) no problem
2) sound like a good idea
-
regarding blinking lights, are there any chance that we can put some values into the Glow sections, such as
Delay; how long before this light triggers
delay because, that would make an easy way to make running lights. They would however run all the time.
i dont know about all of you, but i think its plain stupid to have lights going on and off, in the middle of a battle.
In a nebula, that would double. ("like here i am, shoot me")
so maybe a new SEXP is needed here like
when (missiontime)
do (AI_DONT_BLINK)
data ("SHIP")
data ("SHIP2)
data ("wing")
data("wing2").
and a vice verca SEXP like AI_BLINK_AGAIN.
but neither should be bound to AI orders since you cant order player ships anything.
and and and, sorry :)
well, but could you make sure those lights dont blink or give light when the ship is playing dead, like the addition i made, and will upload soon to CVS like rotating sections not to rotate when playing dead.
btw made the knossos device accept play_dead order so you can have the effect of turning it off and on.
the playing death thing should be easy to implement.
-
that is how it is being done, basicly,
the test models I made wern't very good implementations (well the Ulysses was fairly good) the glows shouldn't be nearly as big as they were
-
OK uploading a new vertion, the glows blink one second on 1/2 seconds off, default testing values, these will be things loaded from the POF soon,
big reason for the upload I have implemented the busted up ship flicker code, when a ship is damaged and the electrical arcs are spurting the glows flicker, very cool looking, sort of hard to see though with how much blinking is going on though
-
that sounds really great :)
mmh, can't really go through all the thread for now, so what are the drawbacks ( I mean what still won't work, or will something crash )?
-
any chance for sequenced blinking lights? so that we can make the orion runway light up they way they have it in the cutscenes?
-
do the lights actually cast light into the scene?
ie if your righter goes past a green light on a carrier it casts a green glow on you
-
I havn't made the dynamic lighting yet, but I guess we should get the POF specs redy for it
int pos
int rad
vect rgb
int intensity
for each bank
I'll have to make some sort of light culling code, cause this will be a monster procesor hit with that many lights
-
I hope the lights aren't dynamic. Having, say, every single light in a runway strip calculated as a dynamic light source would murder the frame rate. Plus there would be the complication of making sure a light didn't cast onto the ship it was attached to. FS2's lighting model just isn't good enough for this to look right. Anyway, running lights in real life aren't supposed to illuminate anything besides themselves. They're really not that bright.
Regarding the issues with turning the lights on and off, how hard would it be to add an untargetable "Lights" subsystem?
-
forget the dynamic lights, zylon is right, too much of a hit
[and yes they would hit the ship casting them[
-
well I would only think a handfull of them would be, anyway I don't realy want this myself
-
ok seeing as we have that other thread to discus glow points, can we discus fighter beams again
-
aye
-
OK boys and girls I am now going to try and get beam sheild hit code working
I must like pain :nod:
-
hey I got it too work, cool
I have to do a bit more work and I'll post an update, bunch of debugging code I have to coment out and have to figure why it isn't rendering sheild hits
-
just updated it, sheild hit code... sort of works
some times it flairs up some times it doesn't
it always hit's the sheild and drains the right quadrint
I stoped the beam wack for beam-sheild colisions, becase I wanted too
-
Hmmmm. Is there anywhere that you can upload your changed code files? I'm assuming that we are talking about several files and a lot of code that had to be modified, so it might be easier to just download your actual cpp files from somewhere and look at them than to ask you to post the code you added/changed.
Either way, I'm really curious how you finally worked the beams out and how you got the beams to strike shields in the right place.
-
Cool!
By the way, Bobbaou, have you gotten the fighter beams to drain weapons energy yet?
-
I've had them draining energy for quite some time now, and in this version I think the energy draining is the best it drains energy per second, as oposed to energy per frame as my earlier code did
the only major thing I'd like to change in the code is how it handles sound effects
-
Oh good. I must have missed that bit of news somewhere along the way. :)
-
ba-da bump this thread because it has the GLOW specs - time to go BUG HUNT in POF CS
-
remember I added a type specifier along with the other things in the light groupe structure
sorry my keybord is sticky today
-
what
-
this (http://freespace.volitionwatch.com/blackwater/newglowfs.zip) has two pofs with the correct glow format
glow groupes have
on time
off time
displacement time
LOD
submodel parent
and now type
these are all ints
-
to be specific, the chunk when veiwed raw (like with a hex editor) is now
(4 bytes) ID //the chunk name, GLOW
(4 bytes) int /size //the size of the rest of the chunk
(4 bytes) int /number of light groupes //how many light groupes are in this model
[for each light groupe]
(4 bytes) int /displacement time //amount of time that this groupe will be displaced from 0
(4 bytes) int /on time //how long this groupe will be on
(4 bytes) int /off time //how long this groupe will be off
(4 bytes) int /object parent //the subobject number that will be asosiated with this groupe, used for linking to destroyable subobject and rotating submodel-not implemented
(4 bytes) int /LOD //how far away will this glow be visable
(4 bytes) int /type //what rendering type, so I can make normal glows and ones that render like a beam<-something I rescently added and isn't in the format listed in this topic
(4 bytes) int /number of points //number of points int this groupe
(4 bytes) int /str length //number of charicters in the preperty string
(str length bytes) char /properties// the properties string, ie "$glow_texture=$thrusterglow01"
[for each point]
{vector} /pos //the position of the glow point
(4 bytes) float /x
(4 bytes) float /y
(4 bytes) float /z
{vector} /normal //the direction the glow point is pointing
(4 bytes) float /x
(4 bytes) float /y
(4 bytes) float /z
(4 bytes) float /radius/ the radius of the glow point
]next point[
]next groupe[
so the structure is (chunk header (ID and size) +) 1 int + (the groupe structure wich is 7 ints, 1 string (an int and as many chars as that int says), + (the points structure wich is 2 vectors (3 floats each) and a float) * number of points in the groupe)* number of groupes
struct HullLightPoint
{
vector point;
vector norm;
float radius;
};
struct HullLights
{
int disp_time;
int on_time;
int off_time;
int obj_parent;
int LOD;
int type;
int num_Lights;
string properties;
HullLightPoint* lights;
HullLights() : disp_time(0), on_time(0), off_time(0), obj_parent(0), LOD(0), num_Lights(0), lights(0), type(0) {}
};
struct GLOW
{
int num_glows_arrays;
HullLights *lights;
};
-
doh.. figured out the crashing - PCS code for it works correctly now - couple general bugs, the crashing was because i was forgetting to add 4 bytes to the chunk size for the num_glow_arrays - i've merged your "int type" into the structure in PCS and im going to add it to the GUI after I get back from Geology...
-
oh... i commited the working GLOW code to CVS last night.
-
much more stable than the last build, but it still has the bug that I had in my "fix", to see what I mean open up the fighter01.pof in that zip I posted, then open up any other pof, it'll crash, or at least it did for me, it's good enough for now though
-
what bug are you talking about.. i couldn't make sense of your babling
-
after opening a model with glow points (more so with more of them) upon opening another file, or saveing more than once, it crashes,
to see what I mean open one of the two pofs in this (http://freespace.volitionwatch.com/blackwater/newglowfs.zip) zip and then open the other
-
POF CS has _ALWAYS_ crashed when trying to unload/load a new POF.. the POF::Reset() function apparently isn't unloading the data cleanly enough
-
it has!?! :wtf:
*loads up v0.98*
*loads a model*
*loads another*
*notes PCS does not crash*
no it hasn't
-
ok.. w/e i'll hgave to try and find what is crashing