Jibble

Author Topic: AGS 3.5.0 - alpha 9 - next WIP version  (Read 22639 times)

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #80 on: 09 Jul 2018, 15:21 »
So would installing 4.0 fix this?
No more military army stuff. I'm alive and back.

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #81 on: 09 Jul 2018, 15:23 »
I have 4.6 installed
No more military army stuff. I'm alive and back.

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #82 on: 09 Jul 2018, 15:26 »
I wonder if it needs a specific thing out of framework 4.0
No more military army stuff. I'm alive and back.

tzachs

  • Parking Goat- games that goats like!
    • I can help with translating
    • tzachs worked on a game that was nominated for an AGS Award!

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #84 on: 09 Jul 2018, 15:52 »
It is, fixed that thankfully, but now getting this

https://ibb.co/eSoACT
No more military army stuff. I'm alive and back.

Crimson Wizard

  • Local Moderator
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    • Lifetime Achievement Award Winner
    • Crimson Wizard worked on a game that won an AGS Award!
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #85 on: 09 Jul 2018, 16:26 »
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

  • Parking Goat- games that goats like!
    • I can help with translating
    • tzachs worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #86 on: 09 Jul 2018, 16:43 »
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: [Select]
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true"><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup></configuration>

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #87 on: 09 Jul 2018, 16:54 »
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!
No more military army stuff. I'm alive and back.

Crimson Wizard

  • Local Moderator
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    • Lifetime Achievement Award Winner
    • Crimson Wizard worked on a game that won an AGS Award!
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #88 on: 09 Jul 2018, 16:55 »
It 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.
« Last Edit: 09 Jul 2018, 16:57 by Crimson Wizard »

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #89 on: 09 Jul 2018, 17:08 »
The plugin needs the 2.0.dll
No more military army stuff. I'm alive and back.

Dualnames

  • AGS Baker
  • Pretty Badass
    • Dualnames worked on a game that won an AGS Award!
    •  
    • Dualnames worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #90 on: 09 Jul 2018, 17:14 »
Alright this seems to be working!
No more military army stuff. I'm alive and back.

Crimson Wizard

  • Local Moderator
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    • Lifetime Achievement Award Winner
    • Crimson Wizard worked on a game that won an AGS Award!
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #91 on: 11 Jul 2018, 12:16 »
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':
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)
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:
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:
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:
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

  • Local Moderator
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    • Lifetime Achievement Award Winner
    • Crimson Wizard worked on a game that won an AGS Award!
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #92 on: 17 Jul 2018, 10:02 »
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.
« Last Edit: 17 Jul 2018, 10:55 by Crimson Wizard »

Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #93 on: 17 Jul 2018, 10:36 »
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

  • Global Moderator
  • Private Insultant
    • I can help with proof reading
    • I can help with translating
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #94 on: 17 Jul 2018, 11:54 »
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).

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.

Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #95 on: 17 Jul 2018, 12:52 »
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

  • Local Moderator
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    • Lifetime Achievement Award Winner
    • Crimson Wizard worked on a game that won an AGS Award!
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #96 on: 17 Jul 2018, 13:15 »
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.
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?


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...)
« Last Edit: 17 Jul 2018, 13:58 by Crimson Wizard »

Cassiebsg

  • Cavefish
  • Fleeing the Cylon tyrrany...
    • Cassiebsg worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #97 on: 17 Jul 2018, 14:21 »
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...

Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #98 on: 17 Jul 2018, 14:29 »
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

  • Local Moderator
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    • Lifetime Achievement Award Winner
    • Crimson Wizard worked on a game that won an AGS Award!
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
Re: AGS 3.4.2 - alpha 2 - next WIP version
« Reply #99 on: 17 Jul 2018, 14:50 »
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.
« Last Edit: 17 Jul 2018, 15:18 by Crimson Wizard »