test

Sick markup

"And now for a lesson in [ttttttttttttemplate] mmmmmmmmmanagement... [wikiwikiwiki] llllllllllllet's begin..."

Linkin Park, Cure for the Itch

geyser, deprived of laptop and ICQ for a while ^^ ... which explains the "born to nag" attitude.

Foreach

29 Bit CAN-ID
Template:ProtokollTabelleDef	Template:ProtokollTabelleDef	Template:ProtokollTabelleDef	Template:ProtokollTabelleDef

That solution is universal, and sorta authoritative, but it takes ages for the engine to evaluate : in any given situation, one should probably prefer a lighter, more specific solution.

How about this?

29-Bit CAN-ID

Note how 1-bit, 2-bit and 3-plus-bit chunks are all handled by the same (small) template ^^

TightTable takes "optional" arguments called align and color. They're not really specified as optional, but when not provided, the relevant syntax gets screwed up "the smart way".

The "skipped bits" span of every chunk is specified in pixels, which can be handy in case one wants a more compact layout. The non-breaking space can then be replaced with a "..." to avoid confusion.

I think the skipped widths are best let custom, as well as the "header". Apart from arbitrarily shrinking the skip fields, one may want to rephrase the header, or omit it, or make it a caption :

29-Bit CAN-ID

(again, maybe a "..." in the skip fields would look nicer)

(and a non-breaking space in front of the description, in the template)

Arithmetics (will only show fine when and if #expr parsing works OK...)

One can calculate the width of the "skipped bits" internally, only feeding two bit IDs to the template.

The template would then evaluate the difference, and decide upon a 1-bit, or on a 2-plus-bit layout with an adequate skip.

However, the markup is a bit heavier, and makes a few assumptions about e.g. the order in which the bits are listed (unless one wants to emulate abs, which is a little bit heavier still).

Right now, it produces a fatal error parsing Expr.php (then again, so does {{#expr:2+2}}, so there is a problem), but it would look something like this :

{|{{TightTable|color={{{4}}}}}
|-align=center
|width=18|{{{1}}}
|-
|width={{#ifexpr:{{{1}}}>{{{2}}}|{{#expr:18*({{{1}}}-{{{2}}}-1)}}|0}}|{{#ifexpr:{{{1}}}>{{{2}}}+1|...|}}
|width={{#ifexpr:{{{1}}}>{{{2}}}|18|0}}|{{#ifexpr:{{{1}}}>{{{2}}}|{{{2}}}|}}
|colspan=3|{{{3}}}
|}

CAN-ID table

It could be possible to embed the chunk tables into a big template table specific to the "29-Bit CAN-ID" usage, but most components would have to be in HTML. Bad idea.

---

---

OBD file types

0x000 :	26	00	33	00	40	00	4D	00	5A	00	67	00	74	00	81	00	8E	00	9B	00	A8	00	B5	00	C2	00	CF	00	DC	00	E9	00
0x020 :	F6	00	03	01	10	01	5F	45	F9	3D	B6	FA	09	5F	45	F9	3D	B6	FA	18	39	1B	34	88	77	09	18	39	1B	34	88	77

Heh.

Type	Description	Notes		Type	Description	Notes		Type	Description	Notes
3CLA	RGB Color Array			KeyI	Key Icons	L0		StNA	String Array	L0

Type Description Notes 3CLA RGB Color Array ABNA BSP Tree Node Array L AGDB Gunk Quad Debug Array L AGQC Gunk Quad Collision Array L AGQG Gunk Quad General Array L AGQM Gunk Quad Material AGQR Gunk Quad Render Array L AISA AI Character Setup Array L AITR AI Script Trigger Array L AIWA AI Imported Waypoint Array AKAA Adjacency Array L AKBA Side Array L AKBP BSP Node Array L AKDA Door Frame Array L AKEV Akira Environment L AKOT Oct Tree L AKVA BNV Node Array L BINA Binary Data S CBPI Character Body Part Impacts C CBPM Character Body Part Material C CONS Console L0 CRSA Corpse Array L DOOR Door L0 DPge Diary Page L0 EDIA Edge Index Array ENVP Env Particle Array L FILM Film - FXLR FX Laser Effect GMAN Geometry Animation HPge Help Page L0 IDXA Index Array - IGHH IGUI HUD Help L0 IGPA IGUI Page Array M IGPG IGUI Page M IGSA IGUI String Array M IGSt IGUI String M Impt Impact Tree C (0B) IPge Item Page M

Type Description Notes KeyI Key Icons L0 M3GA Geometry Array - M3GM Geometry - M3TA Triangle Array Mtrl Material (0B) NMSA Network Spawn Point Array OBAN Object Animation - OBDC Door Class Array L OBLS Object LS Data OBOA Starting Object Array L OFGA Object Furn Geom Array L0 ONCC Oni Character Class C ONCP Oni Character Particle Array C ?! ONCV Oni Character Variant C (0B) ?! ONFA Imported Flag Node Array L ONGS Oni Game Settings L0 ONIA Oni Character Impact Array C ?! ONLD Oni Game Level Descriptor L0 ONLV Oni Game Level L ONMA Imported Marker Node Array L ONOA Object Gunk Array L ONSA Imported Spawn Array L ONSK Oni Sky Class L ONTA Trigger Array L ?! ONVL Oni Variant List L0 ?! ONWC Oni Weapon Class L (0B) OPge Objective Page M OSBD Oni Sound Binary Data L0 OTIT Oct Tree Interior Node Array L OTLF Oct Tree Leaf Node Array L PLEA Plane Equation Array L PNTA 3D Point Array - PSpc Part Specification M PSpL Part Specification List L0 PSUI Part Specifications UI L0 QTNA Quad Tree Node Array L QUDA Quad Array SNDD Sound Data -

Type Description Notes StNA String Array L0 SUBT Subtitle Array L0 TMFA Float Array TMRA Template Reference Array TRAC Animation Collection C TRAM Totoro Animation Sequence C TRAS Totoro Aiming Screen C TRBS Totoro Body Set C TRCM Totoro Quaternion Body C TRFT Totoro Facing Table TRGA Totoro Quaternion Body Geometry Array C TRGE Trigger Emitter L0 TRIA Totoro Quaternion Body Index Array C TRIG Trigger L0 TRMA Texture Map Array C TRSC Screen (Aiming) Collection C TRTA Totoro Quaternion Body Translation Array C TSFF Font Family M (0B) TSFL Font Language L0 TSFT Font L0 TSGA Glyph Array L0 TStr String L0 TURR Turret L0 TXAN Texture Map Animation - TXCA Texture Coordinate Array - TXMA Texture Map Array L TXMB Texture Map Big - TXMP Texture Map - TXPC Texture Procedure Data TxtC Text Console M UUEA Error Binding Array UVDL UV Data List VCRA 3D Vector Array - WMCL WM Cursor List L0 WMDD WM Dialog Data L0 WMM_ WM Menu L0 WMMB WM Menu Bar L0 WPge Weapon Page L0

Templates

• Template:Data screen

ONI BINARY DATA AKVA << Other file types >> CBPI BINA : Binary data switch to XML:BINA page Overview @ Oni Stuff

ONI BINARY DATA
AKVA << Other file types >> CBPI
BINA : Binary data
[[OBD:File types/{{{family}}}|{{{family}}} file]]

HexRow

0x00:

01

51

02

00

01

00

00

06

AD

DE

AD

DE

AD

DE

AD

DE

Who needs this?°

0x10:

AD

DE

AD

DE

AD

DE

AD

DE

AD

DE

AD

DE

AD

DE

AD

DE

°°°°°°°°°°°°°°°°

---

Oni 2D

Motivation

It all started with Prince of Persia. I mean the really old one, with monochrome graphics.

Then there have been great 2D shooters like Flashback and Abuse and Super Metroid, as well as melee-oriented beat-them-up platformers, more or less inspired by Street Fighter gameplay.

Right now, be it on PC, big consoles or even little portable ones, we just don't see any platformers. 3D action is all the rage.

Oni 2D is about reviving the 2D platformer genre. Flashback was great (and had much in common with Oni, actually). Super Metroid and Abuse were great. There was a great action/quest mix for Flashback and Super Metroid. Abuse was pure action, very much like the DOOM of 2D platformers, and it had a really nice mouse-aiming system.

Take Flashback, add Abuse's mouse-aiming gunplay and an Oni-like melee component, throw in hi-res graphics and the power of today's hardware, and you'll have a little retro-revolution. Fast, playable and beautiful.

Feasibility

• Platformers are relatively easy to code, they run fast, and can readily use Oni's resources
• Recording Oni's animations live against a transparent background can be done pretty fast.
• Same for the background: it won't take much to create a 2D world with textures extracted from Oni.

For a start, we can just reproduce some of Oni's levels in side view. But 2D level design is, again, much easier than 3D level modeling, so we can get totally new content (close to an actual game) really fast.

KonokoPayne may be great, Oni++ and Oni 2 may be great, but Oni 2D, properly managed, may give us the first actual opportunity ever to fight an Iron Demon.

Wanted

• Resource extractors. Level textures are piece of cake. The major work is on character animations : rendering them in side view from within KonokoPayne is an option, but the easiest way is to do it from within Oni, with standardized perspective and resolution, and no background.
• Game content. Levels, mostly. And character interaction. The way combos and throws are handled in Oni (range, damage etc) must be carefully analyzed and made to fit 2D gameplay (relatively easy).
• The engine/code, of course. Well, I'm looking into that right now. I'm looking into a lot of things right now.