[Cancelled] AGS 3.4.0 Early Alpha [many limits removed]

[Crimson Wizard]

WARNING: this forum thread describes very old experimental version that is no longer developed or supported.

I do not recommend to use it.

AGS 3.4.0 Early Alpha

Warning! Warnung! Alarma! НевлезайÃ'Æ'бÃ'Å'Ã'‘Ã'‚! 我不会说中国话!

This is early ALPHA release. It is a work in progress, and may be generally unstable. Please, be cautious and backup your game before using this version.

Or rather do not use this version except for testing purposes, unless you are desperate to get its features.

*** Download as ZIP archive ***

The archive includes only Editor/Engine binaries. Make a clone of your current AGS program folder (tzach's 3.2.2 or newest 3.3.0) and then copy archive contents over.

1 jan 2014: Updated with all the 3.3.0 Beta 12 contents

Please, understand that this is work in progress. The further updates may include new features and fixes, as well as change or even remove existing ones. While I'll try to keep compatibility with game files created by earlier alpha versions, I give absolutely no guarantee about savedgame format (i.e. saves made with early alpha engine may become unreadable by later updates).
3.4.0 meant to be fully compatible with 3.2.1 and 3.3.0 projects and will try to upgrade them automatically.

This version still undergoes tests. There's chance I haven't noticed something and you will receive an error when trying to open a game project. Good luck .

So, what's in this version?

--------------------------------------------------
Limits removal
--------------------------------------------------
Following limits were updated:

Item	Old limit	New limit	Comments
State-Saving Rooms	300	999	Max room number is still 999
Dialog Topics	500	unlimited
Options per Dialog Topic	30	unlimited
Controls on GUI	30	unlimited
ListBox Items	200	unlimited
Mouse Cursors	20	unlimited
Room Backgrounds	5	unlimited
Room Objects	40	unlimited
Room Hotspots	50	256	restriction imposed by palette of a 8-bit mask
Room Regions	16	256	restriction imposed by palette of a 8-bit mask
Room Walkable Areas	15	256	restriction imposed by palette of a 8-bit mask
Room Walk-Behinds	16	256	restriction imposed by palette of a 8-bit mask
Custom Properties	30	unlimited
Overlays	20	unlimited

--------------------------------------------------
Features and behavior changes
--------------------------------------------------
1. Every room has now a "StateSaving" property, which should be set manually by user. Default is TRUE. When importing old project, rooms with id <= 300 will have this flag set to TRUE, others will have this flag set to FALSE.
This property may be changed freely at design-time, however this may cause strange results if you try to load older savedgames in new game version.

2. Room region/areas number is currently set manually by editing corresponding Room property (HotspotCount, RegionCount, etc). Take precaution, as decreasing this number will delete last areas in the list, including all their setup and mask parts. Which means, if you make a mistake, you'll have to repaint them (or reimport mask) again.
Be informed, that when importing old projects you'll likely want to decrease Hotspot number, because previous versions of AGS created all 50 of them for every room.

3. Custom properties can be changed at runtime, and stored to savedgames. For each GetProperty/GetTextProperty script function there's now a corresponding SetProperty/SetTextProperty function. There's still a restriction that you can only get/set properties that are in the Property Schema.

4. This version includes support for extended WFN fonts with 256 characters (by Alan v. Drake).


--------------------------------------------------
What's next
--------------------------------------------------

I thought about adding a TODO list here, noting most important advancements I had in plans, but I need to think this over again first.
I have literally no ideas on when the 3.4.0. will be "completed". There might be a lot of more things to come.

Currently I am considering looking into display resolution problem, then game resolution. We'll see...

Regarding limits, there are still few to remove. Some weren't removed simply because I forgot to (e.g. max Fonts, Animated Buttons) - I will fix this bit later, others are unlikely to cause problems (e.g. Drawing Surface limit of 20), the last require additional code rewriting. For instance, Inventory Item limit is affected by Plugin API interface as well. Then, a sprite cache system should be changed to allow having >30k sprites without adding problems.

[monkey0506]

Erm, you said I could extract this over 3.2.1?

Spoiler

---------------------------
Error
---------------------------
An unexpected error occurred trying to start up the AGS Editor. Please consult the details below and post the error to the AGS Technical Forum.

System.IO.FileNotFoundException: Could not load file or assembly 'WeifenLuo.WinFormsUI.Docking, Version=2.6.0.0, Culture=neutral, PublicKeyToken=5cded1a1a0a7b481' or one of its dependencies. The system cannot find the file specified.

File name: 'WeifenLuo.WinFormsUI.Docking, Version=2.6.0.0, Culture=neutral, PublicKeyToken=5cded1a1a0a7b481'

   at AGS.Editor.GUIController.Initialize(AGSEditor agsEditor)

   at AGS.Editor.ApplicationController..ctor()

   at AGS.Editor.Program.startupTimer_Tick(Object sender, EventArgs e)

   at System.Windows.Forms.Timer.OnTick(EventArgs e)

   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)

   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)



WRN: Assembly binding logging is turned OFF.

To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.

Note: There is some performance penalty associated with assembly bind failure logging.

To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].


---------------------------
OK   
---------------------------

[close]

Had to force kill it in Task Manager. Obviously it's missing the additional assemblies added from 3.2.1 to 3.3.0.

Edit: Regarding HotspotCount, RegionCount, WalkableAreaCount, and WalkbehindCount...shouldn't there be a way for the editor to determine at compile-time which is the highest numerical area that actually has anything painted on its mask? Ultimately it would be nice to do away with the bitmap masks altogether, but setting this number manually seems a naive approach for this. Of course this is an "early alpha", but still it seems like it would be better for these to be handled by the editor rather than relying on the end-user to set manually what they've already defined by drawing their masks.

Seeing as you're removing the hard-coded limits though, I'll just point out that the user will still need to know the limits at run-time, so we'll need some readonly script properties: Room.HotspotCount, Room.RegionCount, Room.WalkableAreaCount, and Room.WalkBehindCount.

Also I've noticed you removed the "State-saving room" checkbox from the new room dialog. Why? Wouldn't it make more sense to leave the checkbox there, and pass its value directly into the StateSaving property in the Properties pane? It looks like you've already defaulted StateSaving to true for new rooms (which would seem to be the appropriate behavior), but I see no reason why the already existing checkbox should be removed when it still has a relevant meaning.

[Crimson Wizard]

Erm, you said I could extract this over 3.2.1?

Gah! My mistake. I forgot about docking panels library. Description fixed for now, but I'll add that dll next time.

Regarding HotspotCount, RegionCount, WalkableAreaCount, and WalkbehindCount...shouldn't there be a way for the editor to determine at compile-time which is the highest numerical area that actually has anything painted on its mask? Ultimately it would be nice to do away with the bitmap masks altogether, but setting this number manually seems a naive approach for this. Of course this is an "early alpha", but still it seems like it would be better for these to be handled by the editor rather than relying on the end-user to set manually what they've already defined by drawing their masks.

This is a complicated issue. First of all, to make it detect newly painted region we must somehow allow to choose a number of region which will be painted. This returns us to a problem of implementing proper UI controls to add/delete exact area(s).
We had some discussion here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48513.0
I did some experiments on making additional ui controls, but am not ready to properly work on this yet.

Seeing as you're removing the hard-coded limits though, I'll just point out that the user will still need to know the limits at run-time, so we'll need some readonly script properties: Room.HotspotCount, Room.RegionCount, Room.WalkableAreaCount, and Room.WalkBehindCount.

True, something I forgot to add, I'll do this.

Also I've noticed you removed the "State-saving room" checkbox from the new room dialog. Why? Wouldn't it make more sense to leave the checkbox there, and pass its value directly into the StateSaving property in the Properties pane?

Alas, I had to .
The editor's architecture prevents me from passing this check value to room's property. I'll try to explain.
There's a distinction between UnloadedRoom and LoadedRoom class in the editor. UnloadedRoom contains some general info about room file, like its Number, FileName, Script filename and description, but it has no way to set other design-time properties. Originally that check did nothing but corrected room number in the New Room dialog, it wasn't even passed further when dialog closed.
Then, after this dialog, the object created is UnloadedRoom, and it has no idea of what the room actually is, because, well, it is not loaded.
When room is eventually loaded, it is a different class (LoadedRoom) and it reads all its properties from the file.
All the initial property values are set not by program, but from "blank" room template, which is copied from embedded resources.
Now when there's a certain property which controls the Save-ability of the room, correcting room number is not needed. And there's no obvious way to change properties in non-loaded room.
This would required altering system somehow.

[monkey0506]

I wouldn't mind taking a look at the state-saving issue. C# being managed actually gives it a far lower learning curve than C++, so I'm much more comfortable working with it. Also the codebase is cleaner. :p

[Crimson Wizard]

I wouldn't mind taking a look at the state-saving issue. C# being managed actually gives it a far lower learning curve than C++, so I'm much more comfortable working with it. Also the codebase is cleaner. :p

I see the possible solution as load the template room into memory, change any parameters, then save as an actual room.

It's done in RoomsComponent::CreateNewRoom.

[monkey0506]

I don't understand why the editor relies so heavily on native (C++) code for editing the rooms. I suppose that by-and-large the way the CRM files are packed and saved, and then loaded and unpacked hasn't really changed since the pre-3.0 editor, so maybe CJ just did it to avoid having to rewrite that code. I just don't see a reason for this particular feature to rely on mixed code (which I hadn't previously realized that it did).

It seems to me that this also directly ties into the whole concept of only being able to have one room open for editing at a time. I don't see a purpose behind this restriction (in the pre-3.0 editor it had some validity as there were no tabs, and the general layout of the older editor supported this general structuring). I really feel that we should try and revamp this particular part of the editor so that multiple rooms can be loaded for editing at once, the editor script can modify rooms without having to "open them for editing", etc. I will be looking into this matter further.

[Crimson Wizard]

It seems to me that this also directly ties into the whole concept of only being able to have one room open for editing at a time. I don't see a purpose behind this restriction (in the pre-3.0 editor it had some validity as there were no tabs, and the general layout of the older editor supported this general structuring). I really feel that we should try and revamp this particular part of the editor so that multiple rooms can be loaded for editing at once, the editor script can modify rooms without having to "open them for editing", etc. I will be looking into this matter further.

This isn't so a restriction of Editor, it's a restriction of AGS.Native mainly. A lot of things are done there, and some of the room data is stored only in the native code (room masks being an example). There's only one global room object (named "thisroom"). If you want this multi-room feature work, you should make an array of rooms in the native code instead; and if you want several rooms being viewed at the same time, you will have to rewrite calls to all the functions that get immediate data from the native code.

E: On other hand you could instead work on carrying all the business logic from native code to C# projects. IMO that will solve far more problems at once... and perhaps, although larger task, will be simplier instead of trying to hack new functionality in AGS.Native. The code there is very messy, I never cleaned it much.

[monkey0506]

I actually forgot that the engine can load CRM files at runtime. This was designed as a form of "patching" feature for individual rooms, but I'm not aware of any games that have ever used it. So there is the question of code duplication if the "business logic" were ported from native C++ to C#. But that all hinges on whether or not that's something anyone is even wanting to use. And it may even be simpler to port the code now and reimplement the engine side later if anyone wants it.

Yeah, the entirety of the native assembly is a mess, as with a lot of the engine code. That's part of the reason I've been so reluctant to really delve into the engine code. But the process of loading the rooms seems relatively simple, it's just obfuscated quite a bit due to the mixed code. Anyway, none of this is strictly relevant to this alpha version as of right now, so we can discuss technical details on the branch I made.

[dbuske]

I am glad we are finally getting these improvments.
It always bugged me that there was a rush to make new ports and improvments were ignored.

[Adeel]

Please Crimson and pretty please: Change the way, objects are accessed in the dialogs script. I don't want to use arrays (I don't know much about them!). Make it like the way you described in the Beginner's Forum.

[Crimson Wizard]

Please Crimson and pretty please: Change the way, objects are accessed in the dialogs script. I don't want to use arrays (I don't know much about them!). Make it like the way you described in the Beginner's Forum.

I mentioned there are technical reasons too, did I? This is not an individual issue with room object, there's a global problem of how script work which makes this difficult to change.
When script is loaded and prepared it needs to get addresses of all objects that are mentioned in there. If it is room objects, we would need to preliminary load a room, and since we do not know which room it is, we may need to load all rooms and register all objects in there.
Leaving aside a fact that this will greatly increase game loading time, this also requires to fully change the system of how room objects are kept in memory.
Other way would be to permit null-referenced script symbols, that are substituted by actual references when room is loaded. Which also requires massively changing how script work.

[Adeel]

I understand, sorry for this suggestion ['twas just a wish of mine but as they say: all wishes aren't fulfilled].  Thanks for explaining this again.

However,  I would really appreciate if Tween Module is also included alongside with keyboard movement module.

[Crimson Wizard]

I understand, sorry for this suggestion

Why sorry? it is a reasonable suggestion, it is just that it won't be easy to implement.

However,  I would really appreciate if Tween Module is also included alongside with keyboard movement module.

If you mean default template, I am not sure if that would be wise. Default template was meant just to mimic Sierra interface.
But you can create your own templates which include the modules you like, and carry them over from one AGS version to another.

[Adeel]

However,  I would really appreciate if Tween Module is also included alongside with keyboard movement module.

If you mean default template, I am not sure if that would be wise. Default template was meant just to mimic Sierra interface.

No, that is not what I meant. I am saying that since keyboard movement module is included in the installer. Likewise, it would be nice if Tween Module is included too (so that you wouldn't have to download it separately).

[Knox]

Removing limits for gui controls and custom properties is just AWESOME! Thanks Crimson!

[Ryan Timothy B]

Room Hotspots   50   256   restriction imposed by palette of a 8-bit mask
Room Regions   16   256   restriction imposed by palette of a 8-bit mask
Room Walkable Areas   15   255*   *walkable area 0 is technically not a walkable area
Room Walk-Behinds   16   255*   *walk-behind 0 is technically not a walk-behind

I'm confused by this. Regions and Hotspots, both have 0 as the "erase" index. Unless you simply just didn't write that for those 2.

And good work on this.

[Crimson Wizard]

No, that is not what I meant. I am saying that since keyboard movement module is included in the installer.

Is it? Heh, I never noticed.
I wonder, maybe AGS site can host a "good modules package" or something like that.

Room Hotspots   50   256   restriction imposed by palette of a 8-bit mask
Room Regions   16   256   restriction imposed by palette of a 8-bit mask
Room Walkable Areas   15   255*   *walkable area 0 is technically not a walkable area
Room Walk-Behinds   16   255*   *walk-behind 0 is technically not a walk-behind

I'm confused by this. Regions and Hotspots, both have 0 as the "erase" index. Unless you simply just didn't write that for those 2.

Yes, well... this is not related to eraser tool.
Hotspot 0 and Region 0 are still fully functional things. You can even attach tinting(oops actually you can't) and event handlers to them. While Walkable Area 0 and Walk-behind 0 do nothing at all.
You know.... I don't remember what I was thinking. Nevermind . Probably I should say they are all limited to 255 functional areas.

[Adeel]

No, that is not what I meant. I am saying that since keyboard movement module is included in the installer.

Is it? Heh, I never noticed.

In a manner of speaking: Yes, it is included.

I wonder, maybe AGS site can host a "good modules package" or something like that.

How about this: A separate folder for all the recommended modules (you may ask everyone about this by creating a new thread or I can - if you permit me).

Installer will then let the user decide whether to install them or not. For a compensation of 1 to 2 MB, I think it will be great. (if you exclude the demo games of each module).

What is your opinion?

[Stee]

If you are considering this how about (If recommended modules get hosted on the AGS Server) an installer that lets you select what modules you would like on install of AGS and retreives them from the server upon installation.

Alternatively a modules hub could be integrated into the editor that pulls them from the server similar to what programs like Netbeans does with it's plugins, Distros of Linux do with their update systems (ie apt-get guis) etc etc.


Regardless these are not really things I think are important. It's not hard to grab your modules from the forum.

[Crimson Wizard]

How about this: A separate folder for all the recommended modules (you may ask everyone about this by creating a new thread or I can - if you permit me).

Adeel, I am sorry, but where did you get the idea that a) you need a permission for this, b) I have a right to give such permissions???