morganw, I don't see setting these settings as something you do just for a single room editing session, but rather:

Locked - This is something I would set once I have positioned an object precisely, to ensure that I don't accidentally move it while editing other things in the room. Once this setting is set, I never want it to be unset again (unless I explicitly turn it off). If I come back to the room in two months (to add another object, for example), I expect it to still be locked.

Visible - This is something I would set for objects that wouldn't normally be visible in the room and that cover up important parts of the background (for example, an object that shows an animation of an explosion). If I turn it off, I want it to remain off (unless I explicitly make it visible again), because to do almost any other editing to the room I would otherwise have to turn it off again every time.

Basically, the reasons I flipped these settings in the first place still apply the next time I come back to the room editor, and it would be annoying to have to set them again every time.

But aren't these are different problems that require different solutions? I did not mean the state saving as a solution to not able to select multiple objects.When people are working on a game, they may open same room many times. Even if there are not multiple objects that need to be turned off but only one, or if there is a convenient way to multiselect, even then they'd probably rather keep that convenient state saved than change it same way over and over.

Yes, I think there are probably three separate issues here. I only mention my point of view for storing state, as in my opinion , the workflow issues that make the persistent state desirable are related to only being able to edit one room at a time (so state cannot persist in the tab) and the existing controls are not particular streamlined (changing the settings is too involved a process). If it is easy to implement and doesn't restrict future changes or rolling back to previous versions, then it wouldn't be an issue.

Basically, the reasons I flipped these settings in the first place still apply the next time I come back to the room editor, and it would be annoying to have to set them again every time.

Yes, but to make the settings persist through Editor upgrades this isn't just simple a serialize/deserialize. It would probably have to be linked to the project upgrade process and I don't know if that even considers per project user preferences rather than just project data. Having had to rewrite the whole preference system for the Editor just so I could add an option to suppress a message box, I wouldn't want these new settings to be trivially added and create a similar problem down the line.

Yes, but to make the settings persist through Editor upgrades this isn't just simple a serialize/deserialize. It would probably have to be linked to the project upgrade process and I don't know if that even considers per project user preferences rather than just project data. Having had to rewrite the whole preference system for the Editor just so I could add an option to suppress a message box, I wouldn't want these new settings to be trivially added and create a similar problem down the line.

The Game.agf.user is loaded through same serialization mechanism as the main game data in Game.agf, that allows using reflection (with help from attributes) to serialize classes.This mechanism considers possibility of new, deprecated, renamed properties, and the change in the value range (this is also why I was suggesting using it for general preferences earlier). If something is lacking or suboptimal there, it may be improved.EDIT: entry point is LoadUserDataFile() in AGSEditor.cs. The serializer is class SerializeUtils in AGS.Types.dll.

On the other hand, for rooms we may consider creating separate similar config files, one per room. It's just that since that may clutter project folder, they are better saved in "Rooms" subfolder already, so not sure.

PS. I honestly did not want to discuss implementation details in this "release" thread. I posted here to know user's opinion. Code problems may be discussed in related forum section, or even on github.

If there is already a mechanism to do it, then it isn't an issue. I just didn't want to get locked into the existing controls indefinitely; as a user the workflow is more of a problem to me than restoring the end result.

If there is already a mechanism to do it, then it isn't an issue. I just didn't want to get locked into the existing controls indefinitely;

No, of course not. This definitely should be saved in such way that makes it possible to even discard if control scheme changes cardinally.

This is also the reason (among few others) I changed my mind on keeping these flags in game classes as I initially thought: while much simplier code-wise, that could become a problem if UI or set of design-time properties changes. So currently I am trying to reimplement tzach's solution into a kind of data table in the Room managers, which corresponds set of editor-only properties to game objects. TBH the current code structure is not perfect for this (receiving updates about object changes is bit clunky), but hopefully I will be able to find good way to sync them.After that next step will be serialization...

As an "end user", I just want to add that resetting these flags after updating the Editor (new version, if that's what you mean) would not bother me. I doubt most of us don't upgrade the editor several times during the developing of a game for it to become a serious issue. Then again, I'm just doing small games that do not take that long to make, so not sure about devs that want to have the latest release for their big and long developing game (and eventually commercial release, when you might want the best working version).

(Pdalist2 is a Listbox) doesn't work. I searched for the entire project (to see if I set .Font on anything), and even put that line on repeatedly_execute_always but it won't go through.I'm using the "custom version", can't check the specific project on previous versions

(Pdalist2 is a Listbox) doesn't work. I searched for the entire project (to see if I set .Font on anything), and even put that line on repeatedly_execute_always but it won't go through.I'm using the "custom version", can't check the specific project on previous versions

By "doesn't work" you mean font looks do not change, or some error showing up?What will happen if you do Display("%d", PDAList2.Font) afterwards?Does this happen only with particular font or any, and does same font apply to ther things like buttons, speech etc?

Everything else seems to be working fine, I think it's the listbox specifically that I can't change its font in runtime. It's always font 7 (which is the one on the editor). I can't change the font of that listbox in runtime, and there's no other code that reverts it to its original (font 7)

Everything else seems to be working fine, I think it's the listbox specifically that I can't change its font in runtime. It's always font 7 (which is the one on the editor). I can't change the font of that listbox in runtime, and there's no other code that reverts it to its original (font 7)

Yes I can confirm that changing ListBox.Font does not work in 3.4.2 Alpha. Changing other GUI fonts seem to work.

This may be related to GUI refactoring too, it was done a while ago. I will investigate.

The code A within the if condition gets to run every time because the if condition always returns true, however when I do

if (Game.DoOnceOnly("open_cutscenetwo")) {

Adding a _ seems to make it work properly!

I could not reproduce this, tried in 3.2.1, 3.4.1, 3.4.2. Could you double-check with the updated version?Also, may be a long shot, but do you use a translation? (Not that it should be translated, but maybe some bug appeared)

I've tried to rewrite Room Editor, hopefully fixing reported problems: one with Character's not appearing in the list, all objects becoming visible at once when a new one is added or renamed, and maybe few others.

I'm pretty sure that if (Game.DoOnceOnly("")) is having some sort of issues cause I used them mostly for stuff that happen when you first load a room, and then I'm being reported issues that are only able to be replicated if the lines within the relative condition are executed again. Is that something that has been fixed on the zip files you just posted?

I'm pretty sure that if (Game.DoOnceOnly("")) is having some sort of issues cause I used them mostly for stuff that happen when you first load a room, and then I'm being reported issues that are only able to be replicated if the lines within the relative condition are executed again. Is that something that has been fixed on the zip files you just posted?

No, I did not change anything because I could not reproduce this with the example you've posted earlier. Is there any chance I could get your game for a test?If not, I may investigate the engine code and see if there is something suspicious.

Now fixed whole room layer getting reset when you add/rename an object.Looks like all is working now, but please try out yourselves.

PS. I removed the behavior when Characters, Room Objects and Walkable areas are all were made visible by default. Was not sure if that's really what users asked for, but tzachs simply made it so. Now it's reverted back to old AGS behavior when only background is visible at startup.

When room editor state will be saved all the existing rooms will reopen in the way you left them, but new rooms will begin with only background.Question: does this still need an option in preferences?

I'm pretty sure that if (Game.DoOnceOnly("")) is having some sort of issues cause I used them mostly for stuff that happen when you first load a room, and then I'm being reported issues that are only able to be replicated if the lines within the relative condition are executed again. Is that something that has been fixed on the zip files you just posted?

No, I did not change anything because I could not reproduce this with the example you've posted earlier. Is there any chance I could get your game for a test?If not, I may investigate the engine code and see if there is something suspicious.

Is there maybe something to do with translations interfering with gamedo once onlys?

I'm 200% there's an issue with GameDoOnceOnly,(I'm using 1327 or so unique tokens, maybe that is an issue), anyhow, I replaced 2 of them, and then 2 others started malfunctioning, so I've made a custom function that does exactly what GameDoOnceOnly does, I'll let you know if that faulters, if it does it's something else.