Should it be possible to make these as r/w members or some functions you can change these options by scripts ?
It should be a nice feature to make containers made of different kind of leathers support different amount of items or more weight, but for now its only the itemdesc entry MaxItems and MaxWeight which are controlling these.
Maxweight and MaxItems for containers
Moderator: POL Developer
-
Yukiko
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Re: Maxweight and MaxItems for containers
Tomi,
I like these ideas but I think the problem with making these things R/W is that all items in itemdesc.cfg files are loaded at start-up and any members on those items cannot be changed because that would require reloading all itemdesc.cfg files again.
I like these ideas but I think the problem with making these things R/W is that all items in itemdesc.cfg files are loaded at start-up and any members on those items cannot be changed because that would require reloading all itemdesc.cfg files again.
Re: Maxweight and MaxItems for containers
Yukiko, you mean itemdesc members like graphic, color, script...?
I don't see why this couldn't be done and I'd vote yes if asked. And this reminds me of an old feature request I should have posted an age ago, UO::ContainerHasSpaceForItem(container, item), which would be a must-have after the feature proposed by Tomi is added.
Maybe one day I'll write a whole new thread out of it.
---
Meanwhile, you can always set the hardcoded values to something obscure, like 65000, and use cprops to save real values which you'd check yourself in caninsert-scripts (aside other required places, if any [I can't think right now]), thus not really relying on the core.
I don't see why this couldn't be done and I'd vote yes if asked. And this reminds me of an old feature request I should have posted an age ago, UO::ContainerHasSpaceForItem(container, item), which would be a must-have after the feature proposed by Tomi is added.
Maybe one day I'll write a whole new thread out of it.
---
Meanwhile, you can always set the hardcoded values to something obscure, like 65000, and use cprops to save real values which you'd check yourself in caninsert-scripts (aside other required places, if any [I can't think right now]), thus not really relying on the core.
-
Yukiko
- Distro Developer
- Posts: 2825
- Joined: Thu Feb 02, 2006 1:41 pm
- Location: San Antonio, Texas
- Contact:
Re: Maxweight and MaxItems for containers
Ncrsn,
I see your point regarding color, graphic etc. but I suspect for simplicity's sake (and probably keeping true to OSI's server standards, because POL is an emulator of OSI) the original design of POL made some members read/write capable and some were kept as constants (read only). This might have been done to save space/processing power on the POL side. Remember that colour and graphics are mostly handled by the client, POL simply passes a number to the client and all the "hard work" is done client side. Whereas max-weight and max-items checks etc. are all server side. However, given today's micro-processor's speed this probably is not much of an issue. I like the idea but I'd bet it would require some major rework on how POL deals with those members. Ofcourse all this is based on what I think I know about POL's development so, as always, I could be way off here.
I also like your idea too. Although it can be scripted (I had to for one of my scripts) it would be nice to be able to preemptively check to see if an item can fit into a container prior to actually trying and failing.
I see your point regarding color, graphic etc. but I suspect for simplicity's sake (and probably keeping true to OSI's server standards, because POL is an emulator of OSI) the original design of POL made some members read/write capable and some were kept as constants (read only). This might have been done to save space/processing power on the POL side. Remember that colour and graphics are mostly handled by the client, POL simply passes a number to the client and all the "hard work" is done client side. Whereas max-weight and max-items checks etc. are all server side. However, given today's micro-processor's speed this probably is not much of an issue. I like the idea but I'd bet it would require some major rework on how POL deals with those members. Ofcourse all this is based on what I think I know about POL's development so, as always, I could be way off here.
I also like your idea too. Although it can be scripted (I had to for one of my scripts) it would be nice to be able to preemptively check to see if an item can fit into a container prior to actually trying and failing.