stuntcock's loader mods - dynamicHairExtenderV5 (1 Viewer)

[stuntcock]

You can find the latest version of my mods on the Resource Manager. The stuff below is included for convenience but it may not be up-to-date.


This post is a collection of hair and costume elements which employ the dynamicHairExtender physics library. These files rely on the Loader and have accordingly been given the *.MOD file extension.

There are a few accessories and static-hair variants of dynamic hairstyles, which are vanilla content and retain the *.SWF file extension. These items are relatively minor, and they're intended for use in conjunction with Loader mods (particularly sby's moreClothing mod). Therefore I'll just leave them here instead of creating a separate "vanilla Imports" thread.

The dynamicHairExtender library has been merged into the content files. You should not need to download the dynamicHairExtender files; they're provided as a reference for modders.

My Little Pony: Friendship is Magic

Spoiler: MLPFiM

Fluttershy

(click for animation sample)
Fluttershy Dynamic Hair (normal) View attachment SDT-MLP-dynamicHair-fluttershyV4-highlights.mod
Fluttershy Dynamic Hair (with highlights) View attachment SDT-MLP-dynamicHair-fluttershyV4+highlights.mod

hairs/SDT-MLP-dynamicHair-fluttershyV4-highlights.mod=Fluttershy:DynamicHair:StaticHair

Static Hairstyle View attachment SDT-MLP-dynamicHair-fluttershy-static.swf
FLA Source File View attachment SDT-MLP-dynamicHair-fluttershyV4.fla


Adagio Dazzle

(click for animation sample)
Adagio Dynamic Hair View attachment SDT-MLP-dynamicHair-adagioV4.mod

hairs/SDT-MLP-dynamicHair-adagioV4.mod=Adagio Dazzle:DynamicHair:StaticHair

Static Hairstyle View attachment SDT-MLP-staticHair-adagio.swf
FLA Source File View attachment SDT-MLP-dynamicHair-adagioV4.fla

Expelled from Paradise

Spoiler: Expelled

Angela Balzac (INCOMPLETE)

Dynamic Hair (TODO)
Static Costume (TODO)
WIP thread

Kuroinu Kedakaki Seijo wa Hakudaku ni Somaru

Spoiler: Kuroinu

Celestine (INCOMPLETE)

Dynamic Hair (TODO)
Dynamic Costume (TODO)
WIP Thread

Bondage Gear

Spoiler: Bondage

Collars

Front Ring View attachment LeatherCollar_FrontRing.swf
Rear Ring View attachment LeatherCollar_RearRing.swf
Both Rings View attachment LeatherCollar_BothRings.swf

LeatherCollar_FrontRing.swf=Leather Front Ring:CostumeCollar
LeatherCollar_RearRing.swf=Leather Rear Ring:CostumeCollar
LeatherCollar_BothRings.swf=Leather Both Rings:CostumeCollar

FLA Source File View attachment SDT-collarsForLeashes.fla


Leashes

(click for animation sample)
Leash MOD files

; ------ Leashes ------
LeashFrontLeftLongV5.mod=Leash Front Left L:DynamicHair>Body2
LeashFrontLeftShortV5.mod=Leash Front Left S:DynamicHair>Body2
LeashFrontDangleLongV5.mod=Leash Front Dangle L:DynamicHair>Body2
LeashFrontDangleShortV5.mod=Leash Front Dangle S:DynamicHair>Body2
LeashRearDangleLongV5.mod=Leash Rear Dangle L:DynamicHair>Body2
LeashRearDangleShortV5.mod=Leash Rear Dangle S:DynamicHair>Body2
LeashRearLeftLongV5.mod=Leash Rear Left L:DynamicHair>Body2
LeashRearRightShortV5.mod=Leash Rear Right S:DynamicHair>Body2

Request thread
FLA Source File

Physics Library

Spoiler: Physics

Code and Binaries
dynamicHairExtenderV5.swf - SWF download links will no longer be provided because you don't need to deal with the SWF file anymore. The physics code is now embedded into the content mods. If you still have a dynamicHairExtender.swf file in your Mods.txt file then please feel free to remove it.
dynamicHairExtender.as - this file is relevant only to modders. If you're a normal user then you can ignore it.

Features, API Documentation, and Tutorials
Start here and then follow the links. Due to lack of interest, the documentation is unfinished and out-of-date. If you're interested in creating a mod which includes major physics-based features, send me a PM.

Changelog

Spoiler: Changelog

• V5 (July 2015)
  • performance improvements
  • general code rewrite for proper use of lProxy
  • ropes can be assigned to any RGB slider (previously: only the Collar slider was available)
  • ropes can be anchored to moving anchor points (mostly for breast slider compatibility, but this feature is also handy for animation)
  • API significantly overhauled.
    • Please note that the API documentation has not been updated to include these changes. If you're interested in creating physics-based clothing mods or enhanced dynamic hairstyles, contact me for details.
• V4 (Released Jan 24 2015)
  • the physics code can now be embedded into the MOD files so that they're more portable and convenient.
    • All existing physics-based MOD files have been re-released with embedded code.
    • Note: you'll still need the Loader if you want to use physics-enabled hairstyles and costumes.
  • the implementation of "soft" rotation constraints is now more robust, and it should be much less onerous to declare them within your FLA file's ActionScript
• V3a (Released Jan 18 2015)
  • minor bugfixes and compatibility improvements
• V3 (Released Jan 11 2015)
  • Leashes are now officially supported; several will be released alongside the mod.
  • DynamicRotationMultiplier has been rewritten; it now allows modders to create "stiff" hairstyles without relying on hardcoded rotation arcs.
  • Custom force vectors can be applied to any Link
  • Links can be anchored to anatomy, and to any named element within the scene
    • TODO: figure out how to bind to Animtools props -- need a dot-delimited pattern
  • Ropes can be assigned to any "layer" - between the breasts, just above the left arm, etc...
  • Ropes will report Tension information. The long-term goal here is to allow tie-in with DialogActions, such as "Ouch! Please don't pull on my hair like that!"
  • Ropes can be bound together via Shared Links. This can occur at a specific midpoint (e.g. a barette), at an endpoint (e.g. welding together a pair of Leashes), or for almost the entire length of the Rope (e.g. physics-based braiding).
  • Hair strands can be given a y-axis "floor" position which they will lie against (rather than falling/dangling through)
• V2 (Released Dec 28 2014)
  • Rotation control can be applied to all Segments.
    • The implementation of this feature is inefficient. It will impose a performance penalty on the game (probably undetectable at normal-usage levels; might be significant with dozens of separate hair strands).
    • To avoid this problem, simply do not declare any of the following variables in your hair strand configuration unless you intend to actually use them: dynamicRotationMultiplier, staticRotationMultiplier, minRotation, maxRotation.
  • All API parameters now use singular names: linkWeights linkWeight.
  • Hair strands can be bound to any anatomical-reference object (previously: all hair strands were bound to g.her).
  • Hair strands can be anchored to any anatomical-reference object (previously: all hair strands were anchored to g.her).
  • Minor expansion of the "angled gravity" API feature, for compatibility with sby's Animtools mod.
    • This fix will not be noticeable until animtoolsV14 is released.
  • Friction can now be adjusted (note: the SDT physics engine seems to ignore Friction).
  • Visual ordering (z-index) of Segments within a strand can now be reversed.
  • The hardcoded limit w/r/t number of simultaneous hair strands has been abolished.
  • Minor changes to the arithmetic of Rotation limits and blending -- which breaks backwards compatibility. Any hairstyles created with V1 of the mod should be re-tested and (if necessary) re-tuned.
• V1 (Released Dec 5 2014)
  • initial release.
  • Rotation control is available but it applies to the first Segment only.
  • Hardcoded limit of 20 dynamic-hair strands per scene.
  • Link weights can be adjusted.

GUI and Game Mechanics

Spoiler: Mechanics

moreCumSpurtsV4 (unofficial)
This is a branch of sby's moreCumSpurts mod. It uses a different coding approach behind-the-scenes, but the main difference is that it's intended to be easier to customize. It also works within the original logic, so there's no sharp distinction between "normal spurts" and "extra spurts."

If you take a look at the Settings file, you'll see that it explains how to achieve special results (such as a scattering of rapid-fire spurts, or a single sustained "firehose" spurt). It's expected that users won't actually use these extreme settings in-game (because they're goofy), but they help to illustrate the flexibility of the mod. You might try out the "firehose" mode, and then choose settings which are much closer to the default (but still delivering a few extra-long spurts during each orgasm).



moreCumSpurtsV4.7z View attachment morecumspurtsV4.zip

Anatomy Modifications

Spoiler: Anatomy

Thicker Ass and Legs

This is a minor edit of Patrick's mod. It adds Loader scripting, so that changes to the Skin Tone and Tan settings (via the in-game GUI) are automatically reflected in the legs. Hence it is no longer necessary to load a different SWF file when altering skin tone (or when switching to a character with a different skin tone).

Any clothing designed to work with Pat's mod will work normally with this mod also.
sdt-thickerAssAndLegs.mod (mod file)
sdt-thickerAssAndLegs.fla (source file)

The mod is compatible with moreClothing:

sdt-thickerAssAndLegs.mod=Thicker Ass and Legs

ThighMaster
TODO. This mod is unfinished.

Cosmetics

Spoiler: Cosmetics

KissMarks


This mod causes small lipstick marks to appear on the male (or futa) character's torso and scrotum. It was requested by 0nymous.

KissMarks | Undertow
SDT-lipstickKissMarks.7z (mod files)
SDT-lipstickKissMarks.fla (FLA source file)

 

[stuntcock]

Queue for Dynamic Hairstyle animation projects:

• @Nightstalker's Chloe (suggested by @Huitznahua)
• Widowmaker (Overwatch)
• Tracer (Overwatch)
• Symmetra (Overwatch)
  
• Long-haired Haruhi Suzumiya (suggested by @sandman_2010)
  
• @Mineur's Ravel Phenex (suggested by @Mineur)
• @Mineur's Erina Nakiri (suggested by @Mineur)

 

[stuntcock]

Re: stuntcock's loader mods

nice one. I was looking forward to try this one.
the trsnsformstions fon't slways seem to follow the mouse movements though.Especially, when using the ankor points at the corners. They rapidly switch between the desired shape and a pretty stretched out one. but I guess this just has to do with the early stage of the mod.

Good point - that problem came up in development (even in the sample video!) and I should have warned people. I'll add a "known issues" section.

I think that the underlying problem is contention (or perhaps just resource exhaustion). You have three different modules (SDT, breastSculpt, and freeTransform) all attempting to modify the same matrix. Officially, the matrix modification should occur in a deterministic pattern and the "correct" value should always be in-effect before a redraw occurs. If there's a lot happening on-screen, though, we get a momentary glimpse of the "wrong" matrix - which is unpleasant for the user.

The only really obvious solution is "reduce the animation quality while a drag-drop operation is ongoing and then restore it afterwards." I might make that an option in the next version, but I'm going to do some more investigation first. There's a very "clean" solution available which involves 5-6 hours of work - I'd call that "excessive" for a simple visual bug, but this work may be a prerequisite for some of the roadmap items that I've identified (in which case I should just fix it ASAP).

personally I think reshaping could be easier sometimes, if the transformations would use an other center, than the actual center of the breast graphic. maybe something closer to the point, where the brest conects with the torso. That way they would not dislocate as easy. or maybe even add the option for the user to chenge this point, with an aditional handler.

Agreed. I wouldn't have included something like that in the V1 release (because I was worried that users would get overwhelmed by seeing too many onscreen controls and options), but it definitely has value as an "advanced" or "expert" feature. It's especially important for any future "animation replacement" or "breast physics" stuff, because the center of rotation needs to be much closer to the torso. I'll add it to the roadmap.

I also think it would be nice to be able to togle, if you want to rotate/skew or scale/stretch the brests, making it easier to resize the breasts without accidently rotating them.

The key problem here is "how does the user communicate their intention?" Here are some options that I've considered:

• Lock-in. If they grab a corner resizing handle and begin a radial mouse movement, then I could assume "this user just wants to resize" and therefore I would lock it into resize mode. Similarly, transverse motion starting from a corner handle could be locked-in as rotation. As a designer, I can accept this control scheme. Unfortunately, this is not a familiar control scheme in normal desktop computing environments, so I'm concerned that it would just confuse people.
• Better handles. I could improve the graphics so that the corner resizing handles look like the Windows resizing mouse point (diagonal double-headed arrow), and then add another handle near the corner (icon=circular arrow) which would be used for rotation. Users would just need to click on the handle which represents their desired transformation action.
  Advantage: greater control/precision
  Advantage: easier to intuit the purpose and effect of the resizing handles
  Disadvantage: more "visual clutter" on the screen
  Disadvantage: single-mode transformations are slower (the user may be forced to click-and-drag twice as much in order to reach the same outcome)
• More hotkeys. If you activate sculpting mode by pressing the period key, you get rotation handles. If you activate it by pressing comma, you get resizing handles. Forward-slash gives you skew handles, etc... This is the lazy approach, and I want to avoid it (because it's unfriendly to users, and because every time that I "claim" an additional hotkey I risk introducing a conflict with another mod).

 

[hugo_boss]

Re: stuntcock's loader mods

how about switching by chlicking? default is both rotate and resize like it is now. if you click on the breast once (without dragging it ) and the handles change to scaling mode, click again and they change to rotation mode.
I've seen it like that in many programms. The mode would be indicated, by difrent handl graphics.

 

[BuckWild]

Re: stuntcock's loader mods

I've noticed that this mod only activated during initialization. I try loading it as a loader mod, but it doesn't work then. It also lacks an option to persist on reset; think you can add that in the settings? I don't know if what I have could be a mod conflict or not. According to your list of compatible mods, it isn't. But I do use mods that are not listed as compatible or conflicting. As far as I know, the mods in my $INIT$ folder operate fine prior to adding breastSculptV1 to it. None of the ones you didn't mention have to do with the torso or tit layers other than NippleHue.swf.

Can you explain why it would activate only on initialization and why it sometimes resets the tit layer so that your mod has no effect on it? While I edit the shape and position of the tit using your mod, it just randomly hops back to it;s original placement and shape, and am unable to edit again unless I restart the loader.

 

[stuntcock]

Re: stuntcock's loader mods

I've noticed that this mod only activated during initialization. <snip> Can you explain why it would activate only on initialization

Aha! We're running into a fairly simple obstacle here: I myself am very bad at setup and advanced usage of SDT mods. I've never managed to get character-folder stuff to work correctly, and so I just dump a dozen mods into $INIT. If something goes screwy during gameplay, then I Alt-F4 and start a new instance. Even if I somehow made the breastSculpt mod reset-compliant, I wouldn't be able to fully test it because I can't identify all of the use-cases.

I don't have an immediate answer for you. I plan to continue coding core features (such as save/load) and testing the mod (functional, regression, performance/stress, and compatibility) via $INIT. If/when the mod reaches a sufficient level of feature-completeness, I expect one of two things to happen:

• I spend a few hours reading guides, do some trial+error, and figure out how to use mods correctly. Then I add the necesssary code to the breastSculpt mod (I expect that it's missing only a few crucial lines of code) and test it.
• A senior modder volunteers to clean up the code so that it conforms to the appropriate template(s). The refactoring process automagically makes the mod become reset-compliant.

My long-term intent is to make the mod fully persistent, resettable, etc... That's currently at a lower priority than most of the new features, for selfish reasons ("I don't use the reset feature in my own gameplay, so its absence doesn't bother me" "Adding features helps me to learn about Flash coding; adding reset-compliance would merely teach me about the idiosyncracies of SDT Loader configuration"). Maybe this is a bad decision on my part.

Question: How serious/fatal is the absence of the reset feature (or character-based mods, etc)? Is it something that you commonly use in gameplay, or is it perhaps a feature that you invoke rarely (e.g. when attempting to resolve a "mod crash" or "mod conflict" problem)?

Question: I'll be happy to add NippleHue.swf to the compatibility-testing plan - except that I don't have a copy of it (site-search and Google return nothing useful). Could you please reply or PM a link? Preferably a link to the development thread, but a download link is okay. Nevermind; I was misusing the search tool. I've found the link.

While I edit the shape and position of the tit using your mod, it just randomly hops back to it;s original placement and shape, and am unable to edit again unless I restart the loader.

Darn - that's a bug. I saw it during development but couldn't isolate it and then it didn't recur during pre-release testing. I'm not sure what causes it - I'm inexperienced at ActionScript/Flash coding and I haven't figured out how to attach a debugger to a running instance of SDT. However, the design of breastSculptV1 includes a very flawed assumption regarding data persistence - this flaw might cause it to throw an exception at runtime*. The V2 design is based on an improved understanding of persistent-vs-temporary objects and should therefore be more stable, but I'll be sure to test for that bug thoroughly.

* The mod must continuously "correct" the anatomy (for each frame of gameplay). A crash would cause the mod to stop making corrections; the breasts would then revert to their normal size+shape (which seems to fit your observations). Of course, the mod might be crashing for some other reason - such as an overrun in the trace() buffer.

 

[ModGuy]

Re: stuntcock's loader mods

Avoid adding/removing events when possible, the loader can handle frame events:

addEnterFrame(f)		Calls f every frame till unloaded. f(l){}, l is loader.
addEnterFramePersist(f)		^ but will continue calling after unload.

As for SDT continually reverting transforms, consider using lProxy to get around this:

Method Proxies

A number of functions have been moved such that they are called by ref instead of by value.
Because of this, it is possible to listen for method calls and outright replace them.
To help manage this, the class lProxy has been added.

var lProxy:Class = l.lDOM.getDefinition("Modules.lProxy");
var lp = lProxy.createProxy(OBJECT, "FUNCTION_NAME");

createProxy will check for an existing proxy or create one.
We can add methods to be called before or after the orignal as well as "unhook" the proxy.
If you wish to unhook the original, it makes sense to leave the return type in.

lp.hooked = false;

This unhooks the original function from the proxy, pre and post are still active.
This can be used to "replace" functions in a manageable way.

To add a method before or after the original, we use the following:

lp.addPre(f:Function)
lp.addPost(f:Function)

When writing these functions, be sure to remove the return type if it's not being used.
For example:

public function move(a:Number, b:Number):Number
public function move(a:Number, b:Number)

This is because Pre functions are called in order.
If the fist Pre returns a value and the second does not, we retain the first value.
We do this until we have looped through them all.
If we do not have a return value and the function is hooked, we call the original.
After this we store the return value if any then pass it to each Post function.
Finally, we return the value.

lProxy.checkProxied(OBJECT, "FUNCTION_NAME");

Returns proxy if it exists.

Proxies are removed on character reset, to prevent this enable persistence:

lp.persists = true;

Allows proxy to persist through automatic removal.

lp.restoreProxy(force:Boolean = false);

Removes proxy from listener list, or nulls out list if last.
If force is true, this overrides persistence and forcibly removes the proxy.

lProxy.checkProxied(OBJECT, "FUNCTION_NAME");

Returns proxy if it exists.

lProxy.restoreProxies(force:Boolean = false);

Removes all proxies, gets called automatically on reset.
If force is true, this overrides persistence and forcibly removes all proxies.

 

[stuntcock]

Re: stuntcock's loader mods

As for SDT continually reverting transforms, consider using lProxy to get around this:

Thank you very much for this suggestion. I lost a few hours of development time in learning about this feature (and hunting through decompiled code), but now that I've got it working it's a major improvement. It actually obviates a chunk of my original design. I had intended to include a "manager" which would merge the transformation effects of mods such as breastSculpt, breastExpPlus, etc... However, such management is unnecessary if we simply ask modders to use the proxy method (well - we also need them to concatenate matrices instead of overwriting them, but that's a pretty quick fix).

The only complication I can foresee involves the non-commutative nature of matrix math. The combined effect of, let's say, [breastSculpt + breastExpPlus + jigglePhysics] will depend on the load order of the mods. Not a problem from the coding side of things, but I'll need to clearly explain this to the end-users (with a recommended load-order in case of known conflicts).



To everyone else

• the switchover to proxy code should greatly improve stability, persistence (character switch, reset, etc) and interoperability (especially forward-compatibility with future mods).
• there will be some impact on the long-term roadmap. I can no longer promise a "resculpt any on-screen object by clicking on it" feature, because the mod's code must now hook into specific functions such as "her.leftBreastController.update". However, I expect that most users are interested in sculpting a few bodyparts (e.g. breasts and buttocks) which can be easily accommodated via hardcoding.
• the proxy approach can also be used to extend or replace the breast animation (e.g. with a gravity/physics system). I'm probably going to opt for "replace" because the vanilla code is too simple (it has only ONE state variable).
• the proxy technique can be used to overcome some internal limitations on breast firmness. I'll include it in an upcoming release as a bonus feature.
• the code switch has delayed progress somewhat. I'm hoping to have breastSculptV2 in testing by Friday.

 

[stuntcock]

Re: stuntcock's loader mods

Since my recent posts have been heavy on code theory and bug reports, here are some pictures:

Bra scaling is functional. I'm going to do some additional work here (maybe included in V2 release, but will defer to V3 if it exceeds an hour). The bra cups follow the breasts correctly (and animate with them), but the bra straps use a set of hardcoded "attachment points" which are slightly incorrect (and this error becomes very obvious when the breast size is increased). Fortunately, the lProxy class allows us to fix it.



Shirt scaling is functional but flawed - it looks okay with standard shapes but as you stretch or rotate the breasts you'll begin to see gaps. I'll add this as a low-priority investigation task, but I don't expect to do anything about it unless there's significant demand. It involves issues, such as masks and sprite boundaries, which aren't really related to this mod.



Nipple piercing have been working since V1, but I've never bothered to include them in screenshots. Unfortunately, their appearance is mostly hardcoded (e.g. they always "hang" along the y-axis rather than pointing to the bottom of the frame and/or obeying the local axis of gravity) and their movement isn't very believable. New roadmap item: improve the animation for nipple piercings. If I include it in the planning, then this can be a quick subfeature of the jigglePhysics mod (perhaps 30 minutes) rather than a separate project.



Breast-shape settings can now be appended to Character Data strings during saving, and loaded during character loading. This behaviour can be disabled (in case it presents a compatibility hazard) but it's on by default. When you find a shape which suits your character's body/costume/etc then you just need to use the normal Save Character (or Edit Character > Save) button to preserve the shape for the future. If you look closely at the screenshot below you'll see a few different breast shapes in the thumbnails (and also some nonsense words because I had to run through the process a dozen times while checking and debugging its behaviour).
Note: The long-term intent is that any character-specific (sculpted) shape data will be merged (at runtime) with real-time deformation parameters from the jigglePhysics mod and "scenario" data from animtools (such as "what's the effective gravity vector for strands? Okay, let's use that same direction (and intensity) for the breast physics simulation"). Hence, the "preview" thumbnail images will not always be an accurate prediction of what the loaded character will look like.



I decompiled some code in the hope of getting a screenshot which shows a strand attached to both breasts. Alas, that's going to take a lot more work (at least 100 lines of hardcoded logic must be proxied and rewritten) so I'll defer it to a future version.

 

[BuckWild]

Re: stuntcock's loader mods

Oh wow. I didn't realize I triggered this much of a response.

I really don't reset unless mods change something that I can't change back, such as Her arms on costume mods. This is usually a feature I use as a last resort, because sometimes some loader mods don't persist. It's definitely not a major deal, but it's more of a convenience.

As for the mod crashing, I'm glad to know what caused it to bug out. Looking forward to the update(s).

 

[sby]

Re: stuntcock's loader mods

Oh wow. I didn't realize I triggered this much of a response.

I really don't reset unless mods change something that I can't change back, such as Her arms on costume mods. This is usually a feature I use as a last resort, because sometimes some loader mods don't persist. It's definitely not a major deal, but it's more of a convenience.

As for the mod crashing, I'm glad to know what caused it to bug out. Looking forward to the update(s).

happen to be using the standalone debugger?

 

[BuckWild]

Re: stuntcock's loader mods

Oh wow. I didn't realize I triggered this much of a response.

I really don't reset unless mods change something that I can't change back, such as Her arms on costume mods. This is usually a feature I use as a last resort, because sometimes some loader mods don't persist. It's definitely not a major deal, but it's more of a convenience.

As for the mod crashing, I'm glad to know what caused it to bug out. Looking forward to the update(s).

happen to be using the standalone debugger?

I use the standalone Flash Player, not the debugger. Should I be using that normally?

 

[sby]

Re: stuntcock's loader mods

Oh wow. I didn't realize I triggered this much of a response.

I really don't reset unless mods change something that I can't change back, such as Her arms on costume mods. This is usually a feature I use as a last resort, because sometimes some loader mods don't persist. It's definitely not a major deal, but it's more of a convenience.

As for the mod crashing, I'm glad to know what caused it to bug out. Looking forward to the update(s).

happen to be using the standalone debugger?

I use the standalone Flash Player, not the debugger. Should I be using that normally?

if you were to use it and re-create the bug, you could give the stack trace error it pops up

 

[BuckWild]

Re: stuntcock's loader mods

I use the standalone Flash Player, not the debugger. Should I be using that normally?

if you were to use it and re-create the bug, you could give the stack trace error it pops up

I'll try that, then.

 

[stuntcock]

Re: stuntcock's loader mods

I'll try that, then.

If this is still in reference to the breastSculpt crash bug that you reported a few days ago, then I'd say "don't bother." The unstable code has been replaced (using MG's lProxy class) and the mod now persists/survives when the Reset command is used. It actually survives too well; I'd like for the Reset button to automatically discard any active sculpting effects (revert to default shape) but I can't find a clean way to hook into the Reset function (or attach a listener to the button itself, since it's declared inline and lacks a name). My best prospect at the moment involves attaching to the customElementLoader.clearInstancedMods() function, but I need to investigate that option for possible side-effects.

If you still encounter the bug after the V2 release then details would be appreciated. At the moment, though, I probably wouldn't be able to do anything useful with the error codes or stack-trace information that you're able to produce using the breastSculptV1 mod.

 

[BuckWild]

Re: stuntcock's loader mods

So you prefer experimentation rather than learning from others' coding mistakes? You really could learn a lot by checking out some of the mods in sby's thread. He has uncompiled code for many, if not all, of his mods in his thread.

Bah, like I'm one to talk, I've yet to even delve into flash scripting.

 

[Sona]

Re: stuntcock's loader mods

I might be missing something but is V2 downloadable?

 

[BuckWild]

Re: stuntcock's loader mods

I might be missing something but is V2 downloadable?

Not quite yet, I'm afraid.

 

[stuntcock]

Re: stuntcock's loader mods

So you prefer experimentation rather than learning from others' coding mistakes? You really could learn a lot by checking out some of the mods in sby's thread. He has uncompiled code for many, if not all, of his mods in his thread.

The breastSculpt mod started off as a copy-paste of sby's superBreast mod. I'm quite willing to read code written by the veteran modders, and to borrow/adapt their techniques. It took me a few hours to integrate the lProxy stuff because it's a relatively new feature (within SDT modding) and I couldn't find very many useful examples. The biggest hurdle has been documentation - it seems as though the veteran SDT modders either don't expect junior programmers to read their code or don't have enough time to include inline comments. Or perhaps they expect that anyone seriously interested in code-modding will already have a thorough knowledge of ActionScript and therefore will not need a hand-holding walkthrough of well-structured code.

Since I'm not facing any serious time constraints at the moment, I've documented my code pretty thoroughly. Once the breastSculpt code becomes fairly mature (around the V3 or V4 release, when I'm hoping to shift development focus onto the jigglePhysics mod), I'd appreciate some feedback on the code structure and documentation (note: don't do this yet! the V1 code uses bad practices and includes many misinformed comments). My background is in c, so my approach (and/or terminology) may not be ideal for AS3 programmers.

I might be missing something but is V2 downloadable?

I've updated the first post to indicate an expected release date of March 7. The core behaviour is working well, but the UI integration (bounding box and drag handles) is a mess because I'm still trying to implement re-centering.

 

[sby]

Re: stuntcock's loader mods

lol comments what xD

the little commenting i do is usually for myself, and those only really exist on the larger mods.