Containers....

[ashjpd]

I don't know if this has already been posted, but what the heck.
I was thinking of how to store stuff and transport them and this came to me. Why can't we put regular items in liquid containers? I don't really see why not....

For Example...
Put rock cask
put aba barrel

You see what I mean? I can understand some things though. Like putting an aba in a cask and then filling it up with water. Maybe it would work like burning something, but after a period of time it would dry up.

For Example....
a wetted brown aba (not sure how to spell it)
a water soaked red cloak

I am just asking this, cause I don't see why I need to buy a chest to store things when I have a cask that I am not using. Maybe the code is to complicated or something, I don't know. Just asking if it were possible.

[HaiWolfe]

From a building standpoint, I imagine the reason something like this isn't implemented is because regular containers and liquid containers are two different object types and really aren't interchangeable in the way you've described it.

[Dakkon Black]

And if they were interchangable you'd have assholes filling up thier backpacks with water. Hell, I'd be one of them.

[theebie]

from the coding point of view i (hope) its not complicated since,
i (hope) that  you guys do object oriented coding, which would mean
that (hopefully) both kinds of container extend/implement a 'container' object, which should (hopefully) have the basic functionalities used
for putting anything into anything

putting water in backpack ...
a container (the 'super'class) could/should (hopefully) have a flag
'fillable' which can be true or false, which would be true for any objects
that could contain liquid without leaking (like barrels) and false for
the rest (like backpacks). again that (should) be very easy to implement.

---theebie---

[Quirk]

from the coding point of view i (hope) its not complicated since,
i (hope) that  you guys do object oriented coding

Eh, Arm is modified DIKU. DIKU is old, DIKU is C. You won't see object orientation in DIKU mud code.

Quirk

[Anonymous]

hell, shoulda be about time to change that ?

[Carnage]

hell, shoulda be about time to change that ?

Brilliant.

Let's completely overhaul a successful and great MUD coding system just so we can put items in water containers. Nevermind the fact that C is made so programs can be the most effecient or the time and dedication put into the current game's system. C'MON IMMS, OVERHAUL THE ENTIRE GAME SO WE CAN PUT ROCKS IN A CASK!

[Anonymous]

He got it object orientation forever !:)

[Xygax]

from the coding point of view i (hope) its not complicated since,
i (hope) that  you guys do object oriented coding, which would mean
that (hopefully) both kinds of container extend/implement a 'container' object, which should (hopefully) have the basic functionalities used
for putting anything into anything

Though Arm isn't written in C++, I'd like to see your implementation of this.  Feel free to send code to xygax@ginka.armageddon.org

I'm guessing that once you try it for real, you may discover that this class heirarchy may make intuitive sense in RL, but in fact doesn't translate well at all to the real problem of liquid containers and object containers.  Here are a few of the questions I challenge to you answer:

1.  What are the common properties of both classes?  If there were an object class you could probably factor things like desc, short_desc, long_desc, weight, and a few behind the scenes "maintenance" structures into IT (class Object), but what would you include in your "class Container"?  If it's capacity, would you measure it in liquid units?  Cubic units?  Weight?  Would your base "Container" class include "liquid type"?  Poison information?  Alcohol, food, water content?  Pointers to a linked-list of contained objects?  If you include liquid-type or poison information, you'll have wasted data in the vast majority of your backpacks, and if you include a linked list, you'll have wasted data in the vast majority of your waterskins.  And if you factor this functionality down into the subclasses, you end up actually writing MORE code long-term.

2. How is the polymorphism actually saving you code?  Looking at the use-cases for all things Container, you'll have to handle "drink", "pour", "fill", "put (into)", "get (out of)", "drop", "get (picking up the item itself)", "put (putting the container into another container)", and since you're dealing with Containers "generically", you'll have to make runtime decisions about every container based on what is actually _realistic_ for it to contain.  Most leather backpacks, for example, wouldn't be great containers for ale, since they aren't designed to be water-tight.  In the long-term, you instead end up with a system that is MORE prone to data-errors, more difficult for builders (who now have to enter more data to complete a container), AND more difficult to extend in code.

3.  And what happens when someone puts both water AND items in their container?

putting water in backpack ...
a container (the 'super'class) could/should (hopefully) have a flag
'fillable' which can be true or false, which would be true for any objects
that could contain liquid without leaking (like barrels) and false for
the rest (like backpacks). again that (should) be very easy to implement.

I don't think this fix is as trivial as you're guessing it is, even if Armageddon WERE written in a traditionally OO language, which it isn't.  Granted, it is possible (though occasionally syntactically ugly) to incorporate OO concepts into code written in C (since really structs are just classes with public access), even still, Armageddon isn't really written with even an OO _philosophy_ such as you suggest.

But mainly, I still don't think that the class heirarchy you suggest makes sense technically.  Liquid containers differ enough in behavior, common data, and intent from object containers that I think it would be both a memory-performance loss, AND a maintenance (and I would usually happily sacrifice memory for maintenance) loss, to use it.

More likely, I could envision everything in the game inheriting a few obvious properties from a base "Object" class, and then having an otherwise shallow object heirarchy.  But, I don't think we'll be switching to C++ for a while.  

-- X

[Angela Christine]

I think there would only be a few liquid containers where it would even make sense to be able to store solid objects, namely barrels and casks.  Waterskins, wineskins, waterbelts, water pouches, water gourds, milk sacks, glands, root saks, etc. may be large enough to hold rocks, pants, or other items, but the opening is very small so nothing bigger than a pebble would be able to get into the container, and getting even pebble-sized objects back out could be tough.  The only dry materials that would be easy to get in and out would be things like sand or silt, and perhaps some of the smaller grained salts and spice units.  I suppose you could cut a larger opening and then sew it shut, but you'd have to be crazy to do it, because you can get nice big bags for under 20 sid almost anywhere in the known world.

While it might be possible for some wide-mouthed containers be dual-purposed, I doubt that it is worth going to much trouble since bags are cheap and readily availble.  Sure, chests are expensive and cumbersome, but bags aren't, and a few bags can hold as much as a chest.  Besides, dual purpose containers could lead to people putting dirty pants they got off a dead elf, a hunk of raw meat, a loaf of bread, a poisonous fruit, and a couple gallons of water into a barrel together, and that is just gross.  Seal that sucker and let it ferment a few days in the desert heat and you've got ... actually I don't know what you've got, but it isn't going to be pretty.

AC

[ashjpd]

Yah, thanks that pretty much solves my question. Reading the replies above were kind of confusing with all the abbrevations and such. I figure that it is too complicated to change the code. It would be nice to have changed at some point though. I also realized that you couldn't put any dry items in waterskins and such. I was mainly talking about casks and barrels.

Thanks,
Ashjpd

[sacac]

Well let's see.. have you ever seen the openning in a cask? It's only wide enough for the liquid most of the time.. I mean.. I don't like this idea..
emote pulls a very blackish-grey aba out of a barrel.? I don't like it..
Then yeah..
emote pulls a very sharp hair needle-like thing our of a miniture barrel.?
No.. come on.. I don't really see why they should waste thier time on this.. But this is Fully my own opinion.. which may not reflect the opinion of the staff or of the poster. But you know what? Awhile..

I don't like it
But everyone else may like it.. and banish me to the far reaches of the Allanak Prisons..

[theebie]

Player // the player object
------
get (Container aWaterproofOrNotWaterproofContainer);   // get and drop actually should be implemented in the object that
drop (Container anotherContainer)                  // tries to get or drop something, should be actually get(Object object)
                                          // with Container extending Object
drink(WaterprooContainer onlyWaterprooOne)            // can drink only from WaterprooContainers
pour(WaterproofContainer mySkin, WaterproofContainer anotherContainer)
                                          // so you can pour from it
fill(WaterproofContainer mySkin, WaterproofContainer fillFromHere)
                                          // or fill it
put(NotWaterprooContainer mySack, Item item)         // ...into this container
                                          // can put only into NotWaterproofContainers


Container
---------
string      desc, short_desc, long_desc               // these attributes we got for all Containers
int         weight
bool      queryWaterproof
public string lookAt()                           // look at the container, works for all kinds of containers
public int getSize()                           // this could return the capacity, may it be as int or Capacity
public setSize(int size)                        // set the size ... same for other values

WaterproofContainer (extends Container)
---------------------------------------
int         capacity [or Capacity capacity]            // these attributes only for Waterproof ones
int         maxCapacity                           // how much you can get in afterall
string      liquidType, poisonType
int         alcoholContent, foodContent, liquidContent
public setLiquidType(string liquidType)               // set the liquid type
public string getLiquidType()                     // get the liquid type ... same for other values

NotWaterproofContainer (extends Container)
------------------------------------------
int         capacity [or Capacity capacity]            // these attributes only for NotWaterproo ones
list      containedObjects[]
public addObject(Object whatYouWantToPutInside)         // add an object

--------------------
{create_a_container}
--------------------
myWaterskin = new WaterproofContainer;
myWaterskin(setDesc) = "a skin";
myWaterskin(setLongDesc) = "its longdesc";
myWaterskin(setCapacity) = 100; // 100 gallons, or whatever, its a big skin

my Player = new Player; // a player object, a character
Player.drink(myWaterskin);

mySack = new NotWaterproofContainer;
mySword = new Sword; // an object
Player.put(mySack, mySword);

==============================================
Player::drink(WaterproofContainer myContainer)
myContainer.setCapacity( myContainer.getCapacity - 20)   // empty it some

Player::put(NotWaterproofContainer myContainer, Item mySword)
myContainer.addOBject(myContainer, mySword)


- - -
if you want more details, i can give them.
btw. i dont think that there is any way to code it (much) easier for maintenance

most of the other features could be implemented the same way
i'm not sure if tab works correctly here, you might have to copy/paste the whole thing into another editor

regards, ---theebie---

[The7DeadlyVenomz]

This guy ain't playing. Heh. I don't think it would be a bad idea at all. I am always in favor of new features.

[X-D]

Nod, But now he has to write it in SML.

[Xygax]

This is all pseudocode and doesn't answer any of my original questions, nor does it implement any of the existing functionality of either containers OR drink containers.

[Anonymous]

This is all pseudocode and doesn't answer any of my original questions, nor does it implement any of the existing functionality of either containers OR drink containers.

then I dont know what you want ?
you want full C-code ?

[Delirium]

If I was Guest, I wouldn't waste my time, and just forget it already.

[creeper386]

He probably wants answers to his question. He didn't ask them for his own health you know.

I except answers, as well as followed up by complete C-Code of what you expect. Hmm... Also! A solution to all the building problems that come from revamping all the items to fit the new code. That might be helpful... Could have been included in all of his questions but it's important so say it twice.

That is all. Double spaced to. We think his eyes might be going.


Creeper

[theebie]

well, i m not sure which answers you mean that i didnt answer.

to write it down a bit simpler, without even pseudo code, and in a way it can be implemented in not object oriented way:

- give each container a flag, either 'waterproof', 'not-waterproof' or 'both'
  where waterskin would be first, backpack second and barrel third

- have an object/c-file that contains all methods that there are for both types of containers

- have one for for waterproof only methods (like pour) and one for not-waterproof only (like put)

- have one for both (for barrel)

---theebie---

ps: very helpfull would be, if you'd show how containers are implemented right now, then i could tell you an easier way to change stuff probably.

[Quirk]

Well, for starters, your waterproof containers do not contain a list of contained objects, so you haven't handled the desired additional functionality discussed throughout the thread. All you've done is attempt to reimplement the functionality already extant, and as that's working fine as is there would be no sense in a rewrite. You haven't handled the case of water and items in a waterproof container, because you haven't handled the case of items inside a waterproof container. You haven't addressed the polymorphism of get/put for the same reason. In fact, you've not answered one question of Xygax's, or provided anything with any functionality over what exists already. The question of which waterproof containers actually have mouths large enough to accept items is also completely unaddressed.

Xygax gave guest a fairly detailed and polite answer compared to what I was very tempted to give him (or her). Object orientation is a tool, and often a useful tool, but if you've already built a nice solid building with other tools there's no sense in tearing it down to rebuild it all over unless the improvements are going to be pretty damn impressive. I'm guessing that guest is not someone who has had to do any amount of maintenance coding for a living.

To Xygax: including a linked list in the vast majority of your waterskins, incidentally, isn't as bad a waste of space as it sounds at first; the list can be kept as a NULL pointer while empty, so you're only losing a wasted int per water container not storing items, which is quite bearable I think.

I think if I were looking to solve the casks and barrels problem, I'd add a "betwixt and between" container class or struct specially for casks and barrels which could handle both, rather than making all waterproof containers capable of storing items. Any compromises that thus had to be made would be restricted to affecting casks and barrels. Some kind of conversion between item weight and liquid volume would have to be made to handle the both items and liquid case - of course, you then get into perilous waters with wood, which floats, and you end up in with nasty special cases. It's quite doable I think, but enough effort for little enough payoff to be scarcely worthwhile.

Quirk

[The7DeadlyVenomz]

Here is the gist. Waterskins, backpacks, chests, crates, cups, etc, would all be containers. By the addition and definement of one more field (and perhaps there is already one that is undefined when one makes a container), the ability to add objects, water, or both to this container would be given.

I like the idea. I do not know if it is worth coding, but if simple enough, I would support it. I support any addition to the game at large.

[theebie]

Here is the gist. Waterskins, backpacks, chests, crates, cups, etc, would all be containers. By the addition and definement of one more field (and perhaps there is already one that is undefined when one makes a container), the ability to add objects, water, or both to this container would be given.

I like the idea. I do not know if it is worth coding, but if simple enough, I would support it. I support any addition to the game at large.

i dont think it would be too hard to code, i might even try 'n help, if someone tells me how to :)

---theebie---

[ashjpd]

Would the code be to hard to write? If it is, then don't bothe, unless at some point in time you have nothing else do to, (which will be never!!)
Thanks for all your posts guys.

[Anonymous]

could please someone of them coders give us an answer please ?

i'd really like to help, but am not sure what to do at the moment

regards, ---theebie---

[Quirk]

The answer to "would the code be hard to write?" has already been answered, albeit in somewhat technical fashion. It's a non-trivial fix required, probably more work than you'd need for say, secret emote. If we got to vote on priorities, I know which way my vote would go :twisted:.

And theebie, as you failed to answer any questions from coders, and seemed not to have understood any of the issues involved, I doubt you'll ever be allowed to touch the code.

Quirk

[Rindan]

I imagine at the very least they would need to go through and add a new flag to every object that can or cannot be containers and liquid holders.  I don't really see a point.  There are extremely few items I can think of that would realisticly hold both liquid and solid objects.  I think the simple answer is that it just isn't worth anyone's time to code.  I can think of a million other things I can see then a handful of lquid/solid containers.

[spawnloser]

I think the simple answer is that it just isn't worth anyone's time to code.  I can think of a million other things I can see then a handful of lquid/solid containers.

Here here.

[theebie]

I think the simple answer is that it just isn't worth anyone's time to code.  I can think of a million other things I can see then a handful of lquid/solid containers.

Here here.

so name me five please :)

[Rindan]

So name five

- Upgrades to the combat code (this should actually count for about 20, but let's just call it one for the sake of argument).

- Reharshifying the desert with less uber NPCs, but more intelligent, poisonous, or otherwise NPCs that can be avoided by rangers but are rough on warriors.

-  Finish up the wagon code that only got half done.

-  Brewing (alcohol) craft skill

- Fixing hide/sneak so it works against all NPCs, and not just non-aggressive NPCs.

- Retool cloth working so that it is possible to make low end items using low end low cost materials.

[Anonymous]

• Turning the existing brew skill into a crafting skill.
• Adding crafting recipes for more existing items.
• Allow for items to be packed on a mount without having to use the mount command.
• Implement a decay system for food.
• Create a system allowing for PC tattoo artists.
• hemote.
• Update the existing trade system to allow for mass purchases at the bartered-for price.

And I certainly could think of more if I had the time.  The compelling reason to be able to stuff some rocks in a water gourd eludes me.  I'd much rather have any of the changes above.

[The7DeadlyVenomz]

Fix bandaging.

[spawnloser]

Well, that's more than five that all seem more important to me.  Any questions?

[ashjpd]

Yah..
I didn't realize there were that many other things to fix. I just put that there, so it could be looked into and see if it was possible. It couldn't hurt right??? Or did it.

Thanks  for your posts guys.

[theebie]

Well, that's more than five that all seem more important to me.  Any questions?

no,no :) actually i do agree with you, that filling something into a waterskin might no be high priority.

i just wanted to see some reactions of the people around here. since there are lots of things to do (i mean, hemote, since when do people want that?
must be ages ?)

i just wonder which concepts/things discussed here are actually implemented (and is there a way for no-stuff members to actually do some of the code-stuff?)

---threebie---

[spawnloser]

(i mean, hemote, since when do people want that?
must be ages ?)

i just wonder which concepts/things discussed here are actually implemented (and is there a way for no-stuff members to actually do some of the code-stuff?)

People have wanted a 'hide emote' or 'stealth emote' for a while now.

I remember several things discussed here that went into the code.

I don't know of the staff allowing random player handling of the code done by anyone that isn't an IMM.