noob: my own ship

[JazHaz]

Hamish - As an example have a look on the link on my signature strip. Select the Galtech Escort Fighter and you can see on the Wiki page the different versions of the same ship. You can use a similar principle and create your own texture for use with the player ship only.

Hamish might have trouble finding the link to the fighter - I did - so here's the direct link: [wiki]GalTech Escort Fighter[/wiki]

[KaiserZandrich]

Hi folks,

I recently came across this thread - it's been an absolutely wonderful help in getting me oriented with ship OXPs. I've reviewed most of the referenced pages/tools, and feel the process is simple enough for me to tackle; oh boy.

I picked up a few base models and tweaked them in Blender, stored them in OBJ/MTL for later conversion to the native DAT, so I have the very first step out of the way. I figured reviewing the two PLISTs mentioned here, SHIPDATA and SHIPYARD - one for the data pertaining to the ship, and the other for stations? Great!

My ship, based on the Anaconda, should, arguably, inherit most of the Anaconda's data, but I've had no luck tracking down vanilla PLISTs for the Anaconda! So I've resorted to cross-referencing two SHIPDATA PLISTs: the "template" SHIPDATA and the SHIPDATA for a custom OXP (Kirin?), carefully removing data fields in the latter's PLIST to reflect vanilla Anaconda data, to be adjusted later.

So far I've had no trouble discerning between data types like variants for NPCs or custom fields used specifically for the OXPs ships, but given how chaotic the template is (Anaconda's "template" is a "trader" variant, the "player" variant simply references it), I'm finding it difficult to populate the correct data. Would it be possible for me to extract "clean" PLISTs for the vanilla/redux Anaconda to adjust instead? Again, I've had no luck tracking down a stand-alone Anaconda OXP (save for a "medical" variant and an older OXP with a broken download link).

Beyond that, from what I've read here, the process looks something like:

* Consolidate PLISTs in OXP folder
* Convert model to DAT (not sure if MTL extraction is also automatic) and place them in the respective folders
* Run Oolite with [SHIFT] depressed, enter a saved game and use Library via the F2 menu
* Access the OXP ship
* Place static light-, flashing light-, laser- (weapon) and engine origins via Library

I'm assuming Library adjusts the PLISTs according to any changes. Is the above correct? ANY constructive assistance would be much appreciated!

[montana05]

Hi folks,

I recently came across this thread - it's been an absolutely wonderful help in getting me oriented with ship OXPs. I've reviewed most of the referenced pages/tools, and feel the process is simple enough for me to tackle; oh boy.

My ship, based on the Anaconda, should, arguably, inherit most of the Anaconda's data, but I've had no luck tracking down vanilla PLISTs for the Anaconda! So I've resorted to cross-referencing two SHIPDATA PLISTs: the "template" SHIPDATA and the SHIPDATA for a custom OXP (Kirin?), carefully removing data fields in the latter's PLIST to reflect vanilla Anaconda data, to be adjusted later.

Please have a look here: https://app.box.com/s/y6vpq8cfyuatujhjvtz3y7nknw49ofc5

This update of the Medical Anaconda is still a WIP, but it includes both Anacondas, the one from Smivs (original) and the one from Griff (core-game). I guess the shipdata.plist will help you.

[KaiserZandrich]

Hi folks,

I recently came across this thread - it's been an absolutely wonderful help in getting me oriented with ship OXPs. I've reviewed most of the referenced pages/tools, and feel the process is simple enough for me to tackle; oh boy.

My ship, based on the Anaconda, should, arguably, inherit most of the Anaconda's data, but I've had no luck tracking down vanilla PLISTs for the Anaconda! So I've resorted to cross-referencing two SHIPDATA PLISTs: the "template" SHIPDATA and the SHIPDATA for a custom OXP (Kirin?), carefully removing data fields in the latter's PLIST to reflect vanilla Anaconda data, to be adjusted later.

Please have a look here: https://app.box.com/s/y6vpq8cfyuatujhjvtz3y7nknw49ofc5

This update of the Medical Anaconda is still a WIP, but it includes both Anacondas, the one from Smivs (original) and the one from Griff (core-game). I guess the shipdata.plist will help you.

Thank you so very much! I'll be taking a look at it right away!

[Cholmondely]

What are you hoping to do to your anaconda?

[KaiserZandrich]

What are you hoping to do to your anaconda?

Besides adjusting a few of the stats in the datasheet (slow and lumbering pitch/roll/yaw with a somewhat higher top speed and a little more thrust to keep things interesting), I'm hoping to import a rudimentary model (adjusted from the base model; a few changes to my taste, and a few more to justify the implied increase in size).

I've finally reduced the Kirin's XML PLIST to the same data range included in Montana05's OXP (again, thank you so much!), and tried a quick test by only including the textures and model of the Kirin (excl. shaders and other fancy things) as placeholders to test the PLISTs data. Set the likelihood of it coming up in station stores to 1.0 and the req. tech level to 5 just to help test it out quick. The PLISTs worked!

Once I'm done figuring out how the converter works (hoping to try it out tomorrow) and I've tested the DAT and textures, I'm finally going to figure out Library and see if I can make sense of the tools. As it stands I haven't run the converter or perused Library yet, but hopefully it goes as smoothly as this first bit did.

When I'm finally content with the stat balancing, entity placements, model and textures, I'm hoping to set the SHIPYARD PLIST back to tech 11 with a really low spawn rate, perhaps 0.2 or 0.1, starting a new save and working up to it. I've always loved pseudorealism in that sense, having to spend time and effort to obtain something that isn't really tangible but has accrued abstract value because of said effort.

I'll definitely check back in as soon as I've given everything a try and run into issues again! So far using an OXP's parts to Frankenstein things seems pretty simple, even intuitive, provided I'm careful and scrutinize everything thoroughly.

Edit: By "spawn rate" I meant the likelihood of it coming up in station docks, I'm not keen on having it being flown by AI as of right now. Perhaps in a large escort wing with a really low chance later on, I quite liked running into the Kirin before I finally got to buy one. It let me get a really good look at it.

[montana05]

Thank you so very much! I'll be taking a look at it right away!

Very welcome, feel free to ask if you need help. Btw I forgot to mention that Griff's Ananconda in my WIP is designed for multiple laser mounts, if you prefer single mode you need to take the weapon positions from the core-game and replace "weapon_mount_mode" = "multiply"; with "weapon_mount_mode" = "single";

[KaiserZandrich]

Thank you so very much! I'll be taking a look at it right away!

Very welcome, feel free to ask if you need help. Btw I forgot to mention that Griff's Ananconda in my WIP is designed for multiple laser mounts, if you prefer single mode you need to take the weapon positions from the core-game and replace "weapon_mount_mode" = "multiply"; with "weapon_mount_mode" = "single";

I did notice that, for most part I just carried over the POS to the Kirin's PLIST. I also added the POR/STA weapon types, not sure why the Kirin didn't have them included but I'm sure there's good reason. I had a little trouble with the Kirin OXP prior to taking on this task, where the lasers would visibly fire in every external view but not from the ship views (1-4) - whatever I've (probably accidentally) done to the PLIST seems to have fixed that - the Kirin now fires frosty white lasers! I can't wait to see them on my own ship, but I've no intention of rushing into it.

Does "multiply" amount to multiple-firing in the same direction relative to FOR/AFT/POR/STA views? If so then I'll probably duplicate "multiply" in the PLIST later on, I quite like the idea of a larger ship relying on POR/STA batteries!

I'm downloading the Obj2DatTexNorm.py script right now so I can take a peak inside. I'm acquainted with C++ and Delphi (mostly due to work), so my knowledge of Python is limited to VERY basic scripting. Very mysterious thing, that Python. Very fitting name, though.

AND I've just taken a look at the script. It seems to read in the OBJ but I didn't notice the MTL being read in? I probably overlooked it, but I'm going to fire it up and work through it anyway, no use speculating. Another thing I noticed was that it carries over the OBJs measurements, not sure if ship size can be adjusted in Library so my model might be immense or tiny depending, I didn't use a reference model ripped from a DAT. Wish me luck!

Edit: I DID overlook the MTL being read in. Everything is ready so I'm going to go ahead and test it out.

[montana05]

I did notice that, for most part I just carried over the POS to the Kirin's PLIST. I also added the POR/STA weapon types, not sure why the Kirin didn't have them included but I'm sure there's good reason. I had a little trouble with the Kirin OXP prior to taking on this task, where the lasers would visibly fire in every external view but not from the ship views (1-4) - whatever I've (probably accidentally) done to the PLIST seems to have fixed that - the Kirin now fires frosty white lasers! I can't wait to see them on my own ship, but I've no intention of rushing into it.

Does "multiply" amount to multiple-firing in the same direction relative to FOR/AFT/POR/STA views? If so then I'll probably duplicate "multiply" in the PLIST later on, I quite like the idea of a larger ship relying on POR/STA batteries!

I'm downloading the Obj2DatTexNorm.py script right now so I can take a peak inside. I'm acquainted with C++ and Delphi (mostly due to work), so my knowledge of Python is limited to VERY basic scripting. Very mysterious thing, that Python. Very fitting name, though.

AND I've just taken a look at the script. It seems to read in the OBJ but I didn't notice the MTL being read in? I probably overlooked it, but I'm going to fire it up and work through it anyway, no use speculating. Another thing I noticed was that it carries over the OBJs measurements, not sure if ship size can be adjusted in Library so my model might be immense or tiny depending, I didn't use a reference model ripped from a DAT. Wish me luck!

Edit: I DID overlook the MTL being read in. Everything is ready so I'm going to go ahead and test it out.

The weapons positions are usually individual for every model. If you use multiple mode and have various positions assigned, they will act as a battery. For the Kirin in Oolite the positions could be like that:

Code: Select all

"weapon_position_forward" =        // double lasers in close positions
(
	"-5.0 -11.0 160.0", 
	"5.0 -11.0 160.0"
);
"weapon_position_aft" =            // double lasers -> 60.00 m separated
(
	"-30.0 2.0 -153.0", 
	"30.0 2.0 -153.0"
);
"weapon_position_port" =           // triple lasers -> 50.00+ m seperated
(
	"-26.0 -10.0 50.0", 
	"-38.0 -10.0 0.0",               
	"-85.0 -13.0 -60.0"
);
"weapon_position_starboard" =      // triple lasers -> 50.00+ m seperated
(
	"26.0 -10.0 50.0", 
	"38.0 -10.0 0.0",               
	"85.0 -13.0 -60.0"
);

Please keep in mind that multiple lasers need a lot of energy and got a tendency to overheat fast.

[KaiserZandrich]

I'll try those out soon, I'm just working on getting the Python to execute. I'm having a little trouble with the syntax in Obj2DatTexNorm.py, not sure why because I'm running it under 2.7. If I get this script to run eventually, I'm hoping to set it up with www.pyinstaller.org so I know I won't encounter this issue in the future!

Edit: After plenty of fiddling and looking around, I've been able to modify an already modified modification for the unmodified conversion script! It finally executes, but I've run into a new problem: "Warning: read unnormalized normal" - so I'm going back to my model and playing around until it works! I suspect the error is as a result of Blender, so I'll read the OBJ into Wings3D and re-export if all else fails, though I'm concerned about Wings3D not importing the MTL file alongside it.

Edit: Wings3D seems to import the MTL after all, but I'm still getting the same error as before (sorry Blender!). Will update as soon as I've figured out this next hurdle.

Edit: I've tried out the various winding modes built into the script, but I've not had any luck getting past the error message; this means there's still something wrong with the base model - I WILL HAVE VICTORY.

Edit: I've rebuilt the model, almost entirely, stitching up the faces manually before recalculating the normals and exporting the OBJ. The conversion script still gives me the same error, so I'll have to look into the script itself again later tonight, perhaps tomorrow; this ship WILL make it into Oolite!

[Cholmondely]

I'll be taking a look at it right away!

You have a "pm"!

[KaiserZandrich]

I'll try those out soon, I'm just working on getting the Python to execute. I'm having a little trouble with the syntax in Obj2DatTexNorm.py, not sure why because I'm running it under 2.7. If I get this script to run eventually, I'm hoping to set it up with www.pyinstaller.org so I know I won't encounter this issue in the future!

Edit: After plenty of fiddling and looking around, I've been able to modify an already modified modification for the unmodified conversion script! It finally executes, but I've run into a new problem: "Warning: read unnormalized normal" - so I'm going back to my model and playing around until it works! I suspect the error is as a result of Blender, so I'll read the OBJ into Wings3D and re-export if all else fails, though I'm concerned about Wings3D not importing the MTL file alongside it.

Edit: Wings3D seems to import the MTL after all, but I'm still getting the same error as before (sorry Blender!). Will update as soon as I've figured out this next hurdle.

Edit: I've tried out the various winding modes built into the script, but I've not had any luck getting past the error message; this means there's still something wrong with the base model - I WILL HAVE VICTORY.

Edit: I've rebuilt the model, almost entirely, stitching up the faces manually before recalculating the normals and exporting the OBJ. The conversion script still gives me the same error, so I'll have to look into the script itself again later tonight, perhaps tomorrow; this ship WILL make it into Oolite!

I WILL NECRO MY OWN THREAD IF I SO WISH!

I have gotten the Python to execute, the .dat looks good, but I won't be able to test until I've worked through the swamp that is my mesh, get some textures up, and run it through the Python again. It's been two years, give or take, but this is the first time I've seen progress, in any measure; VICTORY.