[Nuke]

at le4ast youre making progress, ive been staring at my nuke3d engine code all day, i wrote 2 lines of code, and neither worked

[Bobboau]

well, that didn't happen, I did get started by midnight , ok, well I have nothing else to work on for the rest of the next three months so I'm sure there will be some interesting results soon.

got the turret editor done.

[Kazan]

k

[Bobboau]

yeah, all I have left is paths, glowpoints, and subobjects (I'm not going to make editors for insig or shields, they will probably just have the basic chunk controls of apply, discard, import, export)

with regards to paths, I'm not sure if I should support the whole 'turrets' part, my last editor didn't suport them, but it seems they do have some function in game, but I'm still not sure what that function is.

[Kazan]

i'm not sure either... error on the side of support

[Whitelight]

Forgive me if this reply is on the stupid side, I sometimes don`t see what is really in front of me, but... 

Wouldn`t the paths be for, tracking the turrets position, for incomming bombers or fighters, maybe?

[Kazan]

that's what i always figured

[Whitelight]

Cool, then i`m good today, thanks. 
Oh, and thanks for the really quick reply Kazan. 

[Nuke]

i always thought they were attack paths for ais. so that they can aproach the turret, shoot it, and fly off without colidint with the cap ship. though i never went through the trouble of creating them.

[Kazan]

that's what we just said

[Nuke]

oh, my bad. are we gonna get an autopath feature. be nice if we can insert an autopath and drag the points around pretty much at will. this will shorten the time required to path large cap ships.

[Whitelight]

If i`m not mistaken, I may be! But Aurora could put paths in, but for me, it had a down side to it, as it corrupted the model file making it un-useable. 
Putting paths in manually, as I have had to do, can be a pain, depending on the model, and or, subsystem and turret placement.. Very large cap ships are time consuming, remember each path has 4 vectors, and each consecutive vector as it approaches the target subsystem gives a smaller radius.. Umm I`m babbling now so i`ll shut my pie hole. 

[Bobboau]

auto-path was a relatively easy feature, I can implement it in a mater of hours.

[Bobboau]

ok, last of the easy ones (glow points) done, now onto paths and submodels.

[Kazan]

cool

[Bobboau]

about 80% done with paths, it seems the turret issue isn't going to be an issue, sence there does not seem to be anything in the path data structures about them.

hey, while I'm posting, I'm just wondering how posable will additional GL windows be? like if in the future I wanted to make a UV editor that had a GL canvas window in it? (not the same class as our current render window, would not need any 3d related code)

[edit]done with paths all that's left is submodels, then I start working on the tree so you can actualy USE any of these[/edit]

[Nuke]

go bob go!

[Bobboau]

I'm working on subobjects now, it's turning out to be easier than I had thought, especially sense I'm just making it edit only one subobject at a time (the tree will select which one), I'm going to need to make a few more primitive controls, multi-line string editors and int list selectors (combo box you select an option for which gets converted to an int for the moment I'm just useing normal int controls which will get the job done for the moment but allow for illegal values and don't tell you what the valid ones are)

alright, submodels is semi-done pending me making the int list control, which I'll do tomorrow, then I'll get the tree working, which will take a few days, they it will be time to fine tune the interface (most of the controls have some issues with some data sections not standing out as well as they should I need to add some white space to make things flow better).

it will soon be time to start talking about how the UI is going to talk with the render window. the jist of how I'm thinking this should work is a set of functions in the UI base class that will give out several lists of grpoints (a general purpose vector based class for use in the 3d UI would have a position a radius and a normal even if they weren't always used, flags will determine how they are displayed (ie a flag to determine weather or not to draw a normal, if the normal data is junk it shouldn't be displayed)). I'm thinking a vector of vectors of grpoints, and an int to identify the currently selected list and another int to identify the currently selected point in that list, the GL windo gets this, draws it, and if the GL window makes any changes it sends the modified vector of vectors of grpoints back to the UI to do the actual editing, so there would only need to be one set of functions in the GL window for graphically editing 95% of all data in the model, and these set's of functions would be COMPLETLY generic, so they wouldn't have to worry about what data is selected or if any data is selected it would just have to manage this vector of vectors, update the display when it gets a new one, call a function when it makes changes to it.

let's not do anything concrete until I make my commit and the text editor it in good shape though.

[Col. Fishguts]

*cheers for Bob*

You seem to be on a coding spree, don't let anything stop you !

[Kazan]

k, feel free to edit the renderer as you need - openGL is not that hard, if you have to add runtime variables to the PMF class make sure to stick their decs in the right comment block (Rendering data) in the header - the PMF class stores all the data, so really you just need to stick some context data in - ie what subdata to render (like gunpoints) and any small context variables like "Current selected index", etc and write the code to render the context.