AGS 3.5.0 - alpha 13 - next WIP version

Started by Crimson Wizard, Wed 21/02/2018 13:52:21

Previous topic - Next topic

Dualnames

Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Dualnames

Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Dualnames

I wonder if it needs a specific thing out of framework 4.0
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

tzachs


Dualnames

It is, fixed that thankfully, but now getting this

https://ibb.co/eSoACT
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Crimson Wizard

Quote from: Dualnames on Mon 09/07/2018 15:52:43
It is, fixed that thankfully, but now getting this

https://ibb.co/eSoACT

I do not know why plugin is counted "mixed assembly", maybe it was referencing AGS.Native.dll? Just a guess.
Plugin's author started coming on forum again recently, perhaps it's a good chance to ask him to look into this too. Maybe plugin has to be upgraded.

tzachs

Right, getting a version of the plugin compiled with dotnet 4.0 is probably the best solution.
However, working with the old version might also be possible by setting "useLegacyV2RuntimeActivationPolicy" in the editor's config file (see here: https://stackoverflow.com/questions/6425707/mixed-mode-assembly-is-built-against-version-v2-0-50727-of-the-runtime).
It seems that the editor's config file is not part of the release zip though (I think it should be), but I think (not sure) you can just create an "AGSEditor.exe.config" file and it will be picked up.
So you can try creating that file and putting this inside and see if it works:

Code: ags

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true"><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup></configuration>

Dualnames

Alright making the AGSEditor.exe.config file with the content that tzachs suggested fixes the issue. It also requires irrKlang.NET2.0.dll but now it works just fine!
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Crimson Wizard

#88
Quote from: Dualnames on Mon 09/07/2018 16:54:01It also requires irrKlang.NET2.0.dll but now it works just fine!
What does, plugin or AGS Editor?
irrKlang is the audio playing library, I think. irrKlang.NET2.0.dll was used by AGS before, now it supposed to use irrKlang.NET4.dll.

Dualnames

Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Dualnames

Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Crimson Wizard

I'm done with 3.4.1 for good, hopefully, and now thinking about fixing UI problems reported here.
To sum up what was mentioned:

1. Character not appearing in room bug, reported by Cassiebsg and Privateer Puddin':
Quote from: Privateer Puddin' on Sun 25/02/2018 00:07:54
Open Room X
Change Character to Room X
Character is not seen on Room X, but you can pick it from the list of characters in Properties for that room
Closing and opening the room tab doesn't show the character

Opening another room and then going back to Room X will now show the character (don't need to restart the editor)
Quote from: Cassiebsg on Sun 25/02/2018 01:27:34
I mean the bar where it shows Room > Characters > cName
If I add a new character to the room and open the room, the character will neither be seen nor be available in that drop down list (is there another place to see which characters are in the room?). opening a new room and then returning will show the character in the room and in the list. Removing the character from the room (or moving it to another room) will remove it from the editor show but still show it on the drop down list. Again these are fixed with opening another room and returning.

2. Usability issue, reported by Gurok:
Quote from: Gurok on Mon 21/05/2018 03:23:37
The clickable areas on the new-fangled object/character/everything selector bother me. They're too small to navigate quickly.
I get that it's based on the Windows Explorer address bar, but that is arguably a secondary navigation bar (and I've never found it the mouse navigation intuitive).
Could we have the name and the arrow be one clickable area that shows a menu? The name currently makes it possible to navigate back up the hierarchy, but I don't think that's needed. i.e. There's no specific view associated with having "Room" selected on its own.

3. Another problem(s), reported by Cassiebsg:
Quote from: Cassiebsg on Tue 22/05/2018 11:46:38
I just discovered that when you put a new object in a room it turns all objects visible. :~( I also started a blank project and added a BG and a couple sprites, then added them as objects. does the same. This is a very big bother, as I have a few big sprites that cover everything...
Also it's rather annoying that when you create a new object in a room it doesn't automaticly jump to it's settings/properties, so you can name it and adjust it... you need to actively find it in the list of objects and click on it.

EDIT: And seems like changing the Name of the object does the same thing. :~(

EDIT2: Doesn't help to lock the state of the objects either.


Also there was this feature request from eri0o, although that may be a larger task:
Quote from: eri0o on Sun 10/06/2018 14:11:05
A box where I could type which function my game would use for speech, so Dialog, Voice Script and Translations would know :O
But we've discussed very similar thing with Scavenger recently on Discord, and I suddenly realized that implementing this at least for Dialogs may be not that complicated.

But UI fixes go first.

PS. Also, maybe we should rename this version to 3.5.0, because of changes to editor's GUI.

Crimson Wizard

#92
So, I was looking into problems 1) and 3) from above, and it appears that I'd need to modify some of the tzach's code to make this work correctly.


Technical things aside, my two big questions are:

1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...

2) If it should be saved, should this information be saved as a part of the game project, or as a separate "editing state" config? What I mean, game project stores object properties related to the game in Game.agf, but there is another file called Game.agf.user that saves what is called "workspace state" which has some service info about last usage of editor which is not required to build the game itself (I guess we could also move few options, such as "Build Targets" there.
Anyway, the point of having Visible/Locked-in-the-editor setup in a separate config is to specify these properties as non related to the game itself, and if for example game is worked on by multiple users they may have separate design-time configs which are not shared between them when you sync the project.


NOTE: before this new navigation bar was introduced Room Objects already had Locked property that was saved in the room data and kept with the game.

morganw

I'd say that, if the interface is good and you aren't in the middle of a long-winded task that locks other editor components, you wouldn't expect the state to be saved and restored.

Snarky

Quote from: Crimson Wizard on Tue 17/07/2018 10:02:36
1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...

Yes. Locked in particular (otherwise it's nigh-useless).

Quote from: Crimson Wizard on Tue 17/07/2018 10:02:36
2) If it should be saved, should this information be saved as a part of the game project, or as a separate "editing state" config? What I mean, game project stores object properties related to the game in Game.agf, but there is another file called Game.agf.user that saves what is called "workspace state" which has some service info about last usage of editor which is not required to build the game itself (I guess we could also move few options, such as "Build Targets" there.
Anyway, the point of having Visible/Locked-in-the-editor setup in a separate config is to specify these properties as non related to the game itself, and if for example game is worked on by multiple users they may have separate design-time configs which are not shared between them when you sync the project.

Given your explanation, probably the editing state (Game.agf.user). This doesn't seem that important, though; either would be fine.

morganw

Quote from: Snarky on Tue 17/07/2018 11:54:04
Quote from: Crimson Wizard on Tue 17/07/2018 10:02:36
1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...
Yes. Locked in particular (otherwise it's nigh-useless).

Personally I would say, saving the state is just a workaround for not being able to open more than one room for editing. If opening up the room data is on the to-do list anyway, and storing settings may restrict any future changes (you'll either have to validate them or drop them all), storing more data just seems to add more restrictions in the long run.

Crimson Wizard

#96
Quote from: morganw on Tue 17/07/2018 10:36:46
I'd say that, if the interface is good and you aren't in the middle of a long-winded task that locks other editor components, you wouldn't expect the state to be saved and restored.
Quote from: morganw on Tue 17/07/2018 12:52:27
Personally I would say, saving the state is just a workaround for not being able to open more than one room for editing.

It seems we have very contradictory views on what user expects from the editor... Nearly every contemporary editor I've seen saves layer visibility in the document - game editors and image editors alike, and I had an impression users usually want to see the scene in the same state they had it when closed editor last time.

Being able to edit several rooms at once does not change much in this regard, because you may close and and reopen editing panes, and restart Editor eventually too.

Does your opinion originate from concern about difficulty of implementation, or you actually do not think having state restored is needed, or even expect these settings to be reset every time you launch the Editor because that complies to your personal work habits?

In the example given above by Cassiebsg she has large objects covering whole room, and she wants them to be invisible in the editor to be able to work with the rest of the room. Without these settings saved every time she opens an editing session she would have to adjust their visibility over and over again.
Same will happen if you want to lock things. Usually people would lock objects that are already in place and should not be touched anymore or edited by mistake.

To slightly adjust my original question: do users expect these settings to be saved in between editing sessions, like in: reopening editor next day?


Quote from: morganw on Tue 17/07/2018 12:52:27
If opening up the room data is on the to-do list anyway, and storing settings may restrict any future changes (you'll either have to validate them or drop them all), storing more data just seems to add more restrictions in the long run.

I have no idea when opening room data or having multiple rooms at once will be done. If we are to make this state saved only as a temporary solution until these times, they may be saved in a "workstate config", as mentioned above, and later simply discarded. I believe they won't cause much trouble in such case. (I fear more trouble will be caused by implementing this serialization, because you need to sync it with existing rooms...)

Cassiebsg

Yes, I expect the logic thing is for the editor to remember what I wish locked/unlocked and visible/not visible, even after closing and reopening the editor. (nod)
Having to set it up again every single time is really a pain. 8-0

I think saving it in the user profile is probably best. (nod)
There are those who believe that life here began out there...

morganw

Quote from: Crimson Wizard on Tue 17/07/2018 13:15:27
Does your opinion originate from concern about difficulty of implementation, or you actually do not think having state restored is needed, or even expect these settings to be reset every time you launch the Editor because that complies to your personal work habits?
I guess that I'm saying, having to store the state is something you would need when applying the changes you need is taking too long or is overly complicated. With the example of hiding multiple objects in a room, I'd rather make it easier to multi select objects and apply any setting, rather than leave awkward controls in place and store the settings to avoid frustration.

Crimson Wizard

#99
Quote from: morganw on Tue 17/07/2018 14:29:17
I guess that I'm saying, having to store the state is something you would need when applying the changes you need is taking too long or is overly complicated. With the example of hiding multiple objects in a room, I'd rather make it easier to multi select objects and apply any setting, rather than leave awkward controls in place and store the settings to avoid frustration.

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.

SMF spam blocked by CleanTalk