AE:Bug-fix and feature requests

This is a place for suggesting fixes for the AE or improvements that the AE can make to original Oni.

Iritscen

This might be a timely initiative, but if we are going to make this work at all...

• please sign every line, and make sure all the stuff stays signed after edits
  • at least when you "vote" or say something subjective, you have to sign
• try to be very specific about what you want fixed or added; lazy users suck
• if you have the resources to systematically investigate on the matter, do so
• avoid long, non-factual discussions; if you can't, put them on the talk page
• make sure the list doesn't become overwhelming by lack of tangible follow-up
• KISS and remember that not all of us have the time or desire to argue back

AE has ugly-ass scope creep ATM (probably my fault); let's not make it worse.
Surely we can point out a ton of details that somehow "need our attention"...
But that would be part of the problem rather than part of the solution, I think.

geyser 05:22, 22 September 2008 (CEST)

Improvements on original Oni that AE can make

Cutscene cleanup

Unlocking doors

The very first door-unlocking console in the first room in CHAPTER 01 . TRIAL RUN: why does it not show the door unlocking? This was confusing for me as a newbie ("What did I just do? Let me wander around and try to notice that a tiny light changed color.") and still doesn't make any sense. I mean, they don't even tell you in training that doors can be unlocked by consoles! All the other doors are scrupulously shown unlocking when you use the appropriate consoles, even when they're like five feet away from you, but yet the very first one isn't shown unlocking. --Iritscen

(How typically verbose...) This scene indeed deserves a custom OBAN and/or a specific door-unlocking sound. However, you shouldn't exaggerate the confusion of the first-timers; clear message if they overlook the console and go straight to the door, only one way out anyway, perfectly explicit door-unlocking soon afterwards... --geyser 05:22, 22 September 2008 (CEST)

Passive enemies

When Konoko runs out the door at the end of CHAPTER 02 . ENGINES OF EVIL (and on to CHAPTER 03 . PUZZLE PIECES ), there is (at least sometimes) a Striker standing right there as the camera pans by! The scripting should be deleting all baddies before this cutscene. --Iritscen

What Striker? right where? sometimes when? Could it be "febtober_striker_1" (sorta Easter egg), or "flyway_striker_1"? I know ai2_shownames is broken in the Mac version, but who and ai2_report should work... And at the very least, you can identify the weapon he's holding, if any. --geyser 05:22, 22 September 2008 (CEST)

Moving enemies out of Konoko's path is sensible (more generally, the AI often look awkward when "passive" during a cutscene), but it would also make sense for "baddies" (either surviving Strikers or Ninja or BGI) to observe Konoko during that cutscene, from where Konoko can't see them, G-man style. --geyser 05:22, 22 September 2008 (CEST)

Smart alarm behaviour

Loser wanted to make the AI attack you even when trying to get to an alert console. I don't think he made any changes in that regard yet, but I was chasing down a ninja Comguy who wanted to push the alert button, and when I got in his way, he *did* attack me. I think that further increasing the likeliness of the AI to attack you while in run-for-alert-console mode is not necessary, and maybe even a bad idea, since they can now dash as fast as Konoko, and so it's much more exciting/frightening when they run for the console. Staying and fighting would make them less of a threat, really, since after pressing the button they will fight you anyway and then you will also have other problems to deal with too. So I vote for "no change" in this regard. --Iritscen

"This is a mistake". The point of Loser's aproach is that AI will interrupt their console-running job only when the player is about to take advantage of them (e.g., tackle them - Konoko still dashes faster than anyone except for Ninjas - or backbreak them at the console). They will then resume running as soon as they've put some distance between them and the player (e.g., by knocking the player down and/or retreating). This should much more consistent than the way it happens with the original AI: if you force a console-running AI to fight back, they typically won't resume the alarm-running job when they have the chance. --geyser 05:22, 22 September 2008 (CEST)

Cinematics

Why on earth does Oni use fly-ins when the characters are onscreen? Times when it's not okay include the Muro-Barabus cutscene in Ch. 2: they're right there in front of us, but also have their portraits in the corners. Blah. If you say, "Well, this lets us see them better", (a) we don't need to be reminded that Muro doesn't look like his portrait, at least until he's fixed, and (b) the smart way to show us what they look like is to use close camera angles, not just hanging back and showing them from a distance; portraits are superfluous. On the other hand, a time when it's definitely okay: opening cutscene for Ch. 2, when Konoko's teeth-gritting portrait is shown as the ambush begins. See, that's a good use of portraits. --Iritscen

See, that's a bad bug-fix and feature request. Subjective/ironic (does (a) even look like an argument?), and awfully unspecific for its game-wide scope. Blah. The current approach may be flawed, but it is systematic: lips don't move, body language is limited, so every line of dialogue is considered a voiceover. The only consistent substitute would mean a full-scale change of design (for example, the fly-ins could be elaborate comic/manga panels contributing to the composition of the scene, rather than sketchy miniatures in a corner). Also, using "close camera angles" on Muro or anyone is a bad idea "until he's fixed": as long as the textures are posterized and there's nothing in terms of facial animation, the best bet IMO is to keep the camera far away from the characters or in their backs, and to complement those shots with fly-ins. Anyway, your request struck me as half-baked. --geyser 05:22, 22 September 2008 (CEST)

Widescreen

Various widescreen fixes are needed. For example when playing in a 16:9 resolution at the start of level 3, the camera is positioned behind a wall, in the Dream Lab level the photos in the opening cutscene can be seen before the animation starts and when playing in a 16:10 or 16:9 resolution in the Compound level, Konoko can be seen on the ground before she lands O_o. --Rossy

I noticed while perusing Daodan-C's source code there was a "/* widescreen patch for talking heads */". Would that fix it? --Gumby

I believe that the "widescreen patch" is a specific workaround that fixes only the "cinematics". See HERE for a more general fix. --geyser 05:22, 22 September 2008 (CEST)

Evil TCTF, or Explain This Odd Behaviour

I don't know if this has already been fixed, but in my copy of Oni, there is a civilian in TCTF HQ that is set to the wrong team so good AIs attack her. --Rossy

Is it the woman on the first floor in the side room with those wide long pieces of machinery in the middle of it? --Iritscen 14:11, 20 September 2008 (CEST)

I think so, yeah. --rossy 03:32, 21 September 2008 (CEST)

I'm not too sure what to think about Iritscen's commitment to specificity... If it's a_v1 you're talking about, there's nothing long or wide about the computer in her room. And if you mean lobby_victim06, the floor she's on is not "first" in any way. Oh well... the point is, all those civilians, female or not, are in their typical Neutral team, and the TCTF AI won't attack them unless there is a glitch. The glitch is apparently due to some confusion in the awareness/knowledge/whatever system: apparently, if the TCTF see an enemy and a civilian "at the same time", they tend to label them both as hostilethreat. TCTF HQ is the only mission where TCTF can be seen around civilians after seeing them with hostiles and defeating the latter. The same glitch happens with TCTF VS SecurityGuard, and probably with Syndicate VS SyndicateAccessory. Custom scripts based on OTA could help investigate this bug more systematically. From a more practical point of view, the glitch can be fixed with timely calls to ai2_forget. --geyser 05:22, 22 September 2008 (CEST)

Glitches in the animation system

Furies

The Furies have a transition glitch from combat idle to sidestep left and right. (Vid shows non-combat idle at first.) --Dox

Looks like the other way round to me: the visible glitch is when she goes from sidestep to combat idle. Note that the sidesteps are KONCOMss_lt_1stepa/KONCOMss_lt_1stepb and KONCOMss_rt_1stepa/KONCOMss_rt_1stepb. They're supposed to be overridden by REDCOMss_lt_start/REDCOMss_lt_stop and REDCOMss_rt_start/REDCOMss_rt_stop, but somehow are not. The flaw can be either in TRACred_animations, or in the REDCOM TRAM. --geyser 05:22, 22 September 2008 (CEST)

Ninja

After creeping forward with a pistol, the Ninjas somehow interpolate to STRCOMcrouch_idle instead of NINPIScrouch_idle, then switch to NINPIScrouch_idle after STRCOMcrouch_idle has played once. The flaw can be either in TRACninja_animations, or in the NINPIS TRAM. --geyser 05:22, 22 September 2008 (CEST)

Aiming screens

The shoulder joints of males look awkward for rifle aiming, and more generally extreme aiming angles look funky. This could be fixed by editing or adding keyframes in the aiming screen TRAM; however, there is still no reasonable pipeline for that. --geyser 05:22, 22 September 2008 (CEST)

Another issue is that KONRIF side rolls use an aiming screen. On one hand, it allows her to keep shooting while in the middle of a roll, which is cool. On the other, the weapon stays upright when aiming and rotates 360° through Konoko's fist, which is uncool (of course, it only shows up in slowmo and/or side view). There is no solution apart from disabling the aiming screen on KONRIF side rolls. --geyser 05:22, 22 September 2008 (CEST)

Miscellaneous

The security guard's lines in the State building are kind of silly. "Stop, or I'll shoot". He shoots no matter what you do...>_> --Gumby

Konoko is a "class B threat" wanted dead or alive, who stays defiant in response to the warning, so his "screw this" attitude is understandable... However, it is rather straightforward for a scripter to freeze the action until the player actually "moves a muscle". Another detail is the backup the guard called for; maybe he didn't alert the whole building, but some kind of backup ought to be on its way. --geyser 05:22, 22 September 2008 (CEST)

---

Suggestions for next version of AE

Dashing AI

AI dashing hack applies to Konoko; she should be allowed to run again. --Iritscen

I've implemented this as a plugin for you to test, for the time being. --geyser 05:22, 22 September 2008 (CEST)

The remaining dashing problem is with FILM sequences played back by AI in cutscenes: if they used to run, they now dash and end up off course. There is no simple fix to this. Ultimately, someone has to either rescript the cutscenes so that they use ai2_movetoflag instead of playback or chr_playback (new flags may need to be set up, but pathfinding will probably be OK as is) or reauthor the FILM sequences. Both are feasible ATM, neither is much fun. --geyser 05:22, 22 September 2008 (CEST)

Domino knockdowns and fistsoflegend

fistsoflegend is still broken. geyser indicated that knockdowns might be optional in the final release, but the question is, "Will using knockdowns always break fistsoflegend?". --Iritscen

0) Didn't fistsoflegend suck anyway? 1) I can see there being no such thing as a "final release". 2) Knockdowns will be optional, that's not an option ^_^ The question is whether they will be fixed. If we can prevent spurious domino knockdowns (I believe we can, but maybe Loser knows better), then there is a chance that fistsoflegend will be redeemed. --geyser 05:22, 22 September 2008 (CEST)

Other feature requests

Modular installation

In the final Edition installation process, we need to separate the harder combat mods from the overall improvement mods and make the harder combat mods optional. You probably already plan on doing this, but I felt I should just verbalize it so it's on record as something that's A Really Good Idea. --Iritscen

The problem is the lack of clarity on just what difference (and/or interplay) there is between "overall improvement mods" and "harder combat mods". It's not always easy to decompose the modded content into modules, all the less so as some resources are affected by unrelated mods. This interference is virtually impossible to resolve in the case of free-for-all modding, but with a centralized packaging it should be feasible (barely). --geyser 05:22, 22 September 2008 (CEST)

AE:Glass

Are the breakable glass (i.e., kicks break glass), damaging glass, and the glass collision (body hitting glass breaks it) mods in the Edition yet? I have glass mods installed separately so I can't tell. I didn't think they were part of the Edition, but I see a PAR3 glass particle is in the Edition files, so I'm not clear on what's been changed. --Iritscen

I would love to see the RIF melee animations given glass-breaking status too. It only makes sense that if Konoko can kick glass out, hitting it with a big weapon in hand would also do the trick. Maybe a pistol would as well. --Iritscen

Damaging glass is in the Edition (hence the modded BINA3RAPglass_shard), but with a minor damage amount. There is no difference between what you call "glass collision" (or "improved physics") and "breakable glass". Glass particles are absolutely not involved here; it's all about explosive events (known as "glass charges") attached to body parts, either as standalone particles or as part of glows/contrails/whatever. Ultimately, such particles should be assigned to every body part that has enough momentum to break glass. This implies specifically modding particle tracks of every other TRAM in Oni, which is a lot of work. If custom particles are involved, this also implies setting up these particles and adding them to the ONCP of all the characters. I never attempted such an extensive mod: the glass-breaking combos I released to the public early on either used explosive dust (a dirty hack if there ever was one) or enabled glass-breaking for contrails, with no TRAM-specific or ONCP modding in either case. Loser apparently has tried to produce something more systematic, but "I" have yet to assess it and adapt it for a release of the Edition. --geyser 05:22, 22 September 2008 (CEST)