Adventure Game Studio

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

I do not recommend to use it.










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.

Erm, you said I could extract this over 3.2.1?

Spoiler

Quote---------------------------
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. ;)

Quote from: monkey_05_06 on Tue 09/07/2013 17:02:43
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.

Quote from: monkey_05_06 on Tue 09/07/2013 17:02:43
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.

Quote from: monkey_05_06 on Tue 09/07/2013 17:02:43
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.

Quote from: monkey_05_06 on Tue 09/07/2013 17:02:43
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.

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

Quote from: monkey_05_06 on Wed 10/07/2013 02:41:45
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.

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. :)

Quote from: monkey_05_06 on Thu 11/07/2013 21:16:57
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.

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.

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.

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. :)

Quote from: Adeel S. Ahmed on Mon 15/07/2013 15:10:15
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.

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.

Quote from: Adeel S. Ahmed on Mon 15/07/2013 17:02:12
I understand, sorry for this suggestion

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

Quote from: Adeel S. Ahmed on Mon 15/07/2013 17:02:12
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.

Quote from: Crimson Wizard on Mon 15/07/2013 17:23:18

Quote from: Adeel S. Ahmed on Mon 15/07/2013 17:02:12
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).

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

Quote from: Crimson Wizard on Mon 08/07/2013 20:25:34
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.

Quote from: Adeel S. Ahmed on Mon 15/07/2013 17:28:02
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.

Quote from: Ryan Timothy on Mon 15/07/2013 17:40:25

Quote from: Crimson Wizard on Mon 08/07/2013 20:25:34
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 :P. Probably I should say they are all limited to 255 functional areas.

Quote from: Crimson Wizard on Mon 15/07/2013 17:46:41

Quote from: Adeel S. Ahmed on Mon 15/07/2013 17:28:02
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.

Quote from: Crimson Wizard on Mon 15/07/2013 17:46:41
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?

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.

Quote from: Adeel S. Ahmed on Mon 15/07/2013 19:14:36
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???

Quote from: Crimson WizardAdeel, 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???

Because you rock, sir.  :)

Quote from: Billbis on Tue 16/07/2013 09:04:37

Quote from: Crimson WizardAdeel, 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???

Because you rock, sir.  :)

Regardless of this statement correctness, how that is even related to giving permission to make posts on the forum?

I were asking for your permission due to the fact that it would be suitable only, to ask the other AGSers if you have decided to include the modules alongside the installer.

As for the hosting, I can provide two mirrors for all the AGSers' recommended modules (if the module authors are okay with this).

Quote from: Adeel S. Ahmed on Tue 16/07/2013 09:39:58
I were asking for your permission due to the fact that it would be suitable only, to ask the other AGSers if you have decided to include the modules alongside the installer.

But that's not only for me to decide. I do not take over the creation of AGS or distribution process; if community made a decision, how I can do otherwise?
Also, nothing prevents anyone to package their own distribution.

Will you please put this suggestion forward to all the persons who are involved in the distribution?

Quote from: Crimson Wizard on Tue 16/07/2013 09:46:40
Also, nothing prevents anyone to package their own distribution.

But that will surely not be the official release. Everyone cares about the official release. Who cares about the unofficial releases, no matter how good they are?

This entire discussion has gone horribly off the topic at hand. Feature suggestions of this nature are not appropriate for a alpha/beta/RC/release thread. I'm not trying to deter you from discussing it, but as CW already pointed out, there is no reason why you can't create a thread yourself to discuss it. You should, seeing as you're the one who wants it implemented.

As to your suggestion however, I will point out that there would still be somewhat of a disconnect between "distributing modules with AGS" and the whole process of importing a script. RickJ suggested something similar along the lines of "library modules" which would work in a similar fashion to how the plugin manager works. You could choose on a per-project basis whether or not a specific module should be included without having to manually hunt down the SCM file each time. I began a basic implementation of this via the "Libraries" editor plugin, which isn't in a great condition ATM, and I don't know if I even still have the source files (though it would be simple enough to reverse engineer through reflection). You may want to look into that concept and see if it fits your request.

In any case, this sub-topic discussion should be moved elsewhere as it doesn't really involve this alpha version. ;)

Like monkey_05_06 said, and -

Quote from: Adeel S. Ahmed on Tue 16/07/2013 14:27:53
Will you please put this suggestion forward to all the persons who are involved in the distribution?
<...>
But that will surely not be the official release. Everyone cares about the official release. Who cares about the unofficial releases, no matter how good they are?

Adeel, you seem to misunderstand the current situation around creation of AGS and "official" distribution.
I do not hold the owning rights of that, nor anyone in particular do. I just do what I see is right and beneficial for AGS and present it for peoples test and approval. Not everything I did or suggested was approved in the past. You may do the same, if you like.
My versions or distributions do not become "official" just because it is me. They may yet become official if people agree they are good enough for it.
By saying that anyone can do their distribution I meant that anyone may suggest their own alternative that, if liked by most people around, will substitute what I did.
I give more weight to some of the opinions around here, mainly to those who were making games or been around for a long time and probably know more about game creators needs (that is my personal choice which seems reasonable to me), but in the end every people's opinion count.

Also, important thing is, I cannot do everything and keep eye on everything, nor I want to, frankly, nor, I guess, I have a right to, nor I think is reasonable for me to. That's why I am getting worried when people start to ask my opinion on everything.

One limit I would love to see gone is only 999 lines of spoken voice per character!

I think the best way to manage modules would be a central database and people get the modules from there via a GUI like NuGet or the Firefox Add-on System.

Someone light the Peder signal.

(too lazy to do it myself!)

Could it be possible to allow runtime modification of the Name property for objects and hotspots?
Is is already possible for inventory items and characters...
Many thanks.

Since you've removed custom properties limit in this version, will this plugin I am using right now become absolete?  -->
http://www.adventuregamestudio.co.uk/forums/index.php?topic=42446.msg563322#msg563322

Also, do you think there could be a kind of "pre-load" sprites function in this version? Before playing a large animation, the user could just call the function like "preLoadSprites(0,100, true)" or something...and comes with a built-in progress bar for "loading" (which the user could choose to display or not).

This is what Im using now, but it preloads all the sprites so probably not really efficident(?)

function preloadAllSprites_Array()
{
  int spritescount;
  int v = 1;
  while (v < Game.ViewCount+1)
  {
    int l;
    while (l < Game.GetLoopCountForView(v))
    {
      int f;
      while (f < Game.GetFrameCountForLoop(v, l))
      {
        SpritesData[spritescount] = Game.GetViewFrame(v, l, f);
        f++;
        spritescount++;
      }
      l++;
    }
    v++;
  }
  Display("%d sprites written", spritescount);
   
  int s;
  while (s < spritescount)
  {
    Sprites[s] = DynamicSprite.CreateFromExistingSprite(SpritesData[s].Graphic, true);
    s++;
  }
  Display ("%d dynamic sprites precached",s);
}


Quote from: General_Knox on Sun 28/07/2013 18:48:38
Since you've removed custom properties limit in this version, will this plugin I am using right now become absolete?  -->
http://www.adventuregamestudio.co.uk/forums/index.php?topic=42446.msg563322#msg563322

There's a difference, unlike the plugin I did not change ResetRoom() function; currently it won't reset Object/Hotspot/Region properties to default values. Frankly, I haven't thought about this.

The specification for ResetRoom states:

Quote
Discards all the data that the engine has in memory about when the player last visited ROOM_NUMBER, and resets it as if they'd never been there. The next time the player goes to that room, all the objects and scripts will be in their initial state (as set up in the editor), and not how they were when the player left the room. The "First time enters room" event will be run when they enter this room again.

So I guess it would be proper to reset custom properties as well. I will add this to the future 3.4.0 update.

Quote from: General_Knox on Sun 28/07/2013 18:48:38
Also, do you think there could be a kind of "pre-load" sprites function in this version? Before playing a large animation, the user could just call the function like "preLoadSprites(0,100, true)" or something...and comes with a built-in progress bar for "loading" (which the user could choose to display or not).

I believe preload feature is a must, although I am not so sure about built-in progress bar. IMO the sprite precaching is usefull mainly for hi-res games with complex animations. Such games usually feature distinct UI style, and "default" progress bar will have little use for them, I think. Are there more opinions on this?

Quote from: Billbis on Fri 19/07/2013 15:58:29
Could it be possible to allow runtime modification of the Name property for objects and hotspots?

I don't see anything that would prevent this at the moment.

Quote from: Crimson Wizard
So I guess it would be proper to reset custom properties as well. I will add this to the future 3.4.0 update.

Hmm, perhaps could we have the option per room to reset or not the custom properties? :)

Quote from: Crimson Wizard
I believe preload feature is a must, although I am not so sure about built-in progress bar. IMO the sprite precaching is usefull mainly for hi-res games with complex animations. Such games usually feature distinct UI style, and "default" progress bar will have little use for them, I think. Are there more opinions on this?

A default progress bar could be cool for quickly debugging/setting things up (kind of like the default slider control)...it could be cool that we could modify its art later on, kinda like how we can currently modify the text boxes? Perhaps the user can be able to plug in his own sprite number for the progress bar's background, and his own "bar" sprite as well? That way people can modify the look of the default progress bar as they wish.

Oh, and the progress bar could also be totally optional for those who wouldnt want it displayed.

Quote from: General_Knox on Mon 29/07/2013 17:13:14

Quote from: Crimson Wizard
So I guess it would be proper to reset custom properties as well. I will add this to the future 3.4.0 update.

Hmm, perhaps could we have the option per room to reset or not the custom properties? :)

Won't that defeat the purpose of "ResetRoom"?

Quote from: General_Knox on Mon 29/07/2013 17:13:14
A default progress bar could be cool for quickly debugging/setting things up (kind of like the default slider control)...it could be cool that we could modify its art later on, kinda like how we can currently modify the text boxes? Perhaps the user can be able to plug in his own sprite number for the progress bar's background, and his own "bar" sprite as well? That way people can modify the look of the default progress bar as they wish.

Are you speaking about new Gui control type? In which case there should be one, although not directly connected to loading sprites.
Nothing will prevent from quickly setup such default bar if someone wants to.

Quote from: Crimson Wizard

Quote from: BillbisCould it be possible to allow runtime modification of the Name property for objects and hotspots?

I don't see anything that would prevent this at the moment.

Maybe I have not been clear enough, or maybe I am misinterpreting your answer. I was talking about the build-in Name property, for hotspots (http://www.adventuregamestudio.co.uk/wiki/Hotspot_functions_and_properties#Hotspot.Name) or objects (http://www.adventuregamestudio.co.uk/wiki/Object_functions_and_properties#Object.Name), who are read-only (which prevent there runtime modification at the moment - AGS 3.2.1). Surprisingly, InvItem.Name (http://www.adventuregamestudio.co.uk/wiki/Inventory_item_functions_and_properties#InventoryItem.Name) and Character.Name (http://www.adventuregamestudio.co.uk/wiki/Character_functions_and_properties#Character.Name) can be editable at runtime. IIRC, those names are display by the @OVERHOTSPOT@ label, and thus it can be useful to allow runtime modification of these properties.
It is not a big problem because one can use your lovely editable Custom Properties ((http://r28.imgfast.net/users/2813/62/11/77/smiles/886936.png)) and a custom label to do it.
I am not directly concern by this, but one of the not-english-speaker french AGS user (http://adventuregamestudio.fr-bb.com/t2192-resoluverifier-si-un-objet-hotspot-personnage-a-deja-ete-clique#34220) is.

Quote from: Billbis on Mon 29/07/2013 19:35:48

Quote from: Crimson Wizard

Quote from: BillbisCould it be possible to allow runtime modification of the Name property for objects and hotspots?

I don't see anything that would prevent this at the moment.

Maybe I have not been clear enough, or maybe I am misinterpreting your answer.

Oh. I mean: "I don't see anything that would prevent from adding this functionality".

Quote from: Crimson Wizard
Won't that defeat the purpose of "ResetRoom"?

Crap, true. Ok forget that, hehe...

Quote from: Crimson Wizard
Are you speaking about new Gui control type? In which case there should be one, although not directly connected to loading sprites.
Nothing will prevent from quickly setup such default bar if someone wants to.

A new Gui control type would be cool...

Does this build have the experimental resolution options=? Tried the widescreen variant the other day.

Quote from: GarageGothic on Tue 30/07/2013 10:01:52
Does this build have the experimental resolution options=? Tried the widescreen variant the other day.

No.

Ok, might give it a run anyway. Was trying to get back into Shadowplay and hoping to do a widescreen version, hard to figure out which versions are compatible . we're aiming at a tablet port.

Quote from: GarageGothic on Tue 30/07/2013 10:13:35
Ok, might give it a run anyway. Was trying to get back into Shadowplay and hoping to do a widescreen version, hard to figure out which versions are compatible . we're aiming at a tablet port.

Is there a reason why you want exactly this build? Unless you really need increased object limits, I can't recommend to use it, because it is yet to be thoroughly tested.

No, just thought the most recent alpha might have something related to resolution. Been hoping for 16:9 support since AGS 2.7 or something like that, hope to see it in a release build eventually :)
Would like to try the increased regions/walkable areas though. Been using betas and sometimes alphas throughout development. I understand there's some major changes in this version with the infinite limits so probably hold off until it's in beta.

Hey CW, in roominfo.cpp, around line 500, you have the following:

    if (LoadedVersion >= kRoomVersion_240)
    {
        WalkAreaCount = in->ReadInt32();
    }
    else
    {
        WalkAreaCount = LEGACY_MAX_ROOM_WALKAREAS;
    }

Shouldn't that be checking against 3.4.0 Alpha, not AGS 2.4? It's really bugging me.

I'm pretty sure it was just a typo (in the multiple thousands of lines of code you've written, I can forgive a few ;) ). Just wanted to confirm. Thanks!

Quote from: monkey_05_06 on Tue 30/07/2013 21:08:43
Hey CW, in roominfo.cpp, around line 500, you have the following:

Code (cpp) Select Expand

    if (LoadedVersion >= kRoomVersion_240)
    {
        WalkAreaCount = in->ReadInt32();
    }
    else
    {
        WalkAreaCount = LEGACY_MAX_ROOM_WALKAREAS;
    }

Shouldn't that be checking against 3.4.0 Alpha, not AGS 2.4? It's really bugging me.

I'm pretty sure it was just a typo (in the multiple thousands of lines of code you've written, I can forgive a few ;) ). Just wanted to confirm. Thanks!

No, it's correct.
I transferred this code from 3.3.0 which did not have any references to 3.4.0; and the code originates from earlier versions.
You may check CJ's last engine code from SVN (acroom.h, 1838):

  int num_walk_areas = MAX_WALK_AREAS;
  if (rfh.version >= 14)
    num_walk_areas = getw (opty);


Okay, no worries. I just thought it was related to your removal of the limits. Thanks for clearing that up though.

This has been a long time coming but it's great to finally see it happen!

Yessss!!! he did it I'll wait to this is solid or rather a bit stable but be using this at some point :3

Sorry I'm so late, I just noticed this.

I will probably be merging recent fixes to the editor from 3.3.0 branch soon, just want to track that evil crash on room load first, it seem to happen too often.

Quote from: Crimson Wizard on Tue 30/07/2013 10:11:35

Quote from: GarageGothic on Tue 30/07/2013 10:01:52
Does this build have the experimental resolution options=? Tried the widescreen variant the other day.

No.

I'm currently in the process of transferring my game to this early alpha version (hope its not "too early" to do that) since I really need to use the no-limits feature. Since I have to redo a lot of stuff (replacing old hacks to get around the limits), I figured, why not upgrade my resolution to 1280x720 at the same time (I was going to do that eventually anyways)...

I know you are super busy and all, but theoretically speaking how "hard/long" would it be to integrate the new resolutions (or atleast just one new addition of 1280x720) into this early alpha (3.4)?

Quote from: General_Knox on Thu 29/08/2013 16:18:38
I know you are super busy and all, but theoretically speaking how "hard/long" would it be to integrate the new resolutions (or atleast just one new addition of 1280x720) into this early alpha (3.4)?

Thing is that I do not want to make "only one addition". I am totally against such approach. I know it is very much wanted, but it is really bad for the program, which already is cluttered with quick-additions and hacks (and these are the reason why it takes so long to add new stuff).

I started looking into the custom resolutions some time ago, but was distracted. So far I made custom display resolutions build: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609
(which still needs few fixes).
I am not that busy now, I may consider trying again; just need to gather my thoughts, as they say.

Ok that makes sense. I think I'll just wait for custom resolutions to be properly integrated into a stable build before upgrading to 1280. :grin:

Hmm, I am scratching my head; I spent 30 minutes to make an experimental build with 1280x720 resolution, and haven't seen any problems except for some glitches related to zooming in the room editor. Unless I am missing something terrible, this (adding custom resolutions) might be easier than I expected.
I will return to this in a short while.

E: I used the build with free display modes (http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609) I made earlier, so that could simplify things too.

Quote from: Crimson Wizard on Wed 04/09/2013 09:22:14
Hmm, I am scratching my head; I spent 30 minutes to make an experimental build with 1280x720 resolution, and haven't seen any problems except for some glitches related to zooming in the room editor. Unless I am missing something terrible, this (adding custom resolutions) might be easier than I expected.I will return to this in a short while.

(http://i43.tinypic.com/303cqit.png)

I hope adding custom resolutions does turn out to be easier than you expected!

That said, I do agree with avoiding a hack for one particular resolution (even one as desirable as 1280x720). I think it would be ideal if the designer could choose any frame size/shape (within reason) and the engine would scale it to a resolution appropriate for the player's monitor - adding letterboxing or sidebars as necessary.

Quote from: cat on Wed 17/07/2013 08:37:21
I think the best way to manage modules would be a central database and people get the modules from there via a GUI like NuGet or the Firefox Add-on System.

This does indeed sound like a really nice solution. If the current people developing AGS would be interested in adding such a feature count me in to help any way I can :).

Quote from: Crimson Wizard on Wed 04/09/2013 09:22:14
Hmm, I am scratching my head; I spent 30 minutes to make an experimental build with 1280x720 resolution, and haven't seen any problems except for some glitches related to zooming in the room editor. Unless I am missing something terrible, this (adding custom resolutions) might be easier than I expected.
I will return to this in a short while.

E: I used the build with free display modes (http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609) I made earlier, so that could simplify things too.

I just wanted to follow up on the progress with custom resolutions. Is there anything a non-programmer could do to support this aspect of development? I'd be keen to help test any experimental builds which appear, for instance.

Sorry if this sounds like hassling, I just want to keep encouraging this!

Quote from: Ali on Thu 19/09/2013 11:21:43
I just wanted to follow up on the progress with custom resolutions. Is there anything a non-programmer could do to support this aspect of development? I'd be keen to help test any experimental builds which appear, for instance.

Sorry if this sounds like hassling, I just want to keep encouraging this!

Okay, here's the test build with 1280x720 resolution I made by Mehrdad's request (he wanted it really bad) :D
http://www.mediafire.com/download/z52tkkuynk8z3sb/AGS_3_3_0_customres_test.zip

This build is a combination of:
AGS 3.3.0 beta 7 +
Custom display resolutions build (http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609) +
1280x720 resolution may be selected in the Editor.

WARNING! not thoroughly tested. Code-wise it potentially supports any resolution, but I did not have time to make a proper setup yet, so you can only set 1280x720 in the project settings. Also WinSetup displays incorrect information on resolution (this should not have any impact on gameplay).

I am working further on this in my free time, but there are few improvements to the internal engine architecture (mostly gfx filters/renderers) I want to make first, so it will take some more time.

Wow! I played around and found it worked surprisingly smoothly. Incidentally, I love the moveable tabs in 3.3.0!

The biggest problem I encountered was the graphics failing to initialise when running in windowed mode with the resolution set to 1280x720 or less. Would I be right in thinking recent developments (http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609) should make it possible to scale the window down to fit lower resolutions?

Apart from that, the most notable problem was tearing in full screen. This was very, very distracting. I think VSync for D3D would be essential for decent looking high-res. Is that a realistic possibility? Weirdly, I didn't see any tearing in windowed mode (even at resolutions where the window virtually filled the screen).

Apart from wanting to see this develop further, it would be useful to add an export option for walkable areas / regions and hotspots to make scaling up an existing game easier. I did this using CRM tools (http://www.adventuregamestudio.co.uk/forums/index.php?topic=44543.0) and Photoshop for scaling. But CRM tools doesn't work properly for higher resolutions and it takes a bit of fiddling.

Thanks again CW
on 1280x720:
I can't Quit game GUI center on screen.i seems doesn't fit.

QuoteI think VSync for D3D would be essential for decent looking high-res. Is that a realistic possibility

If Im not mistaken the Draconian version had a lot D3D stuff fixed , vsync and character walking/scaling, right?

Alright, let's continue here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=49014.0
All this is not related to 3.4.0 Alpha yet. ;)

I'm getting this crash when I try to run 3.4.0 Alpha on Windows XP SP3:

Quote
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.

AGS.Types.InvalidDataException: Native initialization failed.
   at AGS.Native.NativeMethods.Initialize()
   at AGS.Editor.NativeProxy..ctor()
   at AGS.Editor.NativeProxy.get_Instance()
   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)

The AGS splash screen displays prior to the above error message appearing, and it remains on-screen permanently after clicking the error message away.

Hey, my favorite Wizard (and all the other fantastic AGS developers), can you make custom text properties translatable ? They are not in AGS 3.2.0.
This topic (http://www.adventuregamestudio.co.uk/forums/index.php?topic=41621.msg550601) suggests that they were not because they were not editable at run-time. But with the help of your great powers, now they are ! 8-0
If you have already done it, thanks a lot and sorry for missing that info.
:)

Hi,

I tried to use 3.4 Alpha but when I start the game I get the following error message:

"Unexpected error: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist."

when i close the programm afterwards I get this

"an unexpected error occured. Please post the following information on the AGS Technical Forum

System.AccessViolationException: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist.
bei
AGS.Common.ObjectArray<AGS::Common::DialogTopicInfo>.{dtor}(objectArray<AGS::Common::DialogTopicInfo>*)
bei ?A0xf6c6a79d.??_Fdialog@@YMXXZ()
bei exit_callback()
bei
<CrtImplementationDetails>.LanguageSupport._UninitializeDefaultDomain(Void*cookie)
bei
<CrtImplementationDetails>.LanguageSupport._UninitializeDefaultDomain()
bei
<CrtImplementationDetails>.LanguageSupport.DomainUnload(Objectsource, EventArgs.arguments)
bei
<CrtImplementationDetails>.ModuleUninitializer.SingletonDomainUnload(Objectsource, EventArgs.arguments)"

I hope this helps

it would be great if someone could tell me if it is possible to get around this problem since I can't go on creating my game with the custom properties limit.

Please excuse me if what I wrote is useless or at the wrong place I'm new and I really try to get this right.

Best regards

There was a number of errors found in the editor since I posted this 3.4.0 alpha build. These errors are fixed in 3.3.0, but not here.
I might find time to update 3.4.0 later on this week. Please, wait for several days. I am sorry for this inconvenience.

Although, I should warn once again, just in case, that 3.4.0 is not called "alpha" for nothing... I mean, it may be unstable and I may not be able to  fix it quickly.

Ok, writing this in the right thread: An idea when the newest changes to 3.3.0 beta10 can be applied to this Custom Resolution Build/3.4 Early Alpha [many limits removed]? :=

Quote from: Knox on Sat 07/12/2013 22:25:46
Ok, writing this in the right thread: An idea when the newest changes to 3.3.0 beta10 can be applied to this Custom Resolution Build/3.4 Early Alpha [many limits removed]? :=

Oh, now I got it.

This will require some effort, because these branches were separated by new features added to 3.3.0 in the past several months, and 3.4 code was somewhat different. I need to find a good amount of free time to do the merge carefully. Currently I am fixing some things in 3.3.0.

So, no, can't tell for sure when I'll do this.

Ok, thanks for sharing that info. I'll just hold off using 3.4 for now. Thanks Crimson.

Merged 3.3.0 Beta 12 with 3.4.0 (that is 6 month difference 8-0).
Download link:
http://www.mediafire.com/download/x12ib6wi48x53vc/AGS_3_4_0_alpha2_2014jan01.7z

Please tell if that at least works.
Nah, merge was not fully succesfull, there are some bugs in there. Need to test more.

UPDATE: reuploaded with couple of fixes (dl link changed).

Hmm, I'm still getting this when I attempt to run the editor (Win XP SP3):

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

AGS.Types.InvalidDataException: Native initialization failed.
   at AGS.Native.NativeMethods.Initialize()
   at AGS.Editor.NativeProxy..ctor()
   at AGS.Editor.NativeProxy.get_Instance()
   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)

AGD2, I could only reproduce such error if I run the editor with some libraries missing.
The 3.4.0 archive does not include all the files needed to run the program, you need to copy it over 3.3.0 to make it work properly.

Hi Crimson,

Since merging the custom resolution build into 3.3 is too much of a change/step up, can we merge the custom resolution build with this one (3.4), or are these 2 builds still too much of a change to put together?

After a few false starts, I deleted everything from the folder, redownloaded 3.3.0, and then downloaded and extracted the 3.4.0 archive over it. Works fine now. ;)

I don't know if this is meant to be but I thought I should mention it:
When using v3.2 and going to your savegame list, if there is a savegame that was saved using v3.4.0, it displays "Invalid slot #" and when trying to load it displays the following in-game message: Unable to load game (error: Not an AGS savegame). But when you do the opposite, using v3.4.0, to access savegames from v3.2, there is no error shown or incompatible message. Does it mean that savegames are meant to be forward-compatible backward-compatible?

Another small detail is when trying to open a non-existent savegame file, in v3.2 it displays an in-game message saying: Unable to load game (error: File not found). whereas in v3.4.0 it shows a Windows popup error with a similar message but after clicking OK it exists the game.

It is a virtually insignificant issue anyway.

Quote from: ner0 on Sat 04/01/2014 01:13:15
I don't know if this is meant to be but I thought I should mention it:
When using v3.2 and going to your savegame list, if there is a savegame that was saved using v3.4.0, it displays "Invalid slot #" and when trying to load it displays the following in-game message: Unable to load game (error: Not an AGS savegame). But when you do the opposite, using v3.4.0, to access savegames from v3.2, there is no error shown or incompatible message. Does it mean that savegames are meant to be forward-compatible?

You're perhaps confusing forward- and backward-compatibility. Forward compatibility means that older program can read data from newer program. Backward compatibility is when newer program reads data from older program.
There was a very limited forward-compatibility for savedgames in AGS, but with 3.4.0 there's completely different savedgame format, so older versions won't be able to read games saved by 3.4.0 engine anymore. On contrary, 3.4.0 will be able to read saves from 3.2.1-3.3.0.

Quote from: ner0 on Sat 04/01/2014 01:13:15
Another small detail is when trying to open a non-existent savegame file, in v3.2 it displays an in-game message saying: Unable to load game (error: File not found). whereas in v3.4.0 it shows a Windows popup error with a similar message but after clicking OK it exists the game.

Yes, it might do that, but that's temporary. We need to find a way (probably customizable) to handle errors like this without quitting.

Quote from: Crimson Wizard on Sat 04/01/2014 02:06:04
You're perhaps confusing forward- and backward-compatibility. Forward compatibility means that older program can read data from newer program. Backward compatibility is when newer program reads data from older program.

Yes, I did confuse. I actually edited the post to correct what was already correct, my mistake. So yeah, I meant to ask if it was backward compatible, which you clarified that it is.

Quote from: Crimson Wizard on Sat 04/01/2014 02:06:04
Yes, it might do that, but that's temporary. We need to find a way (probably customizable) to handle errors like this without quitting.

Ok, thanks for clarifying that. :)

I downloaded this and tried it but when I tried to add more then 5 backgrounds (Says it is now unlimited) it only allowed me to add 5.
Also when creating rooms (says save state room limit is 999 now) It says in the menu only 300 are save state able still.
Did I do something wrong is there a more current version or special version with most the limits removed other then this one?

Quote from: jamesreg on Tue 15/12/2015 03:06:41
I downloaded this and tried it but when I tried to add more then 5 backgrounds (Says it is now unlimited) it only allowed me to add 5.
Also when creating rooms (says save state room limit is 999 now) It says in the menu only 300 are save state able still.
Did I do something wrong is there a more current version or special version with most the limits removed other then this one?

jamesreq, this forum thread mentions very old experimental version. I do not recommend to use it, because it is not stable, poorly tested, and no longer developed nor supported.

Instead I suggest to look into actual AGS 3.4.0 which is being developed now:
Announcement thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=52499.0
Discussion thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51050.0

The limit removal from this old experiment will be re-implemented in later versions.



I am going to lock this topic now, because this is what I should have done long ago.