6 réponses à ce sujet

[Xeneize]

Greetings, I am beginning to look into scripting a system of storage for a persistent world, where a PC can store items and gold for later access. I am wondering if there's any guidance out there to help me though this?

 

Thanks in advance.

[Loki_999]

You best take a look at integrating an existing system, there are a few available on the vault as i recall.

 

You will need an SQL server for storing items... technically speaking you could use local vars on an object, but that would get crazy after a while and be very slow to access, probably resulting in TMI conditions once the store got large enough, and i guess eventually would hit the local variable limit whatever that is.

[Psionic-Entity]

Storing items is a tough one. The only prefab systems I've seen have had to use the campaign database because it actually has a system to save items. The only problem is you really don't want to be using the campaign database. It's easy to lose it during updates and even if you've got a good system I've had it remove variables from items before. There are a couple decent alternatives:

 

One is to reduce items to simple information and store that (ie. the blueprint, any changed properties, icons, variables, etc) in a database so that items can be recreated from it. If you do this you'll need some weighty rebuilding scripts.

 

The other is to forget about database item storage and give PCs 100% weight reduction inventory containers that can only be opened in certain places. This requires a minor UI update to the context menu and a new baseitems.2da row, but once that's in it's very versatile and not at all difficult to manage. The only problem is that every inventory script has to be in house afterwards, otherwise you can access stored items in conversations and the like,.

[Loki_999]

That latter option bulks up BIC files though. Players are pack rats usually, and you give them the option to have massive inventories and most will use. Not a problem with localvault, but if server vault it all adds up.

[Psionic-Entity]

A large servervault isn't really a problem, the issue is more that .bic files have to be loaded to the server and inventory loops have to go over every item. I don't have a problem letting players double their size with a container, most servers do fine having magic bags and the like anyways.

 

If someone were to write a comprehensive item saving system that didn't rely on the campaign DB I might use it, but that would be an awful lot of work and probably dozens of database calls per item.

[BartjeD]

Containers also cause lag online. I remember reading that somewhere. I also know from experience that most persistent worlds don't allow them. So I presume its for that reason. Thats why they want persistent storage.

 

You can insert items into the bioware database with campaign variables, I think. And you can also retrieve them and them spawn them again / copy them into inventory. SQL also works.

[Loki_999]

Main problem with large containers is as pointed out by Psionic is inventory scans. The larger it is the more chance you have of running into a TMI situation where the script eventually falls over.

 

An example of this is with enchanting. The script has to check to see if you have the required items in your inventory.  It has to scan every object you have. If your inventory is too large then the script will fail and you will fail to enchant because it might not find the required items, you probably also fail to get feedback as well.

 

We also have a check for legal items on our server which is even more intensive because it has to check item properties. Making sure nobody has manged to get their hands on items which do not meet our restrictions (eg: No items with blanket immunities or permanent Haste). From time to time we have a packrat that can't exit our OOC room because they have a full inventory with half a dozen containers full to the brim.