I have a script that lists all the objects in the room as object links, but the verbs are finiky and show up less often than not, do they are underlined and highlighted, but nothing can be done with them, or else the verb flickers.

I am going to guess links works better when automatically underlined, highlighted, font changed by the system and recommend you not to change it but I could be misunderstanding your question.

You did misunderstand me. I was just saying nothing looked amiss

I solved my problem, if it is solved, as it seems to be, at least, by asking Copilot to look into it. It's advice sent me to an answer written to somebody else a long time ago, by mrangel.
The answer included a script
UpdateObjectLinks()
And the script works well.
Thanks mrangel. Thanks Copilot AI.
Thanks everyone else, as well.

I am not sure what caused the jam, but I understand it was a jam.

That makes sense, thanks for the update.

Are you using timers?

The function UpdateObjectLinks basically compiles a list of verbs for all visible objects, and sends them to the frontend. This updates the verbs attached to object links, and may also disable object links for objects which aren't in the list.

This used to be called from the function FinishTurn, which was run to synchronise the frontend and backend whenever the Quest interpreter returns control to the browser. However, FinishTurn also runs turnscripts; which you might not want to run during every sync.

During the transition from Quest 5.7.2 to 5.8, I suggested modifying FinishTurn and/or RunTurnScripts so that the user can choose whether their turnscripts run once-per-turn or once-per-sync. But for some reason the engine was instead changed to only run FinishTurn immediately after a command from the player is successfully executed. So… this means that if an object becomes accessible as a result of a timer, or something else that isn't part of a command, you can't rely on UpdateObjectLinks being done automatically.

Well, I don't know.
I was using one timer when the problem occurred, but I have a script in the timer itself to list all old and new objects in the room.
I had honestly thought that would be enough.
However, it wasn't working well, so I added it,
UpdateObjectLinks ()
And it is running perfectly now.
So I guess it was the timer, somehow.

Mr.Angel! Your question and explanation just solved a bug I had flagged for "one day when I understand better" I think! In my updated WeatherLib for Pixie's WeatherLib, there were several things I had to work on and fix. Some of them were as simple as learning that GetBoolean was what was truly wanted and not HasAttribute (which then changed other things).

But I have added turnscripts which move day and night time weather objects to follow the player around if the "currentweather" room was flagged that they should be there, and the player was outside (slightly different if the player was inside but could see outside). The only thing I didn't understand after fixing my other bugs with the system was why it sometimes left the objects so that you couldn't interact with them using your first command, "look at rain."

What you're saying makes me think it's related to the changes you mentioned. I could either update the turnscripts with the appropriate function to update these scenery objects... or ... as I think of it... maybe there's a way to incorporate some of this into "on room enter" script for "outside" and "windowed" flagged rooms. hmm.

Anyway, thanks to both Jennifer and Mr. Angel for sharing. I learn just by reading what other folks are working on sometimes.

But I have added turnscripts which move day and night time weather objects to follow the player around if the "currentweather" room was flagged that they should be there, and the player was outside (slightly different if the player was inside but could see outside). The only thing I didn't understand after fixing my other bugs with the system was why it sometimes left the objects so that you couldn't interact with them using your first command, "look at rain."

This seems odd. I wouldn't think it would be caused by the FinishTurn changes, because FinishTurn should call RunTurnScripts before UpdateStatusAttributes, CheckDarkness, and UpdateObjectLinks.

What you're saying makes me think it's related to the changes you mentioned. I could either update the turnscripts with the appropriate function to update these scenery objects... or ... as I think of it... maybe there's a way to incorporate some of this into "on room enter" script for "outside" and "windowed" flagged rooms. hmm.

If you want the objects to follow the player, I think it might make more sense to put this code in the game.roomenter script, which runs every time the player enters a new room (after showing the description, but before the room's own 'enter' scripts).

Or, of course, to modify the background scope script to make the relevant objects reachable without actually moving them - although this could lead to performance issues if it's a complex script.

I like the idea of putting it on game.roomenter, except that I'm trying to make an integrated core that incorporates the libraries as cleanly as possible. If I add it to the gametype in as the roomenter type script, it will show in red and ask the user to override it on the game object whether they're using the WeatherLib feature or not.

The current new core already includes a check for the feature_WeatherLib flag on the Game object to call the WeatherReport function in that spot and it would go there too.

But there's also already flags on the "weather" tab to check whether a room is "inside" or whether it's "windowed" which the WeatherReport and turnscripts use to move these weather objects and read the attributes of game.currentweather (whichever current room the "weather" is in) respectively. No flags means the room will display the weatherreport and have weather objects by default if the weather feature is enabled.

There's also already a Type dropdown on the Weather tab to select whether a room is "weather" , meaning that its attributes are included and scoped, etc by reading game.currentweather, or "not weather" = no special features. So what I'm thinking is to change these flags for "indoor" and "windowed" into types in the dropdown now.

Then, instead of having the chunk of what's now in the turnscript all on the game object, it could be included separately in each room that's changed to a specific type on the weather tab. As I think of it, it would be better to update the WeatherReport and move it also to the weather room types i'm imagining creating. I think I'll also review the library so that it's checking/running based on "outside" and "windowed" rooms rather than "inside" or "windowed" with a default for all rooms running the weather report.

It seems more intuitive that a creator would only want to go deal with the "weather" tab when they're working with rooms where the weather is something they're creating. That way if they forget to go to the weather tab, they're not having weather in an inside room because they didn't go disable it with a checkbox.

This thing with not being able to look at the weather seems to happen only if it's your first command in the room you start in (assuming it's supposed to have weather). hmmm.

Anyway, does this all make sense to you, Mr. Angel? Pixie's WeatherLib is pretty cool, and I enjoy my enhancements, but it is taking a little bit to incorporate them into the core and editors so it would be easy for a non-coder to just use as a feature.

What I'm thinking at the moment after all this is to create two new types for rooms and change one of the existing labels in the dropdown:
"Outside" which will be the new default for full weather interactions
"windowed" which will be the one with modified weather interactions
"weather" which can remain the same for customizing different types of weather you want to program into your game
and change "Notweather" to "inside" which is just the label for no type in WeatherLib.

Then change whatever is needed in the setup so that weather only "happens" for "outside" and "windowed" typed rooms.

I'm thinking it's worth the work, because that could make it easy for creators to override what moves into their room if they want by having these show only on "outside" and "windowed" room scripts. Maybe move the objects before entering room and call the weather report after entering room. That frees up the game object so it's not checking whether to call the weather report literally on every room enter.

I just realized that all this discussion is happening in a forum question that was about something else! I'm sorry for taking up space on this thread, Ms. Jennifer et. al! Mr. Angel, feel free to message me with any helpful thoughts, or to share them over in the Libraries forum where I've got a thread with updates on my core work.
https://textadventures.co.uk/forum/samples/topic/5nwc3eltt02p2bwh_5zdaw/integrating-favourite-libraries-into-the-core-of-quest-5-8-core3

Wouldn't weather also affect the inside, if differently from how it affects the outside? Inside, on a hot day is either muggy or airconditioned. And inside on an extremely cold day, the furnace is hot but the walls are dangerously cold and they creak. When it rains, roofs leak.

Hello Ms. Jennifer! It certainly could!

The WeatherLib and enhanced WeatherLib are meant to help a game programmer create weather which can be random, or can be very controlled.

I think if someone using Weatherlib wanted to then use the weather that they created to determine if there's a leak in the room's roof, for instance, you'd create a check on game.currentweather

Something like
'''
If GetBoolean(game.currentweather, "presentrain"){
moveobject (drip, game.pov.parent)
msg (There's an annoying drip coming down from the corner of one of the ceiling tiles. It's either raining outside, or someone's left the water running in the tub.)

'''

Sorry, that's from memory, but the weather objects all have flags one checks if they're present on the weather tab of a weather room. Once checked that they're present, the fields for adding description/script attributes for that object appear. It originally was meant to keep the tab interface fairly clean and not so overwhelming with fields you didn't want to use. But the flags are also handy for boolean checks. ;-)

That sounds fantastic, but move object isn't working for me, right now. I don't know what's wrong, if it's just my current game or my game file or if it's my game engine, but I would really rather know how it happened than know where it is. Sorry. It's just that you said something about the move script and all I could think was, yes, a move script would be a nice thing to have access to!!!

Hmmmm. If I remember correctly, you were the one experimenting with a completely different grid system, right? Maybe that did something to the "moveobject" function? Maybe it calculates based on the original grid?

I don't think so. I don't know if I am that person you are thinking of. Move object is a pretty basic tab. Apparantly, Add to Inventory does not do all of the same things as Take.