This isn't revolutionary at all. The reason why that Back Air does this is because it uses an Angle Flipper value of 6. This has been common knowledge since at least 2015. The OpenSA Wiki is your friend.

oh, huh, thanks
though I wasn't trying to say this was anything revolutionary by saying "new avenue"
just that it's not something most seem to know about... at least from my perspective anyways
sorry for the confusion, I've edited the initial post to reflect as such.

it's definitely revolutionary for me though, when I've spent 3 years trying to find the answer XD

For those who don't know, Mr. Legend & Watcher is a god hack for Mr. Game & Watch by the author YellowWollywogOverload.

For a while I was puzzled at a random occurrence that happened while having a fun match against a Lv9 L&W CPU
I wasn't sure how, but L&W somehow managed to turn my character forward (facing the camera)


these images were taken back in 2017, and hardly anyone knew how to do this.
just over 3 years later, this mystery has finally been solved.

the move by Mr. L&W that does this is the backwards-areal (turtle)

now you can all enjoy a new avenue of Brawl hacking to venture down

EDIT: note that this is not revolutionary, just something I've not seen commonly talked about.

So apparently there was an issue where the word "l o s s" in my previous post was replaced by this comic:


While funny, I was left confused when my friend informed me because the comic didn't appear for me...
I had to log out or use Opera's private window to be able to see it.

The issue should be fixed now as I modified the previous post to state "reduced quality" instead of "quality l o s s".

EDIT: wow not even surrounding the word with text fixes the issue.

[262208]

just wanted to give a spoiler
I'm working on another revision for a real emissive map that actually works on the wii
will update the OP with the results once they work.

specs and current results:

I've had to lower the quality of the textures to reduce the file size greatly
though visual quality is still maintained

Pikachu_main:
from: 256x256 RGBA8 262208B
to: 256x256 CMPR 32832B + 256x256 IA4 65600B = 98432B

Pikachu_main_glow:
from: 256x256 RGBA8 262208B
to: 256x256 RGB5A3 131136B

Pikachu_eyes_glow:
from: 256x256 RGBA8 262208B
to: 256x256 RGB5A3 131136B

saved: 425920B

notes on formats
CMPR by itself only has 1 shade of alpha
I wanted to use I4 for the alpha format, but I can't seem to map color as alpha (if anyone knows a method, please tell me)

for alpha gradient:
RGB4A3 has 8 shades of alpha, which isn't a big deal considering they're glow textures
IA4 has 16 shades of alpha, which really looks good on the tail

but I'm a noob and screwed something up while merging the images in the TEV, and this happened:
(yes I had to duplicate the TEV and add another stage before everything)

lol yes I signed the cheek to prove it's a real emissive map X3

you can kinda see a few glitchy polygons for the body as well
I had my hopes up for this first test and they let me down (works in BrawlBox)
but of course, I am a noob so

I don't blame you if you don't want to see

[I refuse to call them shaders, because that's not what they are]

Decided to come out of my hole on Smashboards and make a quick guide towards dealing with emissive maps.

Now note, I'm by no means an expert on TEVs (I refuse to call them shaders, because that's not what they are)
in fact, I'm really only just learning about them...
Really all I'm doing here is just basic mapping which is very easy.
Harder stuff like bloom, while possible, I'm not sure how to do.

Just recently I released a new version of my signature hack Dark Pikachu version 4.6 which makes use of a fake (constant color Intensity) emissive map to achieve this without a memory overflow:


basically how this fake map works exactly is you have the emissive map:

and the color you want it to show in the material's Constant Color 2 (basically the image functions as an alpha channel for this color)

note that Constant Color 2 is delegated by the TEV stage applying the emissive map (stage1 in this case)
in order: stage0 | stage1 | stage2 | stage3

note that stage1 was added and is completely custom

it takes the output from stage0, adds Constant Color 2 * TextureColor, and clamps the result
stage0 just applies shading to the diffuse map (untouched from the original TEV)
stages 2 and 3 are for finalization (also untouched) (not too sure how they work)

now if you want to use a REAL emissive map like this:

all you need to do is change B and C of stage1 to multiply the TextureColor by the TextureAlpha: (rather than the Constant Color by the TextureColor like the fake one does)


I couldn't use a real emissive map at original quality because it would cause a memory overflow causing the Wii to freeze,
but I WAS able to get it working by downscaling the emissive maps by 50%
but here I thought the scaling would automatically apply the size difference and upscale...
I ended up being wrong, and as such, the emissive map is repeated here:

at least it works like it's supposed to

now note the entire image is green (including the transparent parts), so it looks no different from the fake version
but that's where the similarities stop as the fake version can't mix colors.

if you still need a little extra info as to how TEVs actually work, basically they just iterate over each stage in order and apply the equation noted in the Output Function.

here's a rough mock-up I did to help me understand Pikachu's TEV0:

note that the values supplied below the stage() function are just best guess values for testing
there's other stuff that could be done to it, such as comparison operations, but I never really needed that

so note that OutputColor is treated as a register with a default value of 0.0
Python doesn't inherently support vectors, let alone vector maths, so this was really all I could do without writing a complex vector class.
but the operations are still the same as what I have above:
(0,1,2) + (3,4,5) = (3,5,7)
(0,1,2) * 2 = (0,2,4)

for even more detailed information, you can follow BlackJax96's old notes here:
https://forums.kc-mm.com/index.php?topic=39649.msg801235#msg801235

hopefully this helps shed some detail on a topic that's not so well covered

EDIT: Update!
HOOOOO BOY this one took some real effort to get working:



so for the main texture, in order to optimize it AND make it look good, I had to separate the RGB and A channels
how I did that was a CMPR image for the RGB, and an IA4 image for the alpha:
RGB + A =
and then of course overlay the RGB5A3 emissive texture to achieve the glow

the reason I used CMPR+IA4 instead of RGB5A3 is because of the bit difference on alpha
RGB4A3 only has 8 shades of alpha
IA4 has 16 shades of alpha
and of course
CMPR only has 2 shades of alpha (GIF quality alpha)

so with CMPR I actually get ~RGB565 quality with a smaller data print
add 16 shades of alpha to that and the reduced quality is almost unnoticable

as a result of this, I had to write a separate TEV to merge the channels AND overlay the emission:

TEV0 is the original emissive TEV from the full RGBA8 version
TEV3 is the new version that references the alpha map in stage0, and applies it to the RGB map in stage1 before adding the emissive map in stage2 with the finalizations in stages 3 and 4

the material layout also adds the alpha map as a texture slot:

so yeah stage0 references TexMap2, stage1 -> TexMap0, stage2 -> TexMap1
(I wanted to keep compatibility so I wouldn't have to touch the emissive stage)

so yeah, REAL emissive map fully working in Brawl
here's the hack btw if anyone wants to play with it:
https://mega.nz/#!M0ASkSAa!Vj5T4I3A92uG5XGFTj3yoQ3TKEw3L7rX7eP7JLyQwQo
as well as the full quality version:
https://mega.nz/#!l4ZnzAQA!cHOYoJ2f-dUDa9fEkeiqY-k2jlL8f4ON7YXp-Zb1yPM
and the fake version:
https://mega.nz/#!Y9gjzKab!rVwEL5KIXDFUrUEwEIZCx9rLZotL81A67Ce_sMtHmJs
hopefully these serve as some good examples to help you guys get a feel for TEVs

just wanted to praise the python support
that caught me off guard.

glad to see some extendability brought to brawlbox.

I hope it's not ironpython though or you'll really be lacking in n areas of support. >.>

sorry for the late reply... I've had no internet since November...

I know the dev-version on copy doesn't work, there was actually a slight tragedy before I lost net...

but now... there's been alot that's been completely redone and ported,
but I still have yet to actually update copy.
I hope you guys have been following smashboards to stay updated.
(due to my position, I don't have all the time to update everywhere)

well... it's unofficial, and there's alot broken with it in terms of support, but you can download my repo if you like:
https://copy.com/DB24NZi4ejlxFo4I
MDL0 (Havok) needs a re-write... I'm getting no help with understanding my issue with the bones:

I'm also noticing not all weights are applied, same with this Melee trophy:

^not sure if that's the scripts or if it's actually something in my backend/transformer

and I've never gotten an answer to my question about how brawlbox handles invalid definition links...
Pachi for example has a vert-matrix primitive that references the definition ID of 2, which doesn't exist in Pachi's definitions.

also, I've done a little work on the transformer and fixed half of the Singular Matrix issues which comes from matrix inversion, however the other half is in the data verification, which is many times harder to fix...

so... yea... issues...

EDIT:
for some good news though, I've removed that annoying '...' at the top-left of the screen and sorted the file-browser directory list from A-Z, so that should be alot easier...

I'm currently trying to work on intellisense (code-insight) for SIDE
(I need SIDE to fix my MDL0 script, since nobody will help me)

[Post Merge: July 08, 2015, 05:28:45 PM]

been doing some major work on the backend...
got scripts to load in their own private namespaces.
I'll do the same with libs and even implement multiprocessing support in an update.
(multiprocessing means I'll be able to display the imported data while it's importing)

but yea, I'll have a method for registering lib-functions with scritps as well:


@ugeScript() # register with all script types
def libFunction( arg ): pass

@ugeScript( UGE_MODEL_SCRIPT ) # register with model scripts only
def libFunction( arg ): pass

@ugeScript( UGE_IMAGE_SCRIPT, UGE_PALLET_SCRIPT ) # register with specified scripts only
def libFunction( arg ): pass



also updated the loader to be more dynamic:

Loading scripts...

ugeImportModel(): 9
|   UMC_SES.py
|   HAL_Labs_DAT.py
|   MDL02.py
|   MMD_PMD.py
|   testBoneRel.py
|   Sm4sh_NUD.py
|   NTDO_MDL0.py
|   Wavefront_OBJ.py
|   HAL_Labs_DAT2.py
|
ugeExportModel(): 3
|   UMC_SES.py
|   PNG_Textures.py
|   Wavefront_OBJ.py
|
ugeImportImage(): 2
|   NTDO_TEX0.py
|   IMG.py
|
ugeExportImage(): 1
|   IMG.py
|
ugeImportPalette()/ugeImportPallet(): 0
ugeExportPalette()/ugeExportPallet(): 0
ugeDecompressor(): 0
ugeCompressor(): 0
ugeImportArchive(): 0
ugeExportArchive(): 0
Bad Scripts: 0

what this means is I'll now be able to extend script-type support (such as game scripts and logic) w/o having to update the loader.

still have yet to find the UT problem that's plaguing UMC's release though...
it's pinpointed to have something to do with the weights...
Post Merge: July 08, 2015, 05:28:45 PMsee update on smashboards
post-merge can suck itself.
Post Merge: July 10, 2015, 08:51:17 AM*removed post because it's not at the top of the page*

yea screw this, if you guys what updates, please visit my SmashBoards thread.

just for some news, here's for some support:
(yes I'm actually updating here first for once... lol)

who and all here remembers my blender script which could export bf32 vertices?
well, now I'm working on a script for UMC which can export more than the same data
more info here: http://smashboards.com/threads/zack-fair-tournament-legal-project.407245/#post-19483358

also, I'm thinking about including the 32bit header regardless of float or int formats (that way you don't need to tell people more info when schooling them on how to hack with UMC)

as far as melee vertexing, I can only hope it'll work well since Melee vs Brawl is global vs local vertices >_>


btw, anyone know someone who could help me fix my MDL0 script??
(my weight issue with Pachi is now affecting almost all weighted models)

WiiChannelTV data is supported
http://smashboards.com/threads/universal-model-converter-side-development-thread.334292/page-12#post-19475348

It's a damn shame no one posts here. You're doing some excellent work with this program.

aww man big thanks
don't worry, I still have yet to get anything on SmashBoards, VG-R, my forum, and the Mario Kart community (though I update the least there due to attitudes and behavioral problems)...
there's also alot of other forums who havn't responded.

but I know I've got alot of watchers

I deeply want to make this release so bad, but I can't until all issues are cleared.
at least updating the backend like this is making things easier to work on


I should also mention, I have a co-dev.
I mentioned him (Matt Sitton) before with the mac screenshot, but with no detail about him.
so yea, he's helping me get up to date with my python coding standards, and is also helping me make UMC more cross-platform with less issues.
(all UMC needs is portable python interpreters in their own isolated environments)
^this means you don't need to install anything

portable python (what I'm currently using which is windows x86 only) is only 18MB without it's Lib/ directory, but it includes all the base libraries and binary modules for things like tkinter and such

as for current progress on this, I've managed to get it running on all 3 of my machines (I've still got the font issue on my secondary compy) and also have it running on Matt's

the only problem I have with Matt is he's using a local python installation rather than UMC's provided interpreter.
the problem with this is alot of modules will be loaded from native directories instead of UMC's directories, which will cause alot of unexpected results.

so Matt's intending to work on a C-loader while I work on finding something more cross-platform.

I've looked into Pyzo, but that's python34 where I need python27
(copying the linux and mac interpreters would add roughly 300MB to the release due to the dependencies)

so yea, I've still got alot of work and cleanup to do.


for another thing I'm trying to do, there's this channel for Wii called Wii Channel TV or something...
Lars informed me about it and sent me the files.
the channel's data uses the same Hal Labs DAT format, but this time there's an interesting twist.
the format actually has string structures, giving it a pseudo string table just above the relocation table.
the format of this table is very similar to MDL0 strings, however, there's only a 1-byte pad string or perhaps a stop character.
(I'm guessing the stop character may only be needed if the hardware (Wii or WiiU) ignores the string size)

in any case, most structures are the exact same as Melee or Kirby AR, however I've run into an object structure who's "material offset" is 0x04 which translates to 0x24.
the structure at that location starts at 0x00 and is over 32 bytes...
so yea, it's causing my script to cough.

I havn't gotten much further than this, but I'm looking into it

EDIT:
now that I'm on my compy and not my WiiU, here's a few links

download and test UMC 3.0a: https://copy.com/gs8OGUauqMuQmjtl
you can start working on scripts if you like, but things are currently strict.
if you need help with anything, send me a contact request on skype explaining as such.

writing UMC-scripts is getting increasingly simpler as development continues with focus set on automation
(automation is the process of passing data to UMC with little to no use of variables)

example:

Code:

        weights_list=[
            array( [bu32,bf32], label=' -- [ [Bone_Offset, Weight], ... ]:' )( offset=WO+32 
            ) for WO in array( bu32, label=' -- [ Weight_Offset, ... ]:' )( offset=weights )
        ] if weights>32 else []

^would be easier to read with syntax highlighting
basically the code is a large 1-liner that reads nested arrays (in this case Melee bone-weight arrays)
it doesn't pass the data to UMC as the full definition of UMC's automation explains, but it's on it's way to doing so.

currently known issues with UMC:
- MDL0 is borked (need to redo the weights)
- other supplied scripts may or may not work correctly (I've intended to fix this but have been working on the backend support)
- UT transformation is borked (it's WIP but still doesn't properly transform)
- various functions don't work as have been advertized (havn't yet gotten to fixing or updating anything there)
- GUI laggs on large directories (I've explained this before but people don't seem to listen)


and for WCTV, here's the channel data: https://copy.com/gcFSKzb44SJyDGBZ
what is WCTV?: https://www.youtube.com/watch?v=4amHBKlj6Nw


EDIT2:
I was wrong about WCTV's strings, apparently that start character is part of the string, the string is terminated by 0x00

well here's an update
wrote a nice little hacky model script which exports all imported images as png images

I'll include this with the release

here's the script btw:

Code:

ugeScriptType(UGE_MODEL_SCRIPT)
ugeScriptFormats('PNG Textures', ['dummy'])

def ugeExportModel(T,C):
    while ugeImagesExist(Global=True):
        name = ugeGetImageName()
        ugeGetImageData('%s.png'%name, isfile=True)

probably my smallest script yet

[Post Merge: June 11, 2015, 08:57:59 AM]

so I've ported to GLFW... still havn't fixed the bone issue yet...

for exporting, the LRS is still as good as supplied if supplied in parent relation
the problem though is UT data can't be transformed w/o the matrices,
and I'm not getting or finding anything legit to build the matrices.
so I can't make a release until I can build the matrices properly.

I was using BrawlBox matrix building functions, but if you followed my SB thread, you saw how bad that was...
I'm now using the matrix building functions from transformations.py through _transformations.pyc using the slow numpy arrays.

anyways, so the port to GLFW now works on:

windows:

^ intel chipset not registering font textures (invalid value)

linux: (not sure about mint, APott has yet to test that for me)

^ screenshot tested on Xubuntu 14.04

mac: (Matt Sitton is working on a native python implementation with his screenshot here)

^ intel chipset not displaying the model textures correctly.

I'm also working on some minor GUI improvements.
porting to GLFW means only having to build my display lists once
(no more SDL deleting the display lists)
however, now my CPU usage averages around 75%


EDIT:
btw, I should also mention, this somehow works perfectly now:

Post Merge: June 11, 2015, 08:57:59 AM
fixed the CPU usage issue =)
apparently I was drawing roughly 1000 frames or so... lol

so I've limited the redraw to your primary monitor's refresh rate:
time.sleep(1./mode.refresh_rate)

the good thing about this is I can now re-implement 3D shutter display
(should work with BT/USB shutter glasses)

my CPU usage is about ~35% now with chromium and other things going

EDIT:
erg... forgot about the annoying post merge delay...
this is one reason I don't post here much >_<

Sorry for posting almost a month after the last post, but I want to state that in the time I was  absent this as really progressed a lot. Can't help on the progression side, but I hope you can learn whatever you need. It would be sad to see this project die.

haha, don't worry, I don't believe in dead threads

personally, I see nothing wrong with necro-posting...
it's not like a thread disappears from the internet just because it hasn't been posted on in 3 months.
lol
to me, dead threads create clutter, so why promote creating more clutter by posting another thread after one dies... why not just resurrect the old thread if you have the same problem or a solution for it, or just wish to post info... blah blah

anyways, don't worry about this project dieing, if I ever quit, I'm releasing my unfinished source with descriptions on my ideas...
but I've got too much to look forward to to be quitting on this project any time soon
I have too much hype and a burning passion for this project and everything about it.


many thanks for your concerns =3

not sure if I mentioned here, but UMC_SIDE might just make an appearence in the next release

I'm currently rebuilding the program to be developer-friendly (meaning friendly to me and my group), more efficient (no more array lookups for widgets), and much much cleaner.

by god, SIDE was probably my most dirtiest code, to the point I had to write an extension module for UMC 3.0
heck no, I've taken that and re-written a moddable decorator for UMC's API which is currently being built into 3.0a's API.

what this means is I can keep SIDE's code local to SIDE instead of putting a quarter of it in UMC.


I've also been working on much more automation tricks for scripts:

switch( bu8, { 0: '''#python code''', ...} )() #WIP

field( [1,7,15], bu8 )() #read bu8 bit-field
field( [1,7,15], bu8 )( [0,2,8] ) #write bit-field as bu8

there's much more I'm working on than that
I don't update much here though due to kc-mm restrictions.
please follow me where the big crowd is for the up-to-date stuff:
http://smashboards.com/threads/334292