[WMCoolmon]

Originally posted by Bobboau
don't forget some waepns should be getting shot at (bombs)

and while your looking at it, could you see how much work would be involved to implement interceptors, weapons designed to nutralise incomeing weapons fire. a weapon flag should enable interceptor weapons to colide with any other weapon, and make the AI prioritise incomeing weapons fire.

I don't think it'd be a whole lot of work. The same functions that handle bombs could be used instead of interceptor weapons, and making turrets shoot at them should just be a matter of specifying any weapons with the interceptor flags as valid targets.

[Bobboau]

well it isn't the interceptor that gets shot at, it's the interceptor that does the shooting, a turret with an interceptor weapon on it should target the most dangerous weapon of any kind that it can find.

[Grug]

Is this a D3D primary build, OGL or both?

-Ta

Update:
Woah, few buggies.
Though I found there did seem to be a bit of a perfomance increase.
 But as you can see, a few other bugs show up:
Piccy

That's running in OGL, the numbers seem to render below the player ship.
More saddening however is that in OGL and D3D, the weapon effects are chopped in half when in Alt-Pause mode. So I goto try and take a screenshot, and the effects are chopped in half if the camera is close.
At a longer distance however, it appears that they are normal.
I think they work ok from the cockpit view too.

I need a screenshot build...

[Singh]

Ok, tried this build and its somewhat stable. However, I keept getting random crashes related to sound bits sometimes.

Also, any mission using the cutscene sexp's CTDs giving a program error once I try to hit commit and launch itno the mission  (there is no problem during loading at all)

I've yet to try it with another build though, so it may be something else. Also, these sexps were from the latest FRED build, where I used the menu stuff rather than doing it via notepad.

[WMCoolmon]

Yeah, Jake101 had the same problem - turns out I did something exceptionally stupid. Something like:

Code: [Select]


if(in_rotation_rate == NULL)
  rotation_rate = *in_rotation_rate;
else
  vm_vec_zero(&rotation_rate);


In english: "If rotation rate is an invalid pointer that is sure to cause FS2 to crash if it is accessed, then access it and set the rotation rate to its value. Otherwise, set the rotation rate to 0."

[StratComm]

Whoops, a little backwards in your code logic there.  I still do that from time to time, so I completely understand how that kind of bug gets introduced.

[Singh]

well, its prevalant from the 0306b build onwards (the earliest I have). Any chance of fixing it anytime soon? I really need to use the missions ASAP :/

Another random crash: whenever I am about to die (i.e. hull 1% all systems 0), it will crash immediatelybefore giving me the death message at all. Rather odd :/

[WMCoolmon]

Yeah, I'll try to remember to upload the release build I made to test it.

[WMCoolmon]

http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip

[Singh]

ok, it stopped crashing for me now, but another bug popped up instead.

After the first scene, when the sexp calls for camera movement of any sort, it'll move for a split-second before resetting itself to the first view. No matter how many camera changes I have after that, it will reset itself to the first view.

The error appears to be in set-camera-facing, since set-camera position seems to work allright.

really, really odd though, to say the least :/

[WMCoolmon]

Does the same problem happen with set-camera-rotation?

[Trivial Psychic]

Originally posted by WMCoolmon
http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip

Most stable build recently.  Good job, and nice that you included Bob's new warp effects.

[Singh]

Originally posted by WMCoolmon
Does the same problem happen with set-camera-rotation?

Haven't tried yet, will do so by today.

[Trivial Psychic]

OK.  I've found a bug with the "ex" build (and possibly others before, I don't get the chance to test too often).  As you can see from the pic below, the targetting of jumpnodes gives and out-of-position result for the targetbox.  I also had this when targetting a sentry gun, (which I gave a cruiser AI so it could mount HUGE weapons).


Also, some of you may have noticed that I'm using a non-standard jumpnode model.  This is one Bob released when node rendering was switched to HTL.

[WMCoolmon]

Is this only for certain ship types, or with everything that you target.

Also, are you using a different FOV from normal or have an odd screen size?

[StratComm]

That node looks horrible.  Way too busy.  If you don't want to use the one Raa made (IIRC) I released one that was closer to standerd, but I thought HTL had been fixed to use the old node anyway.

[Goober5000]

Originally posted by StratComm
I thought HTL had been fixed to use the old node anyway.

[Trivial Psychic]

I've only noted this on the jumpnode and on said sentry gun.  I am using no perspective-altering command lines, and resolution is 1024/768.  It should be noted however, that prior to this, targetting a jumpnode, (since the model was first HTL-ised), always resulted in the target box being very small compared to the node... though in the correct spot.

As for why I use this node model, I like it.  Its actually got an inner sphere too.

[Singh]

Originally posted by WMCoolmon
Does the same problem happen with set-camera-rotation?

set-camera-rotation is even more screwed up. Teh viewpoint jumps all over the place instead of to the way I want it. It's damn scary, to say the least