posted 04-13- 09:51 PM               

I was thinking about adding some things to help group work into OPS.

What did the guys who worked together for the jug and other projects do?

One thing I was thinking about was having a SM source file, sortof like the ASC file but more script/language orientated so the order and position of the objects and parameters in the file didn't matter too much.

That way the aircraft source files could be source controlled and branched and merged with standard stuff like CVS or even source safe, the same way code is.

OPS would support this new file format directly and could read/write it as well as 'compile' it into the final SM.

What do you guys think? Any better suggestions?

posted 04-13- 10:20 PM               

Also some way to line things up without gaps and animate DOF's would be cool.

The name munging for material flags could use an update too.. when I did the cockpit panel in max each dial had a material name like &metal_0, &metal_00, &metal_000 since each has to have a unique name. I eventually ran into problems on the 12th or so material I added.

TS

posted 04-13- 10:36 PM               

Thats sounding kinda cool. Although I don't totally get the whole process. All I know is anything that makes it easier to work in groups is good.

Anything that makes it easier is cool too.

posted 04-13- 11:34 PM               

&metal_00_hurrmki
&metal_00_alt64
etc

which was just &material_flag_texture-name

The material name parser ignores everything after the '00' (or what ever number it is) so long its end is delimited by a '_' so the texture-name is just a convention, and you could use anything, but it does differentiate the material names, while keeping a notation of the actual texture.

I was actually going to add this feature but then it worked 'out of the box' when I tested it.

Re 'Your humble request'. I will probably be adding a right click menu for the names and textures panel that includes a delete function. Also probably a thing that deletes a name reference when you delete a model (or texture), if nothing else uses it, as well as direct access to rename models rather than the round about way it is now. BTW, how does the DOF stuff work better? I didn't think I did anything there, although it sometime seems I fix things by accident

To line things up I use MAX and the export script. If you can't get it working let me know. I have no troubles and it works great!

posted 04-14- 04:52 AM               

I dunno if you can do this, it might make OPS a full 3D prog that could be way too much work for you to do.

posted 04-14- 06:35 AM               

One way a plane could be source controlled now is indeed Hippie's ASC file and LOD files, I have thuoght about this, but it seems messy for the reasons you mention - the asc file is too formatted.

I would think that a more scripted type of asc file combined with some sort of LOD files for the meshes would be ideal.

Also, where can I get CVS? Did I hear it was free? Can it run on an NT server, or is it a unix job?

------------------
-Sv =FC=

WWI in SDOE!

posted 04-14- 08:08 AM               

SV: To do merging properly whats needed is whats called a non-context specific syntax. I suspect the ASC file relies too much on context too allow easy merging.

I would guess that the current LOD format could be retained, especially since merging would involve a complete change of mesh rather than individual lines changing.

CVS is free. You can get it from www.cyclic.com. CVS will run on windows as a client or local mode only at the moment (I'm using it for OPS on Win98) but you need linux or possibly another unix system to run it as a full server.

posted 04-14- 08:26 AM               

First I'd like to see OPS and Hippie's Builder tool working harmoniously again. Lately anything I work with in OPS can only be "extractor-ed" but not "builder-ed." Not sure what the culprit is, but it leaves me only able to import .lods into OPS, with no capability to manually edit the .asc file and recompile the whole model. Since some OPS properties apparently don't get saved and sometimes get corrupted, you can end up with a dead-end that way. The Dauntless, for example, is now completely incompatible with Builder, although it can still be Extracted.

As for "group tools," one thing that would be pretty neat would be the ability to open multiple "windows" of OPS, with a different model in each window. That way you could import the landing gear from the P-38 into a B-26. You could also load up four different versions of a new project, like the SBD, and "merge" the fuselage of one with the wings of another, the canopy of the third and the landing gear of the fourth, instead of having to copy, paste, save, exit, restart, rename, re-DOF, etc.

An alternative would be the ability to create a "Master Model" and then store a list of versions for that model. Clicking on a part of the Master Model would bring up, say, a pulldown menu listing the corresponding parts from each version. Selecting "canopy #3" would bring that part and all its properties, DOFs, etc into the "Master." That way the Team Leader could compile the final or working version of the plane, or try to troubleshoot CTDs by replacing "suspect" parts.

The ability to "animate" a DOF and watch it move along it's DOF axis would be pretty cool too.

posted 04-14- 09:29 AM               

Normal = 0.1 rads or 5.7 deg

Modified with Control = 0.001 Rads or 0.057 Deg

Modified with Shift = 1.0 rads or 57.3 deg

Don't worry, if I ever do the type in or display rotation it will be in Degrees.

Jedi: One of the other "work group" things I was thinking of was having a "SM Import" where you imported another SM of the same plane except modified by someone, and told OPS to import and replace all LODs, or all Proplist, or DOF's. Maybe also for selected parts. Easier than creating a "source file" concept but it doesn't help when you have someone working on FM's and someone else working on DM's etc. Also effiecient source control wouldn't be possible.

I really don't know what the imcompatibilty problems are between extractor and OPS. I don't really use extractor, but some of the ones I've tried that have failed I'm pretty sure it has something to do with Proplist sizeses or something. If extractor still works but builder doesn't, then extractor likes OPS's output, so I guess it might be something to do with alignment, or proplist size.

Let me know what properties don;t get saved. Its just a simple matter to fix, since they are normally properties that fall through the generic property handler. I can add an option to turn proplist parsing off. You would only be able to edit them through the edit as text button, but the properties structure wouldn't actually be touched by OPS.

posted 04-14- 09:49 AM               

I just tried the positioning feature with your script again when I did the shinden, the import seems to work for me but things get positioned all over the place.

TS

posted 04-14- 01:46 PM               

Oddly enough, a "pristine" model will usually work both in OPS and in Builder, but after you modify it enough times, Builder won't work any more. I haven't figured out what "straw broke the camel's back" on the Corsair. The first 25 or so versions were all done with OPS/Builder/AC3D. After that I could only use OPS to view things. Even the smallest change, like altering a DOF min or max, would yield an "unBuilder-able" .sm file. The OPS output .sm would always work in the sim tho. Weird.

posted 04-14- 05:20 PM            

Since had 4 members, we had a boat load of .sm files flying around. We had a few moments of chaos..or at least I did, because I wasnt sent all the files, but all in all it was smoothe.

First, JT and bjorn worked on the getting the plane into one piece. Then, the sent me a semi working Jug so I could start the textures. After it was farther along, JT concentrated on the cockpit, while bjorn continued to do the OPS stuff and I did the textures. When we go closer, we gave it to zur to work magic on.

So, we really had a segmented approach. Kinda like a good program. We defined everyone's task and let them concentrate on that part, without interrupting the whole process. The advantage of a pit allowed JT to work on the interior without having to wait for .sm files to pass from everyone.

posted 04-14- 10:07 PM            

It would be nice however if Bryan could get the .LOD import plugin working properly with
the latest OPS for those people that are using AC3D as a cheap mesh editor.
Since the .LOD format is just an ASCII version of the real OpenPlane LOD format there are
some advantages to using AC3D for meshes, less chance of getting polygon
normal/polygon flags/material screw ups than when converting from other formats
like OBJ etc.

The .ASC file format is really just an ASCII version of the .SM file with
the LODs moved out to seperate files and some end of part / end of group
markers inserted so the builder program can work out offsets and record lengths.
I agree it isn't easy to edit if you are moving stuff around, adding and deleting.

If Bryan could come up with a more logical and easy to edit ASCII representation
of .SM files that would be great.

I've got some more time now to start looking into the whole builder/extractor/AC3D
thing again, but I don't really want to spend time duplicating Bryan's efforts.

There are a few different versions of extractor floating around now,
someone (Bjorn?) altered one to use mallocs to get around some of the static array sizes
that were hard coded into it, but that version doesn't have the fix for the
broken multigen -> sm convertor.

There are some things thats should be fixed, the OpenPlane Doc had a mistake in the DOF
record description, there is a 4 byte DOF id field before the proplist that
is only filled in at run time, I treat nulls as # in ASC file proplists so all
DOF proplists have #### at the start of them. This should be handled properly.
(Proplists also get null padded to the next 32 bit word)
This could be screwing up extractor/builder operation with OPS.

Hippie.

[This message has been edited by Hippie (edited 04-14-2000).]

posted 04-14- 11:10 PM               

I would love to see EVERYTHING hippie's tools can do rolled into OPS. No offence. As without it alot of stuff wouldn't have been done. But that whole text editing stuff scares the crap out of me. I like doing stuff in OPS alot better.

Will we see that day?

And when OPS works seemlessly with 3d studio max and ac3d

posted 04-15- 01:38 AM               

1) an improved version of the Wing Extractor program. I'm thinking it would be more user friendly, allow renaming airfoils to whatever you want, input Coeffs as numbers instead of that weird ratio thing, and maybe include a short readme explaining how to use it. Maybe SV is working on this? Of course he's also working on about six other things :-)

2) a LOD polyflag setting utility. I'm envisioning a little prog that will display a LOD, and allow you to select each face in turn, and set the poly flags via check boxes or something instead of trying to compute the hex equivalent of some number you aren't completely sure you wrote down right. I would be interested in knowing this stuff since apparently it figures into collision detection, and it would be handier for making transparent or two sided etc.

3) improved version of OPS which would include 3 things:
a) clean up unused names/textures
b) run some kind of analysis on the plane which would give extra info such as where the center of mass is, what the total drag of the plane is at a given alpha and where that drag is on average.
c)import export LOD (is this working now?)

posted 04-16- 06:46 AM            

Any theories how that could happen?

Multigen?
OPS?
Carless editing using extractor/builder?

posted 04-16- 06:14 PM               

I am planning on using AC3D... I am loving it! So any work you or Bryan do to improve the integration with OPS would be awesome!

What is the status of beaing able to export multiple objects from AC3D into OPS positioned correctly? Now this would be cool

charmstar,

I stopped work on a new airfoil editor because it struck me that editing the airfoil data was not the best idea for all but the brave of heart. Right now I am looking forward to proper WWI airfoil data created by that NASA program or the like.

It still might be cool, but just not as high of a priority for me right now...

-Sv