[Bobboau]

SubSpace Missle discusion

I have just implemented tag-C as SSM makers

I plan on makeing the SSM index number were the tag time currently goes, and an SSM lock time right after that

any fighter beam needs to have the tag value set as 3 in order for it to work as a targeting beam

any missle with tag level 3 will create a SSM

remember it's right here

code change was

Code: [Select]


} else if (Weapon_info[Weapons[other_obj->instance].weapon_info_index].tag_level == 3) {

struct ssm_firing_info;
extern void ssm_create(vector *target, vector *start, int ssm_index, ssm_firing_info *override);

HUD_printf("Firing artillery");

vector temp;
vm_vec_unrotate(&temp, &ship_obj->pos, &Objects[other_obj->instance].orient);
//vm_vec_add2(&temp, &Objects[aip->artillery_objnum].pos);
ssm_create(&temp, &Objects[ship_obj->instance].pos, 0, NULL);


in
ship_apply_local_damage
in
shiphit.ccp
look for the tag stuf you should be able to figure out were it goes
this was just a quick test, and I have only done some minor testing,
and it has all the other changes I have made to date

[##UnknownPlayer##]

I agree with reviving the tag-C as an SSM implementation (doesn't mess with the original campaign). When this is done we should put it on the CVS.

[penguin]

nice work (again) Bobboau

Minor (somewhat off-topic) suggestion:  use XSTR in any HUD_printf function call -- that will make it easier when we start doing that internationalization thang...  Also, most of the in-game HUD messages use HUD_sourced_printf() not that it makes any difference...

Code: [Select]


HUD_sourced_printf(HUD_SOURCE_HIDDEN, XSTR( "Firing artillery", 1570));
Caveat: as usual I am suggesting things without trying them out myself I don't know for sure what will happen if you reference an XSTR ID thats not in strings.tbl... from looking at the code, it appears to check to see if the index is less than XSTR_SIZE; if not, it returns the original string.

[Inquisitor]

Before this is done, we should put it in CVS.

That's what CVS is for

[IceFire]

Yay!  This is an integral feature of PS

[WMCoolmon]

Added to the fs2_open module; checking now to see that it works with pengiun's suggestion

[Bobboau]

OK I just uploaded a new revision, including new tables that have two examples of how to use the new SSM code, the old targeting laser and tag C , you will see an SSM index number at the botom of these entrys this is the table entry in the SSM table, so now you can specify wich SSM strike definition you want to use, also I think I got the tag time to be the lock time for the targeting laser but I don't remember if I did that or if it was diferen't in the tests

[Bobboau]

alright I am going to look into seperating the targeting lasers from the primary weapons system (I will leave the option of setting a targeting laser as a weapon, and they will still be defined in the weapons.tbl, this is basicly like a thrid primary bank for specal targeting systems), currently I am planing on adding a little hud gauge just above the weapons gauge with a lable "targeting" or "TAG" would like some sudjestions on what to lable this, something short
the selected targeting system and the lock time will be displayed in this new gauge, I'll also be adding interface to the weapons select screen

I'm doing all of this becase I am planing on doing lots of cool things with targeting lasers

[Bobboau]

hmmm, would someone try and explain the whole hud system, I think I've goten it to the point were I need to initialize HC_gauge_regions

what in the name of Hades is all the HCB stuff and how does the  HC_gauge_region stuct work

[##UnknownPlayer##]

A note on XSTR - don't both with it if you don't want to edit the string files. Just supply a string literal and it'll be fin, XSTR is a localization function.

[penguin]

Originally posted by ##UnknownPlayer##
A note on XSTR - don't both with it if you don't want to edit the string files. Just supply a string literal and it'll be fin, XSTR is a localization function.

This is true, but I am hoping we can eventually get some other language ports; both Japanese and French have been requested.  Adding the XSTR  is failrly painless now; however, when someone does start working on the other languages, going back and looking for all the text strings that we added will be a pain.

If the string is not in strings.tbl, the text in the XSTR function call will be used, so nothing breaks.  It's called planning for the future

[Inquisitor]

Agree with penguin. Lets stay compatible with localization stuff.

[penguin]

Originally posted by Bobboau
hmmm, would someone try and explain the whole hud system, I think I've goten it to the point were I need to initialize HC_gauge_regions

what in the name of Hades is all the HCB stuff and how does the  HC_gauge_region stuct work

hudconfig.cpp is for the HUD configuration screen -- the one you get to from the main Options screen -- so the player can pick on/off/popup and colors for the HUD gauges.

All the HCB_nn are the "HUD Config Buttons" -- the UI elements when you are in the HUD config options page.  Open up sparky.vp in VPViewer and look in the data/interface folder... all those HCB_*.pcx files are the buttons and the static versions of the HUD gauges; they're only used on this screen (ie they're not the real in-game gauges -- those are all in the data/hud folder and are mostly .ani files).

The HC_gauge_region struct just tells the UI where to draw all the HUD images when you're in the config screen.  It also has other info -- use IFF color (eg, for the lead indicator) instead of the player-selected color, etc.

You probably don't need to mess with this unless you're adding a new HUD gauge..

[Bobboau]

...I'm adding a new hud guage

and I just five minutes ago figured out what all that was, I didn't see the little definition