Suggestions for the next version of AGS

[Crimson Wizard]

Yes, by using some *.scm format. That is you have to open your other project, export script to scm, open new project, import scm. Can it be quicker to import from existing ash/asc directly?

[Khris]

Try copying them over (the two files in the game dir), iirc that should work.

[Crimson Wizard]

Try copying them over (the two files in the game dir), iirc that should work.

Unfortunately it didn't, that was the main reason I posted here

[monkey0506]

You can do this manually by opening the Game.agf files in Notepad/Wordpad/(whatever other text editing program) which are written in plain XML. Modifying them directly is not recommended and could permanently corrupt your game, so if you do this back up your files FIRST.

<!--DO NOT EDIT THIS FILE. It is automatically generated by the AGS Editor, changing it manually could break your game-->

This is the section of the XML file you are looking for:

Code: ags

    <Scripts>
      <Script>
        <FileName>GlobalScript.ash</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>True</IsHeader>
      </Script>
      <Script>
        <FileName>GlobalScript.asc</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>False</IsHeader>
      </Script>
    </Scripts>

You should have more individual Scripts between the <Scripts> and </Scripts> tags than this, but I only have these two in the particular Game.agf file I opened. What you want to do is copy everything from the opening <Script> tag for your ASH file, all the way down to the closing tag for your ASC file, i.e. this portion:

Code: ags

      <Script>
        <FileName>GlobalScript.ash</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>True</IsHeader>
      </Script>
      <Script>
        <FileName>GlobalScript.asc</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>False</IsHeader>
      </Script>

But not the <Scripts> or </Scripts> tags. You must make sure to copy this EXACTLY. Copy that section of the XML and paste it into the Game.agf file you are wanting to import the script(s) into (be sure to close the project in AGS first), and you must make sure you put the script above the GlobalScript. DO NOT COPY THE GLOBAL SCRIPT FILES FROM GAME TO GAME OR PASTE A SCRIPT BELOW THE GLOBAL SCRIPT DOING THIS. Save the modified Game.agf file, and load it back up in AGS.

Again, this process is NOT recommended to ANYONE doing so CAN BREAK YOUR GAME.

Sounds like too much work for what it's worth? It probably is. Just export/import the SCM files already.

I can appreciate that you might want to just import the raw files but is it really that difficult to use the SCM file? Most of the time when I'm wanting to move a script from project to project it's something I'm going to be releasing as a script module anyway, so I've already gone and exported it as SCM. Maybe that's just me though.

[cat]

An old thread, I know, I just thought it would be better to use this instead of creating a new one.

I'd really appreciate if I could move the selected object in a room or button on a GUI with the keyboard (VS style). This is much more accurate than moving it with a mouse or tablet.

[suicidal pencil]

I think that the new version of AGS should have no limit cap on the number of objects allowed in a room 

[hedgefield]

A tiny qualm, but for consistency's sake, it would be nice if walkable areas could be "disabled" and "enabled", instead of "removed" and "restored".

[Dualnames]

I think that the new version of AGS should have no limit cap on the number of objects allowed in a room 

I think the cap is reasonable. At least for performance point of view..

[Khris]

How about a generic game object "Location" that can point to either a Character, Object or Hotspot?
If it implemented common members such as .GetAtScreenXY .Name or .GetProperty, this could save some scripting time.
It's easy to work around, I know, just a thought.

[tzachs]

How about a generic game object "Location" that can point to either a Character, Object or Hotspot?
If it implemented common members such as .GetAtScreenXY .Name or .GetProperty, this could save some scripting time.
It's easy to work around, I know, just a thought.

Taking your idea one step further, maybe ags should have interfaces? IPositionable (or ILocation if you prefer), IResizable, IHasTransparency, etc. Then Character, Object and Hotspot can implement ILocation, and character and object will also implement IResizable, and this will simplify scripting for various scenario.
There are probably more urgent things than that on the list, though...

[monkey0506]

Instead of interfaces I'd much prefer to see class templates. Seriously. If you're trying to do anything to extend more than one type...it sucks. Code duplication...to the max.

For those who aren't familiar with code templates basically it would allow something like this:

Code: ags

struct MyTemplate<T> {
  T Data;
};

MyTemplate<int> myInt; // declares type T as int for this instance
myInt.Data = 5; // Data is an int

MyTemplate<String> myString; // declares type T as String for this instance
myString.Data = "This is some text."; // Data is a String

MyTemplate<Character*> myCharacter; // declares type T as a Character* for this instance
myCharacter.Data = cEgo; // Data is a Character*

Basically the T would be replaced with a class type, as defined at the time the instance gets defined. So when you put <int> then you are replacing every instance of T in the struct definition with int.

It makes coding much easier if you need to operate with multiple types. I wouldn't even mind if the template type had to be usable as a struct member type (AGS managed type or basic data type).

It would seriously save me a LOT of time.

[Calin Leafshade]

When a character moves they effectively 'jump' across the room by however many pixels their movement speed is.

This causes backgrounds of scrolling rooms to stutter so perhaps it would be better if characters moved one pixel more often rather than 4 pixels less often.

[Ryan Timothy B]

Calin, I could be wrong, but wouldn't that cause the characters feet to slide?

[Calin Leafshade]

hmm thats a good point.

I guess we need the viewport to scroll more smoothly then instead.

[Crimson Wizard]

hmm thats a good point.

I guess we need the viewport to scroll more smoothly then instead.

This is possible to do manually by writing an extension function for Walk, or just processing in rep_exec.

[Calin Leafshade]

Ive tried.

I can make the viewport move slowly but that just causes the character to stutter instead for the same reason.

Unless you feel you can do a better job at scripting it, i cant see a solution..

[Crimson Wizard]

Ive tried.

I can make the viewport move slowly but that just causes the character to stutter instead for the same reason.

I am not sure what may happen there...
I used script-controlled viewport scrolling in my Shooting Gallery techical demo, and there were enemies wandering across the screen while viewport moved around. I don't remember they "stutter" or something.

[ThreeOhFour]

I am not sure what may happen there...
I used script-controlled viewport scrolling in my Shooting Gallery techical demo, and there were enemies wandering across the screen while viewport moved around. I don't remember they "stutter" or something.

Yes but keep in mind that the camera follows the player character, where as it was not following the npcs.

[Crimson Wizard]

Yes but keep in mind that the camera follows the player character, where as it was not following the npcs.

If you control viewport explicitly, camera does not follow anyone.

I'm still not sure what stuttering was mentioned. I think I'll just check this out right now.

[Calin Leafshade]

Yes but we are controlling the viewport TO follow the player. Just more smoothly.