Messages

This gave me an idea, maybe we should add a command line option for the engine to ignore plugin files and go straight to stubs.

E.g. "--no-plugins".

Alright, new update:

1. Now supports local variables (from stack memory), including function parameters.
Supposedly, engine correctly calculates their lifescope, and overriding names in the nested sections should also work (but I cannot remember if old and new compilers allowed to do that yet). But it works correctly if you have multiple variables with the same name inside multiple functions.
The code for local variables turned to be uglier than the rest of the draft, so some things may still be not completely reliable.

2. Added "Type" column.

Branch is still here:
https://github.com/ivan-mogilko/ags-refactoring/tree/ags4--draft-memwatch

I might open a Draft PR to let this build on CI for easier testing.

That's a good call. This reminds me if anyone is wary of someone sending an AGS game, remember you can run others AGS game with a run-time, ScummVm or agsjs - I may need to update the website to the latest version but anyway it usually works.

That is true, but always remember that danger may also come from plugins. You can never tell what plugin does. It may have a standard plugin name, but hacked to do something else.

OTOH there's a super dangerous ags_shell plugin, which should not exist at all, in my opinion, because it allows to run almost any Windows command (at least the old one did, idk if there have been any safer rewrites).

For this matter, any ags game should never be run with administrator rights.

Does it contain all branches from SVN and such?

I think it contains all the commits from SVN's main branch, known as "trunk". This is hinted by the information in commit descriptions, which have the links and hashes of the corresponding svn commits. These links start with "https://svn.bigbluecup.com:7743/svn/ags/trunk1 " and go on increasing the number.
This branch corresponded to v3.2.1.

Changes from v3.2.2 branch were applied separately later (this may be noticed in the git history).

I don't remember which branches did SVN repo contained precisely now, as that was a long time ago. But my guess is that it did not contain anything older, because if there was anything, the original maintainer of git repo would port these commits too. Jochen Schleu had a goal to make old games run, so he would not miss a chance to have an older code.

Did the conversion from SVN to Git cause some kind of lost data?

I doubt it. This was done by an automatic tool meant for this purpose.

Does someone have a backup of the Subversion repo?

Well, I had many years ago, but no longer do.

I found a smaller clone of the SVN to git though here, made by Nick Sonneveld:
https://github.com/sonneveld/ags-cj
it contains strictly CJ commits, with nothing else over them.

The old template had one of the inventory items (the pipe flutes) set to InstantUse, it would make the character play them , instead of picking it up from the inv. window. Maybe the new template should also have one item set in InstantUse ('m assuming it doesn'y now)?

It does.

I am trying to track down the earliest code release of AGS. I have looked at the earliest commit on AGS GitHub repository, but I am uncertain if this is the same as the original forum zip release. If anyone has a cached copy of the original forum zip release, it would be incredibly helpful for future reference.

I found the following forum thread, but the svn server is offline. I wonder if there's some backup somewhere: https://www.adventuregamestudio.co.uk/forums/engine-development/initial-ags-engine-source-code-release/

The date of the forum post is 27/04/2011.

There's a commit in the git repository called "Initial release of AGS Engine source code!" having date 27.04.2011 (commit hash a45f1a55a2c41efae2246c24a7e5c6c1ecddfe6d).

Since these dates match, I suppose it's the same release.

Here's the test build. But it is based on 3.6.1. I'm done patching 3.6.0 for now, since 3.6.1 is out.

https://cirrus-ci.com/task/5215983743270912

I have a weird memory of seeing somewhere a string like "ikl8gjdpq1Tb" used to figure the height extension of a font but can't figure in which code I saw this...

We use a similar line, but only if no real height is reported (WFN, plugin fonts).
https://github.com/adventuregamestudio/ags/blob/1f356b5172a769951d8184e00e66fcf5ab7d1226/Common/font/fonts.cpp#L124-L129

The problem with such magic strings is that you cannot predict which glyph will be "bad", and also, some fonts may not have latin letters at all, for example.

Alright, I have a seeming success, at least judging by values I see under debugger.

Opened a PR: https://github.com/adventuregamestudio/ags/pull/2388

I might post a link to a test build here, as soon as it's ready.

EDIT:
https://cirrus-ci.com/task/5215983743270912

While analysing this font, I found that some glyphs there have "top draw position" higher than ascender. In other words, they ought to be drawn slightly outside the normal font's area (ascender + descender). I was not aware that this is allowed by the TTF, but apparently there's no restriction to this.

I suppose that, if a better way is not found *, the solution could be to run through all available glyphs and measure the maximal found extent of a glyph upwards and downwards, then use this knowledge to report "graphical font's extent" for the engine.

* - meaning, if this is not already cached somewhere inside the font data.


EDIT: this is from FreeType library:

Code: cpp

  /*    The values of `ascender', `descender', and `height' are <...>
  /*                                                                       */
  /*    Unfortunately, due to glyph hinting, these values might not be     */
  /*    exact for certain fonts, they thus must be treated as unreliable   */
  /*    with an error margin of at least one pixel!                        */
  /*                                                                       */
  /*    Indeed, the only way to get the exact pixel ascender and descender */
  /*    is to render _all_ glyphs.  As this would be a definite            */
  /*    performance hit, it is up to client applications to perform such   */
  /*    computations.                                                      */   

I was wondering if this is documented somewhere. We have the page for BASS template in the manual, but it does not mention this custom property. That's definitely our oversight.

Do you actually connect these functions to gui events, or just copy/paste them into the script?

The gui functions should be connected to events, similar to how shown on this screenshot:
https://adventuregamestudio.github.io/ags-manual/images/acintro3_03.png

Patches to the game may be made outside of github too. That's a bit less convenient, but if they are contained in few specific files only, then a person might send them to the manager, who merges the changes and commits to repository.

First of all, check if this function is run at all. The easiest way to do so is to add "Display("i am here!");" command there.

If it is not run, double check that you have connected this function to the button's event, on its events page.

Finally, does the save in question actually exist?

- When opening the project in AGS editor, I got a message that I'm using a newer version of AGS. Which is the intended version? Is it the last stable?

The project is done in 3.6.0. It may be upgraded to 3.6.1 if that's wanted.

- How do we work on this? Of course, we will discuss things first, but afterwards? Just make a fork and then pull-requests? Who is responsible for merging them?

I would prefer if there were at least 1 maintainer/manager, that is - a person responsible for keeping the game runnable, assigning tasks and checking and merging (or rejecting) pull requests. I honestly don't want to be the one, I'd wish someone would volunteer for this, in which case I shall grant them write permissions for this repository.

After that I can add more people there by this manager's request, if necessary.

We also may add automatic game building process using Github Actions (i think?). This would allow to test that game compiles at all times, and have it uploaded to "releases" page on github. @eri0o did this for his own games, and for our test games in other repository (we use them to test the engine, they are not playable).

Should we have something like "room-owners", i.e. every room has a person who decides what goes in? Or is this all a community effort?

Having a person responsible for a room makes sense in terms of working on it. But I think the final decision should be done by a manager who has a full picture in the head, otherwise things may get inconsistent and messy.

This is "more scripting" vs "more disk space use and slower undo/redo operations".

This custom property is already in the BASS template, it's called "InstantUse". Click on "..." besides "Properties" property in Inventory item, and you'll see it.

Btw, you can let AGS do the heavy lifting and simply use savegames.

I would be very careful about this approach. When using saves you won't be able to select what to revert and what to not revert.

To give few random examples: imagine having an auxiliary "window" hovering the map editor. Restoring the save would also restore its position and state.
It would revert any map scrolling, any setup done in the menus, and so forth.
Is that really what you want for the "undo" mechanic?

I'm sorry, I have probably missed this, but was there any conclusion to this portrait?

Yes, that's how it is done: you record a minimal necessary description of an action, with parameters, and then have 2 functions: one that performs the action using this description, and another that reverts or performs opposite action.

You need 2 lists for actions: for undo and redo.
When user does something, an action is added to "undo" list.
When user commands "undo" you take last action from "undo" list and revert it, then put this action to "redo" list.
When user commands "redo" you take last action from "redo" list and perform it, then put this action to "undo" list again.

I believe that the programs commonly do this more or less same way. The difference is mostly whether action is performed by a pair of do/undo functions, that have a big switch (selecting which action to make), or if each action is implemented as a separate class that may be told to "run" the action. I think, at least in AGS 3,*, having 2 functions is easier; but in AGS 4, with better pointer support, the action class approach may also be done.