[opensource-dev] Collaborative LSL scripting and TPV policy
Good morning everybody! I have a question regarding TPVP and collaborative scripting in SecondLife. Several LSL projects I work on actually are a collaborative work of several scripters. Current environment in SL is far from optimal for that kind of project: - the embedded script editor is very limited (issue mitigated by the fact we can now set an external editor) - keeping track of your own script versions is pretty tedious with the functionality provided by SL inventory - keeping track of versions from other co-workers is even harder (very hard to be sure you have merged all the latest versions before you make a public release of the product) Version management in RL is usually addressed by using a VCS such as git or mercurial. But for SL, that would suppose copy/pasting scripts one by one from the viewer to local disk files before committing to the repository. Hence, both for version management and advanced editing, it would really help if all scripts from an object could just easily be exported to a local folder, then updated back from the local copy (2 buttons in the object edit floater: import and export). I know this is an old topic and that some viewers already have similar features, but I would like to make one that would exactly fit my use case and I need to be sure this will not violate the Policy on Third Party Viewers. In particular, I want to be sure how TPVP §2b must be interpreted: /You must not use or provide any functionality that Linden Lab’s viewers do not have for exporting content from Second Life unless the functionality verifies that the content to be exported was created by the Second Life user who is using the Third-Party Viewer./ Since the official viewer already allows: - copy/pasting any modifiable script - and opening them in an external editor, should I understand that modifiable script export is a functionality that Linden Lab's viewers already provides? Or do we really have to be the creator of the script? If the script creator restriction applies, this would be tedious but not the end of it: we would have to work on a copy of the project that was previously imported from the repository (and thus whose creator would be the user of the viewer), but this would preclude directly working on scripts a co-worker shared with you within SL. I assume many viewer developpers who also script must already have thought about these concerns. What is the best answer you came up with? (Note this is only about scripts. Although it would be nice if it was possible to generalize to other assets, upload costs would make it unpractical, even without considering terms of service!) Cheers, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] STORM-280 (Chat logs should not be deleted by uninstalling) Testing help needed
I've posted a test viewer for STORM-280: https://jira.secondlife.com/browse/STORM-280 Chat logs should not be deleted by uninstalling/reinstalling I could use some help with testing on different versions of Windows (I don't believe that we have the problem except on Windows). There is a test plan in the issue. The build can be found from: https://wiki.secondlife.com/wiki/Downloading_test_builds#Developer_Builds ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
Ubuntu 32 GCC 4.4 Any idea's y'all. Im pretty much clueless about programming but with dumb newbie luck I was able to compile if I changed verticesp-mV[3] = 0.f; to verticesp-mV[2] = 0.f; Compiled but particles looked bad (duh..) Any help would be great :) /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In member function ‘virtual void LLVOPartGroup::getGeometry(S32, LLStriderLLVector3, LLStriderLLVector3, LLStriderLLVector2, LLStriderLLColor4U, LLStridershort unsigned int)’: /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: error: array subscript is above array bounds ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collaborative LSL scripting and TPV policy
Current environment in SL is far from optimal for that kind of project: There are many things SL can do to improve project collaboration, not just with scripts. I can share the problems I've encountered trying to work on projects with others if the scope increases. Version management in RL is usually addressed by using a VCS such as git or mercurial. But for SL, that would suppose copy/pasting scripts one by one from the viewer to local disk files before committing to the repository. My solution to this is to use external source control and append the SVN revision number to the end of the script name. when it's copy/pasted into SL. Not optimal, but so far it gets the job done with the least confusion. Hence, both for version management and advanced editing, it would really help if all scripts from an object could just easily be exported to a local folder, then updated back from the local copy (2 buttons in the object edit floater: import and export). Yes please. Since the official viewer already allows: - copy/pasting any modifiable script - and opening them in an external editor, should I understand that modifiable script export is a functionality that Linden Lab's viewers already provides? Or do we really have to be the creator of the script? Policy question. Technically not an item for this list, but there is no place to ask questions like these. See also: https://jira.secondlife.com/browse/MISC-3263 Linden Lawyer should have office hours, more recently submitted to the community manager via email as per the usergroup guidelines, no response. These Jiras might also be interesting. https://jira.secondlife.com/browse/VWR-14023 (drag and drop uploading) And I could have sworn I'd created a Jira regarding a Second Life inventory version control system and even got some feedback from Nyx about it, but I can't find anything about it. Good luck! Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collaborative LSL scripting and TPV policy
On 2011-09-02 12:32, Stickman wrote: Since the official viewer already allows: - copy/pasting any modifiable script - and opening them in an external editor, should I understand that modifiable script export is a functionality that Linden Lab's viewers already provides? Or do we really have to be the creator of the script? Policy question. Technically not an item for this list, but there is no place to ask questions like these. There's nothing wrong with asking policy questions here, so long as they also relate to open source development. I'll see what I can do about getting an answer to that question (such things are rarely quick). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
I just came along that, too. It only happens with a release build, commit that introduced it is 4880a28422be (viewer-development). I worked around it by passing -Wno-array-bounds to the compiler (see here: https://bitbucket.org/ArminW/kokua-merge-3.0.0/changeset/f4a68595e9b6 ) for now. Hope that helps Armin Ubuntu 32 GCC 4.4 Any idea's y'all. Im pretty much clueless about programming but with dumb newbie luck I was able to compile if I changed verticesp-mV[3] = 0.f; to verticesp-mV[2] = 0.f; Compiled but particles looked bad (duh..) Any help would be great :) /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In member function ‘virtual void LLVOPartGroup::getGeometry(S32, LLStriderLLVector3, LLStriderLLVector3, LLStriderLLVector2, LLStriderLLColor4U, LLStridershort unsigned int)’: /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: error: array subscript is above array bounds ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
The underlying code segment here needs a rewrite. This is one of the rare cases where GCC is actually complaining for a very valid reason. On Fri, Sep 2, 2011 at 11:35 AM, Mysty Saunders mysty.saund...@gmail.comwrote: Ubuntu 32 GCC 4.4 Any idea's y'all. Im pretty much clueless about programming but with dumb newbie luck I was able to compile if I changed verticesp-mV[3] = 0.f; to verticesp-mV[2] = 0.f; Compiled but particles looked bad (duh..) Any help would be great :) /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In member function ‘virtual void LLVOPartGroup::getGeometry(S32, LLStriderLLVector3, LLStriderLLVector3, LLStriderLLVector2, LLStriderLLColor4U, LLStridershort unsigned int)’: /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: error: array subscript is above array bounds ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Collaborative LSL scripting and TPV policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/2/2011 9:50 AM, Oz Linden (Scott Lawrence) wrote: On 2011-09-02 12:32, Stickman wrote: Since the official viewer already allows: - copy/pasting any modifiable script - and opening them in an external editor, should I understand that modifiable script export is a functionality that Linden Lab's viewers already provides? Or do we really have to be the creator of the script? Policy question. Technically not an item for this list, but there is no place to ask questions like these. There's nothing wrong with asking policy questions here, so long as they also relate to open source development. I'll see what I can do about getting an answer to that question (such things are rarely quick). I would believe exporting script would fall under the same isOwner isCreator hasCopy hasMod hasTrans check for exporting any other asset. In-viewer revision control has been long time wish list item for me, for the exact same reasons, but my skill level for such things its to the level to do such myself yet. The whole copy-paste routine is extremely annoying after a while. An alternative solution would be at least a bulk upload of scripts, even single script upload would be a vast impoverishment really. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOYR1CAAoJEIdLfPRu7qE25YIH/RnEq3i7/jqN0u8Guq5GDY2X YGILrX5/euZ+C1dV62DSXGcbDLO+5iG//4+vojxfzdKE2M3Wdl6rjvHA8eelQcr4 GWSydyMNeroNSKrv4cplZw7JRkEmZaJy+hz7SDxZujStmJUjtAR7rsso8M70p+zY aSlv6E6cOEk9q7/z5M3DkMH5zyliX/0sQwZL8qUnTK5LTc90jyHnR2j8RgXPu6Pv 9hkSDak4rwbtuKe9K4aRwyzDYVG/Iq5WJ1niCInSJedqX56yHNNFcOOCeYtNtqBu fM7NxR/VD1qEBMre8KeZgN4etcnQUTRysqI7w6EK1YLdthoJ4eAJihX9OI2ZW7w= =X//E -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
The underlying code segment here needs a rewrite. This is one of the rare cases where GCC is actually complaining for a very valid reason. /me agrees absolutely. Is there already a Jira around (I searched, but didn't find one, but that might be just bad luck)? Armin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Mesh decomposition using hacd
I would love to test this out and see how functional it is. Please use the above listed repositories to fork off of and make the needed changes and keep in mind how this is having to be done and where it will hopefully end up. To make a long story short: I did not sign the SLV Contribution Agreement. So obviously making this compatible with a submission that cannot happen anyway is pretty low on my list of things to do. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
