GLBA

[uncertain-string]

This resolves the comments made in PR#25.

Per the unsubstantiated comments in the prior PR, GLBA is not bare-bones, fast, or responsive.

I, however, submit this substantiation for why this is incorrect:

I modified LBA slim by deferring updates that use costly functions such as llSetPrimitiveParamsFast by using timer events.

Per @ThunderRahja's comment,

I disagree. Adding more events will actually reduce script responsiveness in a busy sim, due to how the event scheduler delays firing events when under strain. Timer is even worse because it can stack up in the queue I have reviewed all of the lines you changed or added and think they are not a good fit for LBA slim. You are, of course, welcome to share your own modifications of LBA, but I do not think this is an acceptable replacement.

This is false. Updating primitive properties in every frame is FAR more costly. Simply using a timer instead of doing more work every frame does not "reduce script responsiveness" in a busy or idle sim. Timer events also do not stack up. If you can provide proof of "stacking", please do.

All event execution (and for that matter, every single instruction within the events) happens during a frame. If event execution takes longer than what the scheduler has allocated, the execution state of the script (the stack) is serialized, being deserialized and resuming during the next frame the script is scheduled. So, with a costly instruction, such as llSetLinkPrimitiveParamsFast, while having less resource needs than llSetLinkPrimitiveParmas, may not finish executing during a frame.

Setting prim text is not something that needs to happen every frame. Per your own comment, the timer event gets delayed when there is resource exhaustion. Good. The sim can defer that event until it is less busy. The collision events (and listen events) still continue to process each frame it is scheduled. If the LBA health goes below zero, it will submit llDie just at the same time LBA-Slim would.

For these reasons, "adding more events will actually reduce script responsiveness" is incorrect. The only impact will be that the text above the object will not update until 0.15s (or so) later. Best practices in UX design will tell you that 200ms is a good target for "responsiveness." 150ms is below that.

I chose 0.15s as the timer because that is an update roughly every 7 frames (if there have been any actual hits). If your issue is with my choice of every 7 frames, please offer a different option.

[ThunderRahja]

Cool story, bro. You took my comments out of context after I retracted some of my statements in #25. This crusade you're on is not worth my time.

[uncertain-string]

This PR addresses the comments made in the previous request.

I am not on a crusade, I am submitting GLBA to the LBA repo in the interest of the community at large. There is not enough collaboration within this open source project, a system which is nearly universally adopted.

[HadetTheUndying]

This PR addresses the comments made in the previous request.

I am not on a crusade, I am submitting GLBA to the LBA repo in the interest of the community at large. There is not enough collaboration within this open source project, a system which is nearly universally adopted.

I see no reason to move the current LBA Scripts into a legacy-scripts directory as they are still actively maintained. There is also plenty of collaboration on this project, but certain people making these claims and the claims of "Gatekeeping"(yes I see those too) refuse to work in the spirit of mutual cooperation. There have been people contributing to LBA in some form or another regardless of group since 2015. There is nothing stopping anyone from Forking this project and maintaining their own munition compliant system as I've stated in the past. I will leave this PR open for @Krutchen to review when he has time, but if the discussion turns into a flame war I will close the PR and possibly ban anyone involved in flaming. I also encourage you to squash your commits into meaningful commit messages that mostly just outline files added or changed. For example, moving the current core scripts to a new directory should have been a individual commit, regardless I do not expect this to be merged with that action still intact.

Below I will outline the overall projects goals:

1. Create a system that is less event heavy than collision tracking
2. Make the system approachable for people not familiar with LSL to adopt as a drop in replacement for old collision tracking scripts.
3. Make the project maintainable by the community so that that maintenance does not fall solely on myself or Dread. This is the point where people are trying to create contention over. This project is forkable, we already have several other LBA compliant systems that exist as forks, including but not limited to CLBA, GLBA, MBT-LBA, and LBH.
4. License the project through GPL to encourage a standard of transparency between the forks.

Once again I don't understand the intention of moving the existing and currently maintained scripts into a legacy folder. I would be perfectly fine updating the ReadMe to point to the current active forks and LBA Adjacent projects like the Flare system that Criss has been working on. Please do not open another PR for this. Wait until Dread has a chance to look at it, and discuss it with other community scripters in one of the Discord servers we all share or privately. There is no point in flooding people's inboxes with notifications, and there was no need to close the old commit if you need to reset your work you can do a hard reset to the latest master commit with git reset --hard upstream/master.

[HadetTheUndying]

As one final note. I just noticed you updated the community gun script stuff. I would be fine merging that in a Separate PR now, as yeah there's Regex in the filenames that would break things. I'd also be fine with just removing that directory entirely. I won't be around much until Monday or Tuesday.