1

So can someone give me a explataion of what a fertile object is? And I would also like to convey space in a room rather than a room for many places. For example Lets say the player is in a restaurant and its 10 by 10 All the places where you get your food are at the 10 10 0 wall and tables are at 10 5 10 7 10 3 and the mane door is at 10 0. Is his even possible. I could add props that store the value of x and y and z. The question could I just move the objects out of the room when the player isn't at those coords and move them back when the player is at those set places?

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

2

Fertile means basically that the object can be used as a parent, to create children who inherit from that parent. with the .f flag offf, you will not be able to @create $object-class named <name> It won't work, flip it on, and it will. All generics must be fertile for two very important reasons, A) like I just said, to have the ability to create cildren, and B) The recycling center will not accept fertile objects, they willjust instantly be recreated.

Yes, if you have virtual exits, it's certainly possible to make a certain number of connected rooms in a radius to be able to hear. I'm not good with that though.

The bipeds think this place belongs to them, how cute.

Thumbs up

3

So for something like a coffee is there a way to move the coffee to the cup of the player? Or I guess the liquid of the coffee would be a object by it self.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

4

There are two ways to deal with this. The first, and most obvious way is that the liquid itself is an object, but this is not how I would handle things, because it is grossly inefficient. Think for a minute, You'd need one generic cup, one generic liquid, then you'd either have to create children called coffee, tea, etc. or you would have to write an initialize verb that modified each child to represent the type of liquid you'd want. This means twice the amount of objects, since for every cup, at some point, you'll need some sort of liquid object. Then you're getting into interoperability between two objects, the cup, and the liquid. This basically means that you'd have to tell the liquid how to behave in the cup's verb, so the cup will have to store the object number of the liquid, and tell the liquid, either by calling one of its verbs, or changing one of its props, when to be empty.Then you will need to recycle the liquid without recycling the cup, #63:_recycle(this) would be a big mistake, because you'd recycle the cup itself then the liquid would probably end up in #-1, or in you. So you'd have to store the liquid's object number in a prop like cup.lqd, then do #63:_recycle(cup.lqd). Actuall probably better to use $recycler rather than #63 for best compatibility between servers and if you ever wanted to corify the db, you wouldn't want hard coded things.

Now, the second way, the probably the most efficient would be to create a liquid DB. All this really has to be is an object, it can even be a #1, and doesn't even have to be a $thing or #5, because it will just sit there. think of attributes you'd want each liquid to have, a name for sure, if it is filling to you, i.e. part of a hunger system, how much does each sip fill you up by. You'd them make an array of arrays basically, each array inside the initial one would be a list of strings and ints, maybe floats if required. Now you create your cup, give it a capacity prop and a fill prop, and when you either fill your cup from a source, or a source dispenses into a cup, you could make your fill prop equal to your capacity prop, or just add it slowly over time in a loop with a 1 o 2 second suspend until its equal. What you've done is basically make the coffee virtual, but it can still do everything an object does, and if you don't hard code numbers, like if the array contains 16 elements, which are 16 liquids, don't ever use that, use length(array) as your upper bound, that way, as you add more liquids, you don't ever need to modify that code.

The bipeds think this place belongs to them, how cute.

Thumbs up

5

I was able to make a energy drink that when the person drinks it the drink would restore there hp to 10. I wanted it to go by sips of 1 but it kept jumping to 10.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

6

What is the O(dodstr) I think thats how it is spelled. I see that a lot when needing input.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

7

OK, so a verb can have different arguments based on what you want to do with it. The most open-ended verb you can have has the argument set 'any any any', while the most closed down verb you can have has the argument set, 'none none none'. In position 1, this would be your direct object, next to it is your preposition string, followed by your indirect object. So for example, put is a verb, so put flashlight on table. Flashlight is your dobjstr, on is your prepstr, and table is your iobjstr.

You can also get the entire string entered by the player with argstr. It's also possible to use dobj and iobj, but you will need some code to make sure what they entered is an object and that the object in question is actually usable.

if (valid(iobj))
  "insert coe here";
endif

If you don't do that and you had a flashlight, a book, and a key in your inventory, but the player typed put monkey on table, you'd get a traceback.

As to your other point about the drink doing 10 per shot rather than by 1, just do player.hp = player.hp + 1 or whatever your health prop is called on the player. That's just adding one onto it, and on the default server, you do not get access to ++ -- and +=, so don't try it, you'll traceback because its not designed to parse that.

The bipeds think this place belongs to them, how cute.

Thumbs up

8

Is there anything I can do with exits other than jut linking rooms and locking them? I would also like to put in video cams but right now I am just playing around on a blank server. I don't have the time to setup a vps so you could come on and see this stuff as I do it.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

9

Kind of doing the grid thing. I was able to show the x y and z coords.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

10

you're using which core, and the grid is pre made I would imagine.

The bipeds think this place belongs to them, how cute.

Thumbs up

11

JHCore I did the grid from scratch by having x y and z propertys in rooms.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

12

JHCore's a pain, and just weird. They have a weird way of doing admin stuff to. If you're new to MOO, I wouldn't recommend messing with different cores yet.

The bipeds think this place belongs to them, how cute.

Thumbs up

13

The thing I wanted to do was rather you see a bucket here I wanted you see a bucket of sand on the ground here. I could change the name to that string because the tutorial I saw had a intergrate setting but It doesn;t have that in the lambdacore.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

14

yes you'd have to code that, tutorials often times can be just more confusing than the straight code.

The bipeds think this place belongs to them, how cute.

Thumbs up

15

All those descripters and other advanced features you'll probably have to code yourself, because lambdacore doesn't have them IIRC. A good core you could reference for some ideas (action queue, combat system, basic weapons, basic crafting, etc) is the hellcore, but I wouldn't use that as a base because it's a direct corify of Hellmoo with some glaring errors fixed, but it's still very broken. Once you learn MOO more you might want to look at that, but I wouldn't recommend doing that now because the code would probably confuse you.

Sincerely,
Lucas.

Thumbs up

16

I mean just trying to make a wooden table and put a object on top of it keeps throwing me varible not found. How do I refer to objects from my invantory in a put command. I don't want to have to hard code pot:moveto

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

17

This is frustrating.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

18

I can help you if you forward the port on your router that would let me connect. But with all these questions you have, answering them one by one isn't really gonna be very effective.

No you don't have to code that verb and if you did you would most likely break things horribly. If you don't understand the way moo handles inheritance and the and the relationship between parent and child verbs would throw you off. For instance, a $container or #8 would get its :moveto from #5 because #8 is a child of #5 and is derived from it. By you coding a moveto verb on #8 or one of its children, you would override the inherited verb, and create issues. Now, it can be helpful to do that, it can even be helpful to do it then call the parent verb using pass(@args), but that's a bit advanced for you right now. So I wouldn't recommend ever changing any of the code on any of the generics right now.

The bipeds think this place belongs to them, how cute.

Thumbs up

19

Sadly I don't have router access. I could run it through tor but that would be a hard thing to setup on your end.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up

20

hmm

The bipeds think this place belongs to them, how cute.

Thumbs up

21 (edited by GauravSharma 2018-09-29 07:46:25)

What programming language are you guys talking about here, gentlemen? Is it python or something else? If it is python then it may help me as well, because I'm also learning game development in python.

Impressing girls is harder than chewing stones, so better chew stones and get your teeth strengthened first, otherwise you might end up shattering them!
email: My Email Id
why not give my post a thumbs up if you like it, thumbs ups are free of cost, after all.

Thumbs up

22

No it's MOO's internal language.

The bipeds think this place belongs to them, how cute.

Thumbs up

23

Yeah. I would really recommend starting with a plain old LambdaCore and get the basics down first.

Thumbs up

24

To answer the ops original question, I think that the programmers manual might help, though Ironcross also explained it nicely. Remember, the bits for objects are programmer, wizard, R (read), W (write), and F (fertile). On properties the bits are R (read), W (write), and C (change). Finally, on verbs the bits are R (read), W (write), X (execute), and D (debug). These are described below:
The ‘wizard’ and ‘programmer’ bits are only applicable to characters, objects representing players. They control permission to use certain facilities in the server. They may only be set by a wizard.
The ‘r’ bit controls whether or not players other than the owner of this object can obtain a list of the properties or verbs in the object. Symmetrically, the ‘w’ bit controls whether or not non-owners can add or delete properties and/or verbs on this object. The ‘r’ and ‘w’ bits can only be set by a wizard or by the owner of the object.
The ‘f’ bit specifies whether or not this object is fertile, whether or not players other than the owner of this object can create new objects with this one as a parent. It also controls whether or not non-owners can use the chparent() built-in function to make this object a parent of an existing object. The ‘f’ bit can only be set by a wizard or by the owner of the object.
Every defined property (as opposed to those that are built-in) has an owner and a set of permissions for non-owners. The owner of the property can get and set the property’s value and can change the non-owner permissions. Only a wizard can change the owner of a property.
The initial owner of a property is the player who added it; this is usually, but not always, the player who owns the object to which the property was added. This is because properties can only be added by the object owner or a wizard, unless the object is publicly writable (i.e., its ‘w’ property is 1), which is rare. Thus, the owner of an object may not necessarily be the owner of every (or even any) property on that object.
The permissions on properties are drawn from this set: ‘r’ (read), ‘w’ (write), and ‘c’ (change ownership in descendants). Read permission lets non-owners get the value of the property and, of course, write permission lets them set that value. The ‘c’ permission bit is a little more complicated.
Recall that every object has all of the properties that its parents do and perhaps some more. Ordinarily, when a child object inherits a property from its parents, the owner of the child becomes the owner of that property. This is because the ‘c’ permission bit is “on” by default. If the ‘c’ bit is not on, then the inherited property has the same owner in the child as it does in the parent.
As with properties, every verb has an owner and a set of permission bits. The owner of a verb can change its program, its permission bits, and its argument specifiers (discussed below). Only a wizard can change the owner of a verb. The owner of a verb also determines the permissions with which that verb runs; that is, the program in a verb can do whatever operations the owner of that verb is allowed to do and no others. Thus, for example, a verb owned by a wizard must be written very carefully, since wizards are allowed to do just about anything.
The permission bits on verbs are drawn from this set: ‘r’ (read), ‘w’ (write), ‘x’ (execute), and ‘d’ (debug). Read permission lets non-owners see the program for a verb and, symmetrically, write permission lets them change that program. The other two bits are not, properly speaking, permission bits at all; they have a universal effect, covering both the owner and non-owners.
The execute bit determines whether or not the verb can be invoked from within a MOO program (as opposed to from the command line, like the ‘put’ verb on containers). If the ‘x’ bit is not set, the verb cannot be called from inside a program. The ‘x’ bit is usually set.
The setting of the debug bit determines what happens when the verb’s program does something erroneous, like subtracting a number from a character string. If the ‘d’ bit is set, then the server raises an error value; such raised errors can be caught by certain other pieces of MOO code. If the error is not caught, however, the server aborts execution of the command and, by default, prints an error message on the terminal of the player whose command is being executed. (See the chapter on server assumptions about the database for details on how uncaught errors are handled.) If the ‘d’ bit is not set, then no error is raised, no message is printed, and the command is not aborted; instead the error value is returned as the result of the erroneous operation.
Note: The ‘d’ bit exists only for historical reasons; it used to be the only way for MOO code to catch and handle errors. With the introduction of the try-except statement and the error-catching expression, the ‘d’ bit is no longer useful. All new verbs should have the ‘d’ bit set, using the newer facilities for error handling if desired. Over time, old verbs written assuming the ‘d’ bit would not be set should be changed to use the new facilities instead.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

25

So how would I make things accessible by all players? I look t the owner and all my objects are owned by me.

Bitcoin Address:
1MeNca7h6m8du4TV3psN4m4X666p6Y36u5m

Thumbs up