[mjn.mixael]

Almost forgotten... Galemps re-UVed Mjolnir: https://www.hard-light.net/forums/index.php?topic=95729.msg1884918#msg1884918
-Live debris from the 2 subsystem isn't named properly (Debris03, 04, 05 and 06 have to be renamed).

And this.

[Nightmare]

I didn't touch any of the 90 Docking Points that the current MVP model has. All I did was adding 2 more (BeDock and FeDock). However, I removed all paths (aside the bay paths) and had them recalculated via PCS autogenerate. There's theoretical room for a mistake in case they were hand-made; however, the autogenerated ones on my model appear to be identical to those of the old one
It appears that there is indeed a problem in the version I made: Path120 (Path147 of the current MVP model) goes through the model. I copy the values from the Path in the original model to my version. This appears to be the only different one.

[mjn.mixael]

Provide a fixed pof and I'll include it.

[Nightmare]

Almost forgotten... Galemps re-UVed Mjolnir: https://www.hard-light.net/forums/index.php?topic=95729.msg1884918#msg1884918
-Live debris from the 2 subsystem isn't named properly (Debris03, 04, 05 and 06 have to be renamed).

And this.

Live debris shows up when a subsystem gets destroyed; however it needs to be named correctly (as it works automatical only through naming) without further specification. If it is named Debris03, 04 and the like, FSO will consider it part of the debris layer that shows up after the death. The Knossos model is a perfect example how it has to be set up - if it would have been done wrong, both rings would simply disappear when destroyed, only to pop up as regular debris upon the Knossos destruction.

[Iain Baker]

A new MVP release? Sweet :-)

A few suggestions off the top of my head are;

How about including the custom wingman gauge as an optional extra?

https://www.hard-light.net/forums/index.php?topic=95180.0


Perhaps optional post processing filters, such as the one used in Vassago's Dirge


Perhaps further down the line, optional cockpits for the ships that have them?

One little nit-pick I have with the FS graphics thus far is that engine glows are often visible through the ship model. Is there any way to fix this?

One last things - although I suspect this isn't an MVP thing in which case apologies in advance if I'm asking in the wrong place, but is it possible to revert the god awful controls in the newer versions of the F3 ship view back to the lovely and intuitive controls the early versions had?

[Nightmare]

https://www.mediafire.com/file/xdetetae0d6ocnj/NuArcadia.7z/file

So, I checked every path that still had a potential to screw up. Everything should be OK now, however there are 2 Paths (the 2 Retail ones, actually) that look different in the new version. While I consider both improvements I'd like to have a second opinion on that:
-NuArcadia Path32 (Current Model: Path28) - chained to "topside docking": In the current model, the path is formed along a bow, while the autogenerated one is straight top-down, like all other paths of the current model on the "Arcadia Wing". It should be noted that the old one actually misses the docking point by 50 meters (this should be fixed one way or another).
-NuArcadia Path33 (Current Model: Path29) - chained to "Bigship docking": In the current model, the path goes horizontal, while in the new version it is another Top-down path. I'd say it's an improvement, as in the current model the docking path goes right through the model, however, since it's a retail path I don't know if there are any mods depending on it working that way.

[Nightmare]

One little nit-pick I have with the FS graphics thus far is that engine glows are often visible through the ship model. Is there any way to fix this?

That would be FSO, not MVP related.

One last things - although I suspect this isn't an MVP thing in which case apologies in advance if I'm asking in the wrong place, but is it possible to revert the god awful controls in the newer versions of the F3 ship view back to the lovely and intuitive controls the early versions had?

That's also on the engine-end.

[Iain Baker]

One little nit-pick I have with the FS graphics thus far is that engine glows are often visible through the ship model. Is there any way to fix this?

That would be FSO, not MVP related.

One last things - although I suspect this isn't an MVP thing in which case apologies in advance if I'm asking in the wrong place, but is it possible to revert the god awful controls in the newer versions of the F3 ship view back to the lovely and intuitive controls the early versions had?

That's also on the engine-end.

Hi there, thanks for the heads up :-)

Two more things spring to mind if you are still taking suggestions.

1: Is there a way to make the explosions bombs, cap ship torpedos etc. make when they are intercepted different and distinct from when they hit their target? It can be difficult to tell when warheads are close to the cap ships and everything is getting a bit chaotic.

2: The electricity arcs that damaged ships give off appear to be simple two-colour images when seen up close - plain blue and white. Could these be given a bit of love? It can be a little jarring seeing them up close when everything else looks lovely and graduated, bloomy etc.

[General Battuta]

You can set 'dinky' explosions for bombs when they haven't armed yet, but it would, technically, be a gameplay change, which the MVPs aren't supposed to do.

[mjn.mixael]

As far as I'm aware, those electrical arcs are created entirely within the code. I've never seen an asset defined for them.

[0rph3u5]

You can set 'dinky' explosions for bombs when they haven't armed yet, but it would, technically, be a gameplay change, which the MVPs aren't supposed to do.

You can set $Dinky Shockwave to the parameters of the weapon

[Nightmare]

Would it be possible to have all tbms of a category united in a single file? Currently, if you're setting up a mod and you want to copy the MVP values into a custom ship or weapon (like a subtype) you need to look through 3 VPs to find all data for each weapon and each ship. Nobody has ever used only a part (like the MV_Assets) as dependency for their mod without the other files; so I don't really see the point in keeping things seperate. The only problem I could think of is that some mods override the MVP tables by putting, say, mv_root-shp files into their packages. On the other hand, the mv_assets-shp was also split into pieces during the latest release. One way or another, I think it would be better to have all edits to, say, the Subach in 1 proper mv_root-wep than spread over mv_root-wep, mv_effects-wep and mv_assets-wep tbm.

[0rph3u5]

Counterpoint: having the .tbm split between packages also means that any new files referrenced in the .tbms are stored in the same package, e.g. the new Arcadia model which has new destroyable subobjects is stored in the assets_t package same as the .tbm that enables the destructibility of said subobjects.

[0rph3u5]

(Sry about split post - reason: phone)

... now that doesn't mean much for effects edits where mvps just use the retail filenames for new effects or where edits are just numerical, e.g. to scale a replacement effect to the equivalent size as retail one because e.g. post processing now takes care of some part of the effect.

However if that were to change, having the files.like they are backend editing process should be easier.

[Nightmare]

Does it? To me it doesn't make much difference as changes introduced by the MVPs are already split across several packages (showing loadout stats in selection, different model etc). Most new models have been in there for ages, too, and so far all issues that might arise from them are disabled on the MVP side by default (Lucys new turrets, many new subsystems on some Vasudan fightercraft).

[0rph3u5]

Let's run through an example: Say someone where to introduce a new model for the Leviathan to replace the one currently in 3.8.2

The 3.8.2 model has several destroyable armor plates modeled onto the ship - in leviathan.pof - which are disabled by mv_assets_t-shp.tbm, which also calls for the game to use Leviathan.pof instead of cruiser01.pof as per retail ships.tbl:

Code: [Select]

$Name: GTC Leviathan
+nocreate
$POF File: leviathan.pof
[irrelevant data cut for time]
$Subsystem:                     armour01a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
$Subsystem:                     armour02a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
$Subsystem:                     armour03a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
$Subsystem:                     armour04a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
$Subsystem:                     armour05a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
$Subsystem:                     armour06a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
$Subsystem:                     armour07a, 1, 0.0
$Flags: ( "collide submodel" "untargetable" )
Now if you were to replace with Leviathan.pof in the package is going to be mv_assets_t.vp you only ever have to edit the files that go into that package, and without having to edit anything else. So if you were going to use for-argument-levi.pof instead of Leviathan.pof you would have just to change mv_assets_t-shp.tbm to exchange the referrence under $pof file: and remove all referrences to the now no longer existing subsystems armour01a through armor07a which would no longer exist in the hypothetical for-argument-levi.pof. No other package would have to be touched.

These steps are no that different if you were to consolidate all MVPs into a single package or consolidate the tables in one place; with one big exception - keeping track of all edits and coordination them with multiple contributors.

As the MVPs are structured now you could easily assign each package an individual version number, so you can track which edits occur when. With the packages individually versioned, you can track which changes have been made and also more easily roll back a change that doesn't work out, as any change would just be contained to a single package.

Of course, none of that you would see on the user end - which makes it extra arcane looking - but helps to organize a work process.

[Nightmare]

As the MVPs are structured now you could easily assign each package an individual version number, so you can track which edits occur when. With the packages individually versioned, you can track which changes have been made and also more easily roll back a change that doesn't work out, as any change would just be contained to a single package.

Never heard of Knossos allowing you to give the individual files version numbers. I asked ngld once whether it'd be possible to have a "last change" for each file instead of the whole mod, but he said it'd take some fiddling with the way Nebula/Knossos works so no. I don't use Knossos so I can't tell myself though.

[mjn.mixael]

What's the specific use-case where someone wants to use MediaVPs table data enough that they have to tediously copy all that data to a new table, but also doesn't want to use the MediaVPs as a secondarylist mod?

[0rph3u5]

Never heard of Knossos allowing you to give the individual files version numbers.

That is making the assumption that MediaVPs are structured solely based on what Knossos can do; Knossos is the distribution plattfrom not work plattform as far as I am aware. Other software to manage a shared database allow for these things.

[Nightmare]

What's the specific use-case where someone wants to use MediaVPs table data enough that they have to tediously copy all that data to a new table, but also doesn't want to use the MediaVPs as a secondarylist mod?

I often use the MVP stats when I upgrade retail-level modpacks. As they are using the MVPs I tend to copy/paste/adapt the MVP stats to ensure that they go in line with their "look and feel" (ie piercing effects, damage type for weapons/effects and loadout stats for ships etc). The same goes for making ship variants.