Local subversion repository

Another post? It's like a post overload!

I've set up a local subversion (svn) repository to manage the viewer source code as I make revisions, allowing me to easily save old versions, view what I've changed, and revert to the older version if something bad happens. It's not accessible over the internet (at least not yet), which means that it is of very limited usefulness to other people. But hey, I know how fun it is to read about what other people are doing that doesn't really affect me personally, so now my readers (I think I have some of those? Maybe I'm thinking of lemurs.) can enjoy the same luxury.

Here's the plan for repository layout:

• linden — contains the most recent vanilla source code from Linden Lab.
• jacek — contains my tinkered source code.

You might be wondering why I would maintain a directory with the untouched source code, when I can always revert any changes that I've made. My reasoning has to do with managing changes to the linden branch and merging them into my own branch as needed. When a new version of the source comes out, I can update the linden branch, see what changed, and apply those changes to my branch—without overwriting any changes I may have made to the same files.

I might also make more branches off of jacek if I ever decide to implement something that takes a really long time to code, then merge the changes back when I'm done.

UI abstraction follow-up

Not to toot my own horn in public, but one of my images for the UI Abstraction Photo Contest won first prize! I thought that was pretty neat. It was this one:

There were a metric ton of other really awesome images in the show, in a surprising variety of styles! The social phenomenon that is Torley submitted some images, and they were pretty awesome, which is natural, seeing as how Torley is to UI abstraction what Rembrandt van Rijn was to portraiture. I even use a mash-up of one of Torley's pics as my desktop wallpaper. Not to mention Torley's texture packs—they look really cool on a nice twisty torus! And there is a new pack out that I have to run out and get! And the songs, oh so many wonderful songs (especially lovin' the piano fantasies)! *gush* <3 We all love Torley! <3

(Hey, that's like 3 posts in one day. This is starting to turn into a blog or something. What the cube?)

Disabling Typing Sound Client-side

You know that really loud and annoying typing sound? The one that plays whenever anybody starts to chat? The one that used to ruin in-world live music events? The one you muted all sound effects to get rid of?

Yeah, you know the one. Well guess what: you can replace it with the sound effect of your choice, or just get rid of it entirely. You don't even have to change any code in the viewer source; we could have done this all along. (Which really rubs salt in the wound, doesn't it?)

Here's how:

1. Enable the Client and Server debug menus with Ctrl-Alt-Shift-D.
2. Client > Debug Settings (second entry from the bottom)
3. Type or find "UISndTyping" in the drop-down menu box.
4. To get rid of the typing sound: clear the text entry box at the bottom. To use a different sound file, paste its UUID into the text entry box. (You can get a sound's UUID by right clicking it in your inventory and choosing "Copy Asset UUID".)
   

That should save the setting to your user_settings.xml file:

    <!--Sound file for starting to type a chat message (uuid for sound asset)-->
   <UISndTyping value=""/>

This only changes what you hear from your own client, which means everyone else will hear whatever they set. And best of all, you won't hear typing from other avatars, either! Now that's music to my ears!

OSS Viewer success

Minor news bulletin: I compiled the latest viewer source and successfully connected to the grid today. I'm not sure exactly why it worked this time, but there are a few major possibilities:

1. I used the faster, but proprietary jpeg2000 decoder library.
2. I actually followed all the instructions.

But there's no way of knowing exactly which it was... so, um... yeah.

UI Abstraction Photo Contest

You may have read about the next contest at the Photography Studio in Grignano. I've submitted two images to the contest, which you can view below!

Both entries are based on a set of snapshots I did of one scene; every snapshot in the set was of the same scene from the same angle, but with different settings. The stark difference between the images below is the product of experimenting with how the many snapshots were layered and combined. The series is entitled "Welcome".

Click each image to view a larger size.

They will be hanging on the walls of the venerable Studio with all the other entries for the exhibit, so you should check the place out!

Also, if you're thinking of submitting an entry, you'd better hurry: the deadline for submission is tomorrow evening!

Purple Reinaday!

Status Update 01-13

I've compiled the vanilla viewer 3 times so far, twice as "release" and once as "releasefordownload". I've also connected to the Grid (Agni) several times, but each time the connection was apparently interrupted or died or was deauthorized soon after log-in.

Movement, teleportation, profile viewing, map viewing, and who knows what else were non-operational. The Friends list seemed to work, and I tried to send a couple IMs to my online friends, but they were not received. L$ balance was blank, and some menu options were disabled (specifically "Appearance" and "Upload ____"). My avatar was invisible except for a few attachments attachments, and no in-world objects were visible. The terrain was visible, however.

There were several varieties of suspicious/interesting messages which flooded the console at various times.

The first variety looked like this:

[INFO] tile 1 of 1
[INFO] - tiers-1 took 1.032843 s
[INFO] - dwt took 2.815572 s
[INFO] - tile decoded in 4.792272 s

I think it is reporting on the download and decoding of texture files from jpeg2000 format. Some time after the log-in process began, an increasing amount show up like this:

[INFO] tile 1 of 1
[ERROR] tcd_decode: incomplete bistream
[INFO] - tiers-1 took 0.117982 s
[INFO] - dwt took 0.406939 s
[INFO] - tile decoded in 0.736888 s
[ERROR] read error

If I try to move or fly, I get messages like this:

2007-01-11T23:22:44Z WARNING: sendMessage - Trying to send AgentUpdate on unknown circuit 72.5.13.29:13004

If I try other things, I get the same message, but with "AgentUpdate" replaced with other message names, like "ViewerEffect" or "TeleportLandmarkRequest" or "AgentPause" or "LogoutRequest".

Finally, here is an example of the message log summary I get when I quit the viewer.

2007-01-13T23:04:01Z INFO: START MESSAGE LOG SUMMARY
2007-01-13T23:04:01Z Run time:      591.330 seconds
2007-01-13T23:04:01Z Incoming:
2007-01-13T23:04:01Z Total bytes received:                     78004 ( 1.06 kbits per second)
2007-01-13T23:04:01Z Total packets received:                     403 ( 0.68 packets per second)
2007-01-13T23:04:01Z Average packet size:                        194 bytes
2007-01-13T23:04:01Z Total reliable packets:                      24 ( 5.94%)
2007-01-13T23:04:01Z Total compressed packets:                    71 (17.57%)
2007-01-13T23:04:01Z Total compression savings:                 8097 bytes
2007-01-13T23:04:01Z Avg comp packet savings:                    112 ( 1.38 : 1)
2007-01-13T23:04:01Z Avg overall comp savings:                    20 ( 1.10 : 1)
2007-01-13T23:04:01Z
2007-01-13T23:04:01Z Outgoing:
2007-01-13T23:04:01Z Total bytes sent:                          2000 ( 0.03 kbits per second)
2007-01-13T23:04:01Z Total packets sent:                         437 ( 0.74 packets per second)
2007-01-13T23:04:01Z Average packet size:                          5 bytes
2007-01-13T23:04:01Z Total reliable packets:                      71 (16.21%)
2007-01-13T23:04:01Z Total compressed packets:                    14 ( 3.20%)
2007-01-13T23:04:01Z Total compression savings:                  244 bytes
2007-01-13T23:04:01Z Avg comp packet savings:                     16 ( 1.22 : 1)
2007-01-13T23:04:01Z Avg overall comp savings:                     0 ( 1.12 : 1)
2007-01-13T23:04:01Z
2007-01-13T23:04:01Z SendPacket failures:                          0
2007-01-13T23:04:01Z Dropped packets:                             10
2007-01-13T23:04:01Z Resent packets:                              34
2007-01-13T23:04:01Z Failed reliable resends:                     42
2007-01-13T23:04:01Z Off-circuit rejected packets:               267
2007-01-13T23:04:01Z On-circuit invalid packets:                   0
2007-01-13T23:04:01Z
2007-01-13T23:04:01Z Decoding:
2007-01-13T23:04:01Z                             Message     Count      Time       Max       Avg
2007-01-13T23:04:01Z END MESSAGE LOG SUMMARY

On the plus side: except for not being able to log in or do much of anything, it works great! ...

Miscellaneous Feature Ideas

Just brainstorming features (large and small) that would be both possible and desirable to add to the Second Life viewer client. Things which would require server changes don't fit here, only things which can be accomplished by changing the client only. I'm also focusing only on new features for this post; I might make another post of bugs that should be fixed.

• Menu items for builder tools (e.g. Edit Linked Parts, Ruler Modes, Color/Texture Pickers).
  
• Hide/show specific UI elements. (Tateru gets the credit for thinking up this one.)
  
• Arbitrary number of clothing layers on all body sections.
  
• Improved avatar mesh UV maps, so clothing and skins are easier to create and align.
  
• Improved avatar mesh weighting, so joints don't bend in such an ugly way.
  
• Modifiable menus (rearrange and set shortcuts on the fly).
  
• UI color schemes.
  
• Additional image file formats (e.g. PNG).
• Client-side script API, allowing interpreted scripts to access client functions.
  

Here's how I would rank them:

The three least difficult to accomplish, in increasing difficulty:

1. Menu items for builder tools.
2. Hide/show UI elements.
3. Improved avatar mesh weighting.

The three most beneficial, in decreasing benefit:

1. Client-side script API.
2. Arbitrary clothing layers.
3. Modifiable menus.

The three best time investments (most gain for time spent), in decreasing return on investment:

1. Client-side script API. (The gain is simply astounding.)
   
2. Menu items for builder tools. (The gain is only moderate, but the effort is minimal.)
   
3. Arbitrary clothing layers. (The gain is very great.)

If you care to comment on how you would rank the listed items differently, please do so. I'm not asking for new ideas for features, though; I think there are more appropriate (and worthwhile) channels to be heard.

Post-OSS Plans

I've dived head-first into the client source code. For the moment, I'm just orienting myself, poking my head around to see what goes where, building up a mental map of how the pieces fit.

An obvious next step is to attempt a compile of the viewer as-provided, before making any changes. That way, if something doesn't work, I will know that at least it used to work, so something I did broke it.

I'm also familiarizing myself with Linden Lab's issue tracker, wiki, mailing list, etc.—all the new stuff that appeared. I'll probably see if there are any little bugs in the issue tracker that I can fix.

In the meantime, I'm noting areas of the source code that interest me, so that I can focus and specialize in them. At the moment, improving the user interface seems to be where I get my kicks. The things I noted in my exploration of XUI as being impossible without access to the source code are now, of course, possible.

Lots of new toys to play with.

Second Life Viewer Open-Sourced

This is quite simply the most important SL news ever. Don't I seem excited? Well, I am. You could say I am cautiously optimistic.

Linden Lab has put a lot of thought and planning into this move, as evidenced by the info-laden open source page and new wiki. I can only hope they know what they are doing.

Yes, part of me worries about the negative effects we will almost certainly see in the near future. This has the potential to be much worse than the CopyBot scare, and with good reason—this turns the Grid upside-down. The assumptions that had been in place are now defenestrated, and business models will have to adapt, and adapt fast. Except for scripters and sex workers, there is no SL market I can think of that will not have to fundamentally rearrange itself.

Honestly, Linden Lab should have given an announcement several days prior to the source code release, to give time for preparation. I would not be surprised if many content providers close down temporarily, until they decide what to do.

We will probably see theft and panic. Temporary economic instability. But people will adapt. New business models will emerge. And most importantly, new tools will be created to improve Second Life.

Let's have hope for the future. The next few days will be rough as vendors panic, but things will calm down. Later, probably within a week, some new tool will be released to exploit some security hole, and more people will panic. But things will calm down again.

And then we'll see some really neat stuff. The kind of stuff that restores your faith in humanity.

That's how I see it, anyway. Time will tell.

Happy Patiday

On the Technical Town Hall

Some excerpts from the Technical Town Hall transcript that I found particularly interesting or insightful, for whatever reason. Quotes are sometimes followed by my comments, when I have something to add. All emphasis in the quotes is mine.

Server scaling, other than the centralized services issues I just covered, is primarily a function texture prioritization/downloading, script processing, physical simulation, and interest list calculation.

The phrase interest list calculation gave me a fascinating little peek at how the servers prioritize what content (esp. animations, sounds, and textures) to keep ready-at-hand to feed to your viewer. It also explains why editing or hovering your mouse cursor over an unrezzed texture often makes it rez faster. And why textures you haven't accessed in a year take longer to rez than textures a dozen people see every day.

We had a serious bug through october and november that was crashing sims in the messaging code. That bug is now fixed, so sim crash rates should drop. As we find them we try to kill them.

Background: for several consecutive weeks in November, the sim where I host my Advanced Building class would crash 3-4 times within the 2-hour class session. On more than one occassion, I strongly considered retiring from teaching in SL, simply because of this issue.

I will say that we are trying to update our messaging system to more properly leverage existing standards rather than our hand-rolled one. … Doing this is, as you might imagine, a tremendous amount of work, because we have to start by taking message template out behind the shed and shooting it. Then, we need simulators and viewers to be able to discover what features they have, be able to fall back gracefully, etc etc.

I would ask folks to remember that when we undertake major changes, it is a little like trying to rebuild the engine of a car. While driving it. And changing to a hydrogen economy. Without hitting anyone, losing control, or breaking the car.

If they [libsecondlife developers] break the terms of service we treat them like any other resident, but just because they tinker does not make them criminals.

Speaking of hiring … to reinforce what Philip said, if you and a friend are somewhere other than the Bay Area, we still should talk. We are already a distributed company and I see no reason why we can’t become more of one.

Rolling Your Own Menu

Jacek's secret herbs and spices

Have you ever wanted to gather all your favorite and most-used items from Second Life's main menus, and put them all in one place for easy access? Well, you can do exactly that by editing SL's XUI files!

For my own purposes, made a new sub-menu, Builder Tool, which lives under the Tools main menu. In it, I put lots of useful building tools and options that I took from various other menus. Now I can tear off one little menu, and have them close at hand while working! Yay!

I also added two new menu items, for options found in the Edit tool window: Stretch Both Sides and Stretch Textures! Because they are now menu entries instead of checkboxes in the Edit window, I can assign keyboard shortcut keys to toggle them! Double-Yay!

Rather than walk through every step of editing the XML, I'll just point out the important or new things. All the editing is done in menu_viewer.xml, the same file we editted to change the keyboard shortcuts before, but I also referred to floater_tools.xml, as described later in this post.

Creating a new menu is fairly easy: just make (or duplicate and modify) a <menu> block, being careful (of course) to close the block with a </menu> tag. Gathering items from other menus is a simple matter, just copy and pasting each desired <menu_item_*> block into the middle of your new menu block. From what I can tell, the positioning attributes (bottom, left, etc.) are ignored or overridden by SL, so you don't even have to worry about getting those numbers right.

Adding the two new menu items, Stretch Both Sides and Stretch Textures, was not much harder. But in fact, it is only possible because of the particular way that those two options, along with the Snap to Grid/Use Grid option, were implemented; I suspect that they were all once menu items in the past, or were intended to be so. Snap to Grid currently is a menu item in the Tools menu, and it was by examining the XML for the menu item and comparing it to the corresponding checkbox in the Edit window that I discovered that it was possible to do the same with the other two options.

The key is that all three of these options are manipulated by calling the ToggleControl function and passing the control name of the option. Both the menu and the checkbox refer to the SnapEnabled control name: in floater_tools.xml, the Use Grid checkbox has an attribute, control_name="SnapEnabled"; in menu_viewer.xml, the Snap to Grid item has two lines which mention SnapEnabled, once in an <on_click> tag, and once in an <on_check> tag.

Making the two new menu items was just a matter of looking up their control names (ScaleUniform and ScaleStretchTextures) in floater_tools.xml, and plugging them into copies of the Snap to Grid menu item definition in both lines (be sure to change the text labels to be descriptive of their new functions).

Doing a quick grep of the XML files, there are a handful of other miscellanious options which have control_names. This suggests to me that menus could be built to change these too. Some notable example uses are: (un)muting audio; the Copy Selection tool; toggling chat bubbles; toggling avatar names above their heads.

It may also be possible to change other options which are not simple on/off switches. For example, it just might be possible to make a menu item which changes all the render detail settings and draw distance to the minimum, for dealing with crowded areas.

Unfortunately, this dependence on knowing the option's control name means that this method does not allow us to add an "Edit Linked Parts" menu item—the checkbox in the Edit window does not refer to any control name. I still hope that it can be added somehow, but for now it's up to the Lindens.

Happy building!

My XUI Wishlist

There are specific things that I want to accomplish which drive me to poke my nose in SL's XML User Interface (XUI) definitions.

Here are the ones I have already accomplished:

1. Customize some menu shortcuts.
   
2. Rename "Hole Size" to "Thickness".
   
3. Decripple Transparency.

Here are the things I want to accomplish, but are probably impossible through XUI-editing alone:

1. Define keyboard shortcuts to toggle "Edit Linked Parts" and "Stretch Both Sides".
2. Move the color and texture eyedroppers/pipettes from the Color/Texture Selection windows to the Toolbox's Texture panel, next to the swatches.
3. Decripple the prim attributes.
4. In particular, be able to edit the Profile Cut attribute for Box, Cylinder, and Prism.

I have already tried #2, performing a simple copyandpastectomy of the pipette button from the Color Selection window to the Texture panel, but the button was nonfunctional/disabled. I suspect that the Toolbox window does not have the proper function(s), or is not programmed to listen for clicks to that button. Likewise for #1: the button tag may not respond to shortcut attributes as the menu items did.

#3 and the more specific #4 appear to be impossible because the functionality involved in limiting, adjusting, and hiding various attributes based on prim type is programmed into the SL viewer, and is not part of the XML. To be able to coax the Profile Cut attribute to appear for Boxes, I would probably need access to SL's source code; of course, I do not have access to the source code, so this seems to be out of my hands.

Decrippling the UI

Ok, so I changed the Second Life XML User Interface files to change some text labels and names in the Toolbox (Edit window). This was just a simple matter of reading through the floater_tools.xml file and changing a few words here and there. No biggie. (No, I did not add a new prim type!—I just renamed "Sphere" to "Watermelon". It's much nicer, don't you think?)

But aside from the obvious comedic value, what can changing the UI do for us?

Here's a good one, the true poster child of useful UI changes: we can decripple the Texture panel's "Transparency" input form. Have you noticed that you can only make an object 90% transparent using the UI, but you can make it 100% transparent with a single function call in a script? Linden Lab crippled the UI, perhaps to prevent new Residents from making hundreds of totally invisible prims and forgetting where they put them.

Well, if you are capable enough to edit SL's UI definitions, you are experienced enough to toss aside that crutch! Please note that the same disclaimer as my earlier post also applies here—you are doing this at your own risk! Here's how: in floater_tools.xml, search for the string ColorTrans. That should take you to a <spinner> tag defining the spinner (a numeric entry form with up/down arrows on the side) that controls transparency. That tag has an attribute, max_val, which defines the highest number you are allowed to put in it. Change that number from 90 to 100. While you are at it, change the increment attribute to something more useful, like 5 or 10; now it will increase by that amount whenever you click the up/down arrows on the spinner (or use your mousewheel ← bonus pro tip for you!). The default value of 2 gives you a good degree of precision, at the expense of convenience. Don't forget that you can always just click on it and type in whatever number you want, when you need precision!

Now start (or restart) SL, and enjoy your newfound freedom!

IM IN UR XML IMPROVIN UR INTERFACEZ

(Write-up and useful changes to XUI tomorrow.)

Hacking XUI for Fun and Goodness

Today, I was writing up a huge post about custom keyboard shortcuts. I was covering all the bases: why keyboard shortcuts make everything happy and warm, the ways in which SL's shortcuts are poo, and how Linden Lab could and should implement custom keyboard shortcuts. During my research into this last aspect, I realized something:

I can do it myself.

In fact, I not only can do it, I have done it. As a proof of concept, I successfully remapped the Ctrl-Shift-M shortcut. It had previously been bound to View > Mini-Map; it is now, for my Viewer, bound to World > Force Sun > Midnight.

This is just the beginning.

For the curious, here's how I did it.

Second Life's user interface is (at this point in the time, but not so in the past) defined as XML located in the skins/xui/xyz/ directory (where xyz is the language code; for English readers like myself, it's en-us). The XML for the menu bar along the top of the viewer is in the menu_viewer.xml file.

The majority of this file are <menu_item_call> tags, one block for each menu item. One of the possible attributes for this tag is "shortcut". The values for the shortcut attribute are a pipe-separated list of modifiers followed by a key. For example, the "Ctrl-Shift-M" key combination is expressed as "control|shift|m".

Make a backup copy of menu_viewer.xml before you make any changes, in case you break something and need to revert. Then use a text editor (or, if you have one, a dedicated XML editor) to open the file. Find the entry for "Mini-Map", and cut out the part that says: shortcut="control|shift|m". Then find the entry for "Midnight", and paste it after name="Midnight" (but before the closing brace; and don't forget to put a space between between the quote after Midnight and the beginning of shortcut).

That's it. Start up SL, and if everything went as planned, the "World > Force Sun > Midnight" menu item will show a shortcut key combo next to it, and "View > Mini-Map" will not. You can press Ctrl-Shift-M to see for yourself that it now forces the sun to midnight.

Like I said earlier: This is just the beginning. There are dozens of other XML files in that same folder, defining such things as the layout of the edit window, the min and max values of number entry forms, and many, many other things which I intend to experiment with.

I will close with this disclaimer: I re-read the SL Terms of Service tonight, especially section 4.2, which covers accessing SL with "unauthorized" software (this is one of the sections that was amended after the recent CopyBot scare). And although I think that modifying the XML files accessed by the SL Viewer client is probably not a violation of the spirit of the TOS, should you choose to do it, you do so at your own risk.

It would be a mistake for Linden Lab to discipline anyone for trying to improve their own user experience without harming others; but it wouldn't be Linden Lab's first. Fair warning.

Unheavenly Bodies

The sun and moon in Second Life are unrealistic and just plain ugly.

That's right, I said it. I went there. Ugly!

Figure A.

As I see it, there are three main problems with Second Life's sun and moon:

1. Their reflections on water stretch unrealistically.
2. They sometimes appear as dark or darker than the sky around them.
3. Background stars are drawn in front of them.

Examine Figure A; the left half is raw, untouched snapshot of a near-sunset in SL at 300m; the right half is what I think it should look like. (NB: the bottom of the reflection is partially obscured by clouds.) Both problems 1 and 2 are in full force here.

Figure B.

Optics minilesson #1: In the real world, a reflection of the sun or moon on the water appears stretched because of small irregularities (i.e. ripples) on the surface of the water which change the angle at which light is reflected. You can see this in Figure B, a test image I rendered in Blender using raytraced reflections. The image shows a lit sphere resting on a perfectly reflective surface. On the left side, the mirror is completely smooth; note that no stretching occurs in the reflection. On the right side, however, the mirror has small ripples which affect the angle of reflection, causing the same type of stretching seen in the real world.

My graphics card is not powerful enough to enable fancy water, so I, like many Residents, simply see an upside down and yuckily stretched version of the sun or moon in the water. I know the programmer who did that meant well—he or she just wanted to make it look as if there were ripples distorting the reflection. But all it accomplished was making it look like the Grid is a concave Discworld.

Optics Minilesson #2: In the real world, the sun can never appear as dark or darker than the surrounding sky for the simple reason that the brightness of the sky is due to partial scattering of the light from the sun. Most of the light from the sun passes through the atmosphere without much scattering, which is why the sun appears to be a circle with definite edges, rather than a vague patch of brightness.

Figure C.

Optics Minilesson #3: The moon, too, will always appear at least as bright as the sky around it, never darker (as it does in the left half of Figure C). This is especially obvious on days when the moon is visible during the early morning or late afternoon; the unlit parts of the moon, which would appear black at night, appear the color of the sky.

Why does this occur, when mountains and skyscrapers do appear dark against the sky? Quite simply, because mountains and skyscrapers block the scattered light from the sky. The moon, because it is outside the atmosphere, does not block it.

Also note in Figure C the star appearing in front of the moon. That's just crazy.

Oi, clients.

This is not a rant. This is a cautionary tale.

I have done all my ranting about this issue in private conversation; ranting in public would do nothing to help it. I will not be naming names, and I ask that anyone familiar with the situation refrain from the temptation as well. I am not writing this to attack any individual, but as a general warning to others, and a reminder to my future self.

Over the past month, I have been working with an individual, "X", to thrash out the design for a large-scale building project. We went through several iterations of the design as I began to understand what X wanted. Finally, X was satisfied with the direction I was taking the design, and asked me to submit a formal bid—how long it would take to build, and how much I would charge to build it.

I mulled it over for a couple days, and sent my bid to X: estimates for what work I would be doing, how many hours each part of the work would take, when I would start construction, and when construction would be complete—along with my fee (regardless of how long it actually took to build). Given the number of hours of work estimated, I was charging about US $15/hour for construction, texture treatment, and scripting (my design allowed for the layout of the building to easily change with the client's needs).

It was, from my point of view, a fair offer. Given the scope of the project and the skills involved, I could have asked for much more than that. However, I am not a big-name well-established builder, so there is some amount of risk, from the client's viewpoint, that what I deliver would not meet the client's expectations. I took this risk into account in my fee, among many other risks on both sides. Confident that my offer was reasonable, I sent my bid to X.

To put it nicely, X was not prepared to pay what I asked, and rejected my bid.

To put it accurately, X snidely accused me of charging an excessive amount for my services and dismissed me without any further discussion.

X, it seems, would not pay more than a certain amount which, given the number of hours I had estimated as necessary, came out to less than US $3.50 per hour. Upon hearing this, I (trying to remain civil) asked X for verification of that rate, and asked if the number of hours I was estimating was, perhaps, more than would be necessary to achieve X's vision. X refused to discuss it.

Now, X had been a difficult client to work with during the design phase. X's "requirements" were vague, and in some cases contradictory or simply impossible given the realities of three-dimensional space. (On the other hand, if I were building for four-dimensional space, such pithy concerns as distance and volume could be ignored). I was warned by another builder who had worked with X. I had no reason to expect X to act rationally, but hope springs eternal.

The lessons I have learned (or had reinforced) are:

1. Make sure the client knows what he/she wants before you begin, and can communicate it to you. Otherwise, you are trying to hit an unknown and possibly moving target, which is quite frustrating! It also increases the likelihood that the client will pull something new out of their hat halfway through the process.
   
2. If you are designing a build in addition to constructing it, treat them as separate processes, and charge separately. Planning the design before you build is good on general principle, of course, and treating them as separate processes helps enforce that. On top of that, it ensures that you will be paid for the design work, even if the client changes his/her mind about hiring you for the building. I also recommend charging as-you-go for each revision of the design if possible, for the same reason.
3. If the client is full of drama before you are working for them, they will probably be even more full of it while you are. If drama, headaches, and frustration are what you are searching for, this is good news. On the other hand, if you value your sanity, pass up that client.
4. Contracts protect both sides. Write up contracts for every step of the way, outlining the expectations of both parties, and what should happen if those expectations are not met. Have the client sign/agree to each contract, then stick to it.