Problems during mapdb update for Shard Cleric Guild portals

[vtcifer]

I tried updating the mapdb last night for the Shard Cleric guildleader, so that both portals could be used. This worked fine for me in both non-cleric and cleric testing, but broke this morning for some users. For some reason, they were getting errors with the stringproc I put in to timeto for those portals to return nil if they're not a Cleric: "13737"=>StringProc.new("DRStats.guild == 'Cleric' ? 0.2 : nil") . A user in lnet, and another user in discord reported that this failed:

,e echo("#{DRStats.guild}")
--- Lich: exec1 active.
--- Exception: uninitialized constant DRStats
exec1:1:in `_script'
--- Lich: exec1 has exited.

Both had drinfomon running, but could not access the DRStats class. I get the following executing the same line:

,e echo("#{DRStats.guild}")
--- Lich: exec1 active.
[exec1: Cleric]
--- Lich: exec1 has exited.

[Tarhish]

So, I pulled up the map xml. The only other place that uses DRStats in a stringproc is room 14351, which has:

@timeto={"14352"=>0.2, "12208"=>StringProc.new("Scripting::DRStats.circle >= 30 ? 0.2 : nil rescue nil")}

I'm wondering if this would work better.

[vtcifer]

Forgot to mention, I had them try that too, using :: to resolve to Scripting class from Lich itself, but got pretty much the same error.
Since I can't reproduce, I really have no idea what's going on. If anyone else has the same behavior (error when trying to directly reference guild method from DRStats), I'd be willing to create a map to share, but this broke the hell out of go2 for someone in Haven, and I really rather not break the map again.

[jandersson]

If i understand the problem correctly: There is no guarantee that a user of go2 has drinfomon running. What youre seeing is errors from users without drinfomon, so DRStats does not exist. My suggestion is to include a check in your StringProc for drinfomon (script_running? i think), and do business as usual, else you should do whatever is reasonable for a user without DRStats.

[vtcifer]

I thought that might be it as well, but did confirm at least one of the people having problems already had drinfomon running, so I didn't think it was that.

[jandersson]

🤔 It could be that they have an old version of ruby (< v2.3) where the concept of ;trust still exists. I believe this was why the skillrecorder script was made.

Go2 is trusted DRStats is untrusted So go2 cannot access DRStats... but it can access UserVars which is what skillrecorder writes your athletics skills to and what paths requiring athletics read from, for example

[jandersson]

I would honestly just suggest they upgrade ruby if this is the case... otherwise you or someone has to write some weird logic that writes to UserVars

But to be 100% compatible, its probably going to have to be the UserVars hack

[Tarhish]

That was it, I remember now. There was a problem where drinfomon was running but other scripts couldn't read it. It was if someone had trusted drinfomon

[vtcifer]

I'll give that a shot, I have a list of those who were having problems and I'll see if any of the are able to confirm ruby version.

DRStats is untrusted

DRStats, or drinfomon?

[jandersson]

DRStats, or drinfomon?

Yes ;)

drinfomon.lic should be implementing the DRStats class, unless thats been changed.

edit: To be clear, you're still going to have a compatibility issue with this, whether they have drinfomon trusted or not. If I use lich, there's no guarantee i've installed this script repository via dependency; which is what you're banking on when you enter DRStats into the mapdb without any safeguards. The user might not even have drinfomon.lic.

edit edit: You could modify the skill recorder script to write the stats you need to UserVars (which all users have). Then the bits in the mapdb would read from UserVars.strength instead of DRStats. Its a huge pain in the ass work around, but then you can be sure its going to work for everyone.

Sorry about the million edits :)

[vtcifer]

Still looking at this, just otherwise occupied.

It's interesting that DRstats is in the mapdb already: Scripting::DRStats.circle >= 30 ? 0.2 : nil rescue nil; I assume the rescue nil is there to solve the "Oh crap, there's an error" part. And since I think it's really only to get into a dead end, in an already low traffic area (Thieve's guild, master's den), problems don't crop up with path finding that much.

I'll try to look at updates to skillrecorder, and reaching out to those I know had issues in the past to test before doing any push to mapdb/pr.

[vtcifer]

Officially not supporting ruby versions lower than 2.5.5 (#5048) means these kinds of StringProcs can be safely added back in (once the mapdb is unlocked again).