[RandomTiger]

Is that a fs2_open bug or original release bug?

[Goober5000]

This got lost in the shuffle first time around...

Originally posted by Goober5000
Couldn't [the ship trails compatibility] be fixed by having the parsing routine set the ship trail flag when it sees a nebula mission?

And why doesn't fs2_open work with the old player files?

[Righteous1]

And why doesn't fs2_open work with the old player files?

There have been additions to the key mappings (slide keys).  Using old pilots may result in crashes with the new exe.  It's best to create a new pilot.

[Goober5000]

Can't they implement backwards compatibility, and save the old pilot in the new format?

[Inquisitor]

No, we can't. Unlesss you want to write a program to convert them

[DTP]

Originally posted by GalacticEmperor
Argh. Apparently when you fixed the secondary weapon firing time inheritance, you broke something... because after I fire the last missile in my first secondary bank, the first missile in my second bank fires immediately afterwards. Perhaps the inheritance was in there for a reason. The best fix I can think of is setting it to a mandatory 1 second delay when switching banks instead of inheriting the previous delay.

weird, thought i took care of that, should however only be a problem with dumbfire missiles or in other words. missiles without the "no dumbfire" tag.

one question, GM. Does the missiles have something less that 250 ms of fire delay.

looking at it again.
-------
edit just tested hornet and trebuchet, seems to be no problems.
tested varios setups ,linking etc etc.

need more info, what kind of missiles where you using GM?

[DTP]

Originally posted by EdrickV


I bet the key isn't getting reset fast enough, so the fire function gets called again 'cause it thinks the key is still down. (Without the pause the fire function might get called again within a second.) A pause long enough for the key flag to get reset would be what you would need. (Might need a bit more then one second depending on the computer.)

well, there should be a penalty of 250 ms if next bank has a firewait that have elapsed.

The V programmer who made this "dont know where he had his head at the time" but he did it like this.

Code: [Select]


if ( (obj->flags & OF_PLAYER_SHIP) && (swp->secondary_bank_ammo[bank] <= 0) ) {
int fire_wait = (int)(Weapon_info[weapon].fire_wait * 1000.0f);
if ( ship_select_next_valid_secondary_bank(swp) ) {
swp->next_secondary_fire_stamp[swp->current_secondary_bank] = max(timestamp(250),timestamp(fire_wait));






which is not the way, but we all know that. notice line 2
taking our current weapons fire delay.

i did it like this

Code: [Select]


if ( (obj->flags & OF_PLAYER_SHIP) && (swp->secondary_bank_ammo[bank] <= 0) ) {
//int fire_wait = (int)(Weapon_info[weapon].fire_wait * 1000.0f);
if ( ship_select_next_valid_secondary_bank(swp) ) {
//swp->next_secondary_fire_stamp[swp->current_secondary_bank] = max(timestamp(250),timestamp(fire_wait));
if ( timestamp_elapsed(shipp->weapons.next_secondary_fire_stamp[shipp->weapons.current_secondary_bank]) ) {
shipp->weapons.next_secondary_fire_stamp[shipp->weapons.current_secondary_bank] = timestamp(250);
}



notice, it should block for people getting no penalty when they shift banks.

[Goober5000]

Originally posted by Inquisitor
No, we can't. Unlesss you want to write a program to convert them

Is this the specific bug?
http://www.hard-light.net/forums/index.php/topic,7539.0.html

Looks like someone released a fix already. Has it been added to the CVS repository?

[EdrickV]

Originally posted by Righteous1


There have been additions to the key mappings (slide keys).  Using old pilots may result in crashes with the new exe.  It's best to create a new pilot.

The new key mappings do not seem to cause any crashes with a pilot originally made by the regular program, but if you run the original exe it will strip the new key bindings from all the pilots, even if you don't use a particular pilot. (It might be better to save new key bind data in a seperate file.) However, the original exe should not affect any pilot files in -mod directories. (Since it doesn't know about them.) An easy way to make a "clean" pilot would be to take a regular pilot, set them to the main FS2 campaign and then reset the campaign so that they have not flown any missions and have no kill data. That is what all my current fs2_open pilots are made from. (Said pilot originally was copied from my Robotech MOD install, but all the known problematic data was removed by resetting it's campaign status.)

[Sesquipedalian]

Agreed.  In my experience, pilot problems seem to be connected to campaign progress.

[LtNarol]

Any chance we can get the ships.tbl limits bumped up to 200-250 entries with about 2mgs worth of characters?  130 entries is gonna be a bit tight...

Also, would it be too much to ask if the limited number of polys per subobject in pofs got bumped up to 2k, with 3k as the max for lod1?  I realize this will be havoc for some older machines, but some larger models really would look better if they could use some more polys; not sure what kind of recoding this would require though.

[Inquisitor]

RIght now, no.

130 is a hard limit, otherwise it breaks multi. We're working on it.

[EdrickV]

Originally posted by LtNarol
Also, would it be too much to ask if the limited number of polys per subobject in pofs got bumped up to 2k, with 3k as the max for lod1?  I realize this will be havoc for some older machines, but some larger models really would look better if they could use some more polys; not sure what kind of recoding this would require though.

There is, AFAIK, no poly limit per submodel. There is, however, a vert limit per submodel, but by splitting the submodel into different parts you can get around that. If those submodels don't have subsystem info, in game it should appear to be one object. I've gotten a currently 1 LoD model, with some turrets, of over 2000 polys into FS2. (Current version of that model is at about 2800 polys right now but needs some fixing due to stuff I did.) I had to split the main hull model to do it, but it converted with PCS and worked in game.

[DTP]

Originally posted by EdrickV


There is, AFAIK, no poly limit per submodel. There is, however, a vert limit per submodel, but by splitting the submodel into different parts you can get around that. If those submodels don't have subsystem info, in game it should appear to be one object. I've gotten a currently 1 LoD model, with some turrets, of over 2000 polys into FS2. (Current version of that model is at about 2800 polys right now but needs some fixing due to stuff I did.) I had to split the main hull model to do it, but it converted with PCS and worked in game.

as a side note; i can add that the Shielded lucifer version downloadble via the fs1port site has 2178 verts and 4361 polygons for the shield mesh alone.

[EdrickV]

Originally posted by DTP


as a side note; i can add that the Shielded lucifer version downloadble via the fs1port site has 2178 verts and 4361 polygons for the shield mesh alone.

Odd, ModelView32 doesn't like the shield mesh but a Debug POFView has no trouble with it. Seems the 1100 vert limit check doesn't count for shields.

[TrashMan]

Questions about FS3_open:

 - Can you have multi-part turrets on the sides of ships?
 - Can turrets have multiple weapons (that actually fire)?
 - Do the lights blink when the capship is heavily hit (if you made the glows than this should be simple to add)?

EDIT: Most importantly: does it work with GeForce 4 Ti 4200?

[DTP]

Originally posted by TrashMan
Questions about FS3_open:

 - Can you have multi-part turrets on the sides of ships?

no, not yet

 - Can turrets have multiple weapons (that actually fire)?

not yet

 - Do the lights blink when the capship is heavily hit (if you made the glows than this should be simple to add)?

as far as i know, no.

EDIT: Most importantly: does it work with GeForce 4 Ti 4200? [/B]

yes just start it like this

fs2_open -GF4FIX

[EdrickV]

Multi-part turrets on the sides of ships do not work. The rotation for multi-part turrets looks like it is hardcoded and thus ignores the submodel rotation info. That means the base will always rotate left/right and the barrels up/down.

[Solaufein]

Then you'd just "use" the barrels as turret base and vice versa?

[EdrickV]

The base still wouldn't rotate right I think. And I think FS2 assumes the normals for multi-part turrets point straight up too, which means the FoV would be screwy. (If you did a 180 FoV, it would consider the center of the FoV to be straight up, which means it might try firing through the hull.) Go ahead and try making some yourself. I don't think you'll be able to get some that work right without some major code changes though. (And the code involved is too convulted for me to follow right now, I don't know enough about how the 3D engine itself works.) Maybe someone will be able to figure it out.