Ace Attorney Online

Hi everyone,

As you may have noticed, I have basically not been taking care of AAO for a year, and because of me, a lot of changes and bugfixes were held back.
Indeed, even though I was away, development on AAO didn't actually stop : Enthalpy fixed quite a few bugs over the time and improved the code base - but since I wasn't here to integrate his changes and upload them to the actual site, you didn't get to enjoy the changes.

Well, it's time for a rather big update today !

New features :

• Custom text colours (Enthalpy)
• Player in debug mode can be opened directly from Manager (AceAttorneyMaster111)
• Confirmation dialog on deleting a trial (Unas)
• Confirmation dialog on closing the editor when there are unsaved changes (Unas)

Technical updates :

• Simplify the code of the old format converters. This removes a lot of duplicated code. (Enthalpy)
• Trial object model extraction, as well as extension engine. This enables adding new types of trial data easily, while still ensuring compatibility with old trials where this data was not set. (Unas)
• Diff & Patch engine for JS objects to replace the complex and buggy BufferWrapper implementation. This new engine now powers the game save mechanism, as well as the new confirmation dialog checking changes made in the editor. (Unas)

Bugfixes :

• Issue #2 : Critical failure where, given a certain sequence of actions, The cocouncil End Frame could disappear and desynchronise with the editor layout. (Enthalpy)
• Issue #38 : Inconsistent ordering of trials in series. (Enthalpy)
• Issue #108 : Impossible to examine a default place. (Enthalpy)
• Issue #125 : Some old trials failed to be converted to the new format. (Enthalpy)
• Issue #155 : Presets could save an out-of-date frame (Enthalpy)
• Fixed German translation (ThePasch and Evolina)

And a bunch of others (#34, #83, #109, #122, #123, #127, #141, #146, #153).
Issue numbers reference the AAO issue tracker : https://bitbucket.org/AceAttorneyOnline ... ine/issues


As you see, no huge change yet for users; mostly a few comfort improvements, a lot of bugfixes and some technical changes behind the scenes.
Hopefully, however, those are the start for some interesting things to come - provided I don't disappear again !

Great to hear that constant progress is made. Keep up the great work, everyone!

Technically Unas, you fixed Issue #2. I just did a ridiculous amount of triage.

Hooray for the trial object model! The future, for those who are interested, now looks grey and sepia, with a chance of additional bug fixes and an improvement or two to the editor UI.

(Also Unas, mind looking at this pull request? The prompt asking you to save your trial is a little overactive.)

Whooops, thanks for the fix, that was a terrible mistake xD
It's funny how I can get rather complex algorithms right without much problem, and then be so distracted that I leave out a very obvious issue

That's awesome! Good job, everyone.

Was hoping for the scrolling to make its way into this update - hoping it's the next one, then!

I saw your PR, I will hopefully review it and merge it soon

I notice the editor actually seems to run a lot more smoothly now. Not sure if it's the update or my computer coincidentally handling the editor better. Either way, I'm liking this update, especially now that the color picker's been added. That'll make my life so much easier for finishing Turnabout of the Golden Witch.

Right, I'm not exactly sure where to post this, since I'm not even sure how to format this as a bug report, so I figured that since you're (actually) alive right now, Unas, that, I might as well post it here:

I've been having issues trying to play trials on AAO on Firefox right now (latest version), and it seems to be happening because of this:

NS_ERROR_DOM_BAD_URI: Access to restricted URI denied

Located on the style_loader, line 101. So, it seems to be trying to do an XHR request, but my browser doesn't like it at all.

Any idea what's up with that?

It means that my script picked up a CSS style in the page which does not belong to the AAO domain, so it cannot access it through XHR.

What this means is that you probably have something in your browser (maybe an extension, a userscript, or even an adware or something similar) that inserted an unexpected CSS stylesheet link into the AAO player page.
I guess I could update the style loader to avoid failing in such cases, but still, there is likely something wrong on your end

Hmm, that doesn't sound right though. I still had that happening to me when I disabled my adblock/noscript/Privacy Badger...

Since I took at look at kwando's bug a while back, I recall that when we checked the console to see what scripts were loading, the only CSS that loaded was from AAO. There were some oddities with one script in particular, as well as the order in which things loaded, but I can't seem to find the records from when I looked at it.

In the meantime kwando, it may be worth opening up the console, filtering for CSS and XHR, and tell us what you get.

(Also, do we have an expected time for the next update? For cases with lots of custom content, the bug that I fixed with #45 and was reported here is going to be very annoying.)

Yeah, checking again, the only CSS that the network is loading at the time is from AAO.

The error you have is raised by xhr before sending the network call, using simple policy checks on the URI, as far as I know.
In the terminal capture that you show me here, I see all files called through xhr in status 200, meaning that the xhr calls for all these files went without error.

There must be another file that my script attempted to load through XHR, but which is not displayed here. Maybe because the network call wasn't even attempted, or maybe because it's not even actually a CSS file...

If you want to investigate, put a debugger breakpoint on the xhr.send call (style_loader.js:101), and load the trial. The debugger will stop a number of times (one for each stylesheet it has to load) : each time, check the value of the originalUrl variable before resuming the run.
Then, give me the list of all the URLs that were attempted to load. In fact, in theory the last one should be the faulty one (if it triggered an exception at browser policy check time, it should prevent even sending any other after it) but in any case we can review the whole list.

OK, this is the list of URLS that are attempted to be loaded:
Ah, ok so it seems to be one of my extensions (Privacy Badger) that is interfering with the XHR loading... (Which is odd, considering I disabled it and it's something made by the EFF...)

But at least I have an answer to why now~ :P