search

RuthAndRoth / Ruth

Virtual World Mesh Avatars
26 stars 15 forks source link

Fix receiver script ALPHA bug #7

Closed seriesumei closed 5 years ago

seriesumei commented 5 years ago

The check for an ALPHA command in the feet, hands and head receiver scripts for both Roth and Ruth incorrectly accepted anything as an ALPHA command since the expression in the if was actually an assignment (command = "ALPHA") which is true.

This becomes noticable when an additional else is appended to the if/else chain.

This bug also occurs in the following scripts in the Contrib and Previous Release directories. I did not fix these as I did not want to change anyone's scripts out from under them, but will do so if folks want me to.

Contrib/Elenia Boucher/r2_feet_receiver.lsl Contrib/Elenia Boucher/r2_hand_receiver.lsl Contrib/Fred Beckhusen/r2_feet_receiver.lsl Contrib/Fred Beckhusen/r2_hand_receiver.lsl Contrib/Mike Dickson/r2_feet_receiver.lsl Contrib/Mike Dickson/r2_hand_receiver.lsl Contrib/Sundance Haiku/Scripts/r2_feet_receiver.lsl Contrib/Sundance Haiku/Scripts/r2_hand_receiver.lsl LSLScripts/HUD/Ruth/Previous Release/r2_feet_receiver.lsl LSLScripts/HUD/Ruth/Previous Release/r2_hand_receiver.lsl

aiaustin commented 5 years ago

Interesting one that... I wonder if the “Previous Release” version (at least) needs to maintain its bug? And I am not sure we really should amend the Contrib versions as they can be considered personal copies or mods. The problem would be if people went back to these believing they were working versions rather than using a version of the script considrered as the latest. The faulty scripts are all named r2 which was replaced by ru2 and ro2* in the felease version now.

If Roth RC#1 and Ruth RC#3 scripts in the “Release” directories are okay then those are the base to work on to make changes for the next Release candidate once the new repository is in good shape, the build process better documented and a new variant produced.

aiaustin commented 5 years ago

Then again, this is an experimental repository... you could just fix everyone’s versions as the old versions are still exist in the github history and in buggy form in the previous ingen-lab/Ruth repository. On reflection I suggest you make the fix to all broken scripts. Unless someone else sees that as an issue.

seriesumei commented 5 years ago

I was going to leave Previous Release alone since it works properly in spite of the bug, which only shows up when you add another else/if after the ALPHA branch. I'll do the Contrib scripts too as a separate PR so it can be reverted easily if someone objects.

seriesumei commented 5 years ago

Also, how do you feel about trying to make Ruth and Roth use the same scripts? I haven't compared the body parts list in detail but I'm pretty sure the receivers could be shared at least...

aiaustin commented 5 years ago

I personally think any sort of commonality and reduction of components would be good. But Ruth and Roth bodies have very different alpha cuts Serie.

seriesumei commented 5 years ago

What I am hoping once I study it is that the mechanics are the same, just the list of mesh parts and faces are different. Since link order/number doesn't matter now that gets easier.

seriesumei commented 5 years ago

Oops, GitHub Fail for me

aiaustin commented 5 years ago

Are you okay to close without merge this commit yourself Serie? I believe that pull/9 was the replacement you wanted merged and I just did that.

seriesumei commented 5 years ago

We need to merge this one too, they didn't overlap. I did the Release scripts in this one and the Contrib scripts in PR9

aiaustin commented 5 years ago

I am not convinced we should change the release Ruth RC#3 and Roth RC#1 scripts Serie. There are many inworld copies , and indeed the IARs in the release area have content which contains the glitch.

I think this should be a change for the Roth RC#2 and Ruth RC#4 replacement (and fixes) for the current versions.

In any case I suggest we need to add a comment at the head of the changed files to say who (you) made the change and the date Serie? Otherwise we may not be able to easily separate the scripts in world that are amended and the previous glitched ones.

Also I am NOT suggesting we change the various (many) places this script is already in world on various grids.

seriesumei commented 5 years ago

So here is what I was thinking: We have an RC3 branch that is frozen, master is for 'next', whatever it is called. At some point keeping a history in the file headers gets out of hand for every little change, that is why we use things like git/GitHub. That is where the history is. What we are missing is a way to tie the in-world script back to which git history it came from. and that is a problem because as soon as you record the commit sha in the source file you have now changed the file.

So how about this: we track the changes since the last release (in this case, since RC3) in the file, after we release next we clear that list and start a new one. This way you have something in the in-world file that helps find its match in the git history.

Also, this may be moot soon anyway, I am working on a single hud receiver to match the single hud, both still compatible with the existing stuff, but I am hoping these scripts will not be used in the next release anyway. This PR was just to fix it until then...

aiaustin commented 5 years ago

I totally understand the point Serie... and as you say headers get out of date, file names are not changed if they contain release versions or other elements that identify changes are not updated. We are in a state of flux as you and others try their best to move from the old filename-RC#vxxxVariant-name-version-y.type, and so on, complex naming to be replaced with proper GitHub branch and named checkpointed release mechanism.

Can I make a simple suggestion for now though. In the Mesh/Previous Versions/R-th RCn folders we COPY all the Mesh/Release areas to their respective RC# directories BEFORE any change is made in Release. And we do that just after each release from now on until you have finalised the whole process of using branches and getting rid of previous releases in the current Github contents completely.

Now the Mesh/R-th/Release area... should that always be the CURRENT release. Or do we have Mesh/R-th/Release be a prep area for the NEXT release? AFTER copying to the previous releases area, which can be done at release time I would suggest for safety.

A bit messy while we are in flux, but some sort of mechanism like that would keep us sage, we would know what is the CURENT in the wild contents, the previous releases and the newly emerging changed content still being experimented with, and possibly adopted.

At some stage all the file names with RC# in then or versions with named developer variants ought to be dropped from the SELECTED files in each version I assume?

This is just my two cents worth. I can see may routes that would work, but lets try to make sure its obvious what the current release state is - which currently is Roth RC#1 and Ruth RC#3 (ingen-lab.com:8002 versions) as far as we are able to reproduce it.

aiaustin commented 5 years ago

Just so you see my thinking, your small change to the scripts... even though its tiny... are actually for Ruth RC#4 and Roth RC#2 not a fix to the already in the wild Roth RC#1 and Ruth RC#3 which it is too late to change. That next (essentially identical) release being a minor tidy up of essentially the current releases but with the process and workflow properly documented and the elements, errors corrected, DAE uploads and all parts fully captured.

THEN we start to work on the next serious version with updated script methodology and fixes to the meshes that people are already discussing and proposing.

seriesumei commented 5 years ago

Hrm, I tried responding via email, it doesn't seem to have worked... here's a summary:

I agree with most of what you wrote Austin, I would like to just not do the copying around of files once they reach the mainline directories so we keep a good history for them, which will help in matching in-world copies.

aiaustin commented 5 years ago

Excellent.

I wonder if the branch labelled archive-ruth-rc3 needs a second label archive-roth-rc1 unless that will confuse things more? Is there a way to indicate one branch has TWO labels so its clear its the same content?

But I note that Serie is suggesting that we move straight to Ruth V4 and Roth V4 next tme so that may not be needed?

seriesumei commented 5 years ago

That labelling problem is why I thought we should sync the two. OR we adopt an overall version/release for the project that we would use for branch names and let components within the project keep their own versions within that.

Keeping multiple versions of things in one repo isn't hard if you release everything at the same time. Also, this is why having '2.0' in the name of the project gets inconvenient :)

aiaustin commented 5 years ago

I can certaInly foresee a time when we have one avatar (Ruth or Roth) stable and the other needs some change. And we want everyone to know which version they are using. So changing the version number of one of the avatars that is actually otherwise unchanged could be problematic.

I do agree with other suggestions you made that we should separate attachments, clothing, addons, etc out to a separate repository so changes or additions there can be frequent.

seriesumei commented 5 years ago

I am closing this as these scripts will be replaced soon and this bug is fixed in the replacement. We should remember this version discussion though...