Modding brainstorms

Put any ideas for modding here. Some of these might be useful for the Edition, others might become standalone mods. If you think something is definitely prime material for the Edition (beware "scope creep", suggestions that make the Edition cover more ground than it already does), then it can go HERE for review.

Upgraded content

Textures

High-resolution textures are highly welcome. --geyser

The environment could do with less dull colors, and the character textures have far too much compression/dithering. --geyser

Another challenge is to add reflectivity channels to all the "metallic" parts (characters, objects, environment). --geyser

Precipitation

What can we do with precipitation? The only precip. we see in the game is snow in the last level. What a tease! Can/should we add snow to other levels, or can we add new kinds of precip. like rain/sleet? --Iritscen

Isn't there rain in Rooftops? Gumby

Er, hmm, I guess so! Strange that I forgot that. Maybe it wasn't raining hard enough :-D Well, I still want to see more precip. Snow in particular has some nice possibilities, aesthetically. I guess I just need to know how it is produced from the binary data. --iritscen 02:12, 14 November 2008 (CET)

Precipitation is set up in PART. I think what you really want is for the rain drops (or hail stones) to deal damage. Heavier rain/snow is possible, but it could mean a lot of stress for the engine, depending on how much is "enough". Another problem with heavy rain and snow would be the lack of realism on the ground: ripples in puddles or footprints in snow would have to be implemented with character-emitted particles, puddles themselves would have to be set up from scratch... Sounds like a lot of work. --geyser 04:03, 14 November 2008 (CET)

Damaging precipitation is easy enough. Heavy rain is too much work, methinks, but snow could be done, maybe. Gumby

Retrograded content

It's hard not to notice that some stuff looked better pre-beta. Let's make a list and see if we can turn back time to give Oni back some of the pretty stuff it used to have. Look at the "Pre-beta content" page's screenshots for ideas, there's a heckuvalot of thing to remark upon there.

Models & textures

Muro's face was a lot nicer back when they made the 1999 trailer. --geyser

One can also see animated terminal screens in the trailer. That's currently very doable if you ask me. --Iritscen

Lighting

Barely visible in this shot from the trailer is a totally different wall down in the lobby. The lights actually appear to cast light on the wall (not dynamic, I don't think, but s clever imitation of it), as opposed to now, and generally the whole area is just 100 times better-looking than it is now (maybe I will get a comparison shot up here at some point). Can this be done with vertex lighting or some other means that doesn't involve re-writing the engine? --Iritscen

This is a beautiful shot of the early Lab. It shows just how good baked lighting can look. Now, I'm not saying we try to make the Lab look this way, because obviously the Lab is now seen in the daytime, not at night, but it shows what should be possible, particularly at night. --Iritscen

Weapons

Some people have noticed that there are some different weapons in some early art and/or screenshots. Want to bring those up here? --Iritscen

One thing I can definitely see was different is the gun used here; it's also got a laser sight! --Iritscen

General

TCTF HQ looked crazy better at one time; look at those sweet railings! --Iritscen by way of geyser

I'd like to see a clear shot of Damocles, because I think the concept art looked a lot better, but I'm not sure. If so, this is quite fixable. --Iritscen

Feast your eyes on the comparisons made here and tell me which looks better, the left or the right: Pre-beta_content#Syndicate_Mountain_Compound. Should we even be surprised at this point that the left is the pre-beta version? --Iritscen by way of geyser

Mapping

Someone really ambitious could try to recreate the missing levels that were in the pre-beta, if only for testing at the time, because there's some interesting designs there: Pre-beta_content#Pre-beta_levels. --Iritscen

New animations

Hi-yah!

Anyone want to try their hands at animations? New ones, not tweaked ones? How about giving Konoko some authentic martial arts moves? (Maybe more on this later.) --Iritscen

New characters

Ideas from geyser

Oni characters have a modular design one can take advantage of, by "swapping bones" and authoring all-new textures. One can thus create entities more or less closely related to Oni's original ones, possibly with new storyline roles (Ninja Comguys, BGI executives, cyborg enforcers, WCG troops... you name it: it's almost easy - if you're creative). --geyser

New/revised scenarios

"Reshuffled or upgraded binaries are worthless without some genuinely inventive level logic." - geyser

Taking advantage of savepoint slots

For one thing, Oni's levels allow for 10 savepoints each, which allows:

• either for more savepoints throughout a mission (possibly a lot harder)
• or savepoints that "revisit" a level (alternate missions and storylines)
• or non-mission savepoints like Oni Team Arena (and other such things) --geyser

Ghost possession

A script where Konoko can enter other's bodies and control them, leaving her own behind. This would be part of a new scenario where she has to accomplish some goal, but maybe she can't get into the area, so she leaves her body and takes over the enemy to get them to do her bidding. Picture her current body falling to the ground (we've got good anim.s to pick from for that), and a second Konoko that is ghosted (half-transparent) floats out (like floating ghost Shinatama) and moves through walls as you guide her, and when she touches an enemy, we use BSL to switch control to that character. If we were inventive enough, Konoko's real body could still be in danger while she's "astral projecting", and we could require the player to keep track of her body to make sure no one had discovered it laying there. Imagine running back to her body while in control of an Elite Striker, and beating up some fellow Syndicate dude that was beating on her! Could be a lot of fun if we don't make her body too hard to guard. And I think it all might be doable with scripting.
P.S.: It might sound silly or out of touch with the sci-fi setting of Oni, but this is a side script, it can do anything it wants 8-) Besides, we could always throw in some explanation of a pseudo-science nature, or have it be another dream. Heck, maybe it's an ability she gains from the Daodan in one possible future (at least, in her dreams :-). --Iritscen

AI improvements

Patrol paths

It is also essential to set up innovative patrol paths (redeeming stealth). --geyser

Ninja dodging

I don't know if this was a "manufactured" shot or not, but it's still awesome. Now, Loser has already gotten basic dodging working; what would it take to specifically get ninjas to either "ninja-slide" or jump as a form of dodging fire? Also, that jumping dude is really jumping. How would the game play out if the ninjas actually did have greater leaping ability than Konoko? It would make sense, wouldn't it? Especially if they're androids as some people like to think ;-) --Iritscen

NOTE: Ninjas actually jump higher than Konoko if they use "jetpack timer" powered jump as well (hold spacebar). According to my observations (only empiric - nothing proven) there is probably bug in AI2 code. AI2 computes distance of far jump as if char used jetpacked jump, yet AI2 for some reason CANNOT do more than tap jump.

Next, for AI2 "special" dodge - looks like AI2 is somewheat "vector" powered. And by than way, AI2 can only run/walk/creep. Acrobatics are MELEE only. If we had source....you know the rest.:--Loser 19:26, 13 November 2008 (CET) /NOTE

So it looks like there's two things worth looking into (second one may be too hard, I realize, but this is all hypothetical):

- Can we get AI2 to do more than a tap jump? (P.S.: Can ninjas actually jump as high as seen in that picture?) --iritscen 20:10, 13 November 2008 (CET)

- Are we sure that nothing short of engine patching would allow cool dodge moves? If the AI knows when it's being fired at, is there some way to add to the dodging routines links to the animations for side-rolls/slides and high jumps (for ninjas)? Actually, I thought a little more about what you said, and it seems that what I'm proposing here is impossible to do without actually altering code. --iritscen 20:10, 13 November 2008 (CET)

Ninjas do run/jump significantly faster/higher than Konoko, especially with the maximal body size factor. As for the jetpacking (an upwards acceleration), it's equivalent to lesser gravity, so just make the character-specific gravity factor smaller and you're done. --geyser 00:00, 14 November 2008 (CET)

Won't that mess up the speed at which the ninjas fall back down? Gumby

Not much. Anyway, it is very straightforward to tweak the tap-jump parameters (initial velocity and "gravity" acceleration) so that the AI behaves consistently. Like for the dashing, it is not clear whether the implementation is bugged or incomplete, and there is a workaround, so a "real fix" is not very likely or urgent right now. --geyser 14:07, 14 November 2008 (CET)

Hypothetical features = real scope creep ^_^ As for flashy dodging, there's more to an implementation than "patching" the engine: in order to figure out just what needs to be rewritten and how, you need the source. Or rather Loser needs the source. Get the source, give it to Loser, and then Just Watch. --geyser 14:07, 14 November 2008 (CET)

Riddles for engine patchers

Dynamic holstering

Combat situation and owner's weapon based. Customized for each weapon. That means:

-new flags in CMBT file. It has "melee override" so far, used values are 0,1,2 (cancelled),3,4,5. New values should be counterparts of these ( long (6) medium (7), short(8) ), but causing AI to holster/unholster weapon rather than switching melee/weapon stance.

-new flag in ONWC file. Currently there are some (appearently) unused flag bits which should be used for this.

-Add new flag. Weapon with this flag causes AI which wields this weapon to unholster when focused enemy is knockdowned, even if it is in range where our AI should have weapon holstered according to CMBT. Holster again when focused enemy goes into any different animation than knockdowned, blownuped or lying (so AI holsters as enemy tries to getup). -- Loser

I don't understand some of what you propose above, it's very brief and technical; are you saying that you want AI to be able to shoot someone when they've been knocked down?

I may not understand what you wrote, but it made me wish, for the first time, that I could unholster a weapon while knocked down, and shoot the enemy before I got up. That would be an awesome combat technique. Characters already have a small arc of rotation when on the ground, for some reason, so what if they had a gun in their hands and could aim with a vertical arc from the ground to the ceiling, and with a limited horizontal arc similar to what they seem to have already? --iritscen 20:10, 13 November 2008 (CET)

Brilliant idea !!! Somebody should check whether it is possible. Sorry, I cannot...x_X

About that you don't understand: old wish of mine. Three wishes in fact.

• 1) You see AI character. Unarmed. You run to fight it (no stealth killing). AI2 hears you when you are still quite far, turns, UNHOLSTERS ITS MERCURY BOW (or any other weapon) and....^_^.
• 2) You see AI shooting at you with w3_phr. You dodge shots while approaching this enemy, but at certain distance, AI HOLSTERS ITS WEAPON (not holding it in hand) and fights with you. If you try to run away or somehow you cross requred distance, AI unholsters and fires again.
• 3) You fight with AI from case 2). This AI manages to knockdown you. Now when you enter knockdown animation, AI automaticaly unholsters its weapon and fires at you. You get up as quickly as possible. The moment you start getting up, AI holsters and continues fighting you with MELEE. -- Loser

Ah, I see, that is a good idea. --iritscen 20:45, 13 November 2008 (CET)

Smart jumping

Add this as flag in ONCC. If set, this AI tries systematically (not MELEE randomly) to jump across gaps it can pass in order to reach its enemy. -- Loser

Unsticking bug

Yes, I know that Neo never gets this one, but I do, and geyser, too. Type a cheat into the pause window, and the camera goes flying away as if you pressed "]" in dev mode. I believe it is caused by some sort of overflow in the cheat buffer. The buffer is not cleared when you close the window. For example: type "live", close the window, open it again, type "forever". I got it to bug up by typing random gibberish, too. Clearing the cheat buffer when you close the window might fix the problem. If someone (Neo?) who knows more about these sorts of things could comment, that would be great. Gumby 21:10, 15 November 2008 (CET)

A question and a fact:

1. Gumby, is there any reason why you are calling this effect "unsticiking"? There is no mention of "unsticking" in the engine apart from the unstick keypress event, which I think corresponds to Ctr+Alt/Shift+U (because it indeed "unsticks" a "stuck" character).
2. Once and for all, I'd like to stress that it is not true that "the camera goes flying away". What happens is that the character drifts away, the velocity being frozen. The character is not rendered during the drifting. If you jump, the camera fails to drift up.

geyser 00:14, 16 November 2008 (CET)

Ok, then what should I call it? Bug-induced-derendering? Gumby 04:52, 16 November 2008 (CET)

The drifting caused by ] can be called "the ] bug/feature". As for the thing you're trying to fix, when and if you're sure the problem is with the cheat buffer, then I'd call it the "cheat buffer bug", intuitively enough. --geyser 05:23, 16 November 2008 (CET)

Miscellaneous tweaks

Sneaking

Ever since I first played Oni and was told by the game that I could not be heard while sneaking, it's bothered me that Konoko's heels still made just as much noise while crouch-walking as they did while walking or running. Click-clack, click-clack, all day every day. That makes no sense! Am I the only person who's annoyed by this? The only question is, how hard is it to fix? --Iritscen

If the sound for running is different from the sound of crouchingwalking, just export+lowervolume+import the footstep sound. Gumby

Yes, the sounds are different, and no, there's no need to export-import the SNDD. Just tweak the OSGr. And yeah, 'scen, you're pbly the only one ^_^ --geyser 13:13, 14 November 2008 (CET)

Click-clack

A more general problem is that the Medium and Heavy variants don't sound softer than Konoko's footsteps, as if all the footwear had very hard soles, not rubber or plastic. The only way to fix this is to add some Impt, extend the ONIE, adapt ONCC, and tweak/(re)author OSBD and/or SNDD. --geyser 13:13, 14 November 2008 (CET)

Unlocking the first door

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)

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)

I dislike the current console behavior. You can just backbreak them as they use the console. Not sure what the best fix is though. Gumby 06:12, 22 September 2008 (CEST)

Superfluous fly-ins

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)

breakable glass tweak

I don't know whether it would be too much for engine or not. Due to the fact we can import level geometry (incomplete so far, I know, but still...) what about modifying breakable windows, giving them more GQs.

Point is that then big glass panel would not be fully shattered because one small bullet from w1_tap hit it in the corner (only corner is shattered), while bigger blasts (w3_phr, w5_sbg) would destroy larger area of glass panel or whole panel.

I can see one bug tough - shooting edges of such a glass panel will make it "float" in the thin air. --Loser 13:25, 15 November 2008 (CET)

Heh, that bug alone is a good reason not to do it in the way you suggest. Also, if "only the corner is shattered", surely, the shattered section won't be rectangular? The only thing that will look good is a dense curtain wall: little glass panels and criss-crossed beams between them; but then you'll complain about grenades and such not damaging the (thin) framework ^_^. There is an alternative approach - to somehow make some projectiles go through glass without breaking it (basically creating a decal and moving on). I'd say that's definitely possible. But - scope-creepy ^_^ --geyser 00:14, 16 November 2008 (CET)

Just a reminder that this page isn't about what should be in the Edition; that page is here. This page is for items that may or may not be in scope for the AE, but even if they aren't, could still be done separately from the AE. In other words, people can suggest anything and everything here.

In response to this idea, I am actually happy with the glass as it currently breaks; it's fun to watch a whole pane collapse at once, although I don't know how realistic it is. The one thing I find odd in the area of weapons vs. ordinary windows is that the SBG's shots either explode when they hit glass, or bounce off it, if you hold the 2nd trigger. I'd like to see them break the glass and keep on going. --iritscen 00:32, 16 November 2008 (CET)