Messages

I may upload the source code of CRM-Tools, but this must have to wait until next week.
I actually wonder, too, why there is a problem with the game.xml. Have you tried to move the room-files to somewhere else and loading them then in CRM-Tools? Unfortunately I did not work on this program for more than two years, but of course I will try to support you.

I also thought that this should be a feature of the Editor.

(Just to throw yet another fancy idea into the room: A different plugin system could work similar to a JavaVM, with the plugins being portable compiled bytecode that's interpreted by the engine, with some limited hooks to call platform-dependant libraries for things like the Steamworks API. This would give us the "best" of both worlds, with plugins still portable and yet closed and distributed with the games. Of course, this would add another new language a plugin-author needs to get accustomed to and add to the size of the engine).

This would be really an idea beyond the pale. I mean, the concept sounds nice, but the coding effort would be way too high. For this, and many other "problems" I may refer to the PSP port of AGS again. We only need to add the most used plugins by either asking for the source code or rewriting them - look at how the author of the PSP version ported it. This would lead to that we have to implement every possible plugin into the engine (either or not hard coded), but this is not a very huge problem, as most plugins could be rewritten simply using the (I suppose) existing ScummVM functions. Of course this can not be very easily done for every single plugin, thinking about not only SteamWorks. But I think that this is a minor problem we could think about later on, as we firstly need to get plugin-free games working. Use of plugins is explicitly not encouraged for portability, but I think this is also stated in the FAQ. What about just giving the user a popup saying "we can't support this game because the specific plugin can't be executed on this system"?
The application would run fine without plugins, if the game does not need any special plugins. Same for the compiled game. If the engine works usually for every game, but not for one specific, then I don't think that this could be a reason not to develop an implementation which only works with nearly any game. I don't get why this should depend on how to license it.

And the "legacy" 2.x issue doesn't really exist, I suppose, as all games from 2.6 can be played with the PSP port.

Now I think even GPL is not a problem. The engine doesn't have to be open source at all to get a working engine that can use game data and do things with it. It's all about data processing. ScummVM would only take the compiled ac2game data or strip it off the executable and processes it. So the ScummVM part is really independent to the original AGS Engine. Otherwise ScummVM would not be able to support any other engine anyway.

We should not think too much about exceptions. What we need is a development team that would really work on creating such an implementation. If I had more free time, I would think about reading up on ScummVM development.

[A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.]

This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

I think it is still the best if the games with version 2.6 upwards would work. Lower versions without a doubt do indeed need much more work as to support all later versions. The PSP Port at least also supports 2.6 games, and I don't think that there was so incredibly much effort put on this. Eventhough there could be multiple engines for different versions. For example one for AGS 2.6 - 3.x games and one for 2.0 - 2.6, and so on.

The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.

So why aren't we able to make a GPL implementation or relicensing of the AGS Engine?  
Also, I don't really see where the Artistic license disallows such inclusions in other projects which have a similar license.

ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)

Yes, Scumm was only one example I gave.

I think the most complicated task in the engine are the plugins. In the PSP port there are some of them included, but it is nearly impossible to include all plugins without enforcing an Microsoft Windows environment for the games with other than the best known plugins (snowrain, ...) in it.

The only problem is that the thread is from 2007 and I think CJ's feeling about OpenSource has changed a bit.

What is by the way the problem to make a fork of ScummVM and add AGS support to that fork? Then it could be licensed as anything, just the ScummVM part has to be still in GPL, I suppose. But does this really matter to be either in one or the other license? I mean, it is all OpenSource, so we could use it, right? Otherwise there is no point to make something open source, well, only for security reasons, but it isn't really needed. Let's look at the PSP port again!
Either the AGS Engine can be included into ScummVM, or the ScummVM can be cloned and modified to work with AGS. One of these would absolutely work even with the complicated licensing!

By the way, what is about the older scumm games anyway regarding ScummVM? I mean, the Scumm Engine is also not GPL licensed, is it?

Thank you!

Seems if the room is very large (3072x2304, for example), the bmp file has a large black space and the walkable mask is reduced to the top left corner by 25%.

Strange thing. I'm afraid I can't reproduce it. Even if I scale a room up to 3200x2000 or 3072x2304 I don't get any problems while exporting or importing the masks...

It would be nice that as it exports, it appends the room number to the name (WalkableAreas_Room01.bmp) or something like that.

I thought about it before, but as the user is free to modify the filename before saving I didn't include that before. Now I added this, so it will be in the next release.

Well I don't know where this fits best, so I just try to post it here.

CRMTools is my new program which uses the AGS Native Library (and some parts of the official editor sources) for extending the opportunities AGS itself has. To start off, someone asked in another forum if it is possible to resize a room by changing the background image without losing the area masks. The best possibility for this would be to export the masks and later import them again, because otherwise it is quite a huge work to set them all again. While AGS has the feature to import such masks, it doesn't have an export function. So what I basically did is to write an tool which uses a crm file and exported the chosen mask. This is so far version 0.1 of my tools.

You can download them right here.

If someone needs another room function, then let me know, maybe I will continue the development of this project and then try to include that. It would be the best though if these tools could be included in AGS straight away, but only CJ has influence about this.

I hope the program could help you and I would appreciate any feedback.

Chris got totally crazy.
I want a ScummVM Interface that let me play AGS-Games on other different systems (PSP, NDS,...), but I think it's still a good begin to release the Editor-Code.

You could make multiple MIDI-Files with different Instruments or some other melodys or whatever and use PlayMusic and SeekMIDI mainly... That would be, how I would do it. If every MIDI has the same ticking, length and the same base Melody it should work very well.

Maybe You could have luck with the Plugin API? I mean, I think that Allegro tolerates pretty much, because my Plugins aren't as clean as they could be.
But it works very fast and I think there may be some Allegro-Functions that would make your life easier...
I think even if you cannot code very good in C++ it could be a try, couldn't it?

Thank You very much.
I didn't thought that it would be on "our" resources-site...
But maybe rulaman has a newer Version? Don't know.


Going to be Off-Topic...

Well, I am now sitting at these problems, but they don't seem to be so hard, I think I will finish my "NetRoom-Engine" today or tomorrow.

I could translate my game to English so Chris (AGS rules!) and other interested people from other countries could join us sometimes...

@rulaman, you had a Translating-Tool. Last time I tried to download it, the link was broken. Is it anywhere on the Internet or could you upload it for me? Otherwise I had to translate it by hand.

How good, that AGS 3.2 is still in Beta-Stage. Because for sure it has to do something with the very strange new Sound System.

Hi Rulaman BTW.

Okay, thanks for your reply. I think I'm getting through it. (Do you say it like this?)

1. I'm handling the RoomSize now like my "NetRoom" is 1280 in width (and standard 200 in height) and I'm using some Viewport script. (iRoomWidth is one of many Variables my Plugin returns)

Code: ags

if(player.x>=iRoomWidth-160) SetViewport(iRoomWidth-320, 0); else ReleaseViewport();

Well, the maximum size is 1280x200, but that should be really enough.

2. I think, I will change the GlobalScript to modify HotSpot Names "virtually" (like only to edit the Label in the GUI) and I bet it would work.

3. And, nevermind, Runtime-Scripting from Plugin is not really needed. It would be good, if there would be some kind of access through the Plugin API, but if not, it is no problem, because I will not go any further to break my fingers or something while coding that much.

Next big thing is Views / Inventory Items through internet. But it should be much easier than some scripting through internet. Of course I will need to buffer them (lets say, I have already 100 empty Chars in my Game, because it is the only possibility to let 100 players be online simultanously) but I don't really think that any limitations could be a big problem.

I think all in all it might match the simple question: What would be a world without limits? 

I am making a "Chat"-Like Game using the Plugin API. Every Player is connected via Internet and every single Action (Moving, Inventory, Ints,...) will be send to anybody who also is online. So there are many possible interactions to share over the Internet.

I am working to let players make own rooms. It is possible to change Backgrounds (GetBackgroundScene) and Masks (GetRoomMask) at runtime. But I don't know if it is possible to...

- change the Room-Size before changing the Background, so it may be possible to make scrolling rooms of different sizes at runtime.
- add Room-Objects / change Hotspot-Names.
- get access to Object / Hotspot Scripts and edit them.

I think I have to make use some kind of tricks, but if there is any "hidden" function or you know better or you can explain me why it couldn't work, please answer!

Thank You,
Endres