CREATE YOUR AI CUM SLUT ON CANDY.AI TRY FOR FREE
x
4.10 star(s) 11 Votes

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
I've finally done it. The store is up and the release date should be the 23rd at the earliest. This may just be the one thing that sets me up for a bright future as a creator.

PS: Chapter two is still coming. I've been really busy trying to get the game launched on steam, but I will resume work on it full "steam" ahead, soon.
 

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
Speaking of dickgirls, I kinda wish you could choose between making a character a female or a dickgirl on a case-by-case basis. For example, I liked elf servant and Hazel but would rather have the dream demon have a pussy. But that's again purely my taste issue I guess.
Don't you worry about that. They were "dream sequences" for a reason. In other words, it does not mean that you will get fed a massive meat rod against your will. It simply means that the option for it is there. To be crystal clear. If you have trans on and said character is trans, they will have a third leg. However, I can understand how this may not always be the desired choice for some. With that in mind, we are going to allow switching for main characters, and important ring summoned dickgurls,girls. Into female/trans. And know that this can already be done by simply turning off the "dick" option in the options menu, for say "demon" (trans off, meaning, for the time being)
 
Last edited:
  • Like
Reactions: darth_hiruma
May 3, 2022
174
439
The story is going pretty good and probably one the best from onemanvn at least for me. Although I am harem lover & I love plenty of fap contents but I believe it should be spread out, a delayed gratification is something people would love rather the moving from point A to B & sticking it in somebody and then B to C and so on(Even Shrink is following the same trend from last two updates).. after all we are not here just for the porn.
 

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
I really need your help with THE FATE OF MIRADOR (Steam build) I need one person who uses MAC and one person who uses Linux if they exist here to message me. Or simply reply here. I want to be 100% sure that the Steam build works for the 12 MAC users and the 78 Linux users around the world.

Edit: This issue has now been resolved. The same build plays for all platforms. Thanks for reaching out.
 
Last edited:

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
The story is going pretty good and probably one the best from onemanvn at least for me. Although I am harem lover & I love plenty of fap contents but I believe it should be spread out, a delayed gratification is something people would love rather the moving from point A to B & sticking it in somebody and then B to C and so on(Even Shrink is following the same trend from last two updates).. after all we are not here just for the porn.
There is no trend for the SHRiNK to follow. It has always been that way, it was never a story-focused game, to begin with. The only difference right now is one MC and a lot of females/trans, etc. The story is progressing at a slower pace and the virus has made everyone except the MC "very agreeable" to having sex with the horny MC. The reason why everything looks so easy for him was made clear since the first-ever update.

As far as FOM is concerned, there will be plenty of fappening, happening, but not as much as SHRiNK and or as often right away. It will depend on player choices and whether or not they have chosen to go HAREM mode.
 

Master of Puppets

Conversation Conqueror
Oct 5, 2017
7,548
10,058
I really need your help with THE FATE OF MIRADOR (Steam build) I need one person who uses MAC and one person who uses Linux if they exist here to message me. Or simply reply here. I want to be 100% sure that the Steam build works for the 12 MAC users and the 78 Linux users around the world.
I use Linux but don't do adult games on Steam, probably can't help because of that but letting you know just in case.
 

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
I use Linux but don't do adult games on Steam, probably can't help because of that but letting you know just in case.
Uh, okay? Thanks. And this would only be a review copy, not like it is live or anything. You could uninstall it and voila. Anyhow, no worries. I'm sure someone else will pop up until the release date.
 

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
It's official. THE FATE OF MIRADOR has been accepted on Steam. The earliest possible release date is the 23rd. In other words... I will be going live on exactly that date. 3 AM PST or whatever is steam time.:)
 

OneManVN

Engaged Member
Game Developer
Nov 16, 2018
2,490
5,861
I am currently hospitalized after an ER visit around 3 AM today and despite that, I am truly happy to see FOM finally alive and well on Steam. Thank you to every single person on here who has ever had a single kind and encouraging word to throw my way.
You have no idea how much that has helped me keep going these last 4 years and some change.

As for me, they just want to keep me for observation for a few days, at worse. I will despite the doctor's wishes, keep working with my very expensive (for) third-world laptop and even sleep with it cuddled safely in my arms to prevent theft.
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
11,016
16,299
OneManVN

The exact same variable is used to store the character object, and the name of the character:
Python:
define o = Character("[o]", color="590059")
Followed by:
Python:
label scene4:
    [...]
    $ o = renpy.input("(Default is Oriana)")
    $ o = o.strip()
    if o == "":
        $ o ="Oriana"
Same for Lilith and Alistar.

So far it works because the object handling the dialogs are built before the value is redefined. But at some point it will comeback to you and break the game.


It's fixable to a small price (o, l and a will now be saved, what isn't an effective problem):
In definitions.rpy:
Python:
define oname = "Oriana"
define lname = "Lilith"
define aname = "Alistar"

define a = Character("[aname]", color="ffd792")
# ath will automatically adapt.
[...]
define l = Character("[lname]")
[...]
define o = Character("[oname]", color="590059")
Then anywhere on the script:
Python:
label after_load:
    if not isinstance( o, renpy.character.ADVCharacter ):
        $ oname = o
        $ o = Character("[oname]", color="590059")
    if not isinstance( l, renpy.character.ADVCharacter ):
        $ lname = l
        $ l = Character("[lname]")
    if not isinstance( a, renpy.character.ADVCharacter ):
        $ aname = a
        $ a = Character("[aname]", color="ffd792")
        # ath will automatically adapt.
And of course a change in script.rpy (line 647+, 881+ and 5313+) to now use the "oname", "lname" and "aname" variable when the player is asked to choose a name.
 

Master of Puppets

Conversation Conqueror
Oct 5, 2017
7,548
10,058
OneManVN

The exact same variable is used to store the character object, and the name of the character:
Python:
define o = Character("[o]", color="590059")
Followed by:
Python:
label scene4:
    [...]
    $ o = renpy.input("(Default is Oriana)")
    $ o = o.strip()
    if o == "":
        $ o ="Oriana"
Same for Lilith and Alistar.

So far it works because the object handling the dialogs are built before the value is redefined. But at some point it will comeback to you and break the game.


It's fixable to a small price (o, l and a will now be saved, what isn't an effective problem):
In definitions.rpy:
Python:
define oname = "Oriana"
define lname = "Lilith"
define aname = "Alistar"

define a = Character("[aname]", color="ffd792")
# ath will automatically adapt.
[...]
define l = Character("[lname]")
[...]
define o = Character("[oname]", color="590059")
Then anywhere on the script:
Python:
label after_load:
    if not isinstance( o, renpy.character.ADVCharacter ):
        $ oname = o
        $ o = Character("[oname]", color="590059")
    if not isinstance( l, renpy.character.ADVCharacter ):
        $ lname = l
        $ l = Character("[lname]")
    if not isinstance( a, renpy.character.ADVCharacter ):
        $ aname = a
        $ a = Character("[aname]", color="ffd792")
        # ath will automatically adapt.
And of course a change in script.rpy (line 647+, 881+ and 5313+) to now use the "oname", "lname" and "aname" variable when the player is asked to choose a name.
Considering that character objects and strings are effectively interchangeable, I'm not sure it would break the game unless you're doing something weird. Personally I don't really see why people use different variables to hold character names, when you can just change the name field on the character object directly:
Python:
    $ o.name = renpy.input("(Default is Oriana)", default="Oriana")
    $ o.name = o.name.strip()
    if o.name == "":
        $ o.name ="Oriana"
Is there some downside to doing it that way that I've not heard of?
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
11,016
16,299
Considering that character objects and strings are effectively interchangeable, I'm not sure it would break the game unless you're doing something weird.
I don't know what make you believe this, but they aren't at all interchangeable.

Ren'Py works despite the second assignation, only due to a side effect of Python immutability.
When you assign a new value to an attribute, you don't erase the previous one, but make the attribute point to this new value. Therefore, the previous value (here the character object) will persist as long as there's at least one attribute pointing to it. And the fact is that all the AST entries related to Oriana's dialog line are pointing to the "o" character object.

And you don't need to do something weird to break the game. Referring to the character object in another way than as sayer pseudo statement is enough ; except with "[o]", for obvious reasons. There's dozen of threads regarding it in the developer section of the forum. Last time someone had a problem because of this was yesterday.


Is there some downside to doing it that way that I've not heard of?
Yes and no.

By default characters are created as not savable, because they are constants through the game. Therefore assigning the value directly to their "name" attribute will only works for the current update. But, obviously, this also mean that it would works if you create them as savable.
In the end, it's more a question of personal choice than anything else. The third party variable being the most used mostly due to Ren'Py's legacy.
 

Master of Puppets

Conversation Conqueror
Oct 5, 2017
7,548
10,058
I don't know what make you believe this, but they aren't at all interchangeable.

Ren'Py works despite the second assignation, only due to a side effect of Python immutability.
When you assign a new value to an attribute, you don't erase the previous one, but make the attribute point to this new value. Therefore, the previous value (here the character object) will persist as long as there's at least one attribute pointing to it. And the fact is that all the AST entries related to Oriana's dialog line are pointing to the "o" character object.
No, it works because in Renpy "Oriana" "Oriana says this" is explicitly equivalent to Character("Oriana") "Oriana says this". If you later assign a value to the name that is not a string such as an integer, you get an immediate error regardless of what value was previously assigned to that name.
And you don't need to do something weird to break the game. Referring to the character object in another way than as sayer pseudo statement is enough ; except with "[o]", for obvious reasons. There's dozen of threads regarding it in the developer section of the forum. Last time someone had a problem because of this was yesterday.
No, referring to a character variable in a variable substitution like o "My name is [o]" works fine if o is a character object, because str(o) returns o.name for character variables. That's what I mean by them being effectively interchangeable; using a string as a sayer statement is explicitly defined as equivalent by the spec, and using a character object as a string works because the class is set to simply return the name when used in that way. What other ways would one use a character object that would fail?
Yes and no.

By default characters are created as not savable, because they are constants through the game. Therefore assigning the value directly to their "name" attribute will only works for the current update. But, obviously, this also mean that it would works if you create them as savable.
In the end, it's more a question of personal choice than anything else. The third party variable being the most used mostly due to Ren'Py's legacy.
True, variables set using define are technically not supposed to be saveable, though in the current implementation they are, exactly the same as variables set using default; they aren't immutable and they are saved. But it is true that for future-proofing, if storing variable data in a character object they should be initialised with default instead of define.
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
11,016
16,299
No, referring to a character variable in a variable substitution like o "My name is [o]" works fine [...]
You want so much to contradict me, that you start every sentence by "No", while saying exactly the same thing than me :
Referring to the character object in another way than as sayer pseudo statement is enough ; except with "[o]", for obvious reasons.

Anyway, this isn't the place for such debate.
 

Master of Puppets

Conversation Conqueror
Oct 5, 2017
7,548
10,058
Is there any incest in the game or plans to add it?
Yes. He has a cousin, and you can fuck her. No idea how much more family he might have. I don't think it's going to be as big a part of the game as in The Shrink, but it's there.
 
4.10 star(s) 11 Votes