GLBA -> LBA

[uncertain-string]

No description provided.

[ThunderRahja]

Adds a timer, delays on updating HP in description and floating text, and makes LBA slim overall less responsive. This adds unnecessary complexity to what should be a bare bones and highly responsive LBA edition. Scripts that I write that read LBA HP may break if this PR is accepted.

Also, the timer sets the description incorrectly:

SLMCLBA/LBA-Slim-v.2.32.lsl

Lines 49 to 53 in 0d57ec7

	llSetLinkPrimitiveParamsFast(link,[
	PRIM_TEXT,"[LBA Slim] \n AP: " + (string)(hp) + "/" +(string)(maxhp),<0.0,1.0,0.0>,1.0,
	PRIM_LINK_TARGET, LINK_THIS,
	PRIM_DESC, "LBA.v.L.GLBA.1.3," + (string)hp + "," + (string)maxhp
	]);

[uncertain-string]

Adds a timer, delays on updating HP in description and floating text, and makes LBA slim overall less responsive. This adds unnecessary complexity to what should be a bare bones and highly responsive LBA edition. Scripts that I write that read LBA HP may break if this PR is accepted.

Also, the timer sets the description incorrectly:

SLMCLBA/LBA-Slim-v.2.32.lsl

Lines 49 to 53 in 0d57ec7

	llSetLinkPrimitiveParamsFast(link,[
	PRIM_TEXT,"[LBA Slim] \n AP: " + (string)(hp) + "/" +(string)(maxhp),<0.0,1.0,0.0>,1.0,
	PRIM_LINK_TARGET, LINK_THIS,
	PRIM_DESC, "LBA.v.L.GLBA.1.3," + (string)hp + "," + (string)maxhp
	]);

this is necessary to improve script performance to not unnecessarily update primitive params.

how are you using the LB description? llGetObjectDetails usually skips a frame or two, in the first place. are you reading per frame or polling every frame?

[ThunderRahja]

this is necessary to improve script performance to not unnecessarily update primitive params.

how are you using the LB description? llGetObjectDetails usually skips a frame or two, in the first place. are you reading per frame or polling every frame?

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.

[HadetTheUndying]

I also have to agree with this from Thunder. The Sim is capable of ignoring scripts under high load, which is a good and a bad thing. However each script is only capable of processing 40 events per second. That's 20 events instantly and 20 events queued. Since slim also processes collisions this can be a big problem if you add more timer events and things like that are going to cause the events to become delayed at best and in a worst case scenario totally ignored. I apologize for the formatting but I'm using speech to text right now.

[uncertain-string]

llSetTimerEvent resets the timer event queue each time it has been called

please read https://wiki.secondlife.com/wiki/LlSetTimerEvent

[uncertain-string]

https://wiki.secondlife.com/wiki/Category:LSL_Events

[uncertain-string]

https://wiki.secondlife.com/wiki/Event_Order

[ThunderRahja]

llSetTimerEvent resets the timer event queue each time it has been called

please read https://wiki.secondlife.com/wiki/LlSetTimerEvent

Incorrect. llSetTimerEvent(0) stops further timer events from firing, but only after the function is called, meaning that more timer events could be already queued up before the timer is stopped. Only a state change or script reset will clear the event queue. You can IM me in-world for a demonstration of this. Also, the wiki has been out of date on many, many pages, due to LL locking it down to only approved editors. Event handling on the back end has changed dramatically since 2016.

Rather than post multiple comments in a row, please click the ... in the top-right corner of your comment and edit it instead.

Edit: Today I learned that llSetTimerEvent(0) actually does remove further timer events from the queue. Interesting.

[uncertain-string]

llSetTimerEvent resets the timer event queue each time it has been called
please read https://wiki.secondlife.com/wiki/LlSetTimerEvent

Incorrect. llSetTimerEvent(0) stops further timer events from firing, but only after the function is called, meaning that more timer events could be already queued up before the timer is stopped. Only a state change or script reset will clear the event queue. You can IM me in-world for a demonstration of this. Also, the wiki has been out of date on many, many pages, due to LL locking it down to only approved editors. Event handling on the back end has changed dramatically since 2016.

Rather than post multiple comments in a row, please click the ... in the top-right corner of your comment and edit it instead.

Yes, I am very well aware of the changes to event queuing on the backend, as well as how to use GitHub PRs; I would happily utiilize the feature to present comments on the code but you have not commented on the code itself yet.

Please remember that comments are not saved until you hit "Review Changes" with a summary comment.

I would like to see the methodology you are using to create the statistics you are claiming.

[uncertain-string]

@ThunderRahja hi looking for a reply to my comments on this PR

[HadetTheUndying]

Hey I'm not sure when anyone is gonna have a chance to really look at this, Dread and I are really busy at the moment, would suggest asking for an Invite to the LBA Development Discord. Not trying to be dismissive or anything. Thunder had some initial input on it. I don't think anyone would have issue with you using this branch since it's compliant with current munitions. Once I get settled in with work I'll try to revisit this and talk to Dread about it.

[uncertain-string]

the changes i am proposing are very simple. the changes have an understanding of how LSL instructions are executed in the Mono runtime each and every frame (still 45fps as of 6-5-23)

llSetParameterParamsFast(...) executes asynchronously and is overriden each frame that it hasnt executed
llSetTimerEvent(0) cancels the next timer event

i do not understand the hesitation or controversy surrounding these changes. GLBA has used this for over a year, without complaint. if there is a complaint, please raise it

[ThunderRahja]

This PR remains unchanged from the time of my review. My opinion remains that the changes this PR introduces would be a step backward from the goal of having a bare-bones, fast, and responsive LBA edition. I see no reason to turn LBA-slim into GLBA-slim in the main branch.