Server Kicks when package bought
-
try to make it use different internal equipment, one by one until you have the piece you have to check further.
have done that in post above commented out untill all that was left was the minimum needed to launch.
What happens if you make the standard Rhino available on the same base at the same time and buy that?
Top idea ST.
added
[Good]
nickname = lfr_hull
category = shiphull
ship = li_freighter
price = 151000
ids_name = 12002
item_icon = Equipment\models\commodities\nn_icons\li_freighter.3db[Good]
nickname = lfr_package
category = ship
hull = lfr_hull
addon = ge_lfr_engine_01, internal, 1
addon = li_freighter_power01, internal, 1
addon = ge_s_scanner_01, internal, 1
addon = ge_s_tractor_01, internal, 1
addon = shield01_mark01_fr, HpShield01, 1
addon = SlowSmallBlue, HpRunningLight01, 1
addon = SlowSmallBlue, HpRunningLight02, 1
addon = SlowSmallBlue, HpRunningLight03, 1
addon = SlowSmallBlue, HpRunningLight04, 1
addon = contrail01, HpContrail01, 1
addon = contrail01, HpContrail02, 1
addon = DockingLightRedSmall, HpDockLight01, 1
addon = DockingLightRedSmall, HpDockLight02, 1to the same base as the previous trader packages,
launches fine lol
copied above an pasted into space of old trader package / hull
only adjusted name of package and hull, kicks mesomet wrong with name.
FL server actually gave up propper error message for it this timePossible cheating detected (Ship or Equipment not sold on base) by admin (b08184eb-c34c1c43-c8f0673d-91a16689)!
but the rest of packages dont have any equipment sold at there bases and they launch fine, is name or ship.
i also tried changing the cost incase cost of total equip was higher than cost to buy package but it didnt make a difference
-
Hey Gisteron,
[BaseGood]
base = fc01_07_Base
marketgood = trader_package, 1, 0, 1, 1, 0, 1, 1
marketgood = traders_package, 1, 0, 1, 1, 0, 1, 1
marketgood = lfr_package, 1, 0, 1, 1, 0, 1, 1thats the what it looks like atm,
lfr_ launches with out problem
both trader_ and traders_ kick for cheating.
this is the current trader package
[Good]
nickname = trader_hull
category = shiphull
ship = li_freighter
price = 151000
ids_name = 12002
item_icon = Equipment\models\commodities\nn_icons\li_freighter.3db[Good]
nickname = trader_package
category = ship
hull = trader_hull
addon = ge_lfr_engine_01, internal, 1
addon = li_freighter_power01, internal, 1
addon = ge_s_scanner_01, internal, 1
addon = ge_s_tractor_01, internal, 1
addon = shield01_mark01_fr, HpShield01, 1
addon = SlowSmallBlue, HpRunningLight01, 1
addon = SlowSmallBlue, HpRunningLight02, 1
addon = SlowSmallBlue, HpRunningLight03, 1
addon = SlowSmallBlue, HpRunningLight04, 1
addon = contrail01, HpContrail01, 1
addon = contrail01, HpContrail02, 1
addon = DockingLightRedSmall, HpDockLight01, 1
addon = DockingLightRedSmall, HpDockLight02, 1set out exactly same as above lfr_package
only thing i see different are the names -
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.
-
Your right does seem to be a problem with the names Gibbon
ill try your solution although to clarifyYour saying nickname but hull or package,
it cant be the
ship = li_freighterbecause im only creating packages to be used on a ship not using 2 seperate ships. there is only one li_freighter in the shiparch.ini
then 2 packages which call it,
im assuming packages cant have a problem both using same ship
i can try adding a second ship entry under a new name with same setup and see if it helps. -
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.
-
Yep sounds right,
Ill have to test some bits,
Id imagine only one physical file is needed for multiple ships.
but if ST is right then ill copy original files to new names to fix.Id also hope FL shouldnt have a problem with multi packages using same ship arch ini entry but it does look like the problem.
I have several other packages all using same shiparch ini entry with 0 errors by server, but as ST said might be causing problems in close vicinity, ive never tested that.
not had chance to work on any of these theorys yet but will do asap
thx for all your input guys
might get to a place were we all know whats needed to be defined -
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.
-
Confirmed - Adding the new shiparch entry solved the problem.
But since this doesnt occure on any of the multiple other ships set up the same with multiple packages it seems it is mainly a problem with the cheat detection system.
Im gona work through and apply this too all the packages, and poss take on ST info of using diff files just for max mp stabillity.
thx again for all your posts peeps
most helpfull.
