[Shade]

We've been doing some games with MVPs enabled lately, and some fairly serious issues have come up regarding their compatibility with retail.

1) The MVP Cain, Lilith and Hatshepsut models have turrets moved from their retail positions, meaning if the host is running MVPs and a client is not, they are impossible to hit for that client. This basically breaks several multi missions which require you to debeam warships with the quickness. If we find other models with the same issue, I'll update this.

2) The weapons subsystem on the Tauret has been moved from its original position, with fairly significant balance issues resulting. There may be other fighters which also have subsystem issues as well, and I'll update this as we find them.

3) Quite a few MVP fighters are lacking squadron badges. This may seem like a small issue, but in the MP community it is a fairly large one.

I'm not really sure how the MVPs managed to be validated for multi while these issues persisted, but frankly, as long as they're there, they're not ready. Anyway, I hope you won't take this as an attack on the excellent work being done here, but if noone mentions the problems then it's highly unlikely to ever be fixed

[QuantumDelta]

I'm actually kinda surprised this hasn't been brought up sooner, frankly the disparity can be game breaking.

It can of course happen the other way around too, if the host has no MVPs and the client does.

Thinking about it I'm now basically suspicious of any ship that's been 'HTLed'..

[MatthTheGeek]

Get everyone to play multi with no mvps. Problem solved.

[Shade]

In which case MVPs just should not be validated, which they currently are. If we have to tell people to stop using something the server tells them it's ok to use, something isn't right.

[Dragon]

And get somebody to add insygnia to HTL ships using new PCS2 insygnia editor (I would have done that, but I'm busy with real life and not really experienced with insygnia editor).
This would surely come in handy, I like squadron insygnia (if nobody will do it by the time I'll have more free time, I may take care of it).

[QuantumDelta]

Thank you kindly Dragon

[Vasudan Admiral]

I wasn't even aware you could do this in multi.
Model asset wise at least, the MVPs were simply not designed for this. Off the top of my head there will be issues like the extra turrets on the lucifer, subsystems on the hecate, small turret variations on a myriad of other ships, shape differences that would enable MVP players to fly into hangars or hull recesses and stuff where retail players cannot see or shoot, differing amounts of debris chunks between retail and MVPs, greebles on MVP ships that retail players would not be able to see when surface skimming.

To be honest I'd say they're practically incompatible. I know the multi community isn't big - what would it mean for it if the rule was no mixing of MVPs and non MVPs in the same server? How many people still use retail to play multi?

[Zacam]

Be nice if you could package define the usable assets from host to client.

Set a host with Retail for example, and it will refuse a client with MediaVPs (and vis versus)

With an appropriate popup that is. Then validation can still be retained per-Host/Server, providing the connection is with the right "Packages".

[Shade]

That would be very nice indeed, and not just for the mediaVPs. Sadly, at the moment we're having a hard time even getting new people to use the 1.20 patch or use recommended install methods for mods (for every hour we play, it seems we spend two troubleshooting new guys whose installation isn't up to spec for one reason or another), let alone anything like this.

[chief1983]

Well, it probably just needs to verify that the exact same files (not just tables, but assets too) were loaded on the client as the host.  Perhaps allow a host override to enable or disable this behavior, whichever would make the most sense.

[Droid803]

Doesn't the Deimos also have the moved turret issue?

[Shade]

We thought we remembered something of that sort on the Deimos yeah, but none of us were sure. It probably does.

Anyway, slight alterations in geometry and stuff like hangar bays etc. aren't really major issues. The gamebreakers (used in a loose sense, obviously these aren't bugs that make the game not work) are turret and subsystem locations being changed from retail, as this changes mission balance - in some cases far more than one might think. Even in a 100% mediaVPs game balance would actually be off from what has been tested and validated, though admittedly not as much as in a mixed mediaVPs/retail game.

Well, it probably just needs to verify that the exact same files (not just tables, but assets too) were loaded on the client as the host.  Perhaps allow a host override to enable or disable this behavior, whichever would make the most sense.

The absolute ideal solution from the multi community's point of view would be some system to simply not allow people with a corrupt installation to log onto FS2NetD in the first place (ideally pointing them towards IRC or the support forum for help), coupled with some kind of automated 'cleanup' function they could run to get rid of nonstandard crap plus the ability for FSO to automatically download the 1.20 patch from somewhere (even without using the installer) instead of people having to patch manually.

What I'm thinking here is that if somehow the game was aware of which files were supposed to go into the fs2 root directory, and you ran the launcher with an added -cleanup command line argument, it would sort through the folder (and ideally /data/ as well) and move everything that looked wrong to a 'cleanup' folder where people could look through it later. Between this and a self-patching ability that would probably reduce time spent on multiplayer tech support by 90%. Easy. Probably many other kinds of tech support too for that matter. Of course such awareness would need to be able to work with TCs and the like which use completely different setups from fs2, so not sure exactly how it might be done. Hardcoding it would definitely be out.

However, ideally, the ability to block users of certain mods (in this case, mediaVPs) from joining games at the hosts discretion should not be necessary. Multi players like added eyecandy as much as everyone else does, and the FSU work is simply gorgeous. Plus if we're going to interest modern-day gamers in it, we pretty much need it to look as good as it can. So if at all possible, I'd rather see the models in question tweaked to align turrets and subsystems with their retail locations (other geometry differences are not a major issue, as mentioned before), as that would allow them to be used at the player's discretion depending on whether their system has the horsepower for it or not.

[MatthTheGeek]

How many people still use retail to play multi?

Everyone ?

I mean, QD uses retail. He definitely is the reference in that domain.

My personal opinion is, make MVPs not valid for multi. Problem solved.

[QuantumDelta]

I can just about get away with MVPs if I'm not frapsing anything in multi, but when I know we're going to be playing missions like TDiC I tend to make sure I'm using no-mod, same as when I fraps (with, one exception) during multi.


The host should really use retail models/etc, because every extra frame per second on the host computer counts towards extra packets for the clients.
When I'm not hosting, I always use MVPs, but I know more or less where to aim to hit the real turrets.

[Asteroth]

I am amused by the idea of "dogfight" versions of ships.

[Shade]

That wouldn't really solve anything in this case. That sort of thing is for mods like BP where ships are utterly unbalanced compared to each other. Here, we simply want to preserve the balance which existed in retail.

[Zacam]

So if at all possible, I'd rather see the models in question tweaked to align turrets and subsystems with their retail locations (other geometry differences are not a major issue, as mentioned before), as that would allow them to be used at the player's discretion depending on whether their system has the horsepower for it or not.

Which may not be possible if said tweaks are there because the geometry dictates that it be where it is on the new model in the first place.
And I can't and won't just arbitrarily stick it to the Retail dimensions disregarding the newer objects geometry. But we can always see about re-factoring the models to get it closer enough that we can perhaps expand the target area for the subsystem or turret in question to also cover and register a "hit" near it's retail location as well.

Subsystems are usually always placed at the retail locations (usually maybe with an increase or decrease in size to more closely match in proportion) and the dimensions of the model are supposed to match the retail dimensions as closely as possible (if and when an ABSOLUTE match is not possible, which is a rare occurrence). Mind you, that has not _always_ applied, but it has become something of a major motion for me personally to undertake and adhere to to the point that I _will_ be going through ALL of the models in SVN and validating the dimensions, mass, moi and other settings against their retail counter parts.

The reason behind why I will be doing that is, not to address this issue, but because previous versions of PCS2 would arbitrarily "pad" the bounding box area, which would ALWAYS off-set the dimensions in any given direction. As well, since the retail missiles have modeled thrusters (and our newer ones currently don't) people were using missile+thruster instead of just the body sub-object, so practically ALL of the secondary weapon dimensions were non-retail. You can guess how much of a difference that would make.

So, that's about the news as I can think of it. We already have a lot of work on our plate from the awesome amount of work that has been done over the last few months, so we'll do the best we can as time allows, just be aware of the fact that it will take quite a good bit of time to get this all done. The next Release version is going to require some patience on the part of the whole community, but it will be well repaid.

[Shade]

Not expecting an immediate fix or anything of the sort, I know the mediaVPs are a large project and you all have plenty to do. Basically posted it because, well, if we don't point out the problems they're rather unlikely to ever get fixed. These aren't the sort of problems you'd normally spot in single player, though some do actually apply there as well.

[QuantumDelta]

Things to note on that sort of front;
I seem to be completely unable to disable a number of ships with stilettos or even trebuche that you used to be able to;
GTT Elysium, GTC Aeolus, GTFr (whatever the FS1 ship was called...), I'm sure there's so more.

The orion engine also seems to be far more vulnerable to hits from the flight deck and less vulnerable to hits from below than before but the latter could just be me (the former I'm pretty sure of).

And yea, none of us are expecting this to happen right away.

The problem with the Tauret is that the weapons subsystem has been moved behind a bump that previously didn't exist on the model, where as you could disable the weapons subsystem in a head-on before, you no longer can, which as you can imagine is quite a large balance change