[TrashMan]

1. Debris automaticly doesn't use glowmaps. no powr = light out.


2. Ability to select the launch/depatrure fighterbay (if ship has multile)

3. To be able to put several ships in the cap_set_waypont_speed SEXP. Easier then having X such events for X ships.
This could allso be usefull for some other SEXP's too..

[Turnsky]

Originally posted by TrashMan
1. Debris automaticly doesn't use glowmaps. no powr = light out.


2. Ability to select the launch/depatrure fighterbay (if ship has multile)

3. To be able to put several ships in the cap_set_waypont_speed SEXP. Easier then having X such events for X ships.
This could allso be usefull for some other SEXP's too..

burning debris has a tendency to glow, y'know.. all that fire, fuego, burnimation, etc.

[TrashMan]

But all the windows andglowy things tend t shut down without power..you know..

So turn off al glowmap expect the burniong debris one.

[StratComm]

Actually the solution there would be to map the debris with an alternate texture that has no glow map.  The "damage" map should definately glow, and there's no good way to distinguish those that should from those that shouldn't.  Yet.

[TrashMan]

But that means more maps - for each window/something that glows map you would need another that doesn't glow.

I tried that approach. it works, but you end up with more maps needed for each ship.

[StratComm]

Yes, but it keeps the project as a whole from having to remove functionality.  Perhaps when Bob impliments his material system, this could be fit in with that.  Until then, lets not go there as the benefits of the glow are worth more than the defects.

And besides, it's maps/subobject that's important.  Maos per visible object could have a case made for it as well.  But since the ship and its debris are only visible for a split second as the ship explodes, it isn't something to be tremendously concerned about.

[Trivial Psychic]

Originally posted by TrashMan
2. Ability to select the launch/depatrure fighterbay (if ship has multile)

Often requested.  I once suggested the possibility of having a sexp specify which specific bay paths a wing or ship should be restricted to.  Likely one sexp for arrivals, and one for departures.  Something like restrict-arrival-path and restrict-departure-path.

3. To be able to put several ships in the cap_set_waypont_speed SEXP. Easier then having X such events for X ships.
This could allso be usefull for some other SEXP's too..

Useful, but you don't need a different event for each ship.  Just tie a bunch of cap-waypoint-speed sexps into a single event, but it would reduce clutter if we could have multiple ship entries in one sexp instance.  This would of course mean that every ship listed would be limited to the exact same speed... just a minor restruction.

[TrashMan]

I though of a (maby..I hope) simple way to implement that debris thingy.

You have a txt file named debis which the game checks.
Any texture name mentioned in there will remain glowing on the debris.
This way aynone who has custom debris textures, or wants some otehr texture to keep glowing can simplky add it in.

EDIT : Oh wait... textures per subobject are taken into account, not textures er whole model?

[aldo_14]

Originally posted by TrashMan
I though of a (maby..I hope) simple way to implement that debris thingy.

You have a txt file named debis which the game checks.
Any texture name mentioned in there will remain glowing on the debris.
This way aynone who has custom debris textures, or wants some otehr texture to keep glowing can simplky add it in.

EDIT : Oh wait... textures per subobject are taken into account, not textures er whole model?

That seems a bit complex for something possible with trivial changes to current practices.  (especially if you need to do a linear search to check the list).

AFAIK the main problem/slowdown with texture maps - i.e. having too many -  is the context switches between textures on the same subobject.  So i'm not sure having one or 2 new textures would be a significant issue.

Especially with custom debris textures.

[StratComm]

Precisely my point.  It increases filesize a bit, I'll admit, for mods.  But that's a trade-off to using a sane system over one that is completely impractical right now.  And again, with the material system Bob is working on, this would go from a silly request to practical one with - I would guess - relatively little work.  Just have a -glow and a -glow_when_live type arrangement.