Messages

1

Advanced Technical Forum / Re: Recording sound clips in-game

« on: Today at 09:30 »

Hi there!
I was wondering if there's a way to make AGS access the mic to record a voice clip and store it in a file.

Short answer: AGS does not have such function.

Potential solution: plugin, based on SDL2.
* SDL2 is a cross-platform library, which is more up-to-date than Allegro4 (which AGS currently uses).
* There was at least one successful example of plugin with SDL2 (joystick rewrite that works on Linux)
* SDL2 supports audio recording: https://wiki.libsdl.org/SDL_OpenAudioDevice

EDIT: My above answer was written with assumption that you are speaking of recording in game. If not, please elaborate.

2

Beginners' Technical Questions / Re: Removing Inventory Items

« on: Yesterday at 20:48 »

You need a while loop (or something similar)
something like: check how many inventory items the player has, then subtract 1 (with LoseInventoryItem) until the player has 0.

It's faster with InventoryQuantity:

Code: Adventure Game Studio

1. // This removes literally all items from player's inventory
2. for (int i = 0; i < Game.ItemCount; i++)
3.     player.InventoryQuantity[i] = 0;
4. // This removes only particular items
5. player.InventoryQuantity[iMyItem.ID] = 0;
6. UpdateInventory(); // You must call this to force update on-screen inventory window
7.  

3

AGS Engine & Editor Releases / Re: AGS 3.4.2 - alpha 2 - next WIP version

« on: Yesterday at 19:21 »

If there is already a mechanism to do it, then it isn't an issue. I just didn't want to get locked into the existing controls indefinitely;

No, of course not. This definitely should be saved in such way that makes it possible to even discard if control scheme changes cardinally.

This is also the reason (among few others) I changed my mind on keeping these flags in game classes as I initially thought: while much simplier code-wise, that could become a problem if UI or set of design-time properties changes. So currently I am trying to reimplement tzach's solution into a kind of data table in the Room managers, which corresponds set of editor-only properties to game objects. TBH the current code structure is not perfect for this (receiving updates about object changes is bit clunky), but hopefully I will be able to find good way to sync them.
After that next step will be serialization...

4

AGS Engine & Editor Releases / Re: AGS 3.4.2 - alpha 2 - next WIP version

« on: Yesterday at 17:27 »

Yes, but to make the settings persist through Editor upgrades this isn't just simple a serialize/deserialize. It would probably have to be linked to the project upgrade process and I don't know if that even considers per project user preferences rather than just project data. Having had to rewrite the whole preference system for the Editor just so I could add an option to suppress a message box, I wouldn't want these new settings to be trivially added and create a similar problem down the line.

The Game.agf.user is loaded through same serialization mechanism as the main game data in Game.agf, that allows using reflection (with help from attributes) to serialize classes.
This mechanism considers possibility of new, deprecated, renamed properties, and the change in the value range (this is also why I was suggesting using it for general preferences earlier). If something is lacking or suboptimal there, it may be improved.
EDIT: entry point is LoadUserDataFile() in AGSEditor.cs. The serializer is class SerializeUtils in AGS.Types.dll.

On the other hand, for rooms we may consider creating separate similar config files, one per room. It's just that since that may clutter project folder, they are better saved in "Rooms" subfolder already, so not sure.



PS. I honestly did not want to discuss implementation details in this "release" thread. I posted here to know user's opinion. Code problems may be discussed in related forum section, or even on github.

5

AGS Engine & Editor Releases / Re: AGS 3.4.2 - alpha 2 - next WIP version

« on: Yesterday at 14:50 »

I guess that I'm saying, having to store the state is something you would need when applying the changes you need is taking too long or is overly complicated. With the example of hiding multiple objects in a room, I'd rather make it easier to multi select objects and apply any setting, rather than leave awkward controls in place and store the settings to avoid frustration.

But aren't these are different problems that require different solutions? I did not mean the state saving as a solution to not able to select multiple objects.
When people are working on a game, they may open same room many times. Even if there are not multiple objects that need to be turned off but only one, or if there is a convenient way to multiselect, even then they'd probably rather keep that convenient state saved than change it same way over and over.

6

AGS Engine & Editor Releases / Re: AGS 3.4.2 - alpha 2 - next WIP version

« on: Yesterday at 13:15 »

I'd say that, if the interface is good and you aren't in the middle of a long-winded task that locks other editor components, you wouldn't expect the state to be saved and restored.

Personally I would say, saving the state is just a workaround for not being able to open more than one room for editing.

It seems we have very contradictory views on what user expects from the editor... Nearly every contemporary editor I've seen saves layer visibility in the document - game editors and image editors alike, and I had an impression users usually want to see the scene in the same state they had it when closed editor last time.

Being able to edit several rooms at once does not change much in this regard, because you may close and and reopen editing panes, and restart Editor eventually too.

Does your opinion originate from concern about difficulty of implementation, or you actually do not think having state restored is needed, or even expect these settings to be reset every time you launch the Editor because that complies to your personal work habits?

In the example given above by Cassiebsg she has large objects covering whole room, and she wants them to be invisible in the editor to be able to work with the rest of the room. Without these settings saved every time she opens an editing session she would have to adjust their visibility over and over again.
Same will happen if you want to lock things. Usually people would lock objects that are already in place and should not be touched anymore or edited by mistake.

To slightly adjust my original question: do users expect these settings to be saved in between editing sessions, like in: reopening editor next day?

If opening up the room data is on the to-do list anyway, and storing settings may restrict any future changes (you'll either have to validate them or drop them all), storing more data just seems to add more restrictions in the long run.

I have no idea when opening room data or having multiple rooms at once will be done. If we are to make this state saved only as a temporary solution until these times, they may be saved in a "workstate config", as mentioned above, and later simply discarded. I believe they won't cause much trouble in such case. (I fear more trouble will be caused by implementing this serialization, because you need to sync it with existing rooms...)

7

Editor Development / Re: Help file... here we go again.

« on: Yesterday at 12:31 »

First, about the index, I don't know and would need to research. For this to work, one time links have to be recognized as toc tree (need to use bullets in markdown) and references like See Also must not be recognized as toc tree.

I do not think it is links what define index, that sounds more like reverse-engineering an index table. Only if there's no other way, perhaps...
In Latex index keywords are assigned to articles using dedicated command. If Markdown itself does not have such feature, maybe there are special tags recognized solely by Sphynx, or maybe there is a way to assign these differently, like have a separate table of index? Personally I have no idea how this works for Sphynx, just throwing in some thoughts what I'd try to look for.

In the new Scripting Language section, are these valid topics? I really don't know how to teach programming.

I believe you could simply use existing topics for now. My proposal was merely to split current Scripting chapter in two parts. The rest could be done by community members over time.

Following existing topics could be used in "Scripting language":

Scripting tutorial part 1
Scripting tutorial part 2
Pointers in AGS
Calling global functions from local scripts
The script header
String formatting
Multiple Scripts
Understanding blocking scripts
Dynamic Arrays
Extender functions
Game variables
Script language keywords

The rest of the existing topics belongs to Script API.

8

AGS Engine & Editor Releases / Re: AGS 3.4.2 - alpha 2 - next WIP version

« on: Yesterday at 10:02 »

So, I was looking into problems 1) and 3) from above, and it appears that I'd need to modify some of the tzach's code to make this work correctly.


Technical things aside, my two big questions are:

1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...

2) If it should be saved, should this information be saved as a part of the game project, or as a separate "editing state" config? What I mean, game project stores object properties related to the game in Game.agf, but there is another file called Game.agf.user that saves what is called "workspace state" which has some service info about last usage of editor which is not required to build the game itself (I guess we could also move few options, such as "Build Targets" there.
Anyway, the point of having Visible/Locked-in-the-editor setup in a separate config is to specify these properties as non related to the game itself, and if for example game is worked on by multiple users they may have separate design-time configs which are not shared between them when you sync the project.


NOTE: before this new navigation bar was introduced Room Objects already had Locked property that was saved in the room data and kept with the game.

9

Editor Development / Re: Help file... here we go again.

« on: Yesterday at 09:41 »

Hey, just curious what you guys think.

I'd like to propose changing the Scripting division to -
* Scripting language (with articles regarding scripting syntax and tutorials)
* Script API (with functions & properties and enums reference)
* (optionally) Template/module reference - to describe ones coming with AGS and other most popular ones.

(Right now the "Reference" chapter under "Scripting" contains random set of articles)


Another major question I have, is Sphynx potentially able to create Index out of the markdown? Imho good index may be very useful especially when looking for script functions.

10

Adventure Related Talk & Chat / Re: AGS accreditation

« on: 16 Jul 2018, 13:50 »

My copy of AGS 3.4.0 has a licence agreement which requires accreditation to Chris Jones as AGS author.

Is this found in the manual? Unfortunately, documentation contains multiple topics that were not updated over many years.

I have to admit that do not remember if Chris Jones mentioned anything about this when he left the project. Perhaps someone does know?
Thing is that since 2011-12 the program no longer contains only work by Chris Jones, there were about couple of dozens of contributors. Our copyright sais simply "by Chris Jones et al." (with the full list of participants in a Credits article). But I do not know if we should enforce the rule of mentioning authors in the game anymore.

EDIT: there is this page on the website that probably is more up-to-date (though even that could be a bit old) http://www.adventuregamestudio.co.uk/site/ags/legal/

11

Critics' Lounge / Re: Verbcoin Interface

« on: 15 Jul 2018, 23:05 »

nevermind.

12

Editor Development / Re: Help file... here we go again.

« on: 15 Jul 2018, 01:14 »

It is still markdown, but when you build the solution it renders the markdown to HTML (you can use something like Sphinx, or render the pages individually and add some Javascript to jump to particular sections). Then the web based manual is just a copy of the build, the Editors built in manual is also just a copy of the build.

Oh, you meant it other way around. At first I thought you are talking about having HTML pages as source files inside solution.
Last question, by saying "Editors built in manual", do you mean literally built-in in the executable as a resource?

13

Editor Development / Re: Help file... here we go again.

« on: 14 Jul 2018, 19:42 »

HTML pages as a project within the Solution, which would render the markdown files and build the script reference from autocomplete data.

Probably this is something beyond my knowledge, because I still did not understand anything. Can you give an example, like where HTML page is kept, what it has inside, how does it "render markdown file" etc?

Personally I'd prefer the script reference to be generated from where the scripts are, and then keep the rest of the manual separate, but getting the whole thing as markdown first wouldn't stop that later. I did briefly discus with Erio and Gurok who thought it wasn't worth using the autocomplete data to generate it, and they had persuaded me, until I found that the manual links to non-existent functions, and is missing at least one function entirely.

I am myself very reluctant of having larger help text inside the script header. In fact, I noted that in my previous reply at first, but then decided to cut that out.
I see both benefit and disadvantages for either approach. I've seen how tzachs is documenting his MonoAGS API in code, with examples etc, and being documentation for coders that seem to make sense.
My biggest concern in regards to script header though is that having expanded help text there for each function and property would clutter the script API declaration and make it not easy to work with the file. Another thing is that if someone who is non-coder would like to ammend a script API article, they'd have to work with that file which is easy to break (and cause compiler error) and which cannot be previewed as MD, so all formatting has to be done either by heart or typed in some MD editor with preview first, and then copied into script header.

14

Editor Development / Re: Help file... here we go again.

« on: 14 Jul 2018, 15:18 »

I've just created it: https://github.com/adventuregamestudio/ags-manual
If someone else wants to participate, please tell me and I could add you to contributors for this particular repository.

If trying to auto-generate the script reference, and also incorporate another repository as a general manual, is it easier to just make the changes in the main repository instead of creating another, and have an HTML version of the manual build as an an additional project? This also means no more CHM files, as long as context sensitive help can still go to the correct section.

Sorry, I am not following your suggestion. What "changes to the main repository" do you speak of, and what is the idea about having HTML pages as additional project? I thought we had intent to have all docs source in Markdown?

My point of having separate repository for the manual is that I hoped to give community members a way to freely edit the documentation. IMHO it will be very inconvenient to have them edit repository with the source code.

Generated pages could perhaps be simply pushed to the manual repository by the doc update script (same as starts generation)?

15

Editor Development / Re: Help file... here we go again.

« on: 14 Jul 2018, 11:33 »

I'm currently doing nothing for a week after surgery on my foot, so I can try to work on the manual for a few days if I know what and where the final result should be.

So, I can create a new "ags-manual" repository in the community group. But I got distracted and haven't quite realized what was the outcome of eri0os's experiments. I recall he tried several things, including storing pages in a github Wiki. I am unaware how you access that through git means, and whether its possible to work with on your local disk if you prefer to edit files directly.
His findings are listed here, it seems: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51340.msg636589833#msg636589833


Anyhow my proposal stands this:
1) we seem to have decided on having source in Markdown, so be it.
2) the new repository may be thought as an experiment where nothing is set in stone, but the general idea is to have current manual converted into Markdown and brought to a better chapter/page structure.
3) Big LaTeX file may be found here, as usual: https://github.com/adventuregamestudio/ags/tree/master/Manual
If you cannot convert this to HTML yourself (still not certain if conversion works fully on Linux): https://www.dropbox.com/s/snrrhug5ugrc52l/ags-manual-htmlpages.zip?dl=0
4) Suggestions on chapter structure: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51340.msg636589906#msg636589906
That, and my own post after that suggests larger division on root level.

Probably, manual source (in markdown) should be placed in its directory (e.g. "src" or "docs"), because we may also have some conversion scripts in the repository?

I think that, in terms of script reference, it would be possible to generate this on demand, because the information is already entered so that the compiler/autocomplete can use it:

Code: C#

1. builtin managed struct Character {
2.   /// Adds the specified item to the character's inventory.
3.   import function AddInventory(InventoryItem *item, int addAtIndex=SCR_NO_VALUE);
4.   /// Manually adds a waypoint to the character's movement path.
5.   import function AddWaypoint(int x, int y);
6. ...

So what is entered as / converted to Markdown doesn't necessarily need to cover the script functions.

Do you mean generating articles this way, or actual help content? Currently in the script reference articles are larger than that, having elaborations, warnings, examples etc.

16

Site & Forum Reports / Re: Sugestion: Game OS version

« on: 13 Jul 2018, 20:49 »

---

I think Babar approves too.

Idk about that, but --- definitely works now .

17

General Discussion / Re: Translations

« on: 13 Jul 2018, 18:36 »

Context is the KEY in doing a translation and with AGS games it's MUCH harder than translating a book or movie as everything is non-linear and the translation file doesn't tell you where every single line shows up in the game.

I remember translating Ben Chandler's Awakener to Russian language, and later replaying my own translation I found that it does not work in some places, because certain lines do not fit character's personality or match the style they talk in original language. That was a minor thing, but few lines stood out enough to make me cringe.

18

Engine Development / Re: AGS engine Android port

« on: 13 Jul 2018, 00:04 »

Which java file in which repository are you proposing the change?

What is showInGameMenu ? I am unfamiliar with this function.

It's only few posts above.

The explanation of original problem:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg636588597#msg636588597
The explanation of proposed changes:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg636589972#msg636589972

But that problem is not related to problem of building launcher, which mim2011 currently has.

I think CW did it on Windows 10 (guessing).

I used Ubuntu.

Also, I'd wish we were discussing this on github issue tracker instead. This old thread should be locked, and new one created instead, with up-to-date information.

19

Editor Development / Re: Build is wrong after project rename

« on: 12 Jul 2018, 21:09 »

While I agree with everything, deleting random stuff from Compiled folder is somewhat complicated. Since the project structure does not have explicit subfolder for user data, people may put files into Compiled by hand.
This may seem far fetched, but there is currently no way for AGS to know if the *.ags or *.exe found in Compiled are remains of previous compilation before project rename and not files that user put there for some unknown purpose.
Perhaps saving "previous name" in temp program config could hint that project was renamed.

This is also why I was reluctant to make AGS clear Compiled folder after upgrade from 3.4.0 to 3.4.1 (where its structure changed a little).

20

Engine Development / Re: AGS engine Android port

« on: 12 Jul 2018, 16:14 »

I don't think that the hack with copying the ant folder into a newer ndk works.

But this is what I and eri0o did. IIRC eri0o has installed modern Android Studio and built from there.
Could you tell what version of NDK are you using? I might try to retrace all the steps from pointer zero again.