[Akalabeth Angel]

     Could a person change the rotational freedom of a turret on a per mission basis? Let's say that a turret is located on a surface who's spatial relationship to the rest of the object can change, and when it does change it opens up the turret's typical arc of fire to potential shooting at or through the main object (which of course would look very stupid). So if a multiple part turret typically has a 360' rotation with 90' on the barrels, could a person change the first, Y-rotation I guess to something like 270' for example.

     Assuming of course, that a person can have a multipart turret located on a rotating subobject of a larger object. And also assuming that that subobject can through rotation be orientated to a certain point and stopped for the duration of a given mission (or pre-rotated before the mission commences).

[Akalabeth Angel]

Oh, one more completely unrelated scripting question. I know that in, FRED Open you can deactivate glowmaps. I'm wondering, if through scripting a person can activate or deactivate the glowmaps of a submodel(s) of a larger object?

For example, let's suppose we have a ship similar to the Zentraedi Monitor. The bow of the ship is two sections which prior to firing, move to seperate. Let's say inbetween the two sections there's a bunch of cool do-dads, electronic power weaponizer looking crap. Could a person have both those objects rotate to their required position, and then perhaps a few moments later activate the glowmaps of that subobject prior to it firing? So it looks like "A - the weapon is opening to fire" and "B - the weapon is powering up to fire" and then the firing sequence itself.

(And no, Getter Robo, I'm not doing a Monitor. It's just a good a example

[WMCoolmon]

Textures in Freespace work by loading a list of the textures used by that model when the ship is 'paged in' (Basically whenever the game knows it's going to be used). These are the textures from the 'textures' tab in PCS2. When you do texture replacement, it also includes the glow and shine maps. However, that texture list from the PCS2 tab is used for everything - including submodels. They just store the texture's place in that list, not the actual texture itself. So if you change that texture, you will change the subobject.

With some coding, a moderate amount, you could do per-object subobject texture replacement regardless of that list. For now, if you change a texture used by a subobject, it will change that subobject. But it'll also change any other objects that use that model.

I don't know how you'd do this, besides editing the POF file manually, but if you did add identically-named textures to the list, you could perform texture replacement for that subobject and it wouldn't affect anything else (provided the subobject was the only thing using those identically-named textures). You could probably do this by importing the POF with a separate set of textures for those subobjects you wanted to do texture replacement on, and then opening the POF in PCS2 and renaming the subobject-only textures so that they were the same as the general-ship textures. As long as you had the UV coordinates set properly, you could then toggle the glowmaps on and off for one subobject while still only using one set of textures for the whole ship.

As far as slowdown goes, I don't think that you'd experience anything noticeable by using that method, at least not until the renderer is heavily revised. Right now, FS2 renders each set of textures all at once, and then moves on to another set. That means that it first loads the base map, then the glow, spec, and normal maps. Then it moves on to the next subobject and does the same thing. So it's continually changing textures anyway. However, you will still run into the MAX_TEXTURES limit if you use too many texture sets, even if they all have the same name.

(Side note so I don't have to talk around it in the future, textures in the textures tab from PCS2 are loaded from the POF file as 'texture maps', which contain references to the base, glow, spec, normal, and height maps that've been found and loaded. Texture maps are more or less an extremely primitive precursor to some kind of material object.)

[WMCoolmon]

     Could a person change the rotational freedom of a turret on a per mission basis? Let's say that a turret is located on a surface who's spatial relationship to the rest of the object can change, and when it does change it opens up the turret's typical arc of fire to potential shooting at or through the main object (which of course would look very stupid). So if a multiple part turret typically has a 360' rotation with 90' on the barrels, could a person change the first, Y-rotation I guess to something like 270' for example.

     Assuming of course, that a person can have a multipart turret located on a rotating subobject of a larger object. And also assuming that that subobject can through rotation be orientated to a certain point and stopped for the duration of a given mission (or pre-rotated before the mission commences).

I don't know how the AI will react to limiting a turret's rotational freedom. Nuke is more likely to know what would happen.

I have no clue if the turret code supports multipart turrets on rotating subobjects.

[Bobboau]

you can have turrets on rotateing subobjects,

they will fire,

randomly,

or more precisely they will pretend that the object they are on isn't rotating, they will think ther are in there default position and orientation when they are in fact in a totally different location entirely. I spent a great deal of time trying to make this work so I have a somewhat intimate (if foggy cause it's been a year or two) understanding of the situation. if you just want a light show it'll work somewhat, but you probably want there to be a snowball's chance in hell of them hitting something once in a blue moon which unfortunately will not happen,

[Akalabeth Angel]

you can have turrets on rotateing subobjects,

they will fire,

randomly,

or more precisely they will pretend that the object they are on isn't rotating, they will think ther are in there default position and orientation when they are in fact in a totally different location entirely. I spent a great deal of time trying to make this work so I have a somewhat intimate (if foggy cause it's been a year or two) understanding of the situation. if you just want a light show it'll work somewhat, but you probably want there to be a snowball's chance in hell of them hitting something once in a blue moon which unfortunately will not happen,

         Is this something that might be remedied in the code in far-off future? It's certainly not something I need . . . just wondering if I should bother adding that potential to a model that may see years of use and one day may be able to benefit from enhanced code.

   
         @WMCoolman, thanks for the explanation. Sounds feasible. If I ever turn some of my sketches into real live models I might be able to put some of this help to good use (and in the process might need more of it).

[Akalabeth Angel]

      Though I wonder with the turrets, one work around might be to have dockpoints where the turret would go and then put a seperate turret ship on there. Though of course, that would look stupid, in terms of sensors anyway (unless the models were invisible to radar). Think FSOpen supports multiple dockpoints these days.

[WMCoolmon]

That sounds like it would work. FS2Open definitely supports multiple dockpoints and I think they do take subobject rotation into account. You can disable ships showing up on radar or being targetable. You'd have to blow them up with the ship using SEXPs or scripting, and they'd probably still appear in the mission log, but that's not a really visible problem.

[Getter Robo G]

(And no, Getter Robo, I'm not doing a Monitor. It's just a good a example

I have a Monitor separated as a reference, just don't have permission to use it! (Lestat HW1)

But I appreciate you posting that example (on my birthday no less)! [Freaky] I've never been in here before, I just saw the words Variable Turret today in recent posting link and clicked on it...

 L8trs! 

[Akalabeth Angel]

you can have turrets on rotateing subobjects,

they will fire,

randomly,

or more precisely they will pretend that the object they are on isn't rotating, they will think ther are in there default position and orientation when they are in fact in a totally different location entirely. I spent a great deal of time trying to make this work so I have a somewhat intimate (if foggy cause it's been a year or two) understanding of the situation. if you just want a light show it'll work somewhat, but you probably want there to be a snowball's chance in hell of them hitting something once in a blue moon which unfortunately will not happen,

        As a point of interest, this still may work fine. Though Omega Destroyers from B5 enter combat with their gravity positive sections in full spin, I've heard from a lot of people and different sources that any ship with such a section would have it locked down and not rotating during combat. Since combat manoeuvres would put undue stress on the thing, not to mention any damage that will eventually impact on the section.

       So it might be cool to have a ship, which has a rotating section, and some guns on that section, but via scripting have the rotation turned off for scenarios where it engages in combat. (Assuming that it's not surprised during that ordeal)