Messages

Is the backwards compatibility really something that needs to be held onto when it's a change this drastic and important for AGS? I'd personally ditch it.

This is a question of version planning. In my opinion it all depends on what do you expect of future versions of AGS. So far I see people here wanted to have a development branch which is fully backwards-compatible with previous releases of AGS, then, after some time, cut the ties and develop something totally new. At least that is what I heard (read).

There are tons of those non-OO functions we should must ultimately remove.

What's wrong with the function if it simply exists?
It is pretty possible to hide the obsolete functions: switch them on and off depending on the compiler setting.

EDIT: Wait... I missed the word "ultimately".
Well, if we are speaking of some future version with no backwards compatibility, then it's true

I say a setting in the general properties which will allow us to choose which scripting language we would be using, eg: Legacy AGS Script 3.2 and below or New AGS Script 3.3.

Unfortunately this won't always work. What if you are going to use script module written for older version of AGS?
Global setting may define default mode, but there's still should be way to set this for each separate script, I think.

My question now is this, if we decided to use another scripting or embedded engine, would that break the engine's backwards compatibility? I mean, JJS ports can support games all the way to 2.5x. Will that break with a new scripting engine?

Exactly my thoughts. If we just plain put any change, like something mentioned above by Ryan, into script system, older scripts, even 3.2 scripts, will not work.

This surely will require some workaround. The two most simple options that come to my mind are:
1) introducing some "preprocessor command", that would switch compilation to newer version, e.g.:

Code: ags

// the script module start
#enable_new_compiler

// rest of script

2) doing the similar thing but via script properties.

But, when I use <Import New Background... I get that black screen effect! Will I be able to use the <Import New Background function in the future??

I'll try to elaborate.
By using "import new background" you import NEXT background picture, and the editor switches to it. What you see now - is the SECOND background picture. In the editor you can switch between first and second backgrounds by choosing them in that drop-down list; you can also CHANGE any of them if you want. You can also add more backgrounds (up to 5).

However, when game starts, by default it starts with FIRST background. That's why you were getting black screen: you imported SECOND background, but the FIRST one was left black.
If you want to set active background during game, you should use script command:

Code: ags

SetBackgroundFrame (frame_number);

For example, if you want to start with SECOND background active, put this into GlobalScript's function game_start:

Code: ags

function game_start() {

   SetBackgroundFrame(1);

Backgrounds are enumerated from 0 to 4 (that's total five: 0,1,2,3,4).

If you want them animate (i.e. cycle over time):

Code: ags

function game_start() {

   SetBackgroundFrame(-1);

Can I ask? What is " <Import New Background"  used for, then?

Well, as I said, there may be up to 5 background pictures for the room. They are used to make background room animation. If you want to animate lots of objects at once this may be better choice than create many objects and animate them altogether.

Or, if you want room pic change over time for any other reason. Like changing day  and night, etc.

Yes Wizard! That is how I import backgrounds.....that is the way you are supposed to do it!???

Hahaha! It is all clear then.

You see, there can be 5 backgrounds for the room. They are switched by that list. You import SECOND background. But when the game starts the FIRST one is active.
To change first (primary) background you should select "Main background" in the list and click "Change" button.

I agree that may be a bit confusing if you are making your first game.

I guess we should remember this and add some comments to tutorial to prevent this problem in the future.

Arj0n
Check the list of games he tested.

To be honest, that's one of the weirdest errors in AGS I ever heard...

It sounds like graphic data does not save properly to the room file.

Wait a second....
How do you import background? can you tell your steps?

Can it be you choose "Import new background" in the dropdown list?

Heh. http://en.wikipedia.org/wiki/Chernobyl_Diaries

Every time after I add a new Category to the Project at
AGS Forums » Projects » <Project name> » Admin » Categories
I am being relocated to
AGS Forums » Administration Centre » Projects » Modify Projects

Not a big deal, but annoying a bit, also I don't see why should this happen.

The Vestibule
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=35231.0

I remember playing that demo. It was made for DOS! Bizarre and intriguing setting and characters. Loved it.

Clearly you need a hint to get this one, so here is a hint in the form of a riddle:

Spoiler

What do you save when you save the cheerleader.

[close]

A dumb chick?
A team spirit?
Free cemetery plot?

I don't know, lol I keep thinking though.

Oh noes! not that.
That's a terrible, terrible idea.
Seriously, there's GiP thread, where people may show what they are doing. There's Critic's Lounge too. Isn't that enough?

or Finnish games?

Finnish games are in danger? should alert WHAM! 

I actually wonder, is it possible to allow choose issue's category when the issue is being created? Or it is supposed that developers should categorize and prioritize every created issue as a separate step?

EDIT: ouch, my bad again. Category and version selection appears only when there are categories and versions in this project.

The now official tracker for Editor bugs and requests:
http://www.adventuregamestudio.co.uk/yabb/index.php?project=5

(I hope that works, and you won't need admin rights to use that )

Alright, I made whole bunch of them. I suppose 7 projects would be enough for anyone .

Admins actually have the option to create projects now.  I see someone has already made a test project.

That was me

I wonder if monkey agree to copy all the versions he put in the original project...

I would have separate projects for engine and editor myself, to remove clutter and confusion.  If not a separate project for every separate branch of the engine.

What about this for starters:
- Engine
- Engine Ports
- Editor
- Editor Ports (why not )
----
- Modules & Plugins requests and bugs
- Documentation (Manual/Tutorials issues)

The bugs on the project page probably should be just purged. A lot of them are simply not relevant any more.

There are feature requests made in 2004 that were implemented either in dev.3.2.2, or Draconian Edition

BTW, what issue Categories should we have? Like, "Engine" and "Editor", or else?

Is there a format to follow for our notes inside comments ?
// [Username] 2012-12-31: Sausages
// blablabla - Username
// something else ?

- Alan

I agree.
I usually used [IKM] (my initials) or [CW] (not anymore).