Kent wrote:Is the site ready for public consumption?

HALF POINT.

Kent...it's intended to document both my own progress learning Hugo,as well as (hopefully) clear up some of the things that are a little confusing to 'real' newbies like me. (Hence all the annoying questions here. :)) As such, it's an ongoing thing, and probably just as ready for consumption as it'll ever be.

Thanks for your kind words, and of course, I'd be honored to have it announced with the new Hugo release.

(I can also be contacted at cena@cox-internet.com, if necessary.)

You know, seeing as I think the Hugonomicon is a damned cool idea, and well done, and particularly useful in light of the limited number of resources for learning the language, I might note the existence of hugonomicon.sf.net with the release of Hugo v3.0.07 (probably sometime this week).

Is the site ready for public consumption?

Sorry--I'd read this earlier and not responded, and didn't get around to it before going out of town.

The (objectname) thing works like this:

If I create

object book "book"

then it gets the name property "book", so that book.name = "book".

If I create

object rock

without an explicit textual name, it gets called "(rock)", just so that it has a name when something somewhere goes to refer to it. So rock.name = "(rock)" in this case.

This isn't _super_ relevant, really, to the average programmer. It just helps to explain if an object gets referred to as "(something)"--basically that object was never given an explicit name.

As for the child/eldest/elder/younger/etc. question, yes

child(object) = eldest(object)

just as

younger(object) = sibling(object)

The reason for this is that child() gives the _first_ child of an object, i.e., the eldest child of that object. A _younger_ child object is an object added more recently as a child to a particular object, so that it is the next-eldest sibling to a previously added child. (The abundance of keywords is unfortunate ultimately not all the helpful.)

Yes, you can define more attributes past those in the library. Basically

attribute my_attribute

creates a new attribute called 'my_attribute' which can then be set and cleared with 'some_object is [not] my_attribute'.

For instance, the library currently has no notion of buoyancy. Let's say you were creating a game with lots of water in it and wanted some objects to float.

attribute buoyant

will create the attribute, and you can then set or clear or test it for any object, such as:

if object is not buoyant
{
"It sinks beneath the surface and disappears."
remove object
}

That sort of thing.

Aliases are mainly there to double up on limited numbers of attributes and/or properties. This is something borrowed from Inform's syntax, where it is much more necessary; in Hugo it isn't all that necessary, but the library does alias certain mutually exclusive properties for economy.

At the heart of it all is the fact that everything in Hugo is a value. If 'size' is the 10th-defined property, then

object.size

is _basically_ the same as

object.10

The engine will translate object.property (where <property> is any sort of value, including a propery label) by reading the size property from the object.

Now, if you were to alias

property color alias size

then

object.color

would _also_ be equal to

object.10

because the property label 'color' _also_ points to the 10th defined property, because instead of defining it as a separate property, we've made it an alias of 'size'. (Basically, the engine doesn't know anything about property labels; these are syntactic aids used by the language and the compiler. The engine deals strictly in the resulting values.)

That's probably clear as mud.

And yes, to access a particular property, you use the combination object.property. On their own, 'size' and 'n_to' aren't all that useful, since they only represent the name of the particular property. They're only useful to read that particular property _value_ from an object.

Finally, yes again, the #<number> initialization syntax for a property is merely if you want to initialize a bunch of zero values for later use. Let's say, for whatever reason, you're going to need 12 found_in property values for an object. You can either do

found_in 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

or

found_in #12

mainly to save on typing and accuracy.

Now, to access each of those 12, you would then need to refer to 'object.found_in #n', where n is a number from 1-12 (keeping in mind that 'object.found_in' without any further qualification defaults to 'object.found_in #1', since the vast majority of properties use only a single value).

(A lot of answer there, and probably not all 100% clear. Let me know if it helps.)

--Kent

Nobody?

Some questions after going through the first part (roughly through section d.-properties) of the chapter:

In III.a, the manual states that if you don't specify an "object name", the compiler will assign it as ("object name"). Do the parentheses change the nature of "object name" in any way? In other words, is object myobject "myobject" different from object myobject ("myobject")?

III.b-Object Tree: eldest and younger functions are said to be same as child and sibling, respectively. What do youngest and elder correspond to? (p. 43) The same thing (youngest -> child; elder->sibling)? If so, maybe that could be included in future updates of the manual, as well as indicating how one determines the sibling hierarchy? (Eg, why, in a room with 4 children, is 'Player' necessarily the youngest? (p 43)

III.c. -Attributes: p.47 says up to 128 attributes can be defined. 28 are listed as being defined in the lib. Does that mean the game author can define 100 others? If so, how would s/he go about doing so?

...The alias thing is confusing. On one hand, I understand the concept of an alias. On the other, I'm don't understand why I would necessarily use one. Help?

III.d.-Properties: can I define other properties? How?

...p.54 renders me senseless. :) "Whereas a simple property is expressed as <object>.<property>..." What? And I was following along pretty well up until that! :) It feels like a sudden leap in assumed knowledge that I don't possess. Does this mean that in order to access a given property in code, I'd use (for example) suitcase.size? A complete example of this would be appreciated.

...Maybe a little more discussion on 'initializing space in the property table' (p.55)? Do I understand this correctly...I've got a suitcase, with property found_in kitchen. If I want it to be 'findable' elsewhere, then I have to include something like found_in #4? Would that make it SUITCASE FOUND_IN #4, or SUITCASE FOUND_IN KITCHEN, #4? How does this apply to objects that get picked up and dropped at places other than their starting rooms? OR is this the way to initialize where the object starts out, and that's all?

Sorry for the barrage of questions. And I haven't even made it to IIIe yet! :) Any help appreciated.