Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - tzachs

Pages: [1] 2 3 ... 63
I'm getting the same "Cannot read property 'pasteHTML' of null" when clicking on the "quote" button from chrome.
I debugged it a little bit. getRange in forums/themes/default/scripts/editor.js (line 916) returns null.
getRange calls getSelect, and the oSelection object is returned empty (i.e rangeCount == 0) which is why it returns null.
In getSelect itself both bWantText and bWantHTMLText are undefined, so it goes to line 898 ("this.oFrameWindow.getSelection") which returns the empty selection.

At this point, I thought, I didn't select any text, I just clicked the quote button, why should it call getSelection at all?
Unless maybe there's another piece of code that is supposed to select the text before calling this and the problem is that it didn't?

So I tried again, only this time I selected some text before clicking the quote button, but it didn't seem to help, getSelection still returns an empty selection.
I also tried this.oFrameDocument.getSelection (instead of oFrameWindow) but it also returns an empty selection even when text is selected, so not sure what to think.

Adventure Related Talk & Chat / Re: Left/Right clicking
« on: 21 Nov 2018, 12:29 »
(I'm assuming the game in the video doesn't have voices, the computer I'm currently using doesn't have speakers).
It does have voices (admittedly not very good ones though, so maybe he skipped because he was irritated).

Also, I'd like to reiterate. Are we sure people are simply forgetting that there's a right mouse button?
Does anyone else have any anecdotal evidence?
Same game, different reviewer. He didn't right click at all. He actually sounded about 30 years old, so you would assume he would know about right clicking.
But he got stuck a few times, and STILL didn't right click. I mean, I can understand why some people choose not to look at things during normal gameplay, but if you're hopelessly stuck to the point that you try everything on everything, you would try looking at things if you knew it was an option.

Note though that when you send a message there's a checkbox at the bottom that you need to check: "Save a copy in my Sent Items", otherwise it will not be saved at all.
You can set it to be checked by default in Preferences -> "Save a copy of each personal message in my Sent Items by default."

Adventure Related Talk & Chat / Re: Left/Right clicking
« on: 20 Nov 2018, 16:33 »
But what if they never attempt a right click, and they quit the game thinking it doesn't work?
That will totally happen.
I remember that I quit my first verb coin game because it hadn't occurred to me to click & hold, so I thought the game was broken.

Speaking of young modern players. Are there any young modern players actively playing adventure games?
Young enough for you? (laugh)
Note that he never right clicked once in that video (not to mention the obsessive dialog skipping which you can't really design a solution for unless you're going Machinarium style).

Ok, done in your branch, so you can choose if you want Follow(null) or StopFollowingAsync depending if you want to stop the current walk or not.

Ok, I think I really fixed it this time, can you try again?
Sorry.. :-[

Another question: if follow(null) can cause problems, wouldn't it be better to remove this synchronous call completely?
Yeah, I'm not really sure what's the best way to handle it yet.
Here's the thing, the follow method just sets the follow target, and then on each game tick it manages its "state machine" to see what's the next move to perform (and if it's stop following, then it will want to stop the existing walk).
So it kind-of follows the same behavior of ChangeRoom in AGS where the script you write after ChangeRoom will actually happen before the room is changed (not a problem in MonoAGS, btw, that's why it's ChangeRoomAsync). And StopFollowingAsync basically calls Follow(null) with an additional task that you can hang onto to wait until the StopWalking happens in the next tick.

Now, I can't really disallow Follow(null) in compile-time yet (though it will be possible when c# 8 is released). I can make it throw an exception in run-time, though the only problem with Follow(null) is the scenario in which you follow(null) and then walk immediately after it (it might ignore that walk) -> in all other scenarios it will work fine, so I'm not too keen on throwing an exception if you pass null to it.
So here's the possible directions I thought I can take this (let me know what you think):
1. I can make Follow into FollowAsync (and remove StopFollowingAsync) and always return a task, even though it's completely not needed if you don't pass null. And also, it might be confusing for the user, as making it async hints that it will await the entire follow until done following, which is not correct. So I'm not in favor of this approach.
2. I can keep things the way they are for now, and when c# 8 is released to disallow nulls to Follow in compile time.
3. I can change it so it won't stop the current walk when you stop following with Follow(null). I'm not sure what AGS does in that scenario, actually (does anybody know?). But I could just let the character complete its last walk as a follower and then just not do any more walks. And I can make StopFollowingAsync to call Follow(null) and then call StopWalkingAsync, so if you do want to stop walking you'll call StopFollowingAsync and if you don't care you can call Follow(null).
4. I can add an option for StopWalking to accept a specific walking task. Then in the follow component I'll call stop walking on "my" specific walk, so there can't be any confusion, the follow component will never stop a walk issued by somebody else (and I can delete StopFollowingAsync completely). I'm not sure how complicated this is to pull off, but this option might be useful in other future scenarios as well.

However, when it comes to the line Characters.Mortimer.Follow(null); the game freezes. I cannot even move the mouse cursor anymore.
Should be fixed now, and also:
1. Follow(null) followed by walk is problematic, as when you stop following the stop walking action will only be called on the next tick after you fired your walk, so it will stop your walk.
So I added a StopFollowingAsync to be used instead, so await it before walking.
2. I removed the blocking versions of FaceDirection because I'm concerned about their safety, so also replace it with await FaceDirectionAsync.

On a different note: I tried the setting
Characters.Mortimer.Follow(Characters.Cornelius, new AGSFollowSettings(true, 80, 0, 10, 140, 160, 0, 10));
This works almost as desired, but the character will wander off till the end of the walkable area (much farer away than 160 pixel), is it possible to limit this somehow?
Ah, so if you want to stay in the vicinity of the cat, then you don't want to wander off at all, so I'll put it at 0. Wandering off is basically going wherever in the room without care for where the target is.
And btw, you can use named parameters which will make the constructor more readable:
Code: C#
  1. new AGSFollowSettings(wanderOffPercentage: 0,
  2.         minWaitBetweenWalks: 0, maxWaitBetweenWalks: 10,
  3.         minXOffset: 140, maxXOffset: 160,
  4.         minYOffset: 0);

I also added more parameters for tuning the follow behaviour (I don't think you care too much about those parameters for your scenario, but just in case):
1. Be able to have more control over the "wander off" if you want, so it's MinXOffsetForWanderOff etc, same as MinXOffset only just for the wander off phase (if you do want it).
2. Stay put percentage- if the follower is already in valid range of the target, what's the probability to keep moving to a new point anyway? It sounds like you want to always be on the move, so you can leave this at 0 which is the default.
3. Minimum walking distance- I noticed that it looks a little funny when the characters are moving just a few pixels, so this is to enforce a minimum distance for consecutive movements. This will be 10 pixels by default.
4. Stay on the same side percentage (one for x and one for y)- i.e if the follower is on the right of the target, what's the probability for it to stay to the right of the target on the next walk. This is 70% by default, so leaning a bit towards staying in the same side.

Thanks, I'll merge this soon then (hopefully the time it takes now is also acceptable).

From what it printed to the console it looked like the entire application was relaunched once it was finished scanning for fonts.
The restart is something I do on purpose, as I need to install the fonts because of a bug in mono (and also: this).
And I forgot about this, but I need to refresh the cache for the font install to "pick up" after I restart, so it's my fault.
However it only took a split second in all of my tests, so curious why it takes a long time in your environment.
Here's the refresh call:

So I'm guessing to reproduce this all you need to do is delete the 2 fonts that come in the demo from ~/fonts and restart the game.

As for how to fix, well, this bug is bugging me for ages, and one of the reasons I wanted to switch to ImageSharp which loads fonts in managed code and doesn't suffer from this problem, but I did some tests and its performance was unacceptable (they did improve it since, but it still doesn't match System.Drawing performance from their benchmarks). There's also the possibility that it will work fine in dot net core, which is also on the horizon. Though even if we'll support dotnet core I'll still want to allow compiling for mono as well, so I still want to see if there's a way to make it work fast if we'll end up keeping System.Drawing.
I'm wondering if maybe the refresh is slow because you have a lot of fonts on your machine, or if it's a debian thing. Can you see how many fonts you have installed on your machine?
I also wonder if maybe there's a faster version of the command, for example maybe it's just the printouts that take a long time, and if we change fc-cache -f -v to fc-cache -v it will work faster.

Ah, I also see that you can specify a directory, so we can possibly skip rebuilding the system fonts and just build the user fonts, which will maybe solve it.
I.e, just change this line:
Code: C#
  1. ProcessStartInfo info = new ProcessStartInfo("fc-cache", "-f -v") { UseShellExecute = false };
Code: C#
  1. ProcessStartInfo info = new ProcessStartInfo("fc-cache", $"-f -v {LINUX_FONT_LIBRARY}") { UseShellExecute = false };

Can you test if this works? If so, I'll push a fix. Thanks.

Does the actual engine rely on the built-in fonts?
So it's probably not related, but just for sharing, the engine will use the default system font if you didn't specify your own font, and the demo game does use the default font in some places.

Next topic: following a character. I now realize that Cornelius Cat uses quite a lot of different features for such a short game :)

In the original AGS game I use the setting
Code: Adventure Game Studio
  1. cMouse.FollowCharacter(cCat, 150, 0);
This results in the mouse somewhat following the cat, but mostly running around, even when the cat is standing. How do I have to set the values in AGSFollowSettings to achieve the same?
So looking at the manual, the first parameter is the distance the follower will stand from its target, and 150 means "about" 150 pixels. I don't know what "about" means exactly, haven't looked at the code, but let's assume that it's give-or-take 10 pixels.
In MonoAGS there are four parameters to control the distance: MinXOffset, MaxXOffset, MinYOffset and MaxYOffset. This gives you better control over the entire square you want to allow the follower. So to kind of mimic what AGS does (assuming that "about" is 10 pixels), I would give something like MinXOffset = 140, MaxXOffset = 160, MinYOffset = 140, MaxYOffset = 160. It's not going to be exactly the same, as AGS gives you one value so I'm guessing it forms a circle, where in MonoAGS it's a square. But this shouldn't make that much of a difference in practice, I think.

As for the second parameter, the eagerness. From looking in the manual it says that setting it to 0 will make the follower to always be on the move and that it will wander around the target like an energetic dog. It doesn't sound like that is what it actually does, from what you're describing, though.
Anyway, the first part, how often it moves, is controlled from MonoAGS by MinWaitBetweenWalks and MaxWaitBetweenWalks. To make it always on the move, set both to 0. The second part per your description, that it will be mostly running around and not actually following the cat, is something that you can control with WanderOffPercentage. If for example you set it to 50, there's a 50% chance for each walk to be to a completely random place, as opposed to the configured square. So for mostly running around to unrelated places, I guess you can set it to 80?
Let me know if it doesn't work out, maybe we need more parameters for better control.

Btw, I plan at some point to add presets to the follow settings with defaults to match common scenarios, so you'll be able to write something like:
Code: C#
  1. mouse.Follow(cornelius, AGSFollowSettings.Companion());
  3. //It will also allow you to override specific settings, for example:
  4. mouse.Follow(cornelius, AGSFollowSettings.Companion(wanderOffPercentage: 0));

Edit: Btw, there seems to be a problem when un-following a character with Follow(null):
  Message=Object reference not set to an instance of an object.
   at AGS.Engine.FollowTag.AddTag(IObject target, IEntity follower) line 23

Should be fixed now (in your branch).

LostTrainDude did a very nice lecture on this:

It works except for one thing: I set the default cursor via the constructor, but it is only applied after changing to the inventory cursor and back. Of course I could set the cursor myself, but actually I'd expect this to happen automatically when TwoButtonsInputScheme.Start() is called. The same applies for the setter of the DefaultCursor property.

Btw, is it on purpose that the text wraps left-aligned instead of centered? It doesn't look that nice, especially when there is only a word or two in the second line.
I'm still not finished with this, but I pushed just enough so it should work for you as you expect, I hope.

Wait, so does it only happen the first time, or every time?
How did you figure it out? Weird that it takes a few minutes, I wonder if there's a way to bypass it (can you track it to a line in the code?).
Thanks for taking a look.

Can you add to Program.cs in DemoQuest.Desktop, as the first 2 lines of the Main method:

Code: C#
  1. Debug.Listeners.AddRange(new TraceListener[] {new ConsoleTraceListener()});
  2. Debug.WriteLine("Starting Demo");

And then after compiling the debug version, run the debug version from command-line (i.e mono /your_folder/MonoAGS/Source/Demo/DemoQuest.Desktop/bin/Debug/net461/DemoQuest.Desktop.exe)?

Do you still see nothing? Not even the "Starting Demo" line?

Unfortunately I can't get the debugger to attach (this seems to be a common monodevelop problem)
Did you install the flatpak version? Even though it's the "recommended" version according to their website, it's actually broken with regards to dotnet standard. I was able to debug using their legacy version.
Alternatively, you can also try using Rider instead, or maybe even VS Code.

and running without the debugger doesn't seem to do anything (I guess the program is just exiting).
Did you try the release build or the debug build? You should get at least some console printouts with the debug build, or there really is something happening very early on.

One thing I didn't think to check, what is OpenGL requirement?
I'm not sure what's the minimum requirement, but it seemed to work fine with OpenGL 2.1.
A few other things to try:
* What mono version do you have installed? I currently have version
* It might be the graphics driver. I don't know what's the situation with Debian 9, but at least on one ubuntu 16.04 machine, I had a problem with the default graphics driver, and switching (I think it was from mesa to the legacy driver) fixed it.

I got this error as well on Ubuntu 18.04, is that where you're building from?
I haven't gotten a chance to look into it too much, but I think it's a result of this issue:

As a workaround, you should be able to bypass it by disabling Nerdbank (which is the library I use to stamp the dlls with a version). I'm not sure if just deleting version.json from the root folder would do it, or if removing the package from the project is required.

When the player performs a right click when an inventory is active, there is a null reference exception at AGS.Engine.TwoButtonsInputScheme.SetInv entoryCursor(IInventoryItem inventoryItem) in line 37
onRightMouseDown sets the ActiveItem to null, which then triggers the OnPropertyChanged handler.
I'd change SetInventoryCursor to reset the default cursor when null is passed and the active inventory is null. This would help regarding the exception, but also allow the programmer to change back the active inventory programmatically. This is needed when I use the active inventory item on a hotspot and this results in me losing the inventory item.
Should be fixed now (still same branch).

Another issue: You might want to check if the previous cursor should really be changed. Otherwise, there will be weird issues when setting two active items after each other without returning to the default cursor in between.
Consider renaming _previousCursor to _defaultCursor, then it will be more clear. You could also provide a method SetDefaultCursor. This way you can safely change the default cursor, no matter if there is currently an inventory active or not.
Right, I was doing copypasta from the rotating cursors scheme... :-[
Changed it now (there's a default cursor you can pass in the constructor, and also a DefaultCursor property you can set on the scheme afterwards).

Works, but 80% seems a bit too much. Maybe 70% is enough? (But this might be because of my setup with the stage frame around it.)
Ok, I don't have any preference myself, so I changed it to 70%.

Btw, is it on purpose that the text wraps left-aligned instead of centered? It doesn't look that nice, especially when there is only a word or two in the second line.
Not on purpose, but a bit more complicated to get right for all text rendering scenarios, I'm working on it and will update.

Hi, there's a new branch with a bunch of fixes for all the latest issues you mentioned:
If you can test that everything works as expected I'll merge it to master.

However, this does not work with the TwoClickInputScheme. I will rewrite it, but the question is: What is the best approach? I could
  • Add a method for setting the active inventory to the TwoClickInputSchemeclass (public void SetActiveInventoryItem(IInventoryItem inventoryItem)). This is pretty simply but has two disadvantages: I have to remember to call it and I will somehow have to have a reference to the instance.
  • The next idea is to subscribe to repeatedly_execute in the TwoClickInputScheme and continuously check for the active item. This would be the AGS-style approach, but it feels unnecessary to do the check every cycle when the active item only changes ever so often. Which brings me to my third idea:
  • Is it somehow possible to attach an observer to ActiveItem? Then the InputScheme could just subscribe to it and do the cursor handling accordingly. The AGSInventory.Items property is already a BindingList, is there something similar for basic properties?
Great feedback!
What I did is a combination of 1 and 3.
The two buttons input scheme now has a SetInventoryCursor method, which you can either pass an inventory item or pass nothing which will make it take the current active item for the cursor.
In addition, I added the inventory item change event which I missed somehow.
So, you can now do:
Code: C#
  1. cornelius.Inventory.OnPropertyChange(nameof(IInventory.ActiveItem), () => scheme.SetInventoryCursor());

The character switches to the speak animation but still moves towards the walk-to-point. Since there is no 'speakandwalk' outfit, I guess the character should stop walking?
When the say async is done, the character will quickly slide to the walk-to-point without any animation. This happens no matter if I click to stop the sayasync or not.
So 2 fixes here:
1. Any user interaction will now trigger stop walking before applying the interaction.
2. I "added" a 'speak and walk' optional animation to the outfit.  If there's a programmatic SayAsync while the character is walking and you have a 'speak and walk' animation it will be used. If you don't have a 'speak and walk' animation then it will stop walking before speaking.
If you're using portraits, for example, and the walking animation itself can be used as 'speak and walk', then you can just write:
Code: C#
  1. cornelius.Outfit[AGSOutfit.SpeakAndWalk] = cornelius.Outfit[AGSOutfit.Walk];

the default label width is 250 but your game is high resolution so makes sense to have a bigger label -> we should probably make the default label size resolution dependent).
The default label size for speech is now resolution dependent (by default it's 80% of your virtual resolution).

The default position of text shown for character.SayAsync is a bit strange: it is a bit above (OK) but on the right side next to the character. Why?
Fixed, it's now centered above the character.

Right, though besides the preference choice (do I want to easily allow people to view/edit individual assets in the game?), I would say that embedding make some stuff easier:
1. If you don't embed then you need to worry about shipping your asset files with the game (and making sure that they're in the same folder hierarchy).
2. If you want to debug your game on mobile devices and you don't embed your assets, then it won't copy them to the device and you will need to copy those yourself.

And not embedding, otoh, makes it easier to swap asset files when developing (and we might add support for hot reloading those assets directly in the file explorer while your game is running -> though it might be possible for embedded assets as well, not sure).

For the reasons mentioned above, the default behavior that I'm currently thinking of for the editor is to have it as contents while developing, and embedded when deploying.
Though once we have a complete editor, we might be able to eliminate those problems with some programming on the editor side, so we'll see.

Ah, you're right, the character should stop walking. Even if there was a 'speak and walk' animation, you'd still expect that when you right click, it will cancel the existing walk. A 'speak and walk' animation might be interesting to do, though, when you programmatically say something while walking.

As for the second bug, I think I understand why it's happening, after the say async is completed it doesn't switch back to the walk animation, and because you have "MovementLinkedToAnimation" with no moving animation, it defaults to the animation speed which is really fast (because it's configured to work in tandem with the animation, not as a "regular" walking speed).

Thanks, I'll look into fixing both bugs (and the talk position issue, I haven't forgotten it) soon.

Pages: [1] 2 3 ... 63