Naming of Panther PNT-9R collides with prototype Panther of same name

[nx78]

[19:07] Klink [LC]: got a technical problem here

[19:08] Klink [LC]: every time I load a mul that has a Panther mech in it the mech changes from the standard variant it was before to one with an ER LL prototype [19:09] Klink [LC]: both are named PNT-9R

[ghost]

Panther PNT-9R (3039).mtf:PNT-9R Panther PNT-9R.mtf:PNT-9R

whats the usual approach there?

and how does renaming a variation screws up players hangars?

[nx78]

Since there are no protoype Panthers in players hangars yet, it shouldn't affect them at all. Currently only hits people that do free configured (non-campaign)-games on deds

The naming problem refers to the internal naming, how it is called there, not the file name. Two units with the same internal designation (chassis and subtype) confuse MM.

[ghost]

yes that what i expected...

still... is it possible to compile a list aof all units that are in the players hangars? that way we could disable the unused for now... which should increase performance a bit as well

[nx78]

Even if there was a way (and there might be), there is no point in doing that, since there are also games played outside of the regular campaign, meaning all units will need to be available. Aside from that, it would become a major task if we had to write in and out units on each update based on state of the campaign since the tables are changing constantly as well

[ghost]

yep they do... but since the definitions already exist you would have better control about what definitions are used... and it would force players to use just the units that are available up to that campaign time

and it would make "maintanance" easier since you see better which units are used (and might cause problems) and which are not

but... yes it would mean almost twice the work when putting in new units.

okay... now to the solution i propose to name the era specific variant PNT-9R-3039

[nx78]

It would mean an update would be needed Am 30.04.2012 02:15, schrieb ajikeshi:

... and it would force players to use just the units that are available up to that campaign time which isn't the goal since free play, detached from the campaign is expressly permitted

but... yes it would mean almost twice the work when putting in new units.

We are talking about adding and removing up to a hundred units per update, and then reupdating over and over whenever something has been forgotten until we get it right the workload by that alone would rather mean 6-8 times as much work at minimum really

you'd first have to spend time on planning ahead for the time until the next update (note that we are not following fixed patterns on when updates happen so far, we only update when there is enough benefit to it, e.g. new versions that actually have imporvements or fix important bugs)

you'd then after compiling that list have to assemble the list of units still around, those need to stay in as well

you'd then have to either copy all units that are gonna appear in by hand

possibly removing all old, no longer needed units

shut down server and clients and ship the update after compiling it

at that point you will likely find that you have forgotten units and have to do more updates, until you get it quite right

coming to think of it,eight times as much work won't even cut it...this is calling for disaster to happen, even if you go and start scripting stuff it will kill off out-of-campaign play and consume much much more time than now

[nx78]

Of course you are right that the cliented is bloated, but that is due to the nature of Java and how the client is designed. Reasonably fixing that..would mean rewriting it in another language, something like C perhaps, that can be compiled for all platforms and would run a lot faster

Atthat point it would be time to get the army of coding slaves ready though, we'd need them, this is no small endeavour

[ghost]

okay what you said makes sense.

now... what to do with variations with identical names?

and if i assume correctly the stored mechs are stored by chassis+variation, if we change the chassis+variation in the mtf or blk file the client would get the unit that is left by this chassis+variation defined?

example:

hangar has a foobar FB-1A, defined is a FB-1A vehicle and a FB-1A mech

now the client reads the files and the FB-1A would be the unit with the "lowest" (as in alphabetically first) filename

is that assumption correct?

ps: i ll be writing a perlscript to check for chassis+variation being used more than once in the mechfiles

[nx78]

There are indeed two different mechanisms at work.

One is the file name, like "Panther PNT-9R.mtf" and "Panther PNT-9R (3039).mtf" respectively in this case. The file name is what is used in player files (in addition to also a list of armor etc stats that are appended there, making it tricky to "fix" some files if there is much of a difference because that can screw up units already in player hangars) The file name is also used for buildtables and such.

The second source for names is the internal descriptor, meaning Chassis plus variant as they are described WITHIN the file. This is e.g. used for identification in the mechset.txt and also MegaMek internally.

So, what needs to happen here is the internal descriptor for the variant of the Panther 3039 has to be changed Chassis: Panther Variant: PNT-9R (3039) or something of the likes. It would be best to keep those similar to the file names in style so less bugs and confusion occur.

[ghost]

if the filenames are correct and just the internal name would change... it would just fuck up the display of the unit? i mekwars and megamek to use the internal name for identification since its usually more unique than a filename

ack... PNT-9R (3039) would be the best solution

again... i think i will have the script ready in around 1 week... this way we can automagically change the names or just check if there are problems

[nx78]

Hi,

On 04/30/2012 08:50 PM, ajikeshi wrote:

if the filenames are correct and just the internal name would change... it would just fuck up the display of the unit? i mekwars and megamek to use the internal name for identification since its usually more unique than a filename Actually filenames should be unique by default, the internal descriptors are the ones that can have duplicates and the ones we need to track down and eliminate.

As long as file names are stated fully (e.g. Vulcan VlN-5.blk) there is no problem, since no two file names in the same folder can be the same (the operating system will take care of that). The internal descriptors are where errors are more likely to occur. Unless one starts to make multiple subfolders and spread out units there, in which case one is also asking for trouble to happen :-)

Originally the files cam in many fubfulders, sorted by type and then source, you'd e.g. have "mechs\TRO 3025\Atlas AS7-D.mtf" or worse It is one of the main reasons I discarded of that structure and only left top-level type-folders in place, a great many duplicates and wrongly named units turned up that way, many dozens of future bugs avoided.

So now there mostly remain errors in the internal descriptors to track down, like here in this case right now

[nx78]

fixed in today's commit