>>16941
You (should) have read and write access to the repository now.

>>16940
No not yet. Gscot's lastest comment didn't have anything about a date but did indicate that it is still being worked on.

>>16936
Give it time, I was really interested by sago's experiment and do want to implement that.

>>16937
I don't know why someone got offended by that, though it seems that person doesn't post here or I didn't make myself more clear. This template version is heavily inspired by Konashion's SDT and is the basis for how it is designed. When the thing is finished, Konashion is getting put in the credits under special thanks.

>>16938
Thing about that is the work being done now will make it much easier for new characters and animations to be done in the future. Ideally, there would be no need to rely on a extremely small amount of people for changes. If someone wants to, they'd be able to do modifications themselves or have someone from a much larger pool of artists do it. It also reduces the amount of work needed on animations, since the creator could focus on just the animation and it'll work for all characters added, even custom ones. Otherwise, they'd need to maintain a number of copies of the same animation, one for each character and this wouldn't (easily) allow for custom characters

I know this is taking a while and there is a demand for new content but when ppppuNX is feature complete, you will hopefully see that it was worthwhile. Hopefully Gscot's new version comes soon to tide people over.

>>16577
underrated post, someone do this

>>16942
Nice, pushed a change.
Speaking of which I have a few preferences on this:

I don't want to commit my version of the main project file, it points to a different "flash.swc" path and therefore isn't compatible with yours.
I don't like committing build artefacts, since these are created new every time they aren't meaningful or readable.
Updating directly is best, branching should be reserved for big changes, right?

Basic menu works, I guess that task is sorted. I plan to wait until you've got animation swapping and accessories implemented (even in a basic form) before I implement menus to control them.

>>16944
>I don't want to commit my version...
Understandable

>I don't like committing build artefacts...
I'm assuming you mean files like the config files that FlashDevelop creates. If that's the case then I'm more than fine with that. I should probably create a contribute.md that outright says to never commit files like those.

>Updating directly is best, branching should be reserved for big changes, right?
Correct.

Almost done with the default animations for the templates. There are still some rough patches with them (Mouth tweaks such as no major scale changes)

>>16942
when did Gscot last have a comment stating he was working on it?

>>16946
It was more implied than outright saying but the comment is the current bottom comment at https://e621.net/post/show/615848

Not to be rude, but I'm kinda with >>16938

I understand what you guys are doing, and I know it's going to be worth it in the end, but...

>>16949
>>16952
Because neither of us are artists, and the one guy producing such assets (gscot) isn't part of this specific project IIRC.
Feel free to get involved with getting the art in to a workable form, it's open source after all. Otherwise I ask for your patience.

File fuck-your-champion-2.swf - (3.66MB )

>>16956
I found the source, here.

Alright it's been a while, longer than I like but info dump time. I'd show off the recent flash but I'm not satisfied with the progress made and an issue with it currently.

There have been quite a number of road bumps since the last update. Most of them have been dealt with now but there are some left. One of which is a dynamic layer management system, capable of changing a display object's depth while an animation is running (current system is limited in this regard). This is highly important for being able to re-include "cut" characters and to allow completely new parts to be added.

Another road bump I actually just ran into is with hair, which is currently very inflexible due to relying on a created file to define how it's animated instead of being this being handled during run time. This is more of a future issue with custom hair then the current hair but it'd help now, since I ran into an problem with Rosalina's hair, which is not synced with the template body for a few animations (it seems there are some body differences between her and Peach).

That champion flash is interesting and I'll take a deeper look into it but something's telling me that it'll have conflicts with what I already have set up.

Purple, if you're still hanging around here and still want to work on the menus, I push a few commits for the main project and that should be ready to have menus integrated with it. There are some differences in how containers are accessed, especially with the Eye. Also by chance do you have any handy references for those rope physics you mentioned a while ago? It'd greatly help with the hair issue I mentioned.

>>16993
I don't have any particular reference.
It's not too difficult to find basic solutions in the form of a few classes or entire physics engines, but again I don't have anything on hand.
As for the main project, I can't get it to compile, only the test plays nice.

Error: Symbol 'MotionXML.Rosalina:RosalinaReverseCowgirlMotions_HairSideR' is multiply defined in MotionXML\Rosalina\RosalinaReverseCowgirlMotions_HairSideR.as and \ppppuNX\lib\TemplateAnimationMotions.swc(MotionXML.Rosalina:RosalinaReverseCowgirlMotions_HairSideR).
Build halted with errors (fcsh).

I assume it means it has multiple definitions.

>>16994
When I get that issue, I usually have to recompile the template animation motions swc. Guess after compiling a swc there's something set so FD knows to use the swc definition. This particular fix is going to be cumbersome since that requires getting a FD plugin.

Easy solution that avoids that is for you to delete the motion xml folder. That should be okay though since you aren't doing any editing with the animations.

>>16995
Compiles with warnings, those can be dealt with later I guess.
Debugging isn't viable however, since running the resulting SWF takes way too long. Some startup code causes the entire thing to halt flash player for around 10-20s, I don't want to wait that long every time.
Upon load, it appears as if every animation is loaded and displayed at once, halted on the first frame.
If you could perform some basic config to:

Set a single animation to demonstrate the boilerplate for swapping animations.
Reduce startup time to something reasonable.

Then I can easily copy the menu over and begin adding control features.

>>16996
I have got to stop uploading/working on this when I'm sleep deprived. Okay, the startup time might be a challenge since that's all due to parsing xml. I think I got something that'll shorten it though, which is using JSON instead. This will require some helper script changes in addition to code changes though. As for the animations, I'll get on having a default startup.

>>16997
So long as the data doesn't change and isn't related to displayobject you can probably just (de)serialise it.
Try a dict or something, parse then serialise.
Compare against straight loading and deserialising the dict.

>>16998
I kind of went overboard with this and some of the changes probably didn't do too much in the long run and made this more convoluted but what's done is done. Xml is no longer dealt with at all outside the initial export motion xml process. describeTypeJSON is used instead of describeType. The animation motion classes now use an instance of classes that extend ByteArray that have a serialized object embed into them. Because of said serialization, I had to make a helper program in AIR to process information derived from the xml files into an object because as3 doesn't have (easy) file system access.

So after all this, it still takes 4-5 seconds in release and 10-12 seconds in debug to process all 10 animations for the default animations. A good decrease but I'm guessing that it is still too slow, so later I'm going to force staggered loading on a per demand basis(which I should have done in the first place but the optimization still helps with this.)

I'm still going to push the build with all this but there is still some "ugliness" to the code (improperly named variables, a few lingering test variables, etc.)

>>17004
Pushed a stable commit not too long ago.

>>17006
http://webm.host/84096/

Menu is live, but doesn't play nicely. A lot of references that existed in the test don't exist in the actual main project.
Things like templateInUse.EyeR.eye etc.
Hair works, somewhat. The video above demonstrates that persistence is fine but some elements do not conform.
Commit pushed, for now.

Aaaand whelp, committed as3proj files too. Ah well, nothing disastrous.

>>17007
Thanks. This is some nice work you're putting in. Sorry about changing the references without a heads up. Just wanted to use a more easily understandable system when working with containers.

Now about why the skin doesn't work. A while ago (about a month, it might even predate the repo's creation) I changed the way elements work in the main project folder. The skin is completely black (0,0,0), with the intent being to color it using a color transform to allow a greater level of precision and control. Certain elements are unaffected because they are named SkinGradient, which I left the color of alone. This allows them to be filtered as one would expect.

I never did get around answering the question of how to handle skin color and now it has to be dealt with. I am leaning towards the use of color transform more but that might change after I do some heavy experimenting.

>>17008
If the question boils down to RGB vs HSLC then most of the time it's RGB. HSLC only offers value for relative adjustments, RGB is absolute.

>>17009
If that's the case, then I know what needs to be done now. The gradient using elements are going to use the graphics editing function that's in the as3test project. This will give users the most control over the appearance. Just need to create some more menu options to allow this for the 5 or so elements that can be adjusted. Going to read up on the menu library and see what I can come up with.

I must say, that ui library is really easy to use. Still made a small mistake with it but that shouldn't be hard to fix. Anyway, I pushed a small commit just to show my idea for gradient editing.

File ppppuNX_AlphaV0_1.swf - (1.17MB )

Finally got something that seems presentable enough. Tell me what you all think and if there is anything that could be improved. The alpha flash is nothing too big, just basic animation switching (use number keys) and color change menu, which has a few more options to mess with now.

There a few other features I want to integrate before I can move on to other characters, like a system that controls hair, so that the animation for hair will be a fairly automated process in the future (all hair animations still need to be defined currently, which can be tedious and will cause issues when custom hair can be added). I'll try better to stay in touch, especially on the blog which I have neglected.

>>17018
Yep, gradient thing was my mistake. The square checkmark was easy to miss, perhaps the traditional "X" would be more appropriate. But that's a minor issue.
The key "L" tanks performance, but I see that's related to timelines so I'll leave that up to you.

Finished my quick overview of the project and whipped up a task list. Still unsure about a few things and think I missed some features but the list can be found at https://github.com/ppppuProgrammer/ppppuNX/issues

>>17021
argh github pls.
Minor changes, not happy with how the menu collapses but since it's easy enough to decouple from the main app we can probably sort that properly in the future.
For now enjoy sneaky simulated clicks.

Got a basic file selector going to load in images, we don't do anything with the Bitmap object yet. It'll probably be useful around the same time we add the enhanced element containers.

>>17024
Feature, intentional. Might be bound to menu open/close in the future.
It makes adjustments easier at the very least.

Any progress on Gscot's next version?