[CaptJosh]

I had another idea last night. How about support for the scrolling wheel most folks seem to have on their mice these days. It would be nice to be able to use it in places where you can scroll up and down through text or through ship and weapons selection when applicable. Not sure if it's feasible. Just a "would be nice" kind of thing.

[Flaser]

Originally posted by Unknown Target
- Dynamic LOD (yes, I'm saying it for the second time in this thread )
--Why? Saves modelers a lot of workload, and improves the game's overall look (and in some cases, performance),

- Being able to make HUD instruments larger or smaller.
--This would probably require a major HUD code overhaul, but it'd be nice if you could make some instruments small, so it gives the appearance that they're actually instruments on the 3D cockpits that we have now.

- No radar lock behind asteroids.
--Something else that would be cool, but require a major overhaul: When a ship passes behind an asteroid, it's disappears from your radar for however long it's behind the asteroid. Would be cool for multiplayer missions.

If we're going into some sort of rudimentary radar simulation:

- Make it so that looking in a different direction won't influence the radar lock. (Every time I check six, the lock goes haywire)

- Heat seakers don't need lock-on; that's all good and dandy - however aspect seekers work on an optical method:
(So it's actually ladar/lidar instead radar)

1) So to lock on, you need a direct line-of-sight (This could be handled reusing the targeting laser code can it?)
2) Once locked on, the computer keeps track of the target (it reads its radar/lidar reading and predicts its movement) - so for a couple of seconds the lock should remain regardless orientation!

3) (1.b) The emphasis on the direct line of sight - so instead merly keeping something in the HUD we could define gimbal limits, so some ships could manage lock on a broader cone of sight.
...or have over-the-shoulder rear fire capacity a'la Firefox.
4) (2.b) Real AWACS/Command ship support: you can targets ships a lot faster if they're within the radar/lidar range of a capship.
5) (2.c) With a capship present you could relay and/or recieve targeting data from the capship. So alpha 3 tags the bandit while the rest of the squad lets loose a curtain of missiles. (Kinda how the F22 Raptors are said to hunt)

[CaptJosh]

On your second point, Flaser, that is not entirely correct.

Some aspect seeing missiles use laser infrared (LIDAR) seeking method and some are radar homers. The AIM-54 Phoenix that my paternal grandfather helped develop comes to mind immediately.

But targeting radar and fire control radar are seperate systems. Fire control radar only looks forward. So it's perfectly possible to have a radar homer lose lock if you turn off target.

However, the aspect seeking missiles in this game stay on target even if you lose lock after firing. That indicates they all have internal guidance once launched.

Therefore, if it's not already included, I would suggest support for missiles that require the pilot to maintain lock on the target in order for the missile to continue to home. This would be quite useful for the purposes of someone creating an atmospheric flying mod for this game.

Of course, at that point, lift would have to be added to the physics so that you couldn't just cut your engines and hang there in the air. Rearming would also be out without landing, though air to air refueling would be an interesting new possibility...Hrm...Now I'm really going to have to learn how to code stuff. I suddenly have an urge to try to figure out how to make a "TOP GUN: Fire at Will" mod for this engine.

[FireCrack]

Originally posted by CaptJosh

Therefore, if it's not already included, I would suggest support for missiles that require the pilot to maintain lock on the target in order for the missile to continue to home. This would be quite useful for the purposes of someone creating an atmospheric flying mod for this game.
 

yes!

Some $notFaF tag for the missiles or somthing lie thqat would be awesome

[Axem]

Ooh ooh, another semi-FRED related one. A change-texture sexp.

[CaptJosh]

Let me guess. Adaptive damage textures, right?

[Axem]

It could be, but that can sorta already be done with damage decals.

Although now that I think about it, it could already be faked by a change-ship-model, and the model is the same just different texture.

[StratComm]

Originally posted by CaptJosh
I had another idea last night. How about support for the scrolling wheel most folks seem to have on their mice these days. It would be nice to be able to use it in places where you can scroll up and down through text or through ship and weapons selection when applicable. Not sure if it's feasible. Just a "would be nice" kind of thing.

That scroll wheel really should be mappable to relative throttle axis.  Any other uses could be, well, mappable, but the fact that it's the perfect control surface for throttle for the mouse-players out there makes that one a no-brainer.

[CaptJosh]

An excellent point, StratComm. It would be a very good relative throttle axis control for folks who use a mouse. Too bad it doesn't map already. Of course, when the game was written, I don't think scrolling mice were common, if even out at the time.

[TrashMan]

Originally posted by CaptJosh


Some aspect seeing missiles use laser infrared (LIDAR) seeking method and some are radar homers. The AIM-54 Phoenix that my paternal grandfather helped develop comes to mind immediately.

didn't know you grandfather made the mean missile
Allways loved the F-14 and everything it came with.

[Nuke]

Originally posted by WMCoolmon


Esplanation?

 id assume the ship classes are associated with a number fof flags and variables which are hard coded, such as turret capability and such, as well as what icons are used.  id like to un-hardcode that info in table form. so you can add custom classes "carrier" for example. im not sure what all cxan be tweaked with this so it might be usefull, but then again it might be a useless waste of time.

a couple othir thigs id like

properly link engine glows to their respective subsystem so when the engine goes out the glows do too. mainly so that if you have a physical engine subsystem it can be shot off and make the engine glows go out.

expand the animation system. add more trigger options, and somehow make a shorthand version so it doesnt eat up so much table space.

[CaptJosh]

Good idea. Especially since I'd like to go through and redo the ship classes so that they actually match up with naval tradition.

[StratComm]

Number of turrets isn't restricted at all, you could give a fighter 100 if the HUD crash wasn't present.  Ship class is primarily associated with AI AFAIK, and has some other uses such as whether or not the ship can be destroyed with standard weapons.  Just about the only useful things I can think of that such custom definitions would allow would be the speed at which an object rotates in the techroom (odd criteria I know, but strangely a dependence) and the ability to add briefing icon classes.  Which could sort of be fixed just by tablizing the briefing icon options themselves.

[mikhael]

Originally posted by Nuke
add more trigger options, and somehow make a shorthand version so it doesnt eat up so much table space.

Bah. Get rid of the monolithic table. Give each ship its own table--entirely. Make ships self contained.

[WMCoolmon]

Originally posted by Nuke
 id assume the ship classes are associated with a number fof flags and variables which are hard coded, such as turret capability and such, as well as what icons are used.  id like to un-hardcode that info in table form. so you can add custom classes "carrier" for example. im not sure what all cxan be tweaked with this so it might be usefull, but then again it might be a useless waste of time.

That actually sounds like a really good idea...things like big damage and AI options could be added to a table with classes like "corvette" and such, to add a new one you just add it to the table. Overall it doesn't sound too hard, except for the ironing-out-bugs phase.

I'm not sure how well that would work with icons and the like though.

Don't hold your breath though.

Originally posted by StratComm
Number of turrets isn't restricted at all, you could give a fighter 100 if the HUD crash wasn't present.

http://www.hard-light.net/forums/index.php/topic,35607.0.html

[Fractux]

WM,

I'll put my request in for a "camera-movement" SEXP

that allows the camera to move fly around the scene in at least one direction (either x,y,z), or, if plausible, to be able to fly around on multiple axes at the same time.

camera-movement

with appropriate parameters for position, orientation, speed, and acceleration.

Cheers!

[WMCoolmon]

The equations I have now will handle total movement time, and acceleration/deceleration time. Separate for each axis is possible.

What you have there sounds easier, but I'd have to run through it before I know how plausible it is.

[WMCoolmon]

Remove the need for player-craft to have secondary firepoints, either on the models or in the tables.

This should be implemented in the next CVS build. If it isn't tell me and I'll look into it.

As in, the ability to change the weapon mounted on a turret via SEXP, in mission.

This would require loading the weapon on startup, with the changes that I've made for the mission-set-nebula SEXP I should be able to do this properly...mantis & assign it to me with the priority of feature (use the advanced bug report screen)

Rotation settings for skyboxes. Allowing the FREDer to rotate the skybox .pof like a ship model.

mantis w/ priority of feature and assign to me.

- a SEXP that allows you to activate/deactivate player orders. Why?
Let's say I want to make a mission where tehy player is part of a wing he doesn't command (thus all player orders are disabled9. Let's say I want the leader to get killed and you take over. In order to do that I would need some SEXP trick that sets all player orders of a ship/wing to enabled or disabled.

Quoted because it sounds possible but I don't know for sure. mantis + assign if you want me to take a look at it

Originally posted by aldo
Oh, and has the thing with colliding problems for the visible cockpits been fixed?

What problem was that?

Originally posted by Fractux
WM,

I'll put my request in for a "camera-movement" SEXP

that allows the camera to move fly around the scene in at least one direction (either x,y,z), or, if plausible, to be able to fly around on multiple axes at the same time.

camera-movement

with appropriate parameters for position, orientation, speed, and acceleration.

Cheers!

mantis.

[TrashMan]

Escape pod and recovery craft!!

Here's how I immagine it to work.

In FREd, in the ship editor you can set a escape pod model for a fighter/ship (default to none) as soo as you set it, upon destrucion that ship will spawn the appropriate escape pod - and the game will handle it like the ship wasn't destroyed - all messgaes from Alpha 2 will still be recived, but sent from Alpha 2 pod.
the pods are protected and no one will attack them unless specificly ordered to.

In addition to this, a Allow recovery craft mission flag..or a SEXP.. that will automaticly call in an support ship to dock with a ejected pod and warp out..

with this, one can make great mission with charachters that finally don't have to be made immortal or utterly incapable of anything. And the fact that their fighter can be destroyed will force the player to finally protect his wingman - no more writing mission on an account on invulnerable wingmen!

[Trivial Psychic]

How about this one?  Some mods would benefit from an alternate support ship type.  Instead of having a ship warp in when the player calls for one, the player would fly towards a ship already in mission and once within a certain range, use the same key command as FS, but then AI will take over for the pilot and dock to the designated ship.  Once docked, the rearm/repair sequence would occur.

Using BSG as an example, some dockpoints would be added within the bay pods so that the player could enter, dock, and rearm/repair, then undock and return to combat.  It would almost be like a pit-stop.  It would probably necessitate a launcher flag to change over from the standard FS rearming method.

While we're at it, how about the ability to have dockpoints bound to sub-objects rather than the main hull?  That means that you could have objects docked to moving sub-models.  The only real dilema with this is how to deal with paths.  It may require that the dockpoints in question have no listed approach paths, or allow paths that allow the paths to move, staying relative to the dockpoint.