Optimizing RuthAndRoth Delivery and Usage for Upcoming Versions #31
Comments
|
@aiaustin I agree - how do you think that should be organized? Another task is publicity - letting everyone know what we have and where to get it. At this point Sean and Hyacinth are also distributing their versions (anyone else?) so we might want to coordinate with them. Today I'll spend whatever time I have working on vertex weighting for Roth's hands and feet. They need some re-modeling to line up the mesh with the SL/OS armature. RC#1's hands and feet look like pudding and I think we can do better. So far, FUBAR, but that's been true for a while :} |
|
I don't think it will be complicated. I assume you will be best placed to do things? When you have uploaded and are happy with the DAEs and any textures needed in SL and any one open OpenSim grid (say via your area on the RuthAndRoth region on OSGrid?) if you just make a box to put everything in making sure all included elements, textures, scripts, box art, etc are full perm - we often miss out some part like a script or texture) =. We can then perhaps test that via two or three of us to make sure everything comes over full per and test again.. and if that works, we can put out the boxes for the others to take and use as a basis for their own distributions. the main thing being to suggest (only a suggestion) that if they would like to use those assets we may get efficiency, caching and reuse benefits for everyone. I agree on syncing up with @seriesumei, Sean , Hyacinth and others on this. Its just a suggestion to have them use one base mesh asset, but of course they can alter the model and do fresh uploads if they want or need to. |
|
On 11/22/19 10:29 AM, Ai Austin wrote:
I don't think it will be complicated. I assume you will be best
placed to do things? When you have uploaded and are happy with the DAEs
and any textures needed in SL and any one open OpenSim grid (say via
your area on the RuthAndRoth region on OSGrid?) if you just make a box
to put everything in making sure all included elements, textures,
scripts, box art, etc are full perm - we often miss out some part like a
script or texture) =. We can then perhaps test that via two or three of
us to make sure everything comes over full per and test again.. and if
that works, we can put out the boxes for the others to take and use as a
basis for their own distributions. the main thing being to suggest
(only a suggestion) that if they would like to use those assets we may
get efficiency, caching and reuse benefits for everyone.
I agree on syncing up with @seriesumei, Sean , Hyacinth and others on
this. Its just a suggestion to have them use one base mesh asset, but
of course they can alter the model and do fresh uploads if they want or
need to.
I think having a reference set of assets is a great idea, and in the
case of the mesh documenting the mesh import settings used. I have had
times I wanted to make those different so re-imported something but not
known if I am getting everything right that I do not want to change.
The box of Ruth RC3 that I assembled consists of a combination of mesh
uploaded by me and Sean and I forget if I cribbed from anyone else. I
went looking for what worked best for the combination I wanted.
In my other open source work having a common reference can be
invaluable, especially when making "localized" tweaks and sorting if the
trouble is in my own work or is upstream.
The other thing to keep in mind is how the AGPL licensed parts need to
be handled. I have been considering that making the raw uploads
available alongside the packages I create[0] to be part of meeting the
requirements of source being available. Strictly speaking we probably
cover that with the availability of the repos but I am not certain that
is completely settled...and it is in the spirit of being open and
sharing to make that available for others to work with as they like.
ss
[0] The packaged body may not necessarily be completely full-perm for
various reasons...
…--
Serie Sumei
Serie-ous Style
https://serie-ous.style
|
|
@seriesumei @aiaustin Maybe make an avatar called Ruth&Roth TeachingProject or some such? Then we could share the distribution and boxing chores. A notecard directing users back to the GitHub should make the box contents compliant with the AGPL? Along with a list of the names of contributors, which Shin also had in the box art, I think. Meanwhile I am back to the umteenth iteration of Roth RC#2. As I learn Blender 2.8 I've been scrapping and starting over, a lot. But I'm starting to settle down. |
Yes, just a short note referencing the license and the location they can find the source is sufficient. |
|
Yes, a good readme, credits, pointer to build instructions, and license notecard is an essential element of the distribution boxes. I am also very much in favour of all items in the core distribution being full perm. We can always have extras, clothing items, etc in add on boxes. Shin was not keen to include the exact release version/date in the description field of every component when I suggested it to him, but I would still advocate that we do that. |
|
I may not have been clear about what I meant, but I don't think we are thinking too differently... by two packages I was referring to a reference box with what all we have been talking about here and an end-user retail box. I don't think we need to separate by license there and everything in the reference box should be full perm. The second package I am working on is more like a retail package one might pick up from another mesh body vendor, ie Ready to Wear, similar to what Sean has been making. There are parts of this package which we (or just me?) may want to be no-mod, specifically scripts simply because we have no way to verify the compiled output of any script (like checking hashes of binaries to detect changes). For retail-type support and allowing re-distribution I think this is important. The full-perm source of the scripts are either included in a notecard or links to the repos so a knowledgable user can replace the no-mod scripts and continue on her way.
I agree Austin, I found myself doing exactly this when I knew what versions I had, it is the only way to keep things straight in inventory. I did transfer much of that to my wiki as I built the retail box though to keep track of it in one place and make referring between SL and OSGrid saner. I find myself really wanting a meta-script language to drive Firestorm to automate this stuff. I have visions of "make import" being a target in our repos :) |
What's the intent of this?
Same here. It would really save a lot of time. I could contribute some work on this if it's desired. Unfortunately the repository is currently quite haphazard. The exports are scriptable through Blender, but Firestorm would need some enhancements (possible, but not simple). |
|
The intent of no-mod scripts is for support and safety. We will be allowing re-distribution of much of this, and in a retail-like package where someone may give it to others I want to ensure that the scripts have not been modified before being re-distributed. We have no way I know of to do that. Including the full-perm scripts in a notecard gives a knowledgable user the ability to remove the no-mod scripts and replace them. This is something I have run into with things I have given away in the past, maybe my experience is not the norm and I am worried about a rare occurrence? Re imports, I played with Corrade a couple of times and thought it might be simpler (in concept at least) to snag the mesh importer and use it from something that isn't a GUI. On the other hand Lua is fairly straightforward to add to many things, it would be mostly glue work to wire it up to the importer and whatever else. Neither of these are things I have much time for so they remain curiosities I ponder occasionally :) |
I still don't think I understand the intent. What is the purpose of restricting the purchaser's use of the product? What do you mean by "safety" here? Do you mean so that the person who buys a Ruth2/Roth2 body can guarantee that it hasn't been modified without their knowledge by the packager? Unfortunately, hiding the scripts and making them no-mod has the opposite effect and puts the user in potential danger. They can't examine the scripts to ensure they haven't been tampered with or modified to work in nefarious ways. Making them no-mod from the start doesn't solve that problem, it only moves the burden of trust. It's relatively easy to compare two scripts and check for changes if the contents are viewable. The reality is that most users are going to just use what they're given. Putting in an extra barrier won't change that, but will probably make it worse. In fact, I would suggest that a warning should be in place reminding users to be suspicious of scripts attached they cannot read and examine. Can you give more details on your past experience in this? I may be misunderstanding. :)
Blender natively supports Python (Avastar itself is written using this language) and it can be invoked from the command line to create exported models. I would suggest this as the first part of the workflow to automate. I have my hands full with other projects, but this is doable with relatively little effort. As for Firestorm, there are already a few LSL scripts written to be helpers, but for more automation a reliable (but likely not simple) solution would be compiling a modified Viewer that allows selecting multiple models and perhaps a build script with instructions it can follow to correctly construct it (all within the bounds of proper client/server behavior, of course). |
|
[My apologies for the wall of text, maybe we should move this discussion?] I see two aspects of the script thing: a) support - providing mod scripts lets anyone make changes of course, that is its intention. After someone changes a script they ring up and ask why it doesn't work. This is not in a script-knowledgable-user scenario, it is an end-user attempting to make something work and they don't know what they are doing. Walking someone like this through debugging or repairing their item is frustrating for everyone involved. My belief and experience is it is better for everyone involved to put a token barrier up to making script changes so someone with the need and abilities can replace the no-mod script as required rather than having to perform technical steps with someone who may not be up to the task. b) safety. You describe exactly the scenario I imagine, except for one detail. If you do not trust the packager (me) then you should not be using my items. If you only kind-of trust the packager (me) then you will be replacing the no-mod scripts I ship with the source that you have presumably reviewed. In this case you will be the creator on the scripts. When Alice takes my package and modifies my script for evil then distributes the changes, nobody can tell that it has been changed (say by hashing the compiled binary). I am still listed as the creator on the script (she modified it rather than replace it). I can not prove that I did not do the bad thing Alice added. Providing no-mod scripts that list me as the creator means you must trust me. If you don't then you can always replace them yourself. If you take Alice's package and see me as the creator on the no-mod scripts, you can know that you are running the script I shipped and not something that may have been modified by Alice or Carol or any of the other previous owners. I'll admit I am considering a case that may not be common, but I am also targeting a user segment that is likely not at the level of comparing two scripts to see if either one is trustworthy. I am looking at handling the common case and allowing for those able to help themselves address other cases to do so. Am I being paranoid? I have had the B scenario happen, just once thankfully, and have thought about it and tried to pay attention to how others handle this for a long time. For people like my friend Pippi to be able to wear Ruth I need to have it act and feel at least a little like her other mesh bodies. She would have no clue how to read and examine a script to know if she can trust it. Like you said, she is going to use what she is given. In the event it needs to be verified, there is a way to do that. In the event her hubby wants to make a change for her, there is also a way to do that. None of this is meant for the reference Ruth/Roth distribution assets. We already assume when you open that box that you are tall enough to ride. |
|
Ah, I understand much better now. For the reasons you describe, I believe you are correct that is the best option. As long as the notecard contains the information on how to acquire the scripts and the script is not otherwise changed except having its permissions set to no-mod, there should be no issue. Thank you for clarifying your position for me. :) |
|
@seriesumei and @Deledrius Thank you for this analysis, very helpful! I don't think you're being too paranoid. Most of the people using Ruth & Roth are not programmers and will be happy to have a safer script that works without having to figure out how to get stuff out of GitHub and import to their grid. Beginner scripters can get your scripts from Git and learn from them and you get to decide whether or not you want to spend time with that. |
When we have the next versions of RuthAndRoth, can I suggest we coordinate a bit to try to get a single canonical upload of the assets to Second Life and a single upload into an open easily accessible OpenSim grid (such as OSGrid)... with full permissions and grid export availability... to make a single underlying asset version which anyone can use and distribute.
This is something I have raised before when we were another R2 repositories, but let me note it as an issue here too. It is something I advocate to potentially get the same underlying mesh and texture assets used by multiple avatars.
Of course there will be one set of assets of Second Life, and another set for OpenSim, but with luck we could end up with a single asset across all OpenSim grids.
This also, of course, is not meant to stop anyone uploading the DAE versions or modifying the meshes or textures and uploading as they see fit... its just an attempt to improve loading times, use caches where multiple avatars use RuthAndRoth in a single location, etc.
The text was updated successfully, but these errors were encountered: