Messages

One small inconsistency I noticed. Switching to windowed mode usually - but not always - puts the game in a window that is much smaller than the one I specified in Winsetup.exe. I can't reproduce this 100% of the time yet, but this definitely does happen.

I am also noticing that when I add new music, the music never plays. I have to choose the "REBUILT ALL FILES" option before the game will actually play the music. The music plays fine when I select it in the editor. I haven't tried this with sound effects yet.

OK got one confirmation from someone who couldn't get it to work before. It now works for her!

[AGSteam-disjoint.dll]

I've updated the Windows DLL downloads for AGSteam to avoid the need for any particular C++ runtime to be installed, which was an oversight on my part in the first place. Will work on updating other download links. Sorry for the confusion.

To be clear, if you're replacing "agsteam.dll" from a game which uses "AGSteam" in the game scripts (e.g., AGSteam.SetAchievementAchieved(...)), then make sure to grab the AGSteam-disjoint.dll and rename it to "agsteam.dll".

The link doesn't work.

And m0ds: yep the files are in the compiled game folder. If that weren't the case, then NOBODY would be able to run the game via Steam at all.

In 95% of the cases, you are right Abstauber. For some reason, repeatedly_execute IS getting activated in cases where the dialog tree interrupts gameplay. For example, you set up a region so if you walk over it, an NPC talks to you and a dialog menu window appears. While the menu is up, the inventory bar would drop down (although I couldn't click on it). I could reproduce this 100% of the time.

It's happened to about 5 of my testers so far, all Windows users.

I've tried using bug tracking software but it was a faff and a half getting people to actually USE it. Since these are volunteers and not pro testers, we just do it this way. I know it means lots of issues get reported more than once, but since it's just me doing the bug fixing it doesn't bother me.

(although I admit that the thread for the current build is one of the LONGEST in WEG history, so there's that)

Awesome. Don't clutter this thread with feedback/notes and things. Just post them on the WEG forum.

So I've noticed that tinting no longer works in OpenGL mode:

Direct3D (how it's supposed to look):


OpenGL:


The two figures on the left are an object and I used the command: oPlayer.Tint(0, 0, 0,100, 0);
The figure on the right is a character and I used the command: cEli.Tint(0, 0, 0, 80, 0);

Is tinting broken or has the syntax for using the command changed? I tried looking through the thread but didn't find any mention of it.

Hey all. I'm at about the 3/4 mark and I've got a new playable build to test out. We're looking to get some fresh eyes on it, so if you are interested in testing let me know. Register on the Wadjet Eye forum and tell me your username and I'll give you access.

I am taking couple of weeks off work soon, is it OK if I will play the game a bit and tell what I found when I am back in July?
I think I haven't played an AGS game in many months...

PS. I registered by the same nickname.

Sorry didn't see this! Drop me a line when you're back and I'll give you access then.

edit: Oh I misunderstood. You're taking a few weeks off and want to play the game now? OK! Access dutifully granted!

Yep. Snarky is right. This was never an issue when character speech is displayed. Only dialog menus. At first blush, this appears to be solved now!

It's specifically for Windows, and they receive the error "Script link failed: Runtime error: unresolved import 'AGSteam::SetAchievementAchieved^1'"

Yeah, there doesn't seem to be an flag anywhere to check if the dialog window is on the screen or not.

What I can do is turn the inventory bar invisible at the START of the exchange and then make it visible at the end. It's a hack, and it works, but it's kind of hacky and I'd prefer a blanket solution to the problem. Plus some conversations have several exit points and if I miss one of them the inventory bar will never show up again.

Abstauber, is there any way to detect IF the dialog window is on screen or not using your module?


edit: CW I just saw your edit. I didn't even THINK about the dialog_options_repexec function. Worked like a charm. Thank you!

I set up some break toggles to check if Abstauber's code was being triggered, and it was. So repeatedly_execute definitely does run during dialogs, but ONLY in the cases where the dialog is triggered by the game (i.e., interrupting gameplay) instead of a player interaction.

Why that happens is... a mystery.

Huh. For some users it worked. For some users it didn't. Is there anything else that could be causing this?

edit: I've given Monkey0506 a poke on facebook about these issues and hopefully he will respond!

Hmm. I put your code in, but it doesn't solve the problem.

From what I can see of the last bit of code:

Code: ags

  if (in_speech == true) {
    in_speech = false;
    if (gDavesInventory.Visible == false) {
      gDavesInventory.Visible = true;
    }
  }

If this code is put in repeatedly_execute like you instructed, then if "in_speech" equals true, it immediately sets itself to FALSE and then turns the inventory bar back to visible. It doesn't seem to be checking to see if the dialog menu is still on the screen? I am not sure how to do that myself. Unless I am missing something.

Hmm. A number of users also reported the speed up problem after activating the steam overlay, which is activated using shift-tab. Maybe it's a tab thing rather than an ALT thing?

I've also been told that pressing the space bar fixes the problem. This isn't something I can confirm, as I never experience the problem myself.

It's time right now, Mandle. Check the forum where you registered. You should have access to the beta section.

edit: I should have posted this via PM. Sorry for that.

You're in, Mandle.

Did a bit more testing. I noticed that alt-enter does NOT work when a dialog menu is on the screen.

Maybe you have "run game loops when dialog options is displayed" turned on, and so this inventory bar is checked in the repeatedly_execute? Or maybe repeatedly_execute_always (don't remember which one is active when options are on screen).

I DO have that turned on, yes! But the inventory bar is activated under repeatedly_execute, not _always. So that still shouldn't happen?

Hmm, also, since you mentioned that it does not happen when player interacts with character, maybe there is some flag set when you start dialog by generic interaction, but when NPC starts it this flag is not set?

Yeah I'm wondering the same thing. Why one circumstance and not the other? I haven't found anything yet, but will keep digging!