SDT Loader question (2 Viewers)

[CaptainOwl]

I don't know what's causing it but some reason I can't load Non-loader SWF mods while using loader. When I go to modding and Hit "SWF Mod" and open a Vanilla SDT SWF mod it doesn't show up. I tried it without loader (Vanilla SDT) and they load fine so I have no clue what's going on. Every Vanilla SDT SWF mod isn't work not just one kind.

Also it worked fine in V5.19c but when I upgraded to V5.21 that's when I started having the problem.

Loader Mods work fine just not Vanilla SDT SWF ones.

 

[ModGuy]

I don't know what's causing it but some reason I can't load Non-loader SWF mods while using loader. When I go to modding and Hit "SWF Mod" and open a Vanilla SDT SWF mod it doesn't show up. I tried it without loader (Vanilla SDT) and they load fine so I have no clue what's going on. Every Vanilla SDT SWF mod isn't work not just one kind.

Also it worked fine in V5.19c but when I upgraded to V5.21 that's when I started having the problem.

Loader Mods work fine just not Vanilla SDT SWF ones.

Think I know what's happening, will attempt to fix soon.

 

[CaptainOwl]

I don't know what's causing it but some reason I can't load Non-loader SWF mods while using loader. When I go to modding and Hit "SWF Mod" and open a Vanilla SDT SWF mod it doesn't show up. I tried it without loader (Vanilla SDT) and they load fine so I have no clue what's going on. Every Vanilla SDT SWF mod isn't work not just one kind.

Also it worked fine in V5.19c but when I upgraded to V5.21 that's when I started having the problem.

Loader Mods work fine just not Vanilla SDT SWF ones.

Think I know what's happening, will attempt to fix soon.

Thanks and hope you are able to fix it ;D

 

[gollum]

Thanks and hope you are able to fix it ;D

it's not an "if", it's a "when"

*swoons over modguy*

 

[ModGuy]

Fixed.
What I did was remove my old method of loading vanilla mods and settled for file paths.
What I forgot was that mods loaded through the vanilla menu uses a fileReference instead of a path and as such fails to provide any data to the new method to actually load.
I've fixed this by including a simple condition to check if a fileReference was used during loading and switching to the old method.

Expect in next release.

 

[BuckWild]

Fixed.
What I did was remove my old method of loading vanilla mods and settled for file paths.

Question. Did you plan on dedicating static file paths to the vast amount of vanilla mods by category and/or slot as well as ensuring the said file paths would be used by future mods?


Kind of seems like an ineffective process, since everyone's file path preference would likely differ greatly.


If not, enlighten me on what you tried to do by implementing that method initially, because I just can't see you having done that without a solid reason regarding functionality.

 

[ModGuy]

Fixed.
What I did was remove my old method of loading vanilla mods and settled for file paths.

Question. Did you plan on dedicating static file paths to the vast amount of vanilla mods by category and/or slot as well as ensuring the said file paths would be used by future mods?
Kind of seems like an ineffective process, since everyone's file path preference would likely differ greatly.
If not, enlighten me on what you tried to do by implementing that method initially, because I just can't see you having done that without a solid reason regarding functionality.

You misunderstand. The loading process is a bit of a pain to explain so I'll try and simplify it.
The loader has functionality for loading file paths, as does SDT. SDT also has the functionality to load a fileReference.
Filereference objects are used to allow a user to select a file using a dialog box, file paths are not available for the purposes of security.

Because the loader predominantly uses paths (From Mods.txt etc) I had to find some way to manually load the raw data of a fileReference.
This was achieved by checking if the mod was vanilla or loader and performing the necessary action.
For loader mods I just process them as standard (I wish I had thought up something better back then heh), for vanilla I just pass them to SDT.

When I found out that SDT had the capability of loading file paths I decided to modify the loading algorithm to simply exchange links and subsequently make everything much more reliable.
What I forgot about was that you cannot retrieve the file path from a fileReference object and as such when the data reached the loading point in the algorithm, no path was passed and it was ignored.
This is what caused the issue, it wasn't a choice made on a whim.

The actual algorithm is a terrible mess but it works, it has many more checks and steps but it wouldn't help my explanation to include them.

 

[gollum]

would it be possible to add a "customSounds" array to SoundControl?
it would make using custom sounds a lot easier, the only thing I found remotely close to custom sounds is the customCough array, but the add-function requires it to be called cough, which imho doesn't make much sense if I want to add something else.

 

[ModGuy]

would it be possible to add a "customSounds" array to SoundControl?
it would make using custom sounds a lot easier, the only thing I found remotely close to custom sounds is the customCough array, but the add-function requires it to be called cough, which imho doesn't make much sense if I want to add something else.

Yeah, should be easy enough but it's a pretty bad idea. Instead it'd be better off extending the built in arrays for things.
If you really want to play a sound for something write something to load an external MP3.

 

[gollum]

Yeah, should be easy enough but it's a pretty bad idea.

care to explain why it's a bad idea?

If you really want to play a sound for something write something to load an external MP3.

I'm using sdt-sounds (code by sby)

Spoiler

var sfxWretch1 = main.eDOM.getDefinition("sfxWretch1") as Class;
var sfxWretch2 = main.eDOM.getDefinition("sfxWretch2") as Class;
var sfxWretch3 = main.eDOM.getDefinition("sfxWretch3") as Class;
[snip]

g.soundControl.wretch1 = new sfxWretch1();
g.soundControl.wretch2 = new sfxWretch2();
g.soundControl.wretch3 = new sfxWretch3();
[snip]

so I'm currently putting these sounds into existing (but limited) variables. since the sounds are different to each other and every other array is used by sdt itself, I thought it would be nice to have something loader specific that's not interfered with by sdt.
if you have any ideas on how to improve this (I have of course the names of the sounds I want to use), I'm an eager listener ;)

 

[ModGuy]

care to explain why it's a bad idea?

Nope.

I'm using sdt-sounds
so I'm currently putting these sounds into existing (but limited) variables. since the sounds are different to each other and every other array is used by sdt itself, I thought it would be nice to have something loader specific that's not interfered with by sdt.

So you're defining some sounds in your FLA and replacing built in sounds with your own?

Instead it'd be better off extending the built in arrays for things.

EDIT: Will try and have some example code up soon.

EDIT2:

Right, if you look at the actual wretch sfx (wretch1 wretch2 wretch3), you'll find that they (probably) don't get used anywhere.
Other arrays, perhaps not all of these because I didn't check, get looped through and random sounds are selected from them:

Spoiler

public var customCoughs:Array;
public var normalBreath:Array;
public var breatheIn:Array;
public var fastBreath:Array;
public var suddenBreath:Array;
public var quietBreath:Array;
public var down:Array;
public var gag:Array;
public var suck:Array;
public var touch:Array;
public var splat:Array;
public var cough:Array;
public var openCough:Array;
public var held:Array;
public var passOut:Array;
public var swallow:Array;
public var lick:Array;
public var cum:Array;
public var cumInside:Array;

Just replace out the arrays with Sound objects of your own and you're done.

 

[BuckWild]

You misunderstand. The loading process is a bit of a pain to explain so I'll try and simplify it.
The loader has functionality for loading file paths, as does SDT. SDT also has the functionality to load a fileReference.
Filereference objects are used to allow a user to select a file using a dialog box, file paths are not available for the purposes of security.

Because the loader predominantly uses paths (From Mods.txt etc) I had to find some way to manually load the raw data of a fileReference.
This was achieved by checking if the mod was vanilla or loader and performing the necessary action.
For loader mods I just process them as standard (I wish I had thought up something better back then heh), for vanilla I just pass them to SDT.

When I found out that SDT had the capability of loading file paths I decided to modify the loading algorithm to simply exchange links and subsequently make everything much more reliable.
What I forgot about was that you cannot retrieve the file path from a fileReference object and as such when the data reached the loading point in the algorithm, no path was passed and it was ignored.
This is what caused the issue, it wasn't a choice made on a whim.

So vanilla mods were not loaded because they would have had to rely on some sort of file path indicator like the Mods.txt within the Mods folder, all of which were absent in their creation? Or something about SDT preventing access to file paths due to that security measure, seeing as how you pass vanilla mods to be handled by SDT?

The actual algorithm is a terrible mess but it works, it has many more checks and steps but it wouldn't help my explanation to include them.

You're probably right. Too much math can kill a man. ::)

 

[ModGuy]

So vanilla mods were not loaded because they would have had to rely on some sort of file path indicator like the Mods.txt within the Mods folder, all of which were absent in their creation? Or something about SDT preventing access to file paths due to that security measure, seeing as how you pass vanilla mods to be handled by SDT?

Not quite.
Mods don't rely on file paths, one of the built in helper methods that Kona uses/provided that was being implemented in the new loading method requires them.
The paths aren't absent, they're inaccessible due to security constraints in flash itself.
I pass vanilla mods to SDT purely due to the fact that it handles them better then I ever could without messing with code.
See:

So I looked in to this issue and found the cause:

When you load a character SWF file it can contain a chunk of code to change settings automatically.
In certain files, you have the parameter "skin", which of course changes her skin tone.
When this parameter is parsed, the function "setSkin" is called.
Within this function there is code that targets mod elements and removes them, resulting in that effect.

Now that shouldn't be happening. Surely Kona would load the code first, then apply elements right?
And that he does, it's a really unique problem here.
The loader is too fast.

What I'll do to sort this is push official mods on to a list and have SDT parse them itself, that should make vanilla mods solid.

EDIT:

It's fixed, but the solution is disgraceful.
I load all mods, loader or otherwise in to SDT. Basically throwing them all at it, and Kona's error handling makes sure only vanilla sticks.
After this I actually parse loader stuff independently. Nice batch loading function Kona, appreciate it.
Expect bugs.
If you're interested in why this works, allow me to explain:
In the same way I can monitor the loaded state of a loader SWF, Kona controls the state of vanilla SWFs. This information is (probably) unavailable to the loader so it just loads one after another without checking because it (probably) cannot.
Kona can monitor the state of the SWF and as such pace the loading properly.

 

[BuckWild]

God, no matter how many times I read your explanations, I can't seem to understand your overall goal for exchanging File References for File Paths. All I can understand is that Vanilla mods won't load because you are trying to load them through File Paths according to File References. I don't understand how it supposedly relates to Loader mods being to fast.


I feel like a complete moron when I can't understand something that involves program processes.

 

[ModGuy]

God, no matter how many times I read your explanations, I can't seem to understand your overall goal for exchanging File References for File Paths. All I can understand is that Vanilla mods won't load because you are trying to load them through File Paths according to File References. I don't understand how it supposedly relates to Loader mods being to fast.

Ah right, allow me to clear that up.
The loader has no idea when a vanilla mod has finished loading, SDT handles that internally and I don't want to break things by exposing that information.
So what the loader did was line up all the mods and iterate through them, loading them all.
Because I used a single loader object to handle all of the loading, when I loaded a vanilla mod and it "finished" loading I instantly disposed the contents and moved on to load the next.
The loader object associated with the mod will have reported the SWF having "loaded" but I have no idea if the mod elements inside of it will have finished registering. As a result I end up trashing mod data before it has truly completed loading.
So perhaps not "too fast" but "crap coding".
I'd like a better way to handle vanilla mods but for now, lobbing them at SDT seems to do the trick.

EDIT:

I might look in to the algorithm again some time, perhaps Kona has used something detectable like event dispatches. Even then I'm not sure if I can detect external, custom events like that.
mehhh

 

[BuckWild]

Ah, NOW I understand. The Loader was just working at a pace that was ineffective at loading the vanilla mods correctly.

 

[ModGuy]

Loader released.

 

[BuckWild]

Loader released.

Thank you for your patience in explaining the Loader's recent problem. Glad the fix is released, too. We are fortunate to have you around to continue work on this and provide source for future development in the inevitable case that you move on to other projects/hobbies/way of life.

 

[gollum]

We are fortunate to have you around to continue work on this

what he said. we all love you modguy ;D

 

[BuckWild]

I seem to have the same issue as before. I don't know if you improperly uploaded the wrong version, but I'll redownload and extract to confirm if it's isolated to me alone.


EDIT: Yup, issue still there. Could you make sure you uploaded the newest version? It's either misnamed or the fix didn't work.


If it works for others, what could I do so that it works for me as well?