mini VS???

[Moses]

at first im a frelancer modder, and working on a tc/mod called freeworlds (starwars content) for ur server, correcting bugs, adding new stuff, rebalance weapons and ships, making the whole mod/tc more starwarsish ... but there are limits, the crappy steering of the ships,tiny systemsizes and planetsizes, ugly milkshape importers/exporters, unfiendly file-format and the chaos digital anvil leave within the ini-files of the game just a few things that are realy anoying the modders ... but currently its practicly the only spacegame with shooter elements and persidend multiplayer online mode thats modable...

summmer last year i found vegastrike, and thought wow, persident multiplayer and it could beat fl in almost evry aspect exspect the low hardware requiments(fl has a dx7/8 engine that has no problens with ships of 20k poligions or more, but there r no sectacular or refectionmaps)

sadly multiplayer still isn't aviable yet or just a aphla of a deathmatch mode so i can't spend all my energy on a project where the outcome is unshure, means i will mainly stick to fl until multiplayer(mmo-style) in vs is finished ... but i like to make some basic tryouts to be ready if day comes to transfer a lot of our content to the vegastrike-engine...

... so i have downloaded the svn-version (10819) it runs smoth expect of the huge loadingtime between the systems and some framrate drops when i saw 40 powlshares around an eara ship that takes zero damages from them 0_o ... anyway i wasn't looking for balance

then i browse trough the directories and found some very confusing text:

- Mods' files have to be placed in datadir/mods/name_of_mod/ or in homedir/mods/name_of_mod/in order to be found and loaded
- To specify a mod to play use vegastrike -M name_of_mod and be sure that the mod's config file is in its mods/name_of_mod/ subdir

- Moved datadir/subdirs that contains sprites/textures into datadir/sprites/bases
- Moved the nav stuff :
- moved meshes in datadir/meshes/nav/data
- moved textures in datadir/textures/nav/default
- moved nevdata.xml in datadir

Now :
- all bases graphics should be in datadir/sprites/bases
- new nav stuff should be placed in the datadir/textures/nav/ and in datadir/meshes/nav/

what does it mean?
i only store changed files in mods/mymod/ folder and vs looks first in this folder and if the nneded flie is not there it seek in its own folders?

or

i only store changed files but have to make shure the path to original vs stuff is correct if i wanna use it?

the last note is says i should place all basegrafix in sprites/bases, files for my mod too?

very confusing its also not written what files have to be in mods/mymod/ to get vs runnig...

i like to use this modfolder thing and not placing my stuff wihin or overwrite original vs-files but i dont know how ...

the second thingy is the bfxm format i saw for the models, can i use a more common 3d-format in vs like obj,3ds,low or .x ??? does vs support one of these formats, i mean i hate converting ... while most 3d software can load and save a bunch of file-formats representing the same data in a often not that diffrent way ...

at least it would be nice to have a kind of mini-VS version that exemplary shows the possibilities of vs on the latest dev release, 2 systems, 1 planet 1 base 2 warring factions ... that would also be a good point to start off entire tc's cause u dont have to deal with so much stuff during the first steps...

[klauss]

summmer last year i found vegastrike, and thought wow, persident multiplayer and it could beat fl in almost evry aspect exspect the low hardware requiments(fl has a dx7/8 engine that has no problens with ships of 20k poligions or more, but there r no sectacular or refectionmaps)

Have you tried VS with those models?
Apart from loading times, which I gather can very well be longer, the engine itself should run pretty fast too as long as you configure it to use display lists or VBO (which are on by default, I think).
We've tried 200K models and they work reasonably well, as long as they use few textures (one or two).
In general, I've found VS has similar hardware requirements, though FL has far more stunning visuals because of those beatuiful nebulas - let chuck call them unrealistic a thousand times (and they are), but noone can deny their beauty.

what does it mean?
i only store changed files in mods/mymod/ folder and vs looks first in this folder and if the nneded flie is not there it seek in its own folders?

AFAIK, that's exactly what happens.
But that feature hasn't been used much, so it may not work 100% well - if you find any trouble with it, just post a bug report and it should get corrected.
In the next next release (the next release is 0.4.4, then comes 0.5.0 - I'm talking about 0.5.0), the whole data structure will be changed with file format changes as well, hopefully for the better. 1) loading times will be much faster because of this, 2) you'll have nice exporters, but more importantly for you 3) that modding stuff will work exactly like that, and perhaps a bit better - ease of modding is the motto.

Until now, all mods chose the easy way of modding: just replace the files. That means you have to have a separate install of the game to play both, the modded and the unmodded version. But most mods until now retain very little from other mods or the core Vega Strike, so noone really cares much about that issue.

the last note is says i should place all basegrafix in sprites/bases, files for my mod too?

Right now, yes. The engine isn't very forgiving about that, and has pretty inflexible pathing rules.
You'll have to remember, though, that until 0.5.x there will be no 3D base support - all your base artwork must be 2D sprite-based. We could hack a very simple point-and-click 3D interface if you want it hard enough, but don't expect character animation or anything like that prior to 0.5.x (and even in 0.5.x, the thing will come in gradually).

very confusing its also not written what files have to be in mods/mymod/ to get vs runnig...

Since any file not found there is looked up in the original data dir, then you only put there what is new or changed. If you don't change anything, you don't put anything there (though that wouldn't mod much ).
BTW: inside mods/mymod/, you have to mimic Vega Strike's directory structure. So, you'd also have a mods/mymod/sprites/bases with your base stuff.

the second thingy is the bfxm format i saw for the models, can i use a more common 3d-format in vs like obj,3ds,low or .x ???

Can, you can.
The engine can load .obj, not the others, but it's really bad for performance. AFAIK, the engine will call mesher, our conversion utility, to convert the obj to bfxm and use the bfxm from then on. Since the conversion not always goes smooth (it's common to have to flip normals or texture coordinates - don't ask why, but each exporter does it differently), loading .obj directly means you have no control over the conversion process. That may or may not work for you.

does vs support one of these formats, i mean i hate converting ... while most 3d software can load and save a bunch of file-formats representing the same data in a often not that diffrent way ...

Have in mind that modelling software seldom care about loading speed - that is, convenience - while games do. Hence the format differences. Plus, game formats tend to be tailored to their engine's capabilities. We, for example, use bfxm which specifies five basic textures: diffuse, specmap (also modulates environment reflections), glow, damage and detail. With obj, you can only get three of them, I think, and it's not always possible depending on what modelling software you use to create it: diffuse, specmap and glow. The easiest way I found to make materials for VS in obj files is to edit the .mtl file by hand, with a text editor, and add the relevant lines - it's really easy, and we've added custom .mtl commands for our texture types.
I think you'll find this good news (I hope): obj is the preferred import format. That is, if you can get your models into obj, it's the preferred intermediate step towards bfxm.

at least it would be nice to have a kind of mini-VS version that exemplary shows the possibilities of vs on the latest dev release, 2 systems, 1 planet 1 base 2 warring factions ... that would also be a good point to start off entire tc's cause u dont have to deal with so much stuff during the first steps...

Dandandaman was working on exactly that... Dan? Any words?

[Moses]

obj isn't the problem it seems to be highly compatible to most modeling and texturing software, turning the textures upsidedown for export ... well same crap as fl cmp-exporter for milkshaope ...

if u talk about black-paralysys, i downloaded it put it in the mods folder, started the vegastrike.exe with the correct commandline argument ... the game starts and crashes after showing a splashscreen for less than a second, without terminating the soundserver.

maybe it isn't compatible with the latest dev-release?

3d-bases uhh.. that might be cool but, does it speed up modding? will the 2d-bases still be workin?

[klauss]

turning the textures upsidedown for export ... well same crap as fl cmp-exporter for milkshaope ...

With mesher you don't have to change the texture itself, if you add -flipt to the end of the commandline, it will flip the coordinates. But if you load the .obj directly the engine will call it without the -flipt, and now you see why letting the engine convert automatically can bring some trouble.

if u talk about black-paralysys, i downloaded it put it in the mods folder, started the vegastrike.exe with the correct commandline argument ... the game starts and crashes after showing a splashscreen for less than a second, without terminating the soundserver.

maybe it isn't compatible with the latest dev-release?

Very probably. AFAIK, it hasn't been updated since a long while ago, and Dan's work on it hasn't been commited.
But Dan knows more than I about that.

[Moses]

hmmm a mescherflip.exe that flip evrything next to mescher.exe ... renaming them would solve the problem ... or a line within vegastrike.config where an aguments like -flip can be given to the used converter ...

[klauss]

... or a line within vegastrike.config where an aguments like -flip can be given to the used converter ...

That's actually a cool idea.

[dandandaman]

As per my PM, I got svn black-paralysis to a working state (6 hours it took to clear out those problems ... it looks like there was a partially failed commit or two in there or something). Sorry about it being bad before, but it works now

Dan

[Moe479]

hmmm i checked out pb from:

https://black-paralysis.svn.sourceforge ... -paralysis

Revision 41 (Dec. 28th 2006)

but still the same behavior ...

i made a testrun putting a copy of vegastrike.config (not the one that came with black-paralysis) into 'vegastrike/mods/test/' and then starting the game with 'vegastrike -M test' from commandline ... same thing the game crashes the same way ... so think there is something wrong about loading mods in general?!?

[dandandaman]

Oh, you're going about it slightly wrong (sorry bout the delay, have been holidaying in Vietnam )....

the black paralysis data set is standalone at the moment (when the ogre port comes along I'll use the proper modding stuff, but it's a little pointless at the current point in time for my purposes).

so basically just change into the black paralysis directory and run the vegastrike executable as per normal

Dan

[temporalbeing]

Just wanted to note that I've started updating VSU:Black Paralysis at https://github.com/vegastrike/vsu-black-paralysis alongside the new engine work. I emailed the VSU:BP mailing lists about this as well.

Ben

https://sourceforge.net/p/black-paralys ... /44844654/
https://sourceforge.net/p/black-paralys ... /44844653/

[ThinkSome]

Impressive revival after 16 (?) years.

Btw the sourceforge links do not work properly.

[temporalbeing]

Thanks - no, it doesn't quite work yet. I'm just starting the process of resurrecting it. I did pull all the code over from https://sourceforge.net/projects/black-paralysis/ to the GitHub account. Step one is figuring out what is missing, and step two will be making it work with the 0.9.x engine once we release it - going to try to get that released first before I put a lot of effort into VSU:BP, but it's on my agenda.