Messages

Also, Dreamweb is now freeware.

On a Mac is isn't by default, and a lot of system requirements for programs say the filesystem must not be case-sensitive in order for everything to keep working.
Isn't the solution here just to use the correct filenames when reading or writing? If you don't assume that case doesn't matter, it will work everywhere.

The colour is an integer, so unless you've already declared it:

Code: ags

int c = Game.GetColorFromRGB(r, g, b);

Yes, I'd love to work on the AGS manual.

http://gamejolt.com/games/peridium/257024

Anyway, on_event is supposed to go inside GlobalScript -> Edit Script.

Defining on_event will also work in a room script.

If you are running that in response to a click, and the click was the one which changed the room, cJordi.Room will return the previous room number (even if you change room on an earlier line in the script, that change won't occur until the script processing has completed). If the click is in the new room (i.e. you are using a light switch) that would be too late.

You could try this:

Code: ags

function on_event (EventType event, int data) {
    if (event == eEventEnterRoomBeforeFadein)
    {
        // data is the room number of the new room
        if (data >= 20 && data <= 35)
        {
            cFantasma1.FollowCharacter(cJordi);
        }
        else
        {
            cFantasma1.FollowCharacter(null);
        }
    }
}

...which should (untested) run the code as the room changes.

I like the idea, but I also didn't think that hanging is more humane that using the sword (I guess depends what someone is doing with the sword).

I think this is the only part where I struggle to imagine what happens:

But some other problems arise, because he has little access to actual tools, and has to improvise.

Surely, regardless of the maths, the solution is just to shorten the rope?

I think I've found all the tables and have finished fiddling with the checkout script. It'll now work on Windows with the BASH shell you get from the Git installer, the Windows Subsystem for Linux (TM), or the standard Bourne shell. It didn't work previously on Windows as I hadn't realised that Git on Windows disables the use of symlinks by default. Perhaps there is a better way to build without modifying the source, which doesn't use a symlink...

I need to take a break and work on something else for a while, but I'll check back in to see what happens with the recruitment thread.

The next release of Chrome is the one that is meant to flag anything HTTP as unsafe, so people might start to hit problems. If you wanted any assistance at any point, just let me know.

Any chance of trying this again? I'm not sure what happened with the previous attempt with a Let's Encrypt certificate, but was there a reason why it couldn't be used?

I had to redo the tables manually as the original Markdown had no table support, and the lack of conversion just gave rows of dashes which are valid Markdown. I'll see if I can search for any I've missed and redo them. They are pretty easy to make using the GitHub Markdown variant. I tried to post an example, but unfortunately it contains 3 dashes.

I've created the 3 missing pages, so the build gets deployed again. I also changed the build to work with a symlink for the index page, so now all the config and template options can stay in the other repository. This was mainly to get the build date onto the page, which isn't part of the alabasta theme for some reason, so now you can actually see that deployed HTML has actually been changed.

Slight issue, in that the link checker is now checking links in the symlink (so errors in Home.md are shown twice), so I'll have a think about how to fix that.

To sum up, changes that are valid should now be appearing here: https://ericoporto.github.io/agshelp/

First port of call is probably Pulseaudio settings:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636552085#msg636552085

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:

agshelp/checklinks agshelp.wiki/*.md

Bad link EditorRoom on page agshelp.wiki/Home.md (line 17)
Bad link EditorCharacter on page agshelp.wiki/Home.md (line 18)
Bad link EditorSprite on page agshelp.wiki/Home.md (line 20)
Bad link EditorView on page agshelp.wiki/Home.md (line 21)
Bad link EditorInventoryItems on page agshelp.wiki/Home.md (line 22)
Bad link EditorRoom on page agshelp.wiki/_Sidebar.md (line 18)
Bad link EditorCharacter on page agshelp.wiki/_Sidebar.md (line 20)
Bad link EditorSprite on page agshelp.wiki/_Sidebar.md (line 24)
Bad link EditorView on page agshelp.wiki/_Sidebar.md (line 26)
Bad link EditorInventoryItems on page agshelp.wiki/_Sidebar.md (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.