How Can The Problems Be Resolved Or Reduced?

This second post discusses some possible strategies for reducing item loss instances. Following is a short list of ones which have occurred to me; how possible they are varies. None is a "magic bullet" that will resolve the problem entirely, but some are quite possible. I suspect the best 2 solutions are (3) and (5).

(1) Minimize "Invisible Item" Loadouts
If extra items are used in ship loadouts, minimizing them may be very helpful. In other words, although a ship may have 10 RunningLight mountpoints, if only 4 are used in the loadout, the player's distinct item list won't contain the eliminated 6 lights.
This won't help a lot for players who are near the limits; it will only stave off disaster.

(2) Make "Invisible Items" Visible
Making items such as the ship running lights VISIBLE and potentially unmountable is an interesting angle. This allows players to both include them in their count (if they have the patience) and possibly REMOVE them. It also would allow a new category of customizations.
I don't know whether this is even possible, unfortunately; presumably it would require some extensive modding like that done to make power plants visible and buyable/sellable.
Edit: Note CoolBeano's response below: lights are apparently NOT possible to make "visible".

(3) Give Players Item Counts
We could also let players know how many items they currently have. This is promising, because we already have a populat tool that audits all player files, flstat. A minor change to flstat could add an items column to the web output, allowing players to simply look at the flstat page to see their last known count. The flstat pages are usually a few hours old, but since players take TIME to get to a large number of items, this won't be a big deal.

(4) Stacking Items (has problems!)
Stacked items, as we know, only count as a single distinct item in the list. In theory, an flstat-like program that reads all player files during a server restart and then rewrites them could look for "identical" unmounted items (looking only at equip = lines) and then "stack" them into a single unit. When players trade items they will then be prompted for how many they should pass over.
This is NOT GENERALLY A GOOD IDEA. The reason is that if the player has, say, 10 Salamanca II's in a stack he can't tell how many he has without attempting a trade; and if he mounts them, 5 of them will disappear!
The stacking is still a good strategy for admin ships that sell special items, of course.

(5) Specialty Vault Ships
The Asgard RPG Server (see the Asgard Forums for more information about Asgard) allows players to create a special character whose name is prefixed with [VAULT. This vault ship is given an uber shield and is NOT allowed to mount any weapons.
This suggests another approach that might work well on multiplayer servers that encourage storage. Here's how it would work.
(1) We begin with a custom vault ship design. The ship is not allowed to mount any weapons, and thus has no weapon/CM/mine/torpedo hardpoints. To give it everything it absolutely needs for movement and also some basic visual cues, it would have 9 hardpoints, one each for engine, shield, power plant, scanner, tractor, headlight, running light, contrail, and dock light.
This ships would thus be able to hold exactly 246 distinct items. If we eliminated the lights completely, then we could increase this to 250 distinct items; I would favor a "design" that provides the lights at least since individual servers could simply remove them from the loadout. Players would be able to know precisely how many items could be stored in the ship.
This would also allow "safe" use of stacking. By inspecting the ship archetype, a program could automatically perform stacking ONLY on pilots with this custom ship. There would be no risk of loss by accidental mounting; it WOULD be necessary to unstack weapons when transferring them.

As far as I can tell, there is no obvious way to eliminate the problem at this point. Even if there were, it would leave us with the more fundamental problem of managing all that material. However, it looks like there are some decent possible strategies for more precisely defining when people are in danger of loss and letting them know about it.

Edited by - WatercoolerWarrior on 4/7/2005 8:50:46 AM

power plants are possible.
lights are not.

nice find too

A very interesting notion. I've noticed servers warning on a 100 - 120 item limit. Perhaps a program to test for over 220 items in general then find a way to tell the player... email via forum registration could be rather complicated... no idea how to make dynamic messages from console to individual or even if may be possible... just thinking on a keyboard really...

*edit - remembers what was written about flstat and warnings on that... doh.

Edited by - Anton on 4/7/2005 4:46:43 AM

or possibly incorporate it into IFSO, with like a console message that says players with X+ items will be kicked. and actually kick them. Or make a list of all the players that exceed the limit, and then have the server operator manually msg each of them, which shouldnt be alot.

A short contribution:

I once saw an account folder with 5 .fl files.
now, there was one weaponchar among these that caused a servercrash when joining.
the 4 other normal chars worked, as i can remember...

now if you deleted some of the normal chars, the weapon char would work too, no more servercrashes...
maybe there is a account-wide limit for those distinct items...

After reading the responses so far, I wanted to make a few new comments.

+ I integrated CoolBeano's comment about lights NOT being possible to make visible as far as we know into the original suggestions post.

+ The IFSO integration idea is interesting. It's not really possible to do directly as far as I can see since IFSO is neither extensible nor exposed to external automation. Still, a good wrapper routine for fladmin.dll that exposes it to easy automation could make this possible automatically. It would simply have to scan "new" fl files, and since they appear to be temporarily written to the root of the Multiplayer folder as "temp.fl" files, this might be feasible.
A really interesting long range idea that is very possible with the right knowledge is to expose the files to restricted web-based modification by the end users. The interface and controllability would be very important, but a minimalist web server running on the Freelancer server could do it.

+ w0dk4, if you recalled all the details correctly, that may be a more subtle problem since the all-pilots item count in the folder would be the same no matter which pilot is opened. Maybe that was an issue with the "name" file?