Messages

Ah, right. Good call. In particular I'll note that I had to move constants around because of the conflict between the Windows GDI BITMAP type and the Allegro BITMAP type. The Windows headers are included in NativeMethods.cpp while the Allegro headers are included in the GUI headers. I was thinking it would be best to keep changes minimal, but you make a perfectly valid point.

[that]

I'm working to move around some of the code for building the game data file, and I thought it would be a good idea to test building against a larger game to make sure that everything is working appropriately.

Well, I have the source for The Cat Lady laying around still, so I go to create a copy of the and oh my what the huh... the folder is nearly 5 GB. I'm pretty sure the game isn't that big. Oh well. That's life, I guess.

I'm reasonably certain that the engine does write a warning to the log file if this happens, but that might not be very obvious... I think that the editor raising a warning (not an error -- e.g., it won't prevent compilation) would be a good idea in this case.

As I completed the initial implementation of this feature (writing data file from editor assembly rather than native assembly), I realized that there are a rather unwieldy number of constant values that I needed for this that are also needed for the run-time engine. So, putting things in AGS.Types wasn't really a viable option. However, since the editor assembly references the native assembly, it's rather simple to pull in the values from the native code to the managed code just-in-time (e.g., when static readonly fields are initialized, the first time one of them is referenced).

The latest commit in my fork has this implemented. I welcome feedback if someone has a better way of handling this situation, but this seems pretty clean to me (if too many constants are added, it could improve look-up time to implement a map, but that felt like a bit much for now).

I think you definitely make a valid point here, and I appreciate your advice and feedback. I mostly felt concerned about it because I was duplicating so much code from so many different places that sometimes it was hard to wrap my head around what was going on, nevermind keeping track of changes that might be introduced in the meantime. I also realize it creates extra commits that clutter up the history, but for what it's worth it was my way of ensuring that I wasn't inadvertently undoing the work of others.

That said, with the latest commit I'm happy to say that the data file can now fully be built from the managed editor code (sans the script compiler, which is still invoked from native). There are some final things that need to be cleaned up or reviewed before I submit a pull request, but the data file format is thankfully no longer one of them. There's a note about this in the commit message, and this is definitely getting off-topic for this thread (sorry for the derailment). If I have further questions I'll make a separate thread.

in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.

My fear in this is that if I don't pull in intermediate changes that I'll end up so far behind that merging the changes back together will be a nightmare in itself, constantly trying to play catch-up to the changes that other people are making to the existing native code while I'm trying to port it to C#. Especially given how fractured a process writing the data file is, there are several dozen script files that could contain relevant changes that I would have to manually piece back together. I'm not saying you're wrong, but considering how close I am to having the code ready for a pull request, I don't think that I can afford not to keep up at this point.

[huge]

Splitting one large task into smaller pull requests may simplify things a bit. For instance, you could make saving data in Editor first, and multiplatform build later, or vice versa.

Well writing the data file from the editor is definitely a huge task (stream->WriteArray(&structInstance, sizeof(MyStruct), MAX_STRUCT_INSTANCES) seriously made me want to assault someone), but it wouldn't really make any sense or be useful to split that into multiple pulls. But I can definitely do a pull request for that feature once it's ready and then just pull that back into the multiplatform branch that way.

I'm doing my best to clean up temporary code as I go along, though ultimately writing the data file should probably be split into multiple separate files. I've been working with all of it in a single place for simplicity until it can get thoroughly tested to ensure that it's doing what it's supposed to.

P.S. If you could hold off on making further changes to the game data format, I am honing in on completion here. I've got more than 80 of 90 KB of my test project verified...shouldn't be too many major mistakes left to correct.

Gurok, I'm curious what features from Windows XP's Explorer are missing in 7. Really the biggest thing that I felt was missing from XP was Libraries (though I know realize I could have used symlinks to the same end), but 7 is actually very nice to use when you're used to it.

And Fitz, you could unlock the hidden Administrator account. It gets rid of a lot of permission issues. The fact that programs can't write to the Program Files folder is kind of absurd. At the very least they could take the route that Google has now gone with Android and allow programs unfettered access to their own file folder.

I'm definitely not complaining that you've gotten this implemented in the current development branch, but it's definitely throwing off a lot of the work I'm doing (writing the game data file from the editor). I've actually got the full data file building from the editor now, but there's quite a few minor mistakes here and there that are throwing off the entire thing, so I'm working through that ATM. Hopefully I'll have something to show for it soon, then I can merge this back into the branch with the option for building other platforms...

Rick, the voice acting system doesn't work with custom say functions (including extender methods). Any time the Character* in front of the Say method is variable, the voice acting system ignores those lines AFAIK. It only works with the predefined (in the editor, at design-time) script names:

Code: ags

cEgo.Say(...); // voice acting sees this

void SayStuff(this Character*)
{
  this.Say("STUFF"); // voice acting ignores this! :(
}

cEgo.SayStuff(); // voice acting doesn't see this either :(

This is another reason why the engine's reliance on VC++2008 is becoming problematic.

Probably a good idea. Simple enough to implement once I get the rest of this sorted out.

Ultimately I think all of the related code should be moved out of the native assembly, but a lot of the unmanaged code isn't relevant to what I'm working on. I'll see if I can take advantage of AGS.Types for these constants (specifically I'm thinking of "scfilesig", "endfilesig", "ags_version", "SCOM_VERSION", various flags for inventory, cursors, etc.). I'm working with a huge amount of code, so wrapping my head around all of it at once is no small undertaking. Thanks for the reminder about AGS.Types, that's what I was looking for here.

I'm working on getting the game data file to build from the editor's managed code instead of from the native assembly, as part of supporting targeting multiple platforms from the editor (instead of just Windows). As I've gotten into the bulk of the code over the last couple days, and particularly the last several hours, I've come across several constant values that may appear in multiple places. Some of these are being moved to managed code, while others might remain in the native code.

What is the best way to make sure that the code duplication is kept to a minimum in these cases? In particular I'm concerned that a constant may be updated in one place but not another. For now I've been duplicating them in as narrow a scope as possible (until I can finish rewriting/porting the code and make sure it's at least functional), but it would be great to have a sense of direction in this.

Agreed with Khris. That's essentially what a built-in event would be doing anyway, but no, there isn't one built-in.

Alternately you could pair what Cassie said with custom dialog rendering. It looks like what you're doing (calling Say before starting the dialog) could probably be moved into the dialog's starting point (in the dialog script) and then you could check in dialog_options_get_dimensions to fade the overlay out before displaying the options.

Right, sorry. The full plugin can still be run without Steam (although doing nothing) on compatible OSes (Windows and some versions of Linux), but if you're specifically publishing a non-Steam version it's still recommended that you use the stub instead of the full plugin. This allows the end-user to rebuild the stub for their system if the prebuilt stub (the one you would include in your distribution) does not run (e.g., versions of Linux using different core libraries, other unsupported OSes).

[not]

A "stub" is nothing more than a replacement for cases where the plugin can't, shouldn't, or won't run. So you would not push a Steam version of your game to Valve's servers with a stubbed AGSteam plugin. You could release the same game files as a non-Steam version by replacing the full plugin with a build of the stub. This would save you having to rebuild the game files or keep track of separate versions of the game files -- just make sure that you include the full plugin when publishing to Steam (including Steam for Linux) and the stub when publishing to non-Steam sources.

Hopefully that clarifies it.

[never]

Regarding Khris' code, you could also use cAnim.on = false or cAnim.Transparency = 100 in place of cAnim.Visible = false

"Character.on" is a deprecated API; the less you use them the better .

That's not actually entirely true. Character.on is a property which predates AGS 2.7 (and the introduction of most of the OO style structures), but it was never supported for general purpose usages. CJ discouraged using it simply because it was untested and not guaranteed to work correctly in all cases if toggled within a single room, but the engine relies on it for rooms where the player isn't shown (and conversely as well). It has been used by module authors in high profile modules like CharacterControl without any reports (AFAIK) of it malfunctioning.

Since it was never officially supported for use, it could theoretically be removed altogether, but in reality that would break existing scripts unnecessarily. We could provide a Visible attribute which would internally reference the same thing, presumably with no other changes than the imports. Arguing that it shouldn't be used at this point though is like saying Character.x, Character.y, Character.z, Mouse.x, Mouse.y, and many other properties should be avoided.

That's not a bad idea, but like you said, it's a totally different feature. Sorry about the confusion.

No, the engine code was already correctly writing it as a 32-bit int. The error was in my refactoring because BinaryWriter.Write(long) writes a 64-bit value.