tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
It heavily depends on the CGs we have available and the characters I have planned.
As for now, it is highly likely that there will be futa contents since there's a character who is futa in the base game and she have sex with the player,
I don't have anything planned involving incest, pretty much because there are not blood-related characters (except Sana and her mom), so only lesbian incest is possible, I'm not against it but not a priority for me.
For bestiality, it depends on whether you consider orcs/goblins as beasts or not, if so, then yes, there will be bestiality in the game, I have already a backstory and a few quests written for orcs and goblins.
Theoretically, I can create a toggle for any fetish (netorare, femdom, consensual non-consent, etc...), I said in theory because I still need to implement the new quest/event system, the content of the game (and the contents done by modders) will be represented through these systems (quests or events have a list of conditions they need to meet before activation, so a NTR event can check if the NTR content is enabled or not before firing), this makes the game flexible if someone wants to enable NTR and disable it later on in the game, any NTR quest/event done before disabling NTR will remain as done for the rest of the systems though (like the Sana's sex diary if she has participated in a sex scene with another man), so as long as everything goes according to my plan and design it should be doable.
------------------------------
*1: Actually, thanks to the sex framework Ryuna may not need to draw her, since she is futa, she could re-use generic CGs in which only the penis is drawn, in that way I can create quests/events involving her and Sana, re-using these generics CGs, there will be more info about these "generic" CGs once I come back to the sex framework!
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
Thank you! Hopefully I can meet those expectations, I appreciate your words.
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
As a little update for y'all I'm still working on the input mapping/binding.
1. As for now, I have already created a module which allows to rebind keys to the user's desires, this module is available for both the game and mods, each mod needs to create their own input actions and map them to keys/buttons.
2. Keybindings (known as input mappings) are saved in the configuration module without problems
3. The controller is fully compatible!
4. All issues with the old input system has been resolved, the new input system is smooth as fuck! and everything works correctly, whether it is a single key/button or a combination.
5. Added a new method to check whether a key or an input mapping is being released, being released means that the user has pressed down a key/button and just released it.
I encountered a problem with the movement that I just solved today:
I had to implement a new method that "mirrors" the native methods RPG Maker uses to determine the movement (up/down, left/right and whatnot) it was a little pain in the ass to do this since there is not much documentation so I had to spend more time than I wanted in this, the problem was that RPG Maker determines the movement direction using the default keys (directional arrows) and the left stick in controllers (left stick up, down, etc...), so if you mapped the movement to WASD the player won't move.
I managed to replicate this behavior so everything is working as it should but checking the input mappings for movement, so if you map the movement keys to WASD or to the right stick in the controller it works without problems and you are able to move the character.
There are some problems I am currently dealing with:
1. Every window in the game should be adapted to the new input system, this involves modifying all windows that comes with RPG Maker and make them interact with the new module (I'm currently working on this)
2. There are some issues in the configuration scene when setting keybindings, I need to create a window to listen to key/button-strokes and register them (I'm currently working on this)
3. The window (keyboard) input I have created is not compatible with controllers, since it only listen to the keyboard
-> This one is not a huge problem, I will need to do something about this before v1.0, but it is not a priority
4. The scene the game uses to change an actor's name is not compatible with the keyboard, and also, more importantly, it only uses latin characters, so it is impossible to rename a character with japanese/chinese characters.
-> Like I said above for point 3, not a priority for me as for now since it is only a test release, but I gotta do something about this later on, so anyone can rename characters with special characters.
Hopefully I can come up with a devlog sooner than later about the new input system.
1. As for now, I have already created a module which allows to rebind keys to the user's desires, this module is available for both the game and mods, each mod needs to create their own input actions and map them to keys/buttons.
2. Keybindings (known as input mappings) are saved in the configuration module without problems
3. The controller is fully compatible!
4. All issues with the old input system has been resolved, the new input system is smooth as fuck! and everything works correctly, whether it is a single key/button or a combination.
5. Added a new method to check whether a key or an input mapping is being released, being released means that the user has pressed down a key/button and just released it.
I encountered a problem with the movement that I just solved today:
I had to implement a new method that "mirrors" the native methods RPG Maker uses to determine the movement (up/down, left/right and whatnot) it was a little pain in the ass to do this since there is not much documentation so I had to spend more time than I wanted in this, the problem was that RPG Maker determines the movement direction using the default keys (directional arrows) and the left stick in controllers (left stick up, down, etc...), so if you mapped the movement to WASD the player won't move.
I managed to replicate this behavior so everything is working as it should but checking the input mappings for movement, so if you map the movement keys to WASD or to the right stick in the controller it works without problems and you are able to move the character.
There are some problems I am currently dealing with:
1. Every window in the game should be adapted to the new input system, this involves modifying all windows that comes with RPG Maker and make them interact with the new module (I'm currently working on this)
2. There are some issues in the configuration scene when setting keybindings, I need to create a window to listen to key/button-strokes and register them (I'm currently working on this)
3. The window (keyboard) input I have created is not compatible with controllers, since it only listen to the keyboard
-> This one is not a huge problem, I will need to do something about this before v1.0, but it is not a priority
4. The scene the game uses to change an actor's name is not compatible with the keyboard, and also, more importantly, it only uses latin characters, so it is impossible to rename a character with japanese/chinese characters.
-> Like I said above for point 3, not a priority for me as for now since it is only a test release, but I gotta do something about this later on, so anyone can rename characters with special characters.
Hopefully I can come up with a devlog sooner than later about the new input system.
Pretty cool of you to add vanilla to a ntr focused game I'm not really an ntr person unless im the one who's doing it, it just feels wrong and unenjoyable but aye we all have different taste right, but anyways thanks for thinking about us.
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
Input System Devlog
Hello there!
It's been some time since the last devlog, Like I said in previous posts, I have been working on revamping the input system, fixing old code and trying to to bring it into modern standards, hopefully the work I have done is good enough to achieve this.
As a summary of what I have done this past few weeks:
- I have removed all dependencies of the Windows API
- I implemented a new module that replaces the original RPG Maker key codes and button codes (for gamepad), it covers the whole keyboard and the most common gamepad buttons, this module is called Input Map
- I have added backwards compatiblity translating the original key codes to the new ones.
- This input map module allows me to create actions (like interact, cancel, move left, move right, etc...) and map a list of key and buttons to this action
- Each input map has three possible keybinds:
- Main: Main keys/buttons for this action, cannot be removed/cleared, only changed
- Alt 1: First set of alternate keys/buttons for this action
- Alt 2: Second set of alternate keys/buttons for this action
- You can map key (and buttons too!) combinations to an input action, for example:
- You can create an input action: "Open Sex Scene Menu" and map it to use: "Left Shift + G"
- This input action will trigger only when both of these key codes are pressed, you can also perform a "exclusive" check in case you don't want this input action to trigger if other keys are pressed.
- For example: "Left Shift + G + H": Won't trigger since H was pressed
- I have created a default input map bindings for the base-game input actions
- These bindings allows the game to be played in several ways, by this I mean you can play the game single-handedly lol
- "Left hand only": WASD, Space, Tab, Left Shift, etc...
- "Right hand only": Arrow keys, Return, Backspace, Right Shift
- "Both hands" (Main): Default RPG Maker mapping
- Both left hand and right hand mappings are mapped using the alt 1 and alt 2 keybinds, the "both hands" mapping is the default option
- If you have played RPG Maker games before, this feature makes the RPG Maker F1 menu useless, keybindings are now changed in-game, and are not limited to what RPG Maker offered originally of course.
- I have plans to modify mkxp-z source code to free F1 and F2 keys (later on development) so they are usable in-game
- These bindings allows the game to be played in several ways, by this I mean you can play the game single-handedly lol
- Modders are able to register new keybindings and create hotkeys to map their custom actions
- I updated all windows (and the rest of the original RPG Maker code) to use the new input system
- I have created a new window to use inside the configuration scene to register the key bindings (compatible with both the keyboard and the gamepad)
- (A bit technical to understand) I have been modified the selectable window to extract the handler (callbacks) functionality into the base window, in the process, I have changed it to use input mappings and the code is now cleaner
- You can run a callback (handler) inside any window easily when an input map is pressed and the window is active, all you have to do is just register them when creating the window.
- Before this, you had to overwrite several methods from the selectable window, which could result in bugs if the base window method is changed in the future.
How does it looks?
Take a look! (excuse the spam of pictures, I was lazy to record a video lol)
As you can see, the same window works perfectly for both gamepad and the keyboard, it's important to note that, if you want to change a binding for the gamepad, you must have a gamepad connected, otherwise the window won't open because you will be stuck since the window will be waiting for gamepad input.
The window allows two behaviors, setting a combination or keys or a single key, for testing purposes, all pictures has the "combination" flag ON.
There is also two new options: Joystick and triggers dead zone, which allows you to set the deadzone for both the gamepad triggers and joysticks.
The menu also renders which controller you have connected right now, in case you have more than one and don't know which one is active in the game.
These configuration menu entries are created like the other ones I explained before, example:
JSON:
{
"entry_type": "keybind",
"entry_display_name": "$cfg_menu_controls_up",
"entry_description": "$cfg_menu_controls_up_desc",
"entry_config_name": "key_up",
"entry_options": {
"keybind_combinations": false,
"keybind_mode": "keyboard"
},
"entry_config_context": "sana"
}- New entry type: keybind
- New entry options:
- keybind_combinations: Flag to allow keybind combinations or not
- keybind_mode: Sets the keybind input mode (keyboard, gamepad)
Any downsides?
The main downside is because of the way the configuration module is designed, as you may know if you checked my last devlog, the configuration system is made in a way in which you create each option individually, this means that, if I want to allow users to map the alt. 1 and alt. 2 for an action, I have to create a setting for each ones of these like: "key_up1" and "key_up2", but that's not it, if I want to allow mapping the gamepad controller too, I will need to create yet another two settings: "pad_up1" and "pad_up2", this makes the process of creating settings for the input mappings very verbose, for example if you have 8 input mapping settings and you want to allow the user to map alt. 1 and alt. 2 for each one (both the keyboard and controller) you have: 8 x 2 x 2 = 32 settings just for that.
Honestly I don't think I will work on fixing this downside, since the system does not force you to map alt 1 and alt 2, as long as main is mapped, you are good to go, this is probably a problem for me since modders won't need to allow mapping many keys or buttons with their mods, but I will probably need to spend some time to properly create all settings for each mapping if I want to allow different layouts so you don't have to do it manually (you know? the left hand only and right hand only thing), anyways it's easier than redesigning the whole configuration module, which I'm not going to do because, apart from this downside, it works great.
Is there anything left?
Yep, the work is not finished with the new input system, I still need to solve this problem:
- Different input actions can have the same combinations of keys/buttons (keybindings conflicts)
1. You have two input actions: Confirm and Cancel
2. Confirm is mapped to Z and Cancel to X
3. You map Confirm to X
4. The game won't complain because there is no code that performs this check
5. Now, you have Confirm mapped to X and Cancel to X
6. You cannot interact with anything in the game anymore because as soon as you want to Confirm you will also Cancel the action
I will probably fix this by allowing to set a list of incompatible "actions" for each action, so for example, for the action "Confirm" I can add the action "Cancel" as incompatible, being incompatible means that none of the keybindinds must match between these actions, if anyone matches when binding a new key the game will complain about it, likewise, the Up action is incompatible with the Down action, same happens with Left action and Right action.
Besides of this, I consider the new input system to be good enough to continue development.
What's next?
Once I take care of the keybindings conflicts I explained above, the sex framework is up next and this last one will be the last piece of work I have to do for v0.2
ElDonBigotes
Member
- Nov 22, 2020
- 357
- 96
- 152
Thank you very much for your work, and I'm looking forward to playing it. One question later: Can I use the mouse instead of the keyboard? English isn't my language, sorry.
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
No problem!
As for now, it is not possible to play with the mouse because it is "not supported".
I have put it in quotes because the mouse is actually recognized by the new input system, as you can see in this screenshot (mouse_left for Confirm and mouse_right for Cancel), the mouse wheel is also supported (scroll up and scroll down) BUT you cannot use it like you would use it in new RPG Maker MV games since that would require lots of work to make the windows and the player's movement work with the mouse.
Maybe in the future I'll consider doing this but it is not a priority right now.
RenH
Active Member
- Nov 5, 2020
- 777
- 2,312
- 363
Looks promising! Don't worry too much about taking your time. Would much rather have a dev take a while with honest version numbering instead of pushing out what seems like v.0.8 in a few months but feels like 0.2.
Ř@ĐįäÞïőñ
Member
- Jul 30, 2018
- 332
- 411
- 278
consistant update and work-life balance is the key.
this man did this mod for free out of love for the game or just hobby.
we do not want fast cash grab update (even if it's free) causing fatigue and burnt out, we just want genuine update within devs time and pace.
we do not entitled to anything but ofc we'd want some update once in a while because this mod is literally the only light in this dark sky.
nowhere for this game out there getting reworked art with engine custom made/update.
even the og dev moved on to another project.
this mod at this point is a remake of SANA game.
as always thanks for the update and stay safe!
this man did this mod for free out of love for the game or just hobby.
we do not want fast cash grab update (even if it's free) causing fatigue and burnt out, we just want genuine update within devs time and pace.
we do not entitled to anything but ofc we'd want some update once in a while because this mod is literally the only light in this dark sky.
nowhere for this game out there getting reworked art with engine custom made/update.
even the og dev moved on to another project.
this mod at this point is a remake of SANA game.
as always thanks for the update and stay safe!
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
Thanks! I appreciate your words, gotta thank Ryuna_the_2nd too for stepping in to redraw the game CGs and refusing to stop or drop it out of tiredness for this long, specially since this does not bring any revenue
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
Input System Devlog (Pt. 2)
Hey, one the major issues I had in mind before creating the Input Map module was related to this, it was that by allowing to remap keybindings the player would make the game unplayable by mistake, that is not a problem anymore since the keybinding conflict problem is solved (hooray!), I still need to finish some details here and there but the most important part of the code is finished.
How does rebinding work?
Like you may know already from the previous devlog, input map actions represents the mapping of an action to a list of keyboard keys or gamepad buttons and each of them has three slots (main, alt. 1 and alt. 2), now each input action has new flag attributes:
- Unclearable: Determines whether an input map action can be cleared or not
- Defaults to false (by default all actions are clearable)
- Unique: Determines whether an input map action is unique in the game or not
- Defaults to false (by default all actions are not unique)
Of course, the alternative slots (both alt. 1 and alt. 2) are clearable since they are optional, it only checks the main slot, for both keys and buttons.
I have made it false by default mainly because the vast majority of mods should not use this, since they should allow players to clear their keybindings/hotkeys.
About the unique flag, this flag makes an input action unique in the game, including the input actions provided by mods, the combination of keys/buttons that an unique input action is using cannot be ever used by any other input action.
I have only made unique the essential actions of the game, because if these actions ever conflict with something else, it has the potential to make the game unplayable, for example:
- Movement keys
- Main: UP, LEFT, DOWN, RIGHT (ARROWS)
- Alt 1: W, A, S, D
- Confirm keys
- Main: Z
- Alt 1: RETURN
- Alt 2: SPACE
- Cancel keys
- Main: X
- Alt. 1: TAB
- Alt. 2: BACKSPACE
- Menu keys
- Main: ESCAPE
Yeah I know, the messages shown when the keybindings conflict may not be easy to understand (like what the hell is "slot: 0"), believe it or not, as many games I have played in my life, sometimes I find hella difficult to write error/info messages like this which are easy to understand and clear enough lol, I'll change the wording to make it clearer.
In case you have not noticed, I've also changed the way clearing a binding works, previously the ESCAPE key was not usable as a normal key because it was reserved by the game to clear bindings, I kinda did not like this so I've changed the behavior of the keybinding window to un-assign when the ESCAPE key is hold during some time, if the ESCAPE key is released before this time, it will be treated as a valid key code.
Funny thing is that, as simple as it sounds, doing this took me a headache due to synchronization issues, I used Ruby fibers for the binding process and doing so bugged out the code of the scene and freezed the windows, took me a week or so to realize what the hell was going wrong.
Other minor changes
I have changed how configuration menus are shown in the settings scene, previously they were inserted without any particular order, meaning that they appeared in the menu in the same order they were created, I thought that sorting them alphabetically would make it easier for players to find a specific menu, specially if they install many mods that provides new config menus, so I modified the code to sort them like that.
Though, I wanted the game config menu to always appear at the top of the list (for ease-of-use), so the only menus that are sorted are the ones added by mods, the game uses the display name to sort the menu in the list, in case the name is localized, it will translate it first before sorting them, so ordering localized menus is doable.
I have also enabled quick scrolling for the config menu windows, if holding down the prev. page or next page actions, the cursor will move up/down as many positions as needed to go to the next menu that is not shown.
As you can see here, Side Stories is shown last due to starting with S:
If you change the display name, it will be shown above others:
No matter how many menus you have installed, the game config menu will always appear on top.
Besides of this, I've also fixed some logic bugs in the Configuration module, which btw are the worst types of bugs because it seems everything is working as it should and suddenly it breaks the game with almost no trace/logs report, though this is kinda technical so I'll skip this part lol.
Due to what I said above and looking ahead to the future, I improved the logging module to create copies of existing log files, in case you find a bug and decide to play the game again instead of reporting it, the log file won't get overwritten, the game now will keep up to 3 copies of previous log files (game_log1.log, game_log2.log and game_log3.log), and one working log file (game_log0.log)
See y'all in the next devlog!
Last edited:
ElDonBigotes
Member
- Nov 22, 2020
- 357
- 96
- 152
It's been over a month since the last update on the project's progress, how are things going?
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
I have nothing substantial to show yet, I had my vacations around mid August and I've been relaxing.
I'm back to my IRL job from my vacay and as usual, I have a big pile of work I need to do before resuming the project, I will have more things to share eventually as I get back to my routine.
Also I think that before resuming the project and since Windows 10 EOL is next month I will probably move my work PC setup to Linux, it will make it easier to test the game for Linux and also develop the fork I'm using of MKXP-Z for Sana, it is a pain in the ass in Windows to compile and modify the source code.
tygct
Member
- Jun 6, 2017
- 168
- 977
- 346
Status Update
Not really much of an important update, just wanted to say that I am alive and finally moved my setup to Linux and even though it took me longer that I thought everything is working properly for now (God bless Steam's Proton for making everything easier), also since I started anew I decided to use VSCodium instead of VSCode, so it took me so extra work to move everything into VSCodium and find extensions that replaced some that I used in VSCode that are not available there.
I created a VSCodium workspace while I was testing extensions and I think I could use it to share a common ground for mod makers in the future, the extensions I use are automatically recommended to be installed and everything is configured properly within the workspace settings for both Windows and Linux, so I can turn this into a (kindof) plug-and-play environment to create mods.
I don't think I shared the last thing I did before migrating OS, I guess I can let you guys know until I got something better to share about the sex scene framework.
I had to revisit the drawing board so to speak, because there were some problems when it comes to sex animation overlays and sounds, the way I designed did not allow me and modders to create overlays and sounds separately from the animation, so if someone wanted to create an animation overlay/sound pack they would always have to overwrite the animation base files, I managed to re-design this part to actually allow this (at least I think for now).
The downside is that this will introduce incompatibilities if a overlay pack is used with animations base files that were changed by other mod, for example:
If you, as the user, install these three mods:
- Animation Pack A (contains the base animation files)
- Animation Pack A - Overlays (contains overlays for "Animation Pack A" made by another modder)
- Animation Pack A Continued (A redrawn/better version of "Animation Pack A" changing the base shape made by another different modder)
In this situation you will end up with the overlays that comes from "Animation Pack A - Overlays" appearing over the new "Animation Pack A Continued" and they will probably appear as if they are out of place and/or floating since the base shape may have changed, still I'd rather have this than not allowing to create sounds and overlays packs for animations.
My main goal with this is to separate, as much as possible, the art part of the game into smaller pieces of work, so allowing different people to work on the same animations base files is better than working on the whole package.
This screenshot shows the contents of the game's database, now as I said, sex scene sounds and overlays are independent instances of the base animation file (which is the blowjob.sxa one), before this change, they were all inside the element_sex_animation thing as "addons", this instances are later "glued together" when the sex framework detects a change in the database and rebuilds a registry of animations, this registry contains sex animations with all components together and ready to be loaded to avoid lag and frame drops as much as possible when the sex framework requests new animations for a new scene.
Depending of the amount of RAM used in future test versions and the amount of animations, I may change the current behavior to preload all bitmaps into memory, making the animation registry as fast as possible since they will be loaded in the RAM already, which is the most expensive part of the process.
See ya'll in another devlog/update, hopefully sooner than later.