I am not the person who you bought this item from. I don't actually sell any buildings at all. I sell a product called Rez-Faux, and the person who made your product has used Rez-Faux to package and sell their building. You should contact them for more help. You can find out who you bought this build from by rezzing it and checking the Creator on any build piece.
To my customers: If you can't solve your customers' problems, I'd be glad to help you. Please check through this FAQ (specifically "Some pieces of my build aren't rezzing") or submit a Support Request.
Please, please be sure that your customers know that YOU made the build you're selling them! It's a difficult situation for both of us when they come to me for help with your products. It tends to upset people when I tell them that I can't help them, so by the time they get to you, they're likely to already be quite irate. You can make it so that you are listed as the Creator for your Rez-Faux package by simply creating your own package box and moving the entire contents of the Rez-Faux package into your custom package box. The rezzer will still work just fine.
I originally created Rez-Faux as a tool for my own use when I started making large builds for my group's sim, Suffugium (which has since been closed). I wanted to be able to package my builds, but I didn't want to pay the price that CrystalShard Foo was charging for her rezzer/packager product, Rez-Foo. I didn't initially intend to sell it.
I realized that Rez-Faux could do everything that Rez-Foo could do, and that I could conceivably charge less and bring the product to more people while possibly still making enough money to justify the work it took to bring it to market and provide customer support. As a nod to CrystalShard, I named it "Rez-Faux" to imply that it's the "clone" product, and that my product wasn't the first to market. I don't feel that it's a cheap knockoff in anything but price, however, because my product introduced the ability for my customers to sell their packages without having to pay more for a resell-enabled version.
The name Rez-Faux is intended to be self-effacing, not a slam on CrystalShard Foo. We're friends, honest! She's on my friends list in SL, and we talk occasionally, including about our rezzer products. So I'm not evil, I swear. If you're still mad at me for stealing her idea, it might help you to know that Rez-Foo is not the only other product of its type on the market. It was just the most well-known.
I'm sorry to say that no, I can't do custom work at this time due to many RL constraints on my time.
I'm sorry, but I can't guarantee in-person customer support for Rez-Faux, due to the large volume of customer support requests I receive and Rez-Faux's bargain price. However, I am willing to answer questions via IM, so feel free to ask. My customer support representative, Binne Ming, is quite skilled in answering many common Rez-Faux questions, and she forwards the trickier ones over to me. We're here to help!
The support ticket forms (the web form, my Web Tab in my Second Life profile, and my support kiosk) all hook into my customer and sales information tracking database. I wrote the system myself using PHP and MySQL to keep track of my customer relationships. Right now the system is fairly customized and not really in a form that I can package up and sell to customers, but I have received several requests and am considering the possibility of selling the system in the future. If you're interested, please submit a support ticket and I'll add you to the list of interested people. If I decide to sell it in the future, I'll be sure to contact you!
The latest version of Rez-Faux is 2.3.
Previous buyers can always get a free copy of the latest version of Rez-Faux by visiting my store in Suffugium and clicking the Redelivery sign, located next to the Rez-Faux vendor.
There is an option, "Let Me Sell", to make your package transferable after you have finished packaging the build. You can find out more about this in the Rez-Faux instructions.
Your customers may see "(no modify)" beside the name of your package in their inventory when they buy it. Second Life uses that space to list the most restrictive permissions of any part of an object -- the "weakest link". If any single part of the package is not modifiable, they'll see "(no modify)". In this case, the offending part is the Rez-Faux script itself.
Your customers will still be able to rez the package and then modify the build, provided that you enabled modify permissions on the build itself. The "(no modify)" label is nothing to worry about, as it reflects the fact that the Rez-Faux scripts are not modifiable. This label does have the side-effect of preventing your customers (or you) from renaming the package in your inventory. This is a known bug in Second Life that Linden Lab has acknowledged and has not fixed for a long time.
The way to avoid this is to never change the permissions on any item while it is in inventory, even if it says it's no-modify in the properties window.
This problem is caused by a little-known design facet of the SL permissions system called "permissions slam". Permissions slam can result in unexpected next-owner permissions settings on items if and only if you change the permissions on an item while it is in your inventory. When one part of the inventory item is not modifiable (the "rez-faux positioner" script) and you change the object's permissions in your inventory, this no-modify permission gets applied to the entire object the next time it's rezzed.
Because inventory permissions are fundamentally complicated and involve some unexpected behaviors, you should never change the permissions of a Rez-Faux package while it is in your inventory. You should always change permissions on the build itself before packaging it. You should always change permissions on any second life object only while it is rezzed in-world, not via the Properties panel from your inventory! If you are sure to always do this, permissions slam will never happen.
Yes. You may package as many builds as you would like by purchasing one copy of Rez-Faux from me, and you may sell and distribute packages freely, provided that the builds you package are copyable. The package will include a limited version of Rez-Faux that will allow the recipient to rez, move, rotate, and derez the build.
No. You may not purchase Rez-Faux and give the packaging system to your friend. For gift purchases, please use SL Exchange or IM Lex Neva in Second Life. You can also pay me and open a Support Ticket, noting the name of the person you're purchasing a gift for, and I will deliver the gift on the next business day.
The permissions of Rez-Faux are not completely straightforward, because certain portions are transferrable while certain portions are not. This summary will explain what rights you have when you purchase one copy of Rez-Faux:
This depends on the permissions you had on the build before packaging it. If you had the ability to copy the build before you packaged it, you will be able to rez multiple copies with Rez-Faux. Here's a good rule of thumb: Select the build, right-click it, and choose "More". If the "Take a copy" menu item is not greyed out, you have permission to copy the build.
If you want to make any changes to a packaged build, you must repackage the build afterward or the changes will be lost! This is why it is a good idea to wait to delete your "master" build until after you're sure that your Rez-Faux package came out right. Just go back to your master, make the appropriate changes, and repackage.
If it's too late, and you've already deleted the build, you should rez the package, choose "Save", and then delete the package box. Then make your modifications, and rez a fresh new package box and repackage the build.
Permissions in Second Life can be very difficult and tedious to get right. A single non-copyable script or texture in a single prim in your entire build can render the package non-copyable. This means that you'll need to ensure that every single component of your build is set to the appropriate permissions before distributing. You must open up the contents of every prim in the build and ensure that all contents items like scripts and textures are copyable.
Here's a good way to narrow this down: Send the package to another account you own, or to a friend. Have the recipient rez the package box, then examine its inventory by right-clicking it and choosing "Open". They will see permissions tags by each piece of the build in the package box's inventory. If they see "(no copy)" by any item, then this is the offending item. You can then go back to the master build and search further for the offending item.
It's a pain, I know. :(
If you've already chosen the Let Me Sell option, then the cause of your inability to transfer the package is buried in one of your objects. If you package a build that you don't have the right to transfer, then you will not be able to transfer the packaged version of the build.
As in the previous question, a single non-transferrable piece of your build will taint the entire package and render it non-transferrable. Even a single non-transferrable texture that you used on a single prim in the build will render the entire build non-transferrable. You'll have to examine the entire build, ensuring that every single piece is one that you have the rights to transfer. What a pain!
Here's how to narrow this down: Once you've packaged the build into Rez-Faux, examine the package box's contents by right-clicking it and choosing "Open". Look at the permissions tags to the right of each item, if there are any. If you see "(no transfer)" beside any item, then some part of that item is not transferrable. You should then examine that part of the build in more detail to determine what part is not transferrable.
Take care when using textures or scripts that you purchase in builds that you're making with the intent to sell. You should avoid using any item in your build that isn't fully-permissive, or you risk tainting your entire build's permissions.
Your Rez-Faux package box is modifiable, so you may make any modifications to the box that you see fit, including adding your own branding. You can also simply create your own package box and move all of the contents from your Rez-Faux package box into your new box. Be sure to get all of the scripts, notecards, and objects in the package box. Once you do this, you'll be the creator of the package box, which is a really good idea. It means that I'll stop getting support requests from your customers ;)
(Note that Second Life won't let you simply drag the contents of the Rez-Faux box straight into your own box. You'll need to create a temporary folder in your inventory, transfer the contents from the Rez-Faux box to the folder, and then transfer them from the folder into your new box.)
It's possible to set your house as next-owner no-copy before you package it, but I don't recommend it.
Making your package no-copy is unfair to your customers. See the question below about missing pieces for a good example of what can go wrong. It's very easy for something to go wrong that's beyond your customer's control, corrupting the only copy of your build that they have. If their finger slips and the build gets positioned over a neighbor's plot of land, pieces of the build may get returned. When this happens, the only solution is to derez the build and rez a new copy.
All in all, the fairest way of distributing your building is to make it copyable and not transferrable. This way, your customers can recover from the kinds of problems that routinely happen in Second Life that can corrupt their build. It is possible that they could then rez multiple copies of your building, but how likely is it that they're going to want multiple copies of the same house, anyway?
I've had customers ask me if it would be possible to script limitations into Rez-Faux so that their customers can only have one copy of the building rezzed at any one time. While it would be theoretically possible for me to script in such limitations, it would be absolutely trivial for a customer to circumvent such limitations and end up with multiple copies of the building rezzed. This means that offering any such feature would just provide a false sense of security. These limitations apply to all rezzer products. It's just not possible to reliably script limitations like that, and making builds copyable is always the best policy in terms of fairness to your customers.
If you still must have your build set no-copy, then you should be prepared to deal with the inevitable customer complaints that you will receive. You customers will undoubtedly end up with corrupted builds, if even just due to "prim drift". Be prepared to provide a new copy of the package to any customer that has a corrupted build. One way you can handle this is to allow your customers to "trade in" the broken pieces of the build to you in exchange for a fresh copy of the package box. If you do this, please make sure that you're the creator of the package box by following the instructions in the previous question. This will ensure that your customers know to come to you for help, not me!
Michelle Morphett has released a low-cost add-on module for Rez-Faux that makes handling no-copy packages easier. You can find it on SL Marketplace.
No. You must be the owner of any build in order to package it. For group-deeded builds, shared builds, or other builds you don't own but have access to, you must first gain ownership of the build before packaging it. You can deal with this in several ways:
Before doing either of the first two options, you MUST ensure that the build is set to be fully permissive for the next owner! Be sure that every prim in the build is fully permissive, and that every item in the build's contents is also fully permissive. Otherwise, you could end up losing permissions on your only copy of the build!
This is the result of one or more of the pieces of your build being set no-copy. When a script such as Rez-Faux attempts to rez a no-copy item, Second Life will detect this and delete the item from the object's inventory after rezzing it. This ensures that there is always only one copy of the item at any time. Once this happens, the no-copy items will be missing from the package's inventory, which means that subsequent attempts to rez the build will be missing these items. It is not possible to place the no-copy items back into the package box to rez them a second time.
The problem is made worse when your customer decides to Derez the build. The no-copy items will be deleted with the rest of the build, and when that happens, they're gone forever. The pieces won't go to their Trash folder or get returned to them. The latest version of Rez-Faux tries to detect when no-copy items are rezzed and gives a warning before going ahead with the Derez operation, but it is not always possible to detect no-copy items.
Two things may be at play here. First of all, you should be careful when packaging an item that you don't have copy permissions on. For example, you might buy a couch that's no-copy/transfer and use it in your home. If you package the couch with the house, then your couch will be in the Rez-Faux package box. If you rez the house and then choose Derez, you could delete your couch irrevocably, and you'll be out some Lindens. I am not responsible for content lost in this manner!
If your customers are having trouble with no-copy build pieces disappearing from the package box, then you should try to find out which parts of your build are no-copy. See the question above about setting your build copyable.
There are several possibilities here. Please review the next six questions to see if any of them apply to your situation.
This might be caused by rezzing the package too close to the ground or to the edge of the world. Try this: after rezzing, move the package box up in the air. At some point, the pieces might suddenly snap into their proper positions, and the house will appear whole. In this case, the pieces have detected that they would be below the ground and have stopped at the surface of the ground. SL won't let an object position itself below the ground, so you have to move the build up high enough that the pieces won't be below the ground.
The limitations that SL places on being able to position an object below the ground are based on the position of the "root prim" of each link set. This means that you can position a chunk of the build below the ground so long as its root prim is always above the ground. In practical terms, this means you should link the foundation of a house to one of the walls. A simple way to do this is to ensure that you always select a wall prim last when linking the prims of your building together.
This can happen if you forgot to put the "rez-faux positioner" script into a piece of the build before putting the piece into the package box. Don't worry, we all forget! This is why you shouldn't delete your build before test-rezzing the package. Just go back to your build and figure out which piece you forgot to put the script in. Delete the offending piece in the package box, place the positioner script into the piece, and then take a copy and put it in the package box. Test rez again to verify that you've solved the problem.
This is a real pain in the butt. What's happening here is that some of the pieces of your build are getting unlinked by Second Life when they're rezzed. Rez-Faux can't really do anything to prevent that, because it's caused by an obscure bug in Second Life.
One theory I have is that this is due to the limitation on the distance between linked prims. Usually, Second Life will prevent you from linking things that are too far apart, and will send the "Link failed -- pieces are too far apart" message. However, it's possible in some certain instances (e.g. through the use of "edit linked parts") to end up with objects linked together that are technically too far apart to link. These "unstable" link sets will be allowed to stay linked until Second Life happens to notice that they're too far apart to link, at which point they will be spontaneously unlinked. One time this happens is when an object is rezzed.
The solution to this problem is to identify which parts of the build are unlinking and relink them in smaller chunks. Go back to the master build (you didn't delete it before test-rezzing, right?) and remove all of the positioner scripts. Then unlink the offending pieces and relink them into smaller sized chunks. Finally, start fresh with a new package box and repackage the build. Here's hoping it doesn't unlink on you this time!
Using the unsupported "Mega" prims (bigger than 10m in one or more dimension) can exacerbate this problem. If you're having this problem when using mega prims, try reworking your structure to get rid of the mega prims.
Unfortunately, the explanations above don't seem to fit all cases of this problem that I've seen. I'm still unsure what exactly causes this and how best to work around it when it happens to you, because it's never happened to me with any of my own Rez-Faux Packages. If you can shed any light on why this happens or what you might have done that triggered it, please let me know by filling out a support ticket. If I can gather enough evidence on this, I might be able to make a detailed bug report that helps LL to fix this.
Did you get the "WARNING: multiple rez-faux anchors within 100m." error message? It sounds like those pieces of your build got associated with the wrong rez-faux package anchor. Please see the question below about this error message.
Sometimes, door, window, and other similar scripts will get confused when they're in a Rez-Faux package. One way to deal with this is to simply remove the door scripts when packaging the building, and then replace them after rezzing. If this is not an acceptable solution (for example, if you want to sell a house with moving doors), you should try another door script. You can also talk to the person that made the script and ask them to fix it so that it works when used in a rezzer.
There's a longstanding bug in SL that seems to cause some items to spontaneously change their rotations by small amounts in one or more axes. It's not obvious what causes this, and there's no clear workaround. Sometimes a Rez-Faux package will become "infected" by this bug, and every time the package is rezzed, one or more of the build pieces will come out with a slightly incorrect rotation. This can make it look like some seams aren't lining up, floors and walls have cracks, etc. This problem has been around for months, and it's incredibly frustrating.
Unfortunately, there's not much I can do about this. It's not a bug in my code, and there doesn't seem to be any way my code can work around the problem. If this happens to you, sometimes repackaging the build will help. If that doesn't help, sometimes rebuilding the affected parts of your build from fresh prims (not by shift-dragging) can help.
LL has known about this issue for months and currently doesn't know what's causing it or how to fix it. You can find out more information and register your vote to let LL know that you want this fixed by visiting this page: http://jira.secondlife.com/browse/SVC-94
Yes.
Yes! Version 2.0 of Rez-Faux provides a scripting interface ("API") that, among other things, allows the makers of vendor systems to tap into Rez-Faux's capabilities to rez previews of houses for your customers. So far, I know of these two holovendors compatible with Rez-Faux:
Other such systems may become available in the future. If you're the author of such a system and would like me to consider it for inclusion here, please open a support ticket and tell me about it. (I reserve the right to decide which products will be mentioned here.)
This means that the positioner script found more than one Rez-Faux package box within range. It may be that you accidentally rezzed a second copy of the package box, or you've rezzed a build nearby, and the positioner can't really tell which package box you're planning to pack it into.
To solve this problem, make sure that there's only one package box near you. If you need to, try packaging your build in a sandbox.
If you still can't find the extra anchor, please submit a support request, and I'll send you a copy of a script that will tell you the locations of all anchors within 100 meters.
The rez-faux positioner script has built-in detection to ensure that you only place one script in each link set. You should only place one script in each part of your build, and never in a child prim. This error message means that the script has detected another positioner script, and resolved the problem by deleting one of them.
This means that the rez-faux positioner script could not associate itself with a package box. Did you remember to place a package box before putting the script into your build pieces?
This can also happen if you've already run the "Let Me Sell" option on the package box in question. Once you do this, you can no longer add new pieces to your build, and you'll get this error message. You should start over with a fresh package box and repackage the entire build.
Finally, this can happen if your build is too large to package in one rez-faux package box. Your build must be able to fit in a sphere 100m in radius, centered on the package box. In the rare case that your build is too large to fit, you should package it in multiple segments using multiple Rez-Faux package boxes.
Yes. All pieces of the build must be within 100m of the package box in order to be packaged with Rez-Faux. If your build is bigger than this, you will need to package it in multiple pieces using several Rez-Faux package boxes.
New! Customers who have purchased Rez-Faux are eligible to receive a free copy of Rez-Faux Full Region Edition, a version of Rez-Faux that can package a building of unlimited size provided it is contained in one region. You can get Rez-Faux Full Region Edition in my store: Chamonix (56, 117, 96).
No. You can package as many prims as you want into one Rez-Faux package. Since you can package builds that straddle sim boundaries, it's conceivably possible to package as many as 60,000 prims into one package! I've never seen that, though.
You're rezzing the pieces on top of the box, rather than dragging them into the box. Try this: right-click the package box and choose "Open". Drag the items into the inventory window.
You can also drag them into the Contents window in Edit mode.
SL Exchange doesn't let me sell you a folder of stuff, only a box with contents in it. You need to rez the box that you got from SL Exchange, right click it, choose Open, then choose Copy to Inventory.
Is the land you're over script-enabled? If you see an icon in the top bar by the parcel name that indicates that scripts are disabled, then you cannot package your build on that land until you've been granted script access. You should talk to the land owner or move your build to a script-enabled area before packaging.
Alternatively, maybe you aren't the owner of the build. See this question for more information.
Yes :( The notecard originally had pictures embedded in it. An update to SL awhile ago broke all existing Rez-Faux instruction notecards. If you need the pictures, please open a support ticket asking me for it, and I'll send it shortly.
No. Rez-Faux does not actually change the maximum link distance and allow you to link your entire build as one object. However, it does the next best thing: it allows you to aggregate your entire build into one package, which you can move and rotate by just moving one "anchor" object. It's almost as if your entire build is linked, because you can move and rotate the entire build together.
Sometimes, SL doesn't display small objects that are far away. This is so that your computer doesn't have to spend time drawing things that probably don't matter very much. The object isn't actually gone, but you can't see it. The distance calculation is done based on where your avatar is, so even if you zoom your camera over to where the package box should be, it won't be displayed.
The solution is simple: just walk over close to where you rezzed the package box, and it will appear.
If the box still doesn't appear, try relogging. Sometimes SL just really gets confused and needs a kick.
If even THAT doesn't work, then send me a support request. I'll send you a copy of a tool I have that will tell you teh exact position of any package boxes within range.
No. Rez-Faux is not a "Temp-Rezzer", which is the kind of device you're thinking of. These devices cheat the system, taking advantage of the fact that objects marked "Temporary" do not take up your prim alotment.
I'll just take this opportunity to get on my soapbox. These devices for circumventing prim limits are unfair, and allow you to use more simulator resources than you're entitled to. They cause your build to take up much more in the way of simulator processing time than it would if you'd just rezzed it normally. You may be able to keep more prims on your property, but you're doing this at the expense of your neighbors. If you hate lag (and who doesn't?) don't use these devices!
All that said, Rez-Faux can, of course, be used to rez objects that are set "Temporary on Rez", but that's probably not what you were looking to do.
Yes, both of these are possible, but they're tricky to do properly and easy to screw up. I recommend that you repackage the entire build rather than attempting to modify an existing package.
For those technically inclined, here are some tips. As these are advanced techniques, I won't be able to provide support of you can't make this work properly. If your package gets jumbled, just start over and repackage from scratch.
If you want to add a piece to your build, you'll need to ensure that the package box is in the same place relative to the build as it was when you originally packaged the build. If you've already done "Let Me Sell", it's too late, although you can steal the "rez-faux anchor" script out of a fresh package box and shove it into your package if you'd like. Adding a piece to the package should be as easy as dropping the rez-faux positioner script into it, taking a copy, and dropping it into the package. It's better if you do this on your original build, without having moved the Rez-Faux anchor in the mean time. You didn't delete your build before test-rezzing, did you? To modify an item from the package, you can follow a similar course of action, but be sure to delete the existing build piece from the package box before adding the new version.
Is it possible to put one Rez-Faux box inside another?
Yes, you can do this, if you're careful. This can allow you to have optional parts of a house that customers can rez only when needed. For example, you can build your house with a low-detail fireplace, and have a rez-faux package that rezzes a much higher-detail fireplace when the user wants it. This lets them save prims when the house is not in use.
Here's how to do this:
That should do the job. You will see that the inner packages will display their rez-faux menus when the main package is rezzed. You can avoid this by using the Rez-Faux API to disable the menu on rez. Any custom scripter should be able to help you with this if you give them a copy of the "Rez-Faux API stub/documentation" script.
Please note, I cannot provide detailed customer support on this advanced technique for free.
I'd love to hear about it! First of all, if you'd please read through this FAQ and make sure that it's not just one of these issues, you may find the answer to your trouble. Rez-Faux is tricky to use, and there are a lot of pitfalls that could be tripping you up. If it still looks like a bug, by all means, please open a support ticket here and let me know. I've been known to give free products as a bounty for valid, reproducible bugs in the past.
Yes! The Rez-Faux Script API (Application Programming Interface), included in Rez-Faux since version 2.0, allows third-parties to create scripts that work with and control the Rez-Faux system. This allows scripters to create holovendors using Rez-Faux, to translate Rez-Faux into other languages, and to control other aspects of packaging and rezzing.
You can see my list of holovendors compatible with Rez-Faux above.
Michelle Morphett has released two scripts that modify the behavior of Rez-Faux:
PLEASE NOTE: I cannot guarantee the products listed above, nor can I provide support for them. I list them here only as a reference, and make no guarantees as to their functionality, fitness for a particular task, or their safety.
© Lex Neva. All rights reserved.