Messages

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.

I've checked the page links, and apparently there are 346 broken ones, out of a total of 2516. Or perhaps my link checker is broken.
Either way I'll try to fix something tomorrow.

I think as long as you comply with the new licensing, you are fine:
https://opensource.org/licenses/artistic-license-2.0.php

There isn't anything in there about crediting the Copyright Holder.

Sorry, I was a little vague. For the Editors built-in manual, I meant replace the CHM file with the rendered HTML pages (so just include them as part of the installation) and have the builtin help shortcuts (e.g. pressing F1) open those files.

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?

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.

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.

Maybe there is a way to cross reference the two, so one can verify the other in the short term.

I've cleaned the pages on erio's wiki: https://github.com/ericoporto/agshelp/wiki
...there are just some tables left to reformat, and I'll try to rename the file to fix the titles, but the conversion was generally pretty good.

You can use a dynamic sprite, then get a reference to its surface, then use DrawingSurface.DrawSurface to draw it onto another surface (this also takes transparency as a parameter).

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.

HTML pages as a project within the Solution, which would render the markdown files and build the script reference from autocomplete data. I see the point about it being in a different repository though. I've been helping Erio here for the moment, so I guess he will move that across after some more cleaning up. 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.

So the

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.

My main concern is that the scripting reference will go out of sync with the actual scripting implementation, so ideally I'd like to try and get the scripting reference generated from the same source as the autocomplete data (auto-complete could just ignore the extra information for examples, warnings, etc).

In terms of everything else though, I didn't see a repository called "ags-manual", unless my permissions are hiding it from me.

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.

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: csharp

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

So what is entered as / converted to Markdown doesn't necessarily need to cover the script functions. 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.

I just retested and couldn't, so we think it is Babar's different encoding that let him post it.

This would be good, especially for larger games where people might not want to download multiple copies of it.
I think Babar approves too.

I think the webserver configuration is probably not checking the content boundaries correctly in the posted data:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -<BOUNDARYID>
Content-Disposition: form-data; name="message"

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -<BOUNDARYID>

The boundaries are probably getting shifted, if it is looking for two dashes to indicate the start of a boundary and then taking the remainder of the line as the boundary. So it is effectively setting the boundary to a single dash.

(ignore all the spaces, since I couldn't post this without them).

But once again, is MD a good format? I don't know, this is something I was planning to find out.

It is the easiest option I know of to write the pages, and if someone is making changes they would be able to do it directly on the GitHub web interface, so I think it is a good idea. I believe this is the original spec, and GitHub just add a few extra bits like tables and task lists. Worst case, if it needs to come off GitHub, any GitHub specific content would need to be changed, but I think the online editing is enough of a benefit to outweigh the risk (plus there are lots of tools for bulk processing text).

To begin with, is there anything that can just be deleted? There is still a load of stuff in there about licensing which no longer applies (I've never heard of a 'swapware license'). I am currently trying to make a replacement verb coin template, but even if that doesn't end up getting added I'm not sure why the existing verb coin template has manual entries, whilst the templates that people are likely to actually use have nothing.

To track the source you will have to store the path though, as potentially the source image has changed the editor last saw it (so timestamp and hash may have changed). I think fundamentally we are both suggesting the same thing, and the mechanisms needed to reference the files would be similar. Given that an absolute path may not match on two different computers, ideally the source should be relative to the game folder, so really I think the the only difference is an implied import vs manual import, and then where the mapping is stored.

If you're going to have the capability to flag a sprite for tiled import (with x and y dimensions), and set the transparent color (because that's required functionality), and view the sprites, and set the sprite number (implies reordering the sprites?), and probably the option to then delete them from within the editor, because why not... isn't that more or less everything the sprite manager does?

Yes, but those settings are applied at time of import and then everything is manually specified. Just adding a mapping between files and IDs, with the ability to rescan and remap would give similar functionality as the import, but main difference would be if you can specify default settings and then just save images to start using them.

Umm... isn't it the opposite?

It doesn't look like the source file is tracked at all for a tiled import, so I can't see any benefit with regard to re-importing after an edit.

It wouldn't prevent you from using a spritesheet, you could either flag the folder for tiled import, or just flag a particular image for tiled import. Unless I'm missing something, keeping the spritesheet as a single image means you never have to re-import the whole thing if anything on the spritesheet is changed; perhaps people might be preferring spritesheets at the moment to get around workflow issues in the sprite manager. Presumably a tiled import will always give you sequential sprite IDs?

One of the preliminary steps could be reimplementing the way editor draws stuff, perhaps making it rely on its own sprite map.

I guess the question is, should the editor aim to show everything on screen exactly as it is in the game, or should it just be enough to arrange everything and then run it with the debugger attached. I think at the moment it is a bit of both.

This is like a complete overhaul to how you work with sprites in AGS. Are you sure the people will accept this?

I think so, and some of what I'm suggesting is optional, but the end result is you press save in the graphics program to use or update an image. Probably best survey some people though.

This may be a regular workflow for professional artists, but, for example, I got used to import sprites from clipboard, that's very fast and you don't have to manage files.

If you can press save instead of copy, it would be much the same process.

And the tiled import... I was just drawing all animation sequence in 1 document, and then tile-importing them, again not thinking about cutting into files.

The metadata could define how large a tile is, and that could be referenced per image or per folder.

Perhaps there may be a way to keep these import commands? They may be simply creating new files and metadata according to the settings, work like alternate entry point into this system (main is copying file into folder).

Maybe just have the option to convert an image. So for your tiled import, the image is already there and you just define the tile dimensions to reference it as multiple images. But the alternative I'm suggesting would let you specify the tile size on a sprite folder, and then all your sprite sheets which use that tile size would be automatically used as multiple sprites.

There may be slightly different approach: run a file change listener on a Sprites directory, and note files as they are added, removed or changed. Cache may be updated immediately, or at compile time using a prepared list of changes.

EDIT: oh right, the files could have been modified in between editor sessions too.

Presumably though, it is possible to know the position of a particular sprite within the file, without having to read the whole thing?

But if there is no sprite manager, how do you tell it about these exceptions? I think I am missing something in this plan.

Well it would need something, but this something will not import, create or delete sprites. So if there is just a sprite viewer, it could just hand tasks off to a metadata manager, or you could be specifying any changes settings outside of the editor.

As a rough example:

• Save a new sprite into the sprites folder
• Editor see a new path and assigns it a number (possibly yielding to the filename or a metadata file)
• User right clicks a sprite and choose "top left pixel as the transparency" as they don't want the default settings
• User right clicks a sprite and manually edits the sprite number

So for these actions:

• If the asset pipeline is consistent (i.e. you are being given or making graphics in a consistent format) it is likely you would only need to set default import settings and not make any exceptions to this
• If you do need to change something for a particular image, this can just be stored as an exception to the default, either in the XML of the project file or in a metadata file next to the image on the disk (in the case of the extra file, you would check the image settings into version control independently of the project file)
• If you need to make changes for multiple images, this can also be stored as an exception to the default (as above, in project file or metadata file), but referenced against a sprite folder (which is now just a folder on the disk)
• In the case of using metadata files, you could potentially have specified the import modes and ID number reservations before the editor ever saw the images, so potentially it just needs to validate the data

Also, do you mean that file format itself stores frame count? If not, what did you mean by "read the frame count of the file"?

I meant that, if you had something like a GIF file which had multiple frames, you could read the frame count from the file and allocate it the corresponding number of sprite ID numbers (instead of having to extract each frame to disk to use it).

Could you write all this in a form of a task, with all points elaborated?

I will do this. I'm guessing you mean on GitHub?

As long as you can read the frame count of the file, I think it would be okay for a whole animation in a single file, but I think people tend to export as a sequence of images anyway. Potentially you can just have the editor assume a single image with alpha channel (where available) and just store exceptions to that, either in the project file or write it as metadata into the sprite folder (you could probably reserve a sprite number range this way too).

I think I've linked to this before in another thread:
http://thebrotherhoodgames.com/blog/2013/10/visionaire-engine-powering-stasis/

...but have now also found where I read the direct comparison:
http://thebrotherhoodgames.com/blog/2010/12/adventure-game-engines/

I'm suggesting there be no import controls at all. If there was an internal sprite editor (some sort of mini paint program) there would be an argument for keeping sprite management, but everyone is already using external tools and is then forced to go through the import process. If people are already saving their sprites and masks to disk to do an import, they may as well just save them to the game folder:

D:\MYGAME
|   MyGame.agf
|
\---Sprites
    |   apple.png
    |   banana.png
    |   pineapple.png
    |
    \---Grapes
            green_grape.png
            red_grape.png

If storing the mapping of ID number to path in the project file, you would only have to assign numbers for any new file paths which show up. Potentially though, just reading 10_apple.png as sprite 10 means no ambiguity about the sprite number, and the project file wouldn't have to track it at all. Compared to how it works at the moment, even renaming a directory full of files is a lot easier than trying to re-arrange numbers assigned by the sprite manager.