Server Kicks when package bought

hm, looks good. should be just fine. try to change the minimum rep (2nd digit, float, range -1 to 1) or give it a decimal zero. maybe microsoft did something wrong again, obviously you have nothing done wrong.

I’ve been following this with interest. The obvious solution, at least to me, simply because i’ve cloned some of the original ships in my mod as well, i see the problem as the nickname entry in shiparch.

To me you’re using the same ship nickname which is why you are getting kicked. If you change it to say,

nickname = li_freighter2

for example, should work fine. The problem is the program is trying to access two ships called li_freighter which is where the issue is as i see it. It’s the reason you keep getting kicked.

To clarify the above, any ship you add to FL HAS TO HAVE a unique nickname, end of. I have around fifty variants of a freighter in my new mod with different colour schemes for the various factions i have, the reason they all work is each ship has a unique nickname. You simply cannot share nicknames.

its not said, that the liberty freighter entry in shiparch appears multiply. but maybe gibbon, youre right in a certain different way: maybe the anti cheat detection cannot handle it if multiple packages refer to the same ship entry.

That’s exactly the problem. You will need a new shiparch entry as well, should have mentioned that. Just copy the li_freighter one and name it li_freighter2 and all will be well.

Great, yes Gibbon is right…

Only one name will work per ship model. This is because a second entry using the same model will cause a conflict, uncertainty if you like, to FL as to which one to use.

The same with a lot of other things in FL such as material names in model .mat and ship part names in .cmp files and much more.

Having said that, it could be that the cheat detection is triggering because the two ship names are too similar also.

You could rename one as tr1_package and the second as tr2_package for a test only. Keep them short, similar long names are more likely to conflict.

Let us know what happens.

One more thing - if you decide to copy the ship model as a new model, you will have problems because of what I have indicated above (internal materials and ship part names) when the two ships are near each other by chance.

So to be fully OK you will need to copy the ship into new folders, with entirely new names, and clone the ships using FL model Cloner because that will change the internal names.

er what? one ship per model? bulshit! i copied all capitals and transports to a playable version keeping the original untouched. they refer to the very same models and materials, have the same collision groups and everything works fine! no, it might be that one package per ship but not one ship per model. really not, sorry.

@ Gisteron

Why don’t you read the reply properly before flying off the handle and talking a load of rubbish.

Both ST and myself said one nickname per ship, not one model per ship for crying out loud. Each ship has to have, or come to think of it, anything in FL has to have a unique nickname. You can’t have one shiparch entry with multiple loadouts for players, for npcs yes, not for players. Therefore you need a new shiparch entry even if you use the same model but want to have multiple loadouts for players. Simple as that.

StarTrader wrote:
Great, yes Gibbon is right…

Only one name will work per ship model. This is because a second entry using the same model will cause a conflict[…]

me know what’s correct, thats not the problem. but as long as the strings are different there should be no conflict. and it is not needed to have multiple source files for different loadouts, only multiple shiparch entry. models and mats are parameters of the entry like mass, or ids_info2. many ships have same parameter values. so, no issue to expect there, likely no issues even possible.
oh, ST… gotcha!!

Gisteron wrote:
er what? one ship per model? bulshit! i copied all capitals and transports to a playable version keeping the original untouched. they refer to the very same models and materials, have the same collision groups and everything works fine! no, it might be that one package per ship but not one ship per model. really not, sorry.

Heheheh…. guess my reply wasn’t as clear as it seemed to me…

OK, Gisteron, I take your word for it. You mean you have several shiparch entries using the same .cmp, .sur, cockpit.ini and .mat files, right? That’s OK. NPC ships do that too.

But for player ships I never do that, I ensure each model is unique, although it may have an NPC version too. It makes plenty of good sense to me as I like clean mods.

But as Tan found out, he has three ships with three packages for the same shiparch model entry, and he has problems. Not in FL but in cheat detection. Which means FL has not been able to identify the ship as being sold on that base.

The model and loadout are identical to the original, working ship and he has merely changed the names only.

FL builds tables of all unique items, during startup and during gameflow as it encounters them.

In ships using the same material names you will also find the first material with that name is loaded from the first .mat file, and the second time that material name is found in another model, its corresponding texture is not loaded - the first material texture is used again, because it is already in the FL tables.

In a ship part, when two ships using the same part name are near each other or collide, the part from the first ship loaded will be overlaid onto the model of the second ship using that same part name.

As Gibbon says, if Tan changes or copies the model the problem will disappear, but I explained to him that he must also make the internal ship part names and material names unique to be sure of no further problems.

Here we are trying to help him find his problem, so far it looks like it is in the ship name. Really? Hmmm.

Some of us already know, believe me, it’s just we can’t see all your files, so I’m sorry we’re taking so long to help you fix it.

Make new shiparch entries for each ship, just copy the whole Rhino section and change the nickname, so that the nickname is found in shiparch.ini - it can point to the same DATA\SHIPS\LIBERTY\LI_FREIGHTER\li_freighter.cmp etc. athough as I say I don’t like to do that for player ships.

actually, what were talking about here is, whether the game renders the models and textures properly. this does not depend on their model parts, as we often have the situation of multiple identical ships onscreen. also, such things as portwing and starwing do appear in multiple ships and do not cause problems. third, there are less material files in vanilla then ships, meaning that multiple ships do use the same material without any collisions. freelancer has no problem with this, it is only the cheat detection. the solution is either a new shiparch entry pointing to the same files, a slight reprogram of the cheat detection or disabling the cheat detection. the problem here is only configuration based, as long as the models and materials are fine.