Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - morganw

Pages: [1] 2 3 ... 14
I have the same error on my computer ( Ubuntu 16.04, awk 4.1.3 )
I think it should be fixed now.

I think I've fixed all the links, as now it only flags ones on the front page:

Bad link EditorRoom on page (line 17)
Bad link EditorCharacter on page (line 18)
Bad link EditorSprite on page (line 20)
Bad link EditorView on page (line 21)
Bad link EditorInventoryItems on page (line 22)
Bad link EditorRoom on page (line 18)
Bad link EditorCharacter on page (line 20)
Bad link EditorSprite on page (line 24)
Bad link EditorView on page (line 26)
Bad link EditorInventoryItems on page (line 28)

Found 888 pages/anchors
Total links: 2706
Bad links: 10
I've also switched the the line breaks from \ to double spaces, which makes it format correctly in "unflavoured" Markdown editors, but the Sphinx build still doesn't seen to pick it up. I guess there might be an option to pickup the double space, if not I'll look at converting these lines into lists.

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; as a user the workflow is more of a problem to me than restoring the end result.

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.
Yes, I think there are probably three separate issues here. I only mention my point of view for storing state, as in my opinion , the workflow issues that make the persistent state desirable are related to only being able to edit one room at a time (so state cannot persist in the tab) and the existing controls are not particular streamlined (changing the settings is too involved a process). If it is easy to implement and doesn't restrict future changes or rolling back to previous versions, then it wouldn't be an issue.

Basically, the reasons I flipped these settings in the first place still apply the next time I come back to the room editor, and it would be annoying to have to set them again every time.
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.

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?
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.

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

Personally I would say, saving the state is just a workaround for not being able to open more than one room for editing. 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'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.

Editor Development / Re: Help file... here we go again.
« on: Yesterday at 00:16 »
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.

Adventure Related Talk & Chat / Re: AGS accreditation
« on: 16 Jul 2018, 14:41 »
I think as long as you comply with the new licensing, you are fine:

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

Editor Development / Re: Help file... here we go again.
« on: 15 Jul 2018, 08:56 »
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.

Editor Development / Re: Help file... here we go again.
« on: 15 Jul 2018, 00:22 »
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:
...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).

Editor Development / Re: Help file... here we go again.
« on: 14 Jul 2018, 18:54 »
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.

Editor Development / Re: Help file... here we go again.
« on: 14 Jul 2018, 14:20 »
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.

Editor Development / Re: Help file... here we go again.
« on: 13 Jul 2018, 21:03 »
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. 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.

Site & Forum Reports / Re: Sugestion: Game OS version
« on: 13 Jul 2018, 20:51 »
I just retested and couldn't, so we think it is Babar's different encoding that let him post it.

Site & Forum Reports / Re: Sugestion: Game OS version
« on: 13 Jul 2018, 20:47 »
This would be good, especially for larger games where people might not want to download multiple copies of it.
I think Babar approves too.

Site & Forum Reports / Re: Bug reports
« on: 09 Jul 2018, 20:24 »
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).

Editor Development / Re: Help file... here we go again.
« on: 06 Jul 2018, 18:41 »
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.

Pages: [1] 2 3 ... 14