Couple of questions about dialogues and auto (1 Viewer)

[Scoopy]

Even after reading the comprehensive dialogue guide and what have you, downloading a few files and being overwhelmed by all the texts I'm still a little lost.

Anyway, just wondering;

Let's say one imports an audio dialogue, does that effect the auto mode?

Would an in game edited dialogue with actions added that is loaded before/after an SWF audio dialogue effect the SWF or vice versa?

Also, can you edit the auto mode without the dialogue effecting everything?

You can tell I'm confused.

 

[stuntcock]

Let's say one imports an audio dialogue, does that effect the auto mode?

As a general rule, no it does not.

Audio dialogues tend to be very simple. They assign a voice clip to each of the in-game triggers (such as first_throat and wake) so that the clip will be played when the associated text line is spoken -- and the associated text line will be spoken when the associated in-game event occurs. Audio dialogues rarely include any Loader scripting. They don't seek to change how the game works; they simply enrich the audiovisual experience at a few key moments.

Advanced dialogues (those written by WeeWillie, DrZombi, et al) do not limit themselves to the vanilla triggers. They invent many new triggers corresponding to new gameplay concepts (such as purchasing a slave, using a whip, inducing fear, etc) or events (such as mindbreak). These advanced dialogues can alter the Auto Mode behavior (via mods such as Custom Automation) and they can swap between sexual positions whenever it's narratively appropriate. You might be enjoying manual control of a scene, and then the author changes to cowgirl position and activates Auto Mode -- because (in narrative terms) the girl decided to take control of the encounter. That's not a bug; it's a feature :)

Would an in game edited dialogue with actions added that is loaded before/after an SWF audio dialogue effect the SWF or vice versa?

A newly-loaded dialogue will almost always completely wipe any pre-existing dialogue entries. This is done for consistency reasons. Imagine that you were playing a "virgin" scenario and then you load a "slut" dialogue. If the two files were simply merged then half of the girl's responses would be timid and the other half would be aggressive; the experience would be very confusing. To avoid such problems, dialogue authors usually start with a blank slate.

Therefore you shouldn't expect to import custom voiced audio lines into a Slave Bazaar session, and you shouldn't expect to be able to apply Slave Bazaar game mechanics onto the Kidnapped_Daughter.swf audio dialogue scenario. It is possible to do such things, but it requires you to learn how the mods work and then mix/merge the files by hand. It's a complex modding task.

In general, you should regard each dialogue mod as a monolithic item. Other mods can crash a dialogue (by introducing compatibility bugs) or break the narrative (e.g. by changing pleasure rules so that the guy reaches orgasm too quickly). Other mods can apply visual changes to the scene (clothing, backgrounds, hairstyles, etc). But you'll almost never be able to extend the content of a dialogue by loading another SWF file on top of it. It's more of a railroad than a sandbox; you need to acknowledge the author's control and let him tell his story. Some authors will even warn you not to tinker with costumes, because a scene might be based on gradual undressing -- if you manually remove the girl's clothes (instead of seducing her) then the logic might get tangled.

If you have suggestions or proposals then you're welcome to bring them to the dialogue author. You might subsequently obtain a new monolithic file which contains the content that you wanted. For example: if you can find an enthusiastic volunteer (or commission an adult actress) then you might even be able to add voice acting for your favorite dialogue. And of course if you encounter bugs in a dialogue then go ahead and report them to the author.

---------------------​

If you simply want to hear more sound effects during gameplay then you should review the Settings file for animtools. You'll note that there are a few sections related to HuniePop. These are various sexy noises which can be played when the game detects a matching event (such as anal penetration, body contact, female orgasm, etc). These audio effects bypass the Dialogue system, so they should work even if the dialogue author expected his story to be completely silent. You can potentially hear moans even when the girl is in the middle of a long text soliloquoy ... or even if she's been gagged. So there's some risk that the noises will break your immersion :)

Of course, some of the fancy Dialogues already have these sound effects enabled.

Also, can you edit the auto mode without the dialogue effecting everything?

It depends on what you mean by that. You can certainly manually switch Auto Mode on or off during a dialogue, but doing so could interrupt the narrative. The girl might begin repeating lines if you delay too long.

You can change the Auto Mode type (e.g. self -> hard) but doing so might cause the scene to play out incorrectly (because the girl no longer receives "breaks" during which to speak her critical lines).

You can adjust the Auto Mode rules (such as targeted penetration depth, oscillation speed, etc) but that might cause conflicts with the custom positions employed by the dialogue. Some positions are intended for conversation or foreplay; if you try to go balls-deep then you might find that the girl repeatedly headbutts the guy's pelvis because the position doesn't allow her mouth to reach his penis.

 

[Scoopy]

Thanks for the very in depth reply! Appreciate the very clear and concise information.

To be honest I haven't yet tried the various advanced dialogues (I will tho...). Merely looking to achieve something a little simpler than that. For the moment at least.

Not worried about effecting other positions at the moment. Merely the basic on knees position.

Seeing as audio dialogues just play sounds when certain triggers are met (which is just fine for what I want to achieve atm) I'd just like to be able to extend the variation of the basic auto modes soft, normal and hard. Whilst I'm happy to go ahead with doing this I'm not sure how to tinker with this portion of the game.

Couldn't really make sense of the in game dialogue edit menu and didn't see soft, normal or hard options in there.

Could one open a pre-made text document with the basic settings for SDTs auto mode, which when edited and loaded would add more animations to the auto mode and it's various settings?

 

[Slingerbult]

The simple way to auto, if you are happy with the standard modes, is just to use the triggers [AUTO_HARD], [AUTO_SELF], [AUTO_OFF] etc. Refer to the guides and mod readmes for an updated list.

The advanced way to do it is to use a custom automation mod. The most recent and up to date appears to be Auto Move V1 by Acclaim. Refer to its very extensive documentation. Basically, such a mod can make the girl do whatever. For example you can configure one automation to just go back and forth like auto mode, or you can make another special cum animation that inserts the penis tip into her mouth when he cums. For your first dialogue, I'd stay away from custom automation unless you're very comfortable with programming and learning new syntax.

 

[Scoopy]

Crikey, Didn't realise it would be so complicated... I thought the complication came in because people wanted to achieve more with the dialogues and animation.

Thought it might just be possible to open the auto mode text file (or whatever it is) and just edit that.

 

[stuntcock]

Thought it might just be possible to open the auto mode text file (or whatever it is) and just edit that.

If the game had been developed normally then that would probably be true.

Currently there are many details which we would like to customize (such as eye shapes, physics rules, sprite layering, etc) but which are hardcoded. We don't possess the game's source code. We can't just open up the project file, improve it, and then release a new build of the game. Instead we must create an unofficial mod which overrides part of the game's code. The mod itself might allow for reconfiguration via text files.

Obviously this is inconvenient for users. If you want to tweak many aspects of the game then you might need to download a whole slew of mods and adjust forty different settings across twelve different text files. Some of those reconfiguration options might prove to be disruptive or incompatible w/r/t other mods.

The lesson here is to use source control for your software projects. Even if it's just a silly porn game :)

Good example: pim_gd uses a public repository, and he's writing a mod for a silly porn game.

 

[Scoopy]

If the game had been developed normally then that would probably be true.

Currently there are many details which we would like to customize (such as eye shapes, physics rules, sprite layering, etc) but which are hardcoded. We don't possess the game's source code. We can't just open up the project file, improve it, and then release a new build of the game. Instead we must create an unofficial mod which overrides part of the game's code. The mod itself might allow for reconfiguration via text files.

Had wondered why there were no head mods, especially a 'stretchy' graphic that covers that gap in the girls jaw when overly large dongs are inserted where they ought not to be.

So what's the difference between hard coded and... Soft coded?

The lesson here is to use source control for your software projects. Even if it's just a silly porn game :)

Indeed! Kinda surprised no-ones re-started their own version of SDT and put it up on Patreon to make some cash.

 

[stuntcock]

Had wondered why there were no head mods, especially a 'stretchy' graphic that covers that gap in the girls jaw when overly large dongs are inserted where they ought not to be.

That's a slightly different issue.

Flash can't handle freeform deformation, wherein you'd just draw a "normal" cheek sprite and then stretch it to fit the available space. So you end up needing to draw keyframes. Which is actually okay! The mandible is a simple joint, so you can draw a "fully closed" keyframe and a "fully open" keyframe for the cheek, and then tween the stuff in between. There's some additional complexity here involving mouth-shapes (for speech) but let's skip it.

The keyframed-jaw approach isn't really what @Konashion did. He didn't anticipate the "absurd dongs" case. He drew partially-overlapping sprites (you can think of 1 mandible + 1 maxilla, although it's actually a bit more complex) and allowed them to slide across each other. It looks fine when the mouth is closed, and when the mouth engulfs a vanilla-max-size penis ... so therefore everything is fine, no need for further development :)

If you switch to a different game engine then you can do actual FFD. It's not a huge improvement for the appearance of normal human faces (because a face stretched around a giant dick will always look deformed and creepy) but it allows modders to implement new faces/masks/tattoos/etc much more quickly. It's currently very difficult to draw anything on the SDT girl's face because a lot of modding is needed in order to make things stretch as different parts of the face move around.

But the true goal isn't just to treat the SDChan face as a "template" or "canvas" onto which people can draw stretchy graphics. The goal is to give modders the ability to understand and tinker with the anatomy. A modder ought to be able to draw a Pac-Man head or a My Little Pony head or Peter Griffin head or whatever, then adjust the skeleton to fit the new shape, and finally see their work in-game without touching a single line of code.

So what's the difference between hard coded and... Soft coded?

Hardcoded means that critical behavior is embedded into the structure of the code and is therefore unmodifiable. In an ideal world, the SDT auto modes would be defined in an external TXT or XML file which could be edited by users. Instead it does this:

    public function deepSlow_l() : Point
      {
         if(g.penisOut)
         {
            this.avoidPenisOut();
            return this.currentPos;
         }
         this.currentPos.x = this.sinWave(0.25,this.fullLength - 0.1,1.15 - this.fullLength);
         this.adjustAim();
         return this.currentPos;
      }

The key item is the sinWave line. If it was defined in an external file then you could easily edit it in order to make a more "dominant" auto mode. Since it's hardcoded, you must install a mod and configure the mod's external file instead.

The word "hardcoded" isn't meant to be contrasted with "softcoded". It's a play on the word "hardwired" which the author hopes that the reader already understands, even if the reader isn't familiar with software jargon. It suggests a product which is not amenable to modification or repurposing -- either because the creator failed to plan for such use, or because the creator deliberately chose to inhibit or sabotage any future modification.

Hardcoding is usually done because of laziness rather than malice, of course. If your program include a numeric parameter than it might take five minutes to setup a read-from-external-file solution (and then test it to ensure that it works properly). It takes five seconds to define a hardcoded constant.

Indeed! Kinda surprised no-ones re-started their own version of SDT and put it up on Patreon to make some cash.

There's been some discussion. It's easy to nitpick @Konashion's mistakes, but it's important to recognize that he was actually an unusually talented person. He handled the artwork, code, animation, and sound of SDT by himself.

Many people specialize more narrowly (as artists, coders, animators, etc) so you'd probably need a team to move beyond a basic "tech demo" and produce an actual game. If you bring money into question then things can become acrimonious (e.g. if someone feels that they've been deceived, excluded, or cheated). Nobody seems to be very eager to deal with all of that :)

 

[Scoopy]

Spoiler: stuntcock FFD

That's a slightly different issue.

Flash can't handle freeform deformation, wherein you'd just draw a "normal" cheek sprite and then stretch it to fit the available space. So you end up needing to draw keyframes. Which is actually okay! The mandible is a simple joint, so you can draw a "fully closed" keyframe and a "fully open" keyframe for the cheek, and then tween the stuff in between. There's some additional complexity here involving mouth-shapes (for speech) but let's skip it.

The keyframed-jaw approach isn't really what @Konashion did. He didn't anticipate the "absurd dongs" case. He drew partially-overlapping sprites (you can think of 1 mandible + 1 maxilla, although it's actually a bit more complex) and allowed them to slide across each other. It looks fine when the mouth is closed, and when the mouth engulfs a vanilla-max-size penis ... so therefore everything is fine, no need for further development :)

If you switch to a different game engine then you can do actual FFD. It's not a huge improvement for the appearance of normal human faces (because a face stretched around a giant dick will always look deformed and creepy) but it allows modders to implement new faces/masks/tattoos/etc much more quickly. It's currently very difficult to draw anything on the SDT girl's face because a lot of modding is needed in order to make things stretch as different parts of the face move around.

But the true goal isn't just to treat the SDChan face as a "template" or "canvas" onto which people can draw stretchy graphics. The goal is to give modders the ability to understand and tinker with the anatomy. A modder ought to be able to draw a Pac-Man head or a My Little Pony head or Peter Griffin head or whatever, then adjust the skeleton to fit the new shape, and finally see their work in-game without touching a single line of code.

Had no idea that flash was incapable of ffd (didn't even know what it was tbh). What you're saying is that it would be possible to achieve a similar effect with different instances of the face. Can see that being a total fucking nightmare though.

If the true goal is to give modders the means to produce their own new heads entirely has anyone tried to achieve that? Then again I don't really see much point in it per se, you can make little touches to existing static hairs to change the face enough, at least the upper portion of it.

Not that I want to overly dwell on the subject of the jaw split (which can be covered with a bit of imagination and photoshopped static hairs) But a couple of extra rgb layers that rotate or slide into place might be a fix, if such a thing was truly desired.

Spoiler: stuntcock coding

Hardcoded means that critical behavior is embedded into the structure of the code and is therefore unmodifiable. In an ideal world, the SDT auto modes would be defined in an external TXT or XML file which could be edited by users. Instead it does this:

    public function deepSlow_l() : Point
      {
         if(g.penisOut)
         {
            this.avoidPenisOut();
            return this.currentPos;
         }
         this.currentPos.x = this.sinWave(0.25,this.fullLength - 0.1,1.15 - this.fullLength);
         this.adjustAim();
         return this.currentPos;
      }

The key item is the sinWave line. If it was defined in an external file then you could easily edit it in order to make a more "dominant" auto mode. Since it's hardcoded, you must install a mod and configure the mod's external file instead.

The word "hardcoded" isn't meant to be contrasted with "softcoded". It's a play on the word "hardwired" which the author hopes that the reader already understands, even if the reader isn't familiar with software jargon. It suggests a product which is not amenable to modification or repurposing -- either because the creator failed to plan for such use, or because the creator deliberately chose to inhibit or sabotage any future modification.

Hardcoding is usually done because of laziness rather than malice, of course. If your program include a numeric parameter than it might take five minutes to setup a read-from-external-file solution (and then test it to ensure that it works properly). It takes five seconds to define a hardcoded constant.

Thank you for explaining that. Can't say I totally comprehend but appreciate it nonetheless.

Spoiler: sc

There's been some discussion. It's easy to nitpick @Konashion's mistakes, but it's important to recognize that he was actually an unusually talented person. He handled the artwork, code, animation, and sound of SDT by himself.

Many people specialize more narrowly (as artists, coders, animators, etc) so you'd probably need a team to move beyond a basic "tech demo" and produce an actual game. If you bring money into question then things can become acrimonious (e.g. if someone feels that they've been deceived, excluded, or cheated). Nobody seems to be very eager to deal with all of that :)

No no, I'm not trying to downplay Konashions work or his abilities. It's certainly a more interesting legacy than most of us would leave behind. However there are things that were not implemented into SDT that others wanted to see in this 'silly little game' otherwise this group of modders wouldn't work around it.

Yes of course, any project to put together (especially where money is concerned) can be difficult to manage or adequately have the wealth and workload shared about amongst those working on it. Even harder are to find the right people who are honest and hard working who know what they're doing. That's what managers are for and those guys are often right cunts, I should know.

 

[stuntcock]

If the true goal is to give modders the means to produce their own new heads entirely has anyone tried to achieve that?

Sorry, I miscommunicated on that point. I meant that it's a goal for any development project which seeks to remake SDT. It's barely feasible to consider such a project in Flash, and it's not at all feasible to consider it with the SDT codebase.

The FFD limitation isn't really the greatest "sin" of Flash. Poor runtime performance is more signifiicant, because it forces designers to compromise their ideas and simplify everything. Platform restrictions are worse, because it limits the fanbase. Licensing restrictions are worst of all, because they hugely curtail the creativity of the community and prevent many novice modders from ever getting involved.

Then again I don't really see much point in it per se, you can make little touches to existing static hairs to change the face enough, at least the upper portion of it.

But that's the point: modders are restricted to the top half of the face. Their creativity is limited and there are many ideas which they're prevented from properly implementing. Some people have tried anyways (example) but they're pretty much doomed to disappointment.

Not that I want to overly dwell on the subject of the jaw split (which can be covered with a bit of imagination and photoshopped static hairs) But a couple of extra rgb layers that rotate or slide into place might be a fix, if such a thing was truly desired.

Yeah, all of that discussion was in the context of a remake project (which I should have stated explicitly). In that context we wouldn't seek to include a few extra moddable layers (which would indeed be a more economical fix for SDT); we'd instead implement a proper skeletal rigging system with FFD.