need help here

[klauss]

Yep, it's good to show why things move as they do.
I was referring to maneuvering thrusters. Usually, those are fixed (but many), and light up as required. Having moveable maneuvering thrusters I think is impractical in RL, but don't mind me... it's your design.

[chuck_starchaser]

There are compromises to consider. I think that if the maneuvering and up/down and lateral thrusters are smaller than the main engines, the corresponding accels should be proportionately less, to remain congruent. Thus, fixed secondary thrusters would have to be quite large to justify current VS stats. If secondary thrusters were made as large as to agree with current ship stats, they'd be questionable in terms of economy. Too many of them too large would make a ship very expensive. Better to have them vectored. But vectored thrusters can't be too large either, as the forces imposed by the present (ridiculous) accelerations would destroy any kind of pivoting mounts. That's why when I was working on the autopilot I decided that the only solution was for ships to turn around 180 degrees, in order to deccelerate for the second half of the trip.

[Tarran]

I wasn't thinking as in full thrusters.. just something explain a more manuverable ship.. like an extra boost.. nothing major..

I put in the model to show you what I'm doing.. its still very much in the rough stage..

[Ryder P. Moses]

Vectored thrusters can be handy for some things. For one, they mean you've got fewer delicate parts on the surface of your ship just waiting to be shot off. Which is especially handy when said delicate parts have a fuel line back to your highly volatile reactor. Also, they look cool, and that's as good a standard as any, really. Ideally you only have six thrusters anyway, and assuming a displacement drive their surface portions don't need to be very big, but maneuvering jets can take that down to two if you need to.

Personally I'm not a fan just because they're a bleeding pain in the arse to model even when you're not trying to cram them into some game's overly finicky conversion setup. But that's just me.



By the way, what are the exact differences in the post-Ogre importing process going to be?

[Tarran]

6 thrusters? I can think of 5 offhand..

[Ryder P. Moses]

To the rear: Up, left/down, right/down. Same to the front, or inverted, doesn't matter. You don't want to have one or two thrusters on either side, because then you won't be able to manage your rotation in at least one axis, at least not without steering wildly out of control to correct and probably crashing into whatever's out there that's giving you a reason to maneuver in the first place.


Of course, if you don't care about being able to turn on a dime (or a small moon, for that matter), you can make do with only the three rear thrusts and maybe a forward 'braking' thrust for all those wussies out there, and just have to do big loops around and accelerate back the way you came to slow down- not exactly conducive to docking or anything, though, as depending on your speed and the angle the thrusters face from 'forward' (and if it's too high, you're gonna be damn slow, mind) your ship may well be only accurate down to a mile or more. You might totally miss whatever youBut I imagine few players would be interested in having to deal with that- might be cool to see AI ships handle, though, were they smart enough to not just totally spazz at the different flight model and crash into things.

[klauss]

By the way, what are the exact differences in the post-Ogre importing process going to be?

Well... there's a basically launch-and-forget converter script to go from obj->mesh, or bfxm->mesh, which is the starting point.

Sometimes (very few), you'll have to get your hands dirty and modify the material scripts that are part of the .mesh files (in separate .material files - actually, not even - I'm almost finishing a .materialInstance script which is much - and I mean much - more easily handled), because sometimes the automated output isn't enough. Like, for instance, when you use some common nonstandard texture (like in textures/ folder instead of units/blah/ - you have to specify the correct path). With .materialInstance scripts, it will be a breeze, so don't worry about this.

Now... that's for a .mesh file.
Post-ogre models will consist of multiple .mesh files:

First, one for each LOD level. (Ogre handles them this way... there must be a reason).
Next, you have the option to specify different meshes for:

• Ship (in space)
• Ship (landed)
• Cockpit
• Room (a kind of cockpit accessible through base interface)
• Shields
• Collision Ship (not visual - for physics)
• Collision Shields (physics again)
• Thruster

Now... each item on the list (and I mean all of them ) is optional.
So, you need not specify all of them.

To specify them, first you must have them (create the .mesh files), and then create a .model script (a text file similar to material scripts).

Actually, the converter will generate a default script, suitable for current models (single-mesh models), so you won't have to do all that stuff if you're creating a simple model (although, I would really really really recommend using all that power - at least thrusters).

Each thruster will have various "behavioral" parameters that you can and must specify, that will allow modelling pretty much every kind of thruster I could think of.

[Tarran]

whats the largest size an object can be in VS for units?

[jackS]

whats the largest size an object can be in VS for units?

In terms of game-engine issues, or in terms of how big are the largest craft in use?

[Tarran]

knowing both would be kosh.. I always thought one of the aera ships was the largest one..

[jackS]

knowing both would be kosh.. I always thought one of the aera ships was the largest one..

The Leonidas class is ~ 7 kilometers long. The current star fortresses are ~12 KM in the longest dimension. Both of these models are slated for replacement, but the scale is not too far off.

From the engine perspective, the only meaningful limitations are IEEE 754 floating point accuracy (single objects with radii much more than 65 KM or so start drifting over the centimeter accuracy mark, iirc) and efficiency issues - objects can be quite happily massive (see planets), but certain operations may become more expensive to compute accurately, or may require their own code path (again, see planets) if the object is truly divergent in size from all of the other objects (thousands of KM in radius).

[Tarran]

what would be an exceptable size ingame? (rather than sitting at the edges of what the engine deals with )


-=added on=-
by and by.. thank you folks for all the help you've given

-=more added on=-
whats greeble?

[chuck_starchaser]

whats greeble?

http://vegastrike.sourceforge.net/forum ... php?t=4915

[Tarran]

is there a way to make it so a ship can only use weapons that fall under a cannon catagory (I don't think it exists.. ).. or so that a weapon can only use certian types of weapons.. not like the light, special, or that.. but can only use specific weapons out of each different existing catagory

also.. I can't seem to export to blender.. the closest thing I have is vrml 2.0 in wings, however blender does 1.0.. blender won't read 3ds files (which someone suggested earlier)

[chuck_starchaser]

Export to .obj (+.mtl); Blender will import that.

Why would you want to only have one weapon? There's nothing more fun in the game than upgrading... Unless you mean only spawning npc's with one weapon, but that's a spawning issue. You can control the size category of the mounts, in units .csv.

Come to think of it, there could be, and perhaps should be, standard weapon hard points in cvs, that modelers can download and import into their ships. That way no one could define a ship 6 cm across and give it capship weapons.
Also, how about setting reactor room requirements for the various reactor sizes?
Cargo space should also be justified and shown where it is in the model, make sure there are no ships with more cargo space than their computed total volume; stuff like that.
Mountpoints for engines, as well, could use some standardization; like I hate to see a ship with powerful engines, capable of absurd acceleration, yet that mount at the ends of flimsy wings...

[Tarran]

Export to .obj (+.mtl); Blender will import that.

I had tried that before I kept getting an error .. unknown file type.. however I'm likely going about it in the wrong manner.. I'll have to look that up and see

Why would you want to only have one weapon? There's nothing more fun in the game than upgrading... Unless you mean only spawning npc's with one weapon, but that's a spawning issue. You can control the size category of the mounts, in units .csv.

there is this thing.. which looks like a cannon .. so what I had in mind, was maybe restricting it to certian things.. like stormfire, disruptor cannon, razor cannon.. but they aren't really a catagory.. they belong to other catagories..

[Ryder P. Moses]

Tarran: Yeah, there's a tech-restriction list in the unit spreadsheet. However, you can't specify particular hardpoints- it only blacklists technologies for the entire ship. Which is too bad, and should be changed at some point.


Chuck: Uh... for gameplay. Because, believe it or not, it makes ships more interesting when every ship can't have everything all the time, and some are specialized to do certain jobs.

Also, I'd really rather nobody went and started restricting what could be created in the game, for my own sake. If you don't want any 6cm ships with superweapons, or any models that don't fit your personal standards of engineering accuracy, just don't load any into your copy of the game. Personally, I think that sort of thing is quite useful for, say, simulating long-range surprise attacks, especially since VS doesn't really model ships that exceed a fairly short range. Arbitrary restrictions which aren't necessary to keep the game from crashing, that exist solely because someone decided they don't fit the particular atmosphere of the main VS universe (especially when there's so many different mods going on already, even while the game's still in beta) seem really counterproductive and just not a bright idea to me.

Besides, there's an upgrade space value already in place in the game, it's just that all upgrades no matter how massive take up only one space. You want to have space management (which is quite a good idea, really), then code for objects to take up multiple space slots and a textual unit/weapon creation standard for 'official' VS prime objects is what you want- not some wierd rule code that crashes the exporter if a model has 500 units of space but displaces only 499 cubic meters.

[JonathanD]

Definatly with you here Ryder...

adding restrictions for the sake of restrictions is usually a bad idea... this is there balancing stuff comes into play and what it's for.

I think it would be quite cool if ships were a bit more restricted in what they could have. For one thing, it gives you more reason to go after a specific ship, and it gives more meaning to different ships for different jobs. Could also make ship descriptions more interesting...

"The pooper-scooper is the only ship capable of mounting the feared 'kitty litter' cannon due to the complex loading mechanism required for this gun..."

So maybe some ships would have certain guns that could be removed but replaced with nothing else, or are irremovable. Or only changable within a certain class containing a few similar weapons of slighty different costs/ranges/capabilities. Maybe the mount could be upgraded to handle a larger gun at some point.

Thing is, this all sounds pretty complicated against the engine as it stands... but would add a whole new dimension to ship upgrades. AND it would pretty much make good descriptions of weapons and ships a requirement (something lacking right now.)

[chuck_starchaser]

Chuck: Uh... for gameplay. Because, believe it or not, it makes ships more interesting when every ship can't have everything all the time, and some are specialized to do certain jobs.

I've been the biggest proponent of ship specialization around here; but for specialization to be "interesting" we need the ability to command a flight group or fleet and use strategy. That way, interceptors can specialize in intercepting, while your bombers do nothing but bombing, and your assault troop carriers board enemy ships. We don't have such capabilities yet and they go together with ship specialization; therefore I either mention both in the same paragraph, or I mention none. In this case, I chose to mention none, since specialization and fleet tactics are both rather OT in this thread.

Also, I'd really rather nobody went and started restricting what could be created in the game, for my own sake. If you don't want any 6cm ships with superweapons, or any models that don't fit your personal standards of engineering accuracy, just don't load any into your copy of the game.

Okay, well, I say to you if you want any absurd ship following no standards whatsoever, just load them into your own personal copy of VS.

Personally, I think that sort of thing is quite useful for, say, simulating long-range surprise attacks, especially since VS doesn't really model ships that exceed a fairly short range.

Incomprehensible statement: What does "exceed a fairly short range" mean? Are you talking about radar range? If that's a problem it can be fixed, rather than allow 6cm ships with capship weapons ... useful?! In your mind, maybe...

Arbitrary restrictions which aren't necessary to keep the game from crashing, that exist solely because someone decided they don't fit the particular atmosphere of the main VS universe (especially when there's so many different mods going on already, even while the game's still in beta) seem really counterproductive and just not a bright idea to me.

The only one who isn't bright around here is you, pal.
To call any restriction "unnecessary" just because it doesn't prevent a crash is the least bright idea I'd come across in a long time...

Besides, there's an upgrade space value already in place in the game, it's just that all upgrades no matter how massive take up only one space. You want to have space management (which is quite a good idea, really), then code for objects to take up multiple space slots and a textual unit/weapon creation standard for 'official' VS prime objects is what you want-

Agreed.

not some wierd rule code that crashes the exporter if a model has 500 units of space but displaces only 499 cubic meters.

And what exactly is weird about such a rule?

[klauss]

Chuck, those restrictions have no place in the engine.

A) Hard to compute a mesh's volume.
B) Good luck trying to make Privateer work with those restrictions being enforced by the engine...
C) Ryder was saying (and I agree) that such rules must be enforced by the ones assembling the dataset. The engine should be provided with a dataset as consistent as the game developers want the game itself to be.

[chuck_starchaser]

But I never even mentioned the engine! Why's everybody putting words in my mouth? And I never suggested automatically computing the mesh's volume. And I wasn't talking about PR or WCU.

[klauss]

I was responding to this:

not some wierd rule code that crashes the exporter if a model has 500 units of space but displaces only 499 cubic meters.

And what exactly is weird about such a rule?

[chuck_starchaser]

But I never even mentioned the engine! Why's everybody putting words in my mouth? And I never suggested automatically computing the mesh's volume. And I wasn't talking about PR or WCU.

Read what I posted again:

Come to think of it, there could be, and perhaps should be, standard weapon hard points in cvs, that modelers can download and import into their ships. That way no one could define a ship 6 cm across and give it capship weapons.
Also, how about setting reactor room requirements for the various reactor sizes?
Cargo space should also be justified and shown where it is in the model, make sure there are no ships with more cargo space than their computed total volume; stuff like that.
Mountpoints for engines, as well, could use some standardization; like I hate to see a ship with powerful engines, capable of absurd acceleration, yet that mount at the ends of flimsy wings...

Do you see ANY occurrence of the word "engine"? Or any indication that I was talking about any kind of runtime rules?
Where I say "Cargo space should be justified and shown where...", does that sound like I'm suggesting run-time mesh volume computation?
And is this ship for PR or WCU? I may be wrong about this, but I think ships for PR and WCU would be posted in those respective threads. I consider this Vegastrike territory...

[chuck_starchaser]

I was responding to this:

not some wierd rule code that crashes the exporter if a model has 500 units of space but displaces only 499 cubic meters.

And what exactly is weird about such a rule?

Well, there's just nothing "weird" to such a rule. I wasn't talking about computing displacement. Ryder was. Okay? I didn't suggest such a rule. I simply said there'd be nothing weird with it.

[klauss]

I know, Chuck... you didn't, but Ryder did:

not some wierd rule code that crashes the exporter if a model has 500 units of space but displaces only 499 cubic meters.

And what exactly is weird about such a rule?

(and you asked what was wrong with such a rule... so I said what was wrong about that... that's all)

Notice that the rule as mentioned by Ryder implies it being enforced by the engine, becuase the exporter crashes if it's not respected.

Now... enforcing the rule by "dataset quality standard", however, is a noble goal IMO.