[WIP] Modular Ships
-
- Expert Mercenary
- Posts: 893
- Joined: Thu Jul 08, 2010 11:43 pm
- Location: Sol III North American Continent
Re: [WIP] Modular Ships
The most logical mode of operation for a jump drive is that it teases open an existing wormhole. As such, I would think that the drive plays a larger part in jump speed, energy usage, etc. than the hull would.
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
@travists: Well, now that the jump drive is mentioned...
I think the "existing wormhole" therory is valid, because the jumppoints defined in the game are sort of "fixed" objects or locations.
What's cool about them is, that they give modders great flexibility by allowing them to install jumpstations or hyperspace gates or whatever you want to call them at these locations. Just replace the jump point mesh with a "real" mesh or locate a suitable mesh nearby and it's done.
Whether a jump drive should consume jump fuel or just energy. Well I would opt for the energy variant.
@Hicks: looked into the google-docs table and wondered if we could sort it somehow. Is there a logic behind the current sorting (except for the fact that it matches the tables used by VS (units.csv), afaik)? I think it's easier to fill tables alphabetically when looking up values and appending them.
I mean it's no business at all to sort it, but what could be the consequence using the data inside the game? Perhaps the time required for looking up values in a table sequentially is related to the number of lines parsed, so have the most commonly used items at the top would make sense. But since I cant possibly make any suggestion on this for lack of knowledge (I am no coder), I though I'd better ask.
I would love to ad the columns Unit_Scale, Model_Length/z, Model_Width/y, Model_Height/y, so we could simple use a function to calculate the corrected dimensions.
What a about volume? I like to build things into a ship based on volume, calculate the final mass and derive performance numbers from that. This approach of course implies the existence of consistent data for mass, volume and energy consumption (plus perhaps cost) of any given component which could be too much for the purpose. Shall we estimate a multiplier and use that or really calculate volume from the model itself? As long as it's consistent both variants could produce usable data.
@TBeholder: Is the "raw Equipment_Space (empty hull space)" derived from the models dimensions or a value that was made up during the deisign process? I haven't checked, so I don't want to imply the one or the other. Would be just good to know, if it needed recalculation.
I agree the we should have some sort of "useable" total available hull volume from which any component needs to be substracted.
Upgrade_Storage_Volume (accessory bays) - as I would like to understand it - could actually add to the total available voulme (Equipment_Space) by extending the hull with external features. Here's a visual (non Vega Strike) example of what I mean:
Picture 1: shows a Wotan Mk2 Class Freighter without Hull Extensions
Picture 2: shows the same Ship with a set of booster drives
Picture 3: shows the same Wotan Mk2 Class Freighter with Cargo Bay Hull Extension and more powerful Booster Drives.
This probably (also) fits into the area equipment "mounts". For the drives that expanded hull volume does not need to be calculated as drive "pods" will full occupy their own hullextension, they only add mass and geometry and consume energy or fuel or both.
I think the "existing wormhole" therory is valid, because the jumppoints defined in the game are sort of "fixed" objects or locations.
What's cool about them is, that they give modders great flexibility by allowing them to install jumpstations or hyperspace gates or whatever you want to call them at these locations. Just replace the jump point mesh with a "real" mesh or locate a suitable mesh nearby and it's done.
Whether a jump drive should consume jump fuel or just energy. Well I would opt for the energy variant.
@Hicks: looked into the google-docs table and wondered if we could sort it somehow. Is there a logic behind the current sorting (except for the fact that it matches the tables used by VS (units.csv), afaik)? I think it's easier to fill tables alphabetically when looking up values and appending them.
I mean it's no business at all to sort it, but what could be the consequence using the data inside the game? Perhaps the time required for looking up values in a table sequentially is related to the number of lines parsed, so have the most commonly used items at the top would make sense. But since I cant possibly make any suggestion on this for lack of knowledge (I am no coder), I though I'd better ask.
I would love to ad the columns Unit_Scale, Model_Length/z, Model_Width/y, Model_Height/y, so we could simple use a function to calculate the corrected dimensions.
What a about volume? I like to build things into a ship based on volume, calculate the final mass and derive performance numbers from that. This approach of course implies the existence of consistent data for mass, volume and energy consumption (plus perhaps cost) of any given component which could be too much for the purpose. Shall we estimate a multiplier and use that or really calculate volume from the model itself? As long as it's consistent both variants could produce usable data.
@TBeholder: Is the "raw Equipment_Space (empty hull space)" derived from the models dimensions or a value that was made up during the deisign process? I haven't checked, so I don't want to imply the one or the other. Would be just good to know, if it needed recalculation.
I agree the we should have some sort of "useable" total available hull volume from which any component needs to be substracted.
Upgrade_Storage_Volume (accessory bays) - as I would like to understand it - could actually add to the total available voulme (Equipment_Space) by extending the hull with external features. Here's a visual (non Vega Strike) example of what I mean:
Picture 1: shows a Wotan Mk2 Class Freighter without Hull Extensions
Picture 2: shows the same Ship with a set of booster drives
Picture 3: shows the same Wotan Mk2 Class Freighter with Cargo Bay Hull Extension and more powerful Booster Drives.
This probably (also) fits into the area equipment "mounts". For the drives that expanded hull volume does not need to be calculated as drive "pods" will full occupy their own hullextension, they only add mass and geometry and consume energy or fuel or both.
Last edited by riftroamer on Tue Dec 13, 2011 12:31 am, edited 1 time in total.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Expert Mercenary
- Posts: 893
- Joined: Thu Jul 08, 2010 11:43 pm
- Location: Sol III North American Continent
Re: [WIP] Modular Ships
Cool ship!! Where does it come from, and what usage restrictions are there on the mesh?
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
Well, I modeled it for use in illustrations for a pen&paper scifi-rpg I develloped. Recently I modified the ship to meet gaming requirements regarding mesh quality poly count and poosible LOD variants and also added a new cockpit section and some details taken from the public domain shipyard.blend library and I will likely use it for a mod I plan to base on vega strike in the distant future.
Never thought about license conditions or usage restrictions, but since VS will provide a cool game engine for my fantasies I might provide a vessel with a compatible license as well. I am no good texturer at all though, so the model would come as is.
This was the original "Mark One" by the way:
I will think about this.
Never thought about license conditions or usage restrictions, but since VS will provide a cool game engine for my fantasies I might provide a vessel with a compatible license as well. I am no good texturer at all though, so the model would come as is.
This was the original "Mark One" by the way:
I will think about this.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
Try not to sort it for the moment, just so if we want to copy across a column from the spreadsheet to the units.csv we won't have any issues, unless its ok to sort the ships in the units.csv. I think most of the masses, volumes etc were just random numbers picked by the designer. I was hoping the spreadsheet would be able to give us some preformace ratio's, eg density, cargo space/mass. Density would be good to check the ships have an appropriate mass for their size, but it will be a estimation, due to the shapes of most ships. Cargo space/mass should help identify the hauler ships, and highlight any ships that might seem a bit over powered when it comes to roles, etc.
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: [WIP] Modular Ships
It doesn't toggle everything in jump point's range (such as newly arived ships) to the other side, so the work area matters too.travists wrote:As such, I would think that the drive plays a larger part in jump speed, energy usage, etc. than the hull would.
How much, is a matter of parameters. Which can be set arbitrarily.
It's a column that isn't present in default units.csv currently, but seems fully supported internally. As all units.csv data, it's an arbitrary value, thus depends on how a designer defined it.riftroamer wrote:@TBeholder: Is the "raw Equipment_Space (empty hull space)" derived from the models dimensions or a value that was made up during the deisign process? I haven't checked, so I don't want to imply the one or the other. Would be just good to know, if it needed recalculation.
I agree the we should have some sort of "useable" total available hull volume from which any component needs to be substracted.
It's volume indicated on upgrade screen. Extra meshes are currently implementable in data only as subunits (and mounts) - and it's a separate and highly pressurized can of worms.riftroamer wrote: Upgrade_Storage_Volume (accessory bays) - as I would like to understand it - could actually add to the total available voulme (Equipment_Space) by extending the hull with external features. Here's a visual (non Vega Strike) example of what I mean:
"Meshes for upgrades" as such is a sensible idea and probably will be implemented... once there's a way to point where something is plugged, i.e. uni-slots again.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
Let's grab that can opener over thereTBeholder wrote:Extra meshes are currently implementable in data only as subunits (and mounts) - and it's a separate and highly pressurized can of worms.
The highly pressurized can reminds me of a Swedish "delicatesse" called Surströmming which is left inside the can until it visibly deforms due to fermentation. It doesn't sound delicious and it isn't
Well how about placing upgrade markers on the model the same way that drive exhaust markers or turret markers are used in Blender? The marker is such an elegant solution that it just begs to be used for more (except for the "spiked" look of the final model if you forgot to turn off layer two when rendering )TBeholder wrote:"Meshes for upgrades" as such is a sensible idea and probably will be implemented... once there's a way to point where something is plugged, i.e. uni-slots again.
The ship's designer of course has to make sure to name the upgrade components that fit to each mount. Perhaps we could also define a bounding-box size (small. medium, heavy, capital) with a defined origin into which each component has to fit, with the origin being the mount point that correlates to the marker.
Last edited by riftroamer on Wed Dec 14, 2011 7:03 pm, edited 1 time in total.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
Ok, have added fuel tanks to units.csv and master_part_list.csv, haven't added the upgrades for sale yet to anywhere, want to add them to all stations or just select few? No pictures yet either, couldn't find many that looked like a reactor fuel storage unit in a space ship.
You do not have the required permissions to view the files attached to this post.
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
Oh my, seems I am a bit behind now. Well Blender 2.49 with volume calculation script is running fine now, so I can go through the ships one by one, scale them according to the value in - I think it's in your google-doc - and run the script to take a note from the console output. Since it also calculates surface area, I'll jot that down too, as it might be useful for calculating physical armor mass one of these days.Hicks wrote:Ok, have added fuel tanks to units.csv and master_part_list.csv, haven't added the upgrades for sale yet to anywhere, want to add them to all stations or just select few? No pictures yet either, couldn't find many that looked like a reactor fuel storage unit in a space ship.
I don't know how good the numbers are, the script works on triangulated non-manifold meshes (closed meshes) only, which should be true for any of the models.
It takes each triangle and it's distance from the origin and calculates the volume for the resulting irregular tetrahedron. It adds all volumes for those tetrahedrons together whose normals are pointing away from the origin and substracts those whose normals point towards the origin. It also adds all triangle areas together.
And just for the record: I found it on blenderartists.org, so I didn't code it.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: [WIP] Modular Ships
Start a game, hack some megaCRs in savegame, buy a capship with turrets, dive into landing height of a planet, eject, buy a ship with decent weapons, launch, blow up a capship's turret, switch controls to capship and land. Congratulations: you can't replace the turret, it's gone.riftroamer wrote:Let's grab that can opener over thereTBeholder wrote:Extra meshes are currently implementable in data only as subunits (and mounts) - and it's a separate and highly pressurized can of worms.
What happens in Blender is highly irrelevant, as it doesn't make it into VS model.riftroamer wrote:Well how about placing upgrade markers on the model the same way that drive exhaust markers or turret markers are used in Blender?TBeholder wrote:"Meshes for upgrades" as such is a sensible idea and probably will be implemented... once there's a way to point where something is plugged, i.e. uni-slots again.
Mount setup (and Lights as an abridged version) in units.csv does work fine, but using this mechanism for anything else requires not merely copypasting up support for one more column, but deeper changes in code. Specifically, extending the mount tag mechanism to accept arbitrary, non-hardcoded tags - BTW, that's more or less what subunits do and where they fail the worst. Perhaps as an indexed table? Then add at least one more tag for control purpose. If done right, it would become generic enough system to include Mounts, Lights and maybe Subunits as subsets. It can be done, just will take time.
Mounts have gun models and scales. As to the boxes, there's mesh and Rapid_Mesh fields, maybe the latter can be used for collision mesh and/or substitute primitives (box/sphere).riftroamer wrote:The ship's designer of course has to make sure to name the upgrade components that fit to each mount. Perhaps we could also define a bounding-box size (small. medium, heavy, capital) with a defined origin
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
riftroamer, is the model volume you listed that of the model in blender or the ship scaled in game? Just interesting the first ship you did has more cargo space then the volume of the ship. When we get most of the ships done, we might want to look at rebalancing the ships, as some of them seem a bit out of wack.
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
It was the model used for my testing and playing around, but already scaled by the factor given in the tables. I noticed the difference too and found some more details that I am currently looking into.
The Admonisher model for example has meshes for the lights at various positions on the hull that add to the dimensions shown in blender. It also has three (?) LOD meshes that have slightly different measures (which wouldn't be too problematic). I have to see how the LOD meshes behave when running the volume calculation script.
Perhaps I can load the model with the submeshes as individual parts, so I can select only one hull mesh to grab measures and volume. Have to play with the OBJ importer.
Well it seems that any given subject of VS one is looking into opens some sort of pandoras box. Exciting And RL is "interfering" too - of course - so progress is slow.
The Admonisher model for example has meshes for the lights at various positions on the hull that add to the dimensions shown in blender. It also has three (?) LOD meshes that have slightly different measures (which wouldn't be too problematic). I have to see how the LOD meshes behave when running the volume calculation script.
Perhaps I can load the model with the submeshes as individual parts, so I can select only one hull mesh to grab measures and volume. Have to play with the OBJ importer.
Well it seems that any given subject of VS one is looking into opens some sort of pandoras box. Exciting And RL is "interfering" too - of course - so progress is slow.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
@Hicks: Sorry about the delay... I had a little time playing around with the object importer in Blender. In Blender 2.59 to 2.61 there doesn't seem to be a nice solution to get separate meshes to work with. In 2.49b however - the same version the volume calc script works in (how convenient) - the importer can separate the mesh by material.
The original intention was avoiding the material index problem of older Blender versions (no more that 16 material slots per Model), I think. But it helps separating the lights from the body upon importing for example.
Since I don't really want to load each model and manually separate meshes this solution apeals to me
Measures are off of course. Example "Admonisher": Unit Converter states the measures of the combined mesh (including the meshes for the flashing lights sprites), as does Blender when not separating the mesh upon import. The corrected values differ as follows (not scaled yet):
Unit Converter
Length: 30.9531 Width: 47.5644 Height: 38.1295
Blender Model (1/10th scale)
Length: 3.095 Width: 4.158 Height: 3.221
So to get the correct volume I have to separate the sub-meshes within blender for each model *sigh*.
I will append the data to the googledocs-file one by one as I work on this.
---
Happy New Year, by the way
The original intention was avoiding the material index problem of older Blender versions (no more that 16 material slots per Model), I think. But it helps separating the lights from the body upon importing for example.
Since I don't really want to load each model and manually separate meshes this solution apeals to me
Measures are off of course. Example "Admonisher": Unit Converter states the measures of the combined mesh (including the meshes for the flashing lights sprites), as does Blender when not separating the mesh upon import. The corrected values differ as follows (not scaled yet):
Unit Converter
Length: 30.9531 Width: 47.5644 Height: 38.1295
Blender Model (1/10th scale)
Length: 3.095 Width: 4.158 Height: 3.221
So to get the correct volume I have to separate the sub-meshes within blender for each model *sigh*.
I will append the data to the googledocs-file one by one as I work on this.
---
Happy New Year, by the way
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
Thats cool, there is no big rush to do this. I can write up the upgrades for the SPEC drives now, and we can adjust the cost for each ship later when we have the data.
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: [WIP] Modular Ships
Upon importing? It doesn't just read different material sections in OBJ as different meshes? Wings3D does, for one. Of course, Llama is split to 3 different parts even without lights...riftroamer wrote: But it helps separating the lights from the body upon importing for example.
What for? Just to calculate volume? What's wrong with creating a simple boxy mesh fitting inside ship's own meshes and measuring it?riftroamer wrote: Since I don't really want to load each model and manually separate meshes this solution apeals to me
Measures are off of course.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
Yeah, might be. I don't consider myself an expert with Blender, but it's one tool I am used to. Wings3D ins't. I started 3D with Cinema 4D but that OBJ Importer was crappy at that time.TBeholder wrote:Upon importing? It doesn't just read different material sections in OBJ as different meshes? Wings3D does, for one. Of course, Llama is split to 3 different parts even without lights...riftroamer wrote: But it helps separating the lights from the body upon importing for example.
Yes, just to calculate volume See, there are about 80 different hulls/ships to be measured. For now my approach would be:TBeholder wrote:What for? Just to calculate volume? What's wrong with creating a simple boxy mesh fitting inside ship's own meshes and measuring it?riftroamer wrote: Since I don't really want to load each model and manually separate meshes this solution apeals to me
Measures are off of course.
Import Object separated by material, rightclick to select one of the LOD meshes, hit ALT-P in scripting mode. Jot down the volume, discard model, and repeat with next model. That's two mouse-clicks and one Keyboard shortcut within blender after loading the model.
There's nothing wrong with your approach, but for the task at hand, why should I load a model, create a box (ore several) translate and scale it (them) to fit inside hull (likely leaving quite a few sections empty since most ships aren't boxes) then manually take the measures of that box(-es) and calculate volume(s) from dimensions, then repeating with the next. Sure, it would only take minutes per model, but I believe my proposed way takes seconds. And it possibly gives better values since the volume is derived from the actual hull mesh. But I may be wrong.
I'll start this afternoon with a few of the simpler models and test both approaches. Since I wan't to have the total volume that will fit inside each hull, I would need to create more that one Box with your approach to have the best fit and add volumes together. No big deal, as I wanted to verify the values from the script anyway.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
Ok, I dabbled around with some of the models. And used the hawking to create a mesh fitting inside the hull to manually calculating the volume. The script gives larger values of course since the simpler box model fits inside the original hull, so I am confident enough to say that the script is working correctly.
Some models end up with canards and stub wings penetrating the hull, sub-meshes not being closed and the like after importing separated by materials.
In addition to that triangulation is a must. So for most models the process is now slightly modified:
Slightly more work but still very manageable.
@Hicks: All values written into the googledocs-file are unscaled, still! The volume changes cubically with the scale (i.e. divide scale by ten means dividing volume by 1000 (scale^3), while surface area changes with squared values (divide by 100 (scale^2)). Will correct that later.
If someone want's to try, here's the blend and the script.
Some models end up with canards and stub wings penetrating the hull, sub-meshes not being closed and the like after importing separated by materials.
In addition to that triangulation is a must. So for most models the process is now slightly modified:
- - Import Object separated by material into Blender 2.49b, right click to select one of the LOD meshes (with mousepointer in 3d window), or left click in Outliner window.
- Hit TAB (in 3d window), hit ctrl-t (to triangulate), hit ctrl-n (to recalc normals outside), hit TAB again.
- Hit s (to scale), type scale factor, hit Enter, hit Ctrl-a+1 (to apply scale, rotation, etc.).
- Hit ALT-p (to invoke script) in script-window.
- Jot down the surface area and volume from console window.
- Discard model (hit x-Enter in 3d window), and repeat with next model.
Slightly more work but still very manageable.
@Hicks: All values written into the googledocs-file are unscaled, still! The volume changes cubically with the scale (i.e. divide scale by ten means dividing volume by 1000 (scale^3), while surface area changes with squared values (divide by 100 (scale^2)). Will correct that later.
If someone want's to try, here's the blend and the script.
You do not have the required permissions to view the files attached to this post.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: [WIP] Modular Ships
That's a good point, but depends on what you want to end up with. If just somewhat more sensible volumes, why not.riftroamer wrote:create a box (ore several) translate and scale it (them) to fit inside hull (likely leaving quite a few sections empty since most ships aren't boxes) then manually take the measures of that box(-es) and calculate volume(s) from dimensions, then repeating with the next. Sure, it would only take minutes per model, but I believe my proposed way takes seconds. And it possibly gives better values since the volume is derived from the actual hull mesh. But I may be wrong.
Most ships are not berries stuffed with equipment either. They got bulkheads, beams and whatnot inside and whole external parts like Llama's connector or Derivative's consoles that got considerable volume in bulk, but don't look like there's much places for equipment boxes between structural elements. So the raw external volume at least isn't more meaningful than a box or two turned trapezoidal inside the hull.
That, too.riftroamer wrote:Some models end up with canards and stub wings penetrating the hull, sub-meshes not being closed and the like after importing separated by materials.
On the other eyestalk - as often as not docks, mounts and turrets are misplaced/misaligned, sometimes even lights are absent, external boxes need to be calculated for volumes as cargo/ammo... So, the models will need some review either way. Instead of this quickfix, or after it, all the same.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
when i go through the numbers and rework some of the volumes, i won't be setting the cargo space to the volume of the ship, it may get set to half or something for a large transporter, depending on the shape of ship, but battleships would have a rather small cargo hold compared to its volume, and fighters won't have much of a cargohold at all, maybe none, and just a small volume of upgrade space.
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
Does anyone know how ships are classified? eg small fighter, frieghter, etc. Is it based on size, weight, firepower? Was it just what the designer wanted the ship to be? Might look at redoing a few of the classifications. I have noticed 10 ton fighters being heavy and 150 ton fighters being light. Might try and set up some sort of standard based on weight or volume.
-
- Expert Mercenary
- Posts: 893
- Joined: Thu Jul 08, 2010 11:43 pm
- Location: Sol III North American Continent
Re: [WIP] Modular Ships
My thoughts:
Rating
Light, Medium, Heavy are all relative to class. While mass is a fair predictor of armament, combat craft ratings are based on weapon loadout more than mass. For transports, LMH is mostly capacity.
Class
**Combat**
Interceptor: Short range, high speed, fair loadout, typically low mass. Used to attack incoming forces before they can reach striking range.
Scout: Long range, high speed, light loadout, typically low mass. Used on patrols and unsuited for protracted fights, but capable of defending its self when needed.
Fighter: varied in range, speed, loadout, and mass. Generally light indicates fast and limited loadout, while heavy is slow and highly armed.
Bomber: Medium range, low speed, heavy loadout: primarily missiles, typically high mass. Used to attack capitol ships and small bases, it packs a wholup, but is vulnerable to fighters and the like due to low speeds and turning radii.
Gunship: Medium range, medium speed, heavy loadout: primarily guns, typically high mass. When concentrated fire is a must!
More later, but I think the idea should be clear. A "light" bomber is many times the mass of a "heavy" interceptor. While a heavy bomber has less mass then a light capitol ship.
Rating
Light, Medium, Heavy are all relative to class. While mass is a fair predictor of armament, combat craft ratings are based on weapon loadout more than mass. For transports, LMH is mostly capacity.
Class
**Combat**
Interceptor: Short range, high speed, fair loadout, typically low mass. Used to attack incoming forces before they can reach striking range.
Scout: Long range, high speed, light loadout, typically low mass. Used on patrols and unsuited for protracted fights, but capable of defending its self when needed.
Fighter: varied in range, speed, loadout, and mass. Generally light indicates fast and limited loadout, while heavy is slow and highly armed.
Bomber: Medium range, low speed, heavy loadout: primarily missiles, typically high mass. Used to attack capitol ships and small bases, it packs a wholup, but is vulnerable to fighters and the like due to low speeds and turning radii.
Gunship: Medium range, medium speed, heavy loadout: primarily guns, typically high mass. When concentrated fire is a must!
More later, but I think the idea should be clear. A "light" bomber is many times the mass of a "heavy" interceptor. While a heavy bomber has less mass then a light capitol ship.
-
- Bounty Hunter
- Posts: 153
- Joined: Sat Oct 22, 2011 9:17 am
Re: [WIP] Modular Ships
It might be better to classify ships based on their mass, as ships of similar mass would have similar preformance. And then we have to distinguish between class and role. You can consider and interceptor to be a small fighter that has upgraded engines, scouts would be a light fighter with reduced armour/increased speed.
Combat Vessels
Single cockpit
Fighter -Small, Medium, Large. Uses light missle, guns. Rear facing turrets on heavy fighters?
Bomber - Light, Heavy - Uses heavy missle and torpedos, used to engage large slow moving targets
Requires Crew
Frigate
Destroyer
Cruiser
Battlecruiser
Battleship
Carrier
Civillian Vessels
Cargo- subclasses to represent equivilants to trucks, trains and container ships?
Transporters - transports people/whatever you want to call other races
Utility - Builders, repair, refuel etc
Would like to change how ships are listed in the game at the moment by removing the factional catergories, and placing a "manufacturer" feild in the description. For example, instead of opening up 4 faction tabs to find 1 light fighter under each, you open the light fighter tab, and find 4 fighters there, with their faction in the description
Combat Vessels
Single cockpit
Fighter -Small, Medium, Large. Uses light missle, guns. Rear facing turrets on heavy fighters?
Bomber - Light, Heavy - Uses heavy missle and torpedos, used to engage large slow moving targets
Requires Crew
Frigate
Destroyer
Cruiser
Battlecruiser
Battleship
Carrier
Civillian Vessels
Cargo- subclasses to represent equivilants to trucks, trains and container ships?
Transporters - transports people/whatever you want to call other races
Utility - Builders, repair, refuel etc
Would like to change how ships are listed in the game at the moment by removing the factional catergories, and placing a "manufacturer" feild in the description. For example, instead of opening up 4 faction tabs to find 1 light fighter under each, you open the light fighter tab, and find 4 fighters there, with their faction in the description
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: [WIP] Modular Ships
I'd prefer in most cases to have assigned ready for equipment only bare minimum and for cargo only a little box next to the dock (if there's any). Almost everything else - raw Equipment_Space, to be used for cargo and accessory bays. With few exclusions like Yeoman's cans, but these aren't subunits only because subunits don't work properly or efficiently right now.Hicks wrote:when i go through the numbers and rework some of the volumes, i won't be setting the cargo space to the volume of the ship,
Goods categories are related only to availability and prices (not used for ships), set on per faction basis and thus are completely arbitrary otherwise.Hicks wrote:Does anyone know how ships are classified? eg small fighter, frieghter, etc. Is it based on size, weight, firepower? [...]I have noticed 10 ton fighters being heavy and 150 ton fighters being light. Might try and set up some sort of standard based on weight or volume.
For launched ship, what they will try to do is defined only by AI roles.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Expert Mercenary
- Posts: 893
- Joined: Thu Jul 08, 2010 11:43 pm
- Location: Sol III North American Continent
Re: [WIP] Modular Ships
I too would prefer that the ships internal volume be uncategorized, and cargo space is a function of cargo bays loaded.
-
- Merchant
- Posts: 45
- Joined: Mon Nov 01, 2010 2:32 pm
- Location: Sol, 3rd rock from the sun
- Contact:
Re: [WIP] Modular Ships
Intresting thought, but hardly "realistic". Modern day ships or airplane are seldom designed to load cargo bays, powerplant modules, propulsion systems or living space at will, at extremes changing at every port.travists wrote:I too would prefer that the ships internal volume be uncategorized, and cargo space is a function of cargo bays loaded.
Ships are usually build to specification set by the future owner. Cargo freighters don't need raceboat hulls, and raceboats won't usually be converted to a mobile infantry transport every now and then. There's always room for exceptions but you get the point.
It's more likely to have a hull design with a certain fixed space reserved for cargo, engineering, living space and possibly some space that could be used for specialities the owner wants (equipment space). Or something like the Yeoman where each can might theoretically be anything from Advanced labs to Zero gravity sports centers.
Then on the other hand special modules (upgrades) could allow for lab-, passenger- or other modules (think containers here), which convert cargo space for other optional uses (at the cost of each module being lager than those built into the hull). In emergency situations these could be jettisoned too
@hicks: if classification has no game influence we should make up a list of classes like shuttle, fighter, corvette, frigate/destroyer, cruiser, carrier, battleship, trampfreighter, freighter/ fleet supply, megafreighter/ tanker, liner, superliner, etc. with a range stating minimum and maximum metric tonnage (=volume in cubic meters) for each.
Then divide this range in three or four roughly equal chunks for light, medium and heavy, perhaps super-heavy and youre done. And calculating total hull volume has one more benefit
Specialities of the classes could then be further refined/adapted by trying to relate the ships to the best suited AI-role.
And on the eighth day the Lord went riftroaming...
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723
IMTU tc+ tm+ tn+ tg ru- ge+ 3i c+ jt au+ pi+ he+
OTU 42% au+ br- cpu- fs- ge+ j- ti+ tv+ uwp+
Tarlon Rhaan 0201 C88885A-9 S hi as+ va- so- zh vi+ da 723