What can PyWright do that AAO can't?

[GanonZD]

PyWright and AAO are trial engines with significantly different approaches and philosophies, both of which have strengths and weaknesses. While PyWright is much more advanced in terms of features and customisability, and uses a (in some cases) more efficient scripting format, AAO is strong in terms of format and accessibility to the end user through their browser. However, that does not mean that we cannot let ourselves inspire from PyWright. In fact, I suggest that one of the new goals of AAO should be to implement as many features as possible from PyWright, in order to be able to compete and allow for better conversion between the engines. Apart from allowing more advanced customisability, it makes sense to consider adding a scripting language (like Enthalpy's Catalysis or Jean of mArc's Text2Case, or whatever it was called) with official support, for those who prefer editing that way.

I have often looked into the manual of PyWright to get an overview of how it works. However, in order to get an actual impression of the difference in terms of features, you need more experience with both of them. So I would like to ask: Can someone list the features available in PyWirhgt, but currently lacking in AAO?

[AceAttorneyMaster111]

Scientific examination! I don't know any others. Ask ED.

[Calvinball]

I recall that custom UI are a thing in Pywright.

[E.D.Revolution]

Basically everything you listed in Towards v7 I can already do on PyWright. Everything

Okay, not everything. There are some stuff that even Py hasn't been able to do just yet. But here are some things I've been able to do on PyWright and some stuff that might be coming for v 0.989, since I *might* be taking over the development project. I'd need to hire a Python dev, though, since there are issues that have been slated for v0.989 but I have to push back to 0.990.

• Fully functional psyche locks. In my psyche locks guide, you may notice I said something about rewriting the code for psyche locks. Now instead of all convoluted shit regarding layering and such, you can call a simple macro to activate psyche locks, unlock it and whatnot cuz I took care of that.
• Customizable GUI. This one is a biggie for people who want to customize the experience for the player. I'm not going to say much, except play though a little bit of the PyWright version of ASA.
• The ability to move objects at any time. Hell, you can "hide" objects off screen and then scroll them in, WITHOUT the use of gifs. I should tell you that gifs are not supported, so they have to be converted to sheets.
• Checkmarks for conversations. And not just that, the ability to "forget" convos, for whatever need be.
• Perceive. Theoretically possible. saluk has put a barebones version in the examples that come with PyWright. I, however, did rewrite a lot of the code for authenticity and pragmatism. For example, you can see the "eye" looking at the bottom screen to look for the twitch. Pragmatically, I'd have to do two text boxes because it's nearly impossible to emulate the AJ DS version very well. I do have a working proof-of-concept. I am trying to work on a fully functional CE with perceive.
• The ability to customize the bottom screen. Oh so very much, especially for intros. And CE VS sequences.
• Smooth looping. The looping system on PyWright is done differently. Basically, have the intro and then the loop.
• The ability to control the volume of music AND sounds via codes/macros. Fade or no fade, you can control it via command.
• Customizable blips.
• Graphics fade in/out without the use of SVG, APNGs, or GIFs. Yeah, use a command and you can command X thing to fade in or out.
• Colored flashes. Yeah, that's always been there. Not just that, the ability to fade in a color via code as a "flash". Flaw: only works on text mode.
• Controlled shake. Unlike AAO version, the PyWright has two arguments: how long it should shake and how violently it should shake. If you only call one argument, it's the first one. For example, [#s100] would be the equivalent of {s 60} (in-text) or shake 60 out of text. Also, [#sb] is the same thing as {s nowait}.
• The ability to use "check" actions for evidence to do other actions, not just looking at pics, text or sounds. See Turnabout Substitution.
• Keyboard shortcuts. Always been there.
• Faster editing. Scripting methods will always be faster than GUI methods. The fact that you can save scripts and quickly restart a case to where you need to test is a big advantage of PyWright.
• Ability to disable certain investigation actions if not available. For example, if you are at a location where nobody's there, why should you have scripts for talking and presenting evidence?
• Ability to move the textbox around. So it's not just at the bottom of the top screen. Recall some scenes in AAI where the text box was moved to the top. This is possible in Py.
• Customizable nametags. Not just the name tag, the fonts used.

Things listed in v7 that are also not quite implemented in Py:

• AAI Investigations. Saluk has a barebones investigation going on. I'm not sure how I can improve on it just yet. All you can do is walk and bump into walls.
• Deduction. Actually, it is theorhetically possible via two actions: select an area and then present evidence. In an AAI context? Not yet, see above.
• Logic. Again, has barebones version as an example, I'll think of a way to improve on it later on.
• Logic chess. Very complicated. Plus, we need all the rips for AAI2, to pull this off correctly. Can't be done authentically for two reasons: different colored option bars are not possible and the timer system has to be reworked.
• Mood matrix. Theorhetically possible, actually, but not included in any examples yet.
• Thought route. See above.
• Luminol. This was on saluk's list of things to try to implement, but there's nothing so far according to his googlecode.

I'll add to this list any more stuff I can think of.

[TheDoctor]

I don't think it would be too hard to implement a bare bones version of Thought Route into PyWright. It's mainly the visual polish that would be lacking at first (like the floating text, the choices appearing on the top screen in a custom Thought Route GUI, and the semi transparent images floating by occasionally).

[E.D.Revolution]

If you could show me a proof of concept for Py, that'd be great. I'm mainly focused on doing stuff for AJ and AAI. And I still have to work on Case 2 for PyASA.

Now about competing with PyWright. The inherent flaw of AAO will always make it a hard sell for PyWright authors to convert to AAO. That it's becomes very cumbersome to edit and betatest in an efficient manner. The fact that AAO can be a very big resource hog and dependent on moving your assets to a place where you can store it and retrieve via hotlinking are two big sticking points, though github mostly solves that. Mostly. Plus, things don't run as smoothly as it does on Py. Plus, if a PyWright author has some advanced stuff, it'll be hard to convert in a way that is satisfactory to the author.

[Arivenzys]

I'm wondering : why not simply share the code of one to implement on the other ? I'm not really efficient in coding, but is it that hard to make a conversion between languages ?
Or maybe there is some private property stuff that block this king of exchange ?

[E.D.Revolution]

Depends. You have to know what the syntax for the scripting for PyWright really. (btw, coding and scripting are two different things).

Let's take a sample script of a simple sentence in PyWright.
"Hello!{n}I am Phoenix Wright."

In AAO, this would be translated as
"Hello!
I am Phoenix Wright."

Another example:
"Hello!{p30}{n}I am Phoenix Wright."
translates to
"Hello![#p50]
I am Phoenix Wright."

SImple so far, right?
Except when it comes to things like these:
"{f}{sfx Ding}Hello!{p30}{n}I am {sfx Key}Phoenix Wright!"
doesn't translate easily. Because there are two sfxes in that sentences, under the current AAO system, it has to be split into two frames.

I could go into a whole thesis as of why an automatic converter may not work well for AAO, but it's a complicated subject.

[Enthalpy]

Are you asking about converting the code of the PyWright engine to the AAO engine, or a PyWright game to an AAO game?

[Arivenzys]

Okay, I see the point, that's even deeper than I first thought.

And I was talking about converting between the engines, not games. But I guess implementing feature by feature wouldn't work that simply.

[E.D.Revolution]

Either way, engine to engine or game to game wouldn't be that simple. The code for Pywright is on google code. For AAO, you'd need a bitbucket account to even work on it. And the fact that Google code has to be git'd son...

[Enthalpy]

Now that we're clear on why shared code between PyWright and AAO is not a solution to the problem of PyWright having features that AAO doesn't...

I don't think that we need any more brainstorming of large features to add. We already have things to do, just to cite a few. Suggestions are valuable when they are acted upon, and considering how large this wishlist is, it's doubtful that suggestions would be acted upon any time soon. It would be a far better time investment to start migrating topics to the Bitbucket issue tracker, or to start working on development yourself, than to come up with additional suggestions.

[Arivenzys]

Actually, it was something I thought to be a solution to adapt the features of PyWright we wanted on AAO. But I agree it's certainly for the best to focus on what's on the forum.

[GanonZD]

We already have things to do...

I am quite honoured that you consider my V7 topic (named "already") a "thing to do". I thought the developers had hardly noticed it at all.

[TheDoctor]

One feature I noticed in AAOV6 is the evidence metadata section. PyWright doesn't have that, at least, not as far as I can tell.