Phoenix BJ Trainer V0.2 (SBBJT V0.2)

[johns1234]

Questions:

• Should the user be made to test each method prior to starting a session from a safety point of view?
• Is that too draconian?
• Or at bare minimum the release method?
• Am I over thinking things now

If the idea is that a scenario can be sent to someone else in an encrypted file, then you would need to separate the release and event methods out, so they can be fitted to the individual setup. Maybe to make it easy have fixed event names "Release", "Punishment1", "Punishment2", "Punishment3", "Tease1", "Tease2", "Tease3", ... and add a new button next to Edit session to set them up. This would actually be really convenient as on a local computer these methods are unlikely to change, so whenever you setup a new scenario instead of having to select the program and parameters and so forth every time you could just reference what should happen on the event by name.

I think the program gains excitement from the "unknown" which is in this case just the randomness of number of sucks for example. As you introduced jobs already one nice feature to have would be instead of all jobs executed in sequence to have options "random number of jobs X" with min/max and then during a session a random number of randomly selected jobs have to be completed.

Exchanging an encrypted file for a scenario someone else thought out (not much randomness required here) takes this obviously a step further. I can already see people exchanging those and submitting their report cards. Actually considering that people may share their report cards, maybe pictures on there should be optional.

[Phoenix]

Think you've laid it all out there well Johns1234.

I like the idea of the standard names. Easy enough to do with another EventAction style form and then store as a local XML. As you said this will make setup for future sessions much easier as well. Think I'll need to jump this up the queue to implement.

Random jobs is on the cards to implement. Hard one to judge will be how many of the settings in a job to make randomised for a random number of jobs. Could end up with a huge Min/Max form if not careful.

The idea to allow interchange of session files between people was one of the key ones I wanted to implement. Having it encrypted allows for the total unknown. I hear what your saying with the photos though. Is it worth doing one pdf with and one without? Easy enough to do once the core code is done.

Speaking of which been playing around with the Report draft generator with some dummy images in place:

Code currently allows for a definable boarder to be set around an image taken from the harddrive and then apply abstract rotations and a resizing event.

Grade stamp is interchangable depending on a value from the data.
"Items" are just raw MI representation at the moment.

[johns1234]

I am curious about getting an "unknown" session once, that will be interesting. Finishing a job and hoping it's over ...

I like the report card, but .... 3/325 failed is a D? That is over 90% good - a D!? Unfair! lol

To make the report more verbose you could include more info about the session:
- number of jobs (maybe even broken up with a section per job and a summary section?)
- total session time
- release time
- if it was cancelled also, I guess that's an F
- how many "PunishmentX" or "TeaseX" were executed

[Phoenix]

A D seems fair to me lol At the moment these are all dummy hard coded values. The report is pure POC until have worked out the engines underneath. I've already got the starts for the grading system in place and current thought is to have % thresholds of the max values against each of the grades. Then to treat each A as 5, B as 4 etc and then final grade is done off total points. Session grade could be average of all job grades. Settings for this would be customisable on a session basis with a default included.

I like everything in your more verbose suggestions! Please keep them coming

As looking to track many more stats should there actually be the possibility to fail a job/session? Ie Failing X DT causes the job to fail. Two failed jobs in the session causes session fail with Y punishment.

[johns1234]

As looking to track many more stats should there actually be the possibility to fail a job/session? Ie Failing X DT causes the job to fail. Two failed jobs in the session causes session fail with Y punishment.

The "Cancel session after X consecutive fails" is more a safety setting, lets say the camera moved or something like this.
What you describe is good though, to me this sounds more like a special ending scenario: If you were doing so bad then instead of the regular release time, the release time is X with random punishments while waiting?

[Phoenix]

Exactly

I think it's very important to have the "Cancel session after X consecutive fails" from a safety point of view but also thinking of these sessions as challenges as well as being as the title suggests a trainer.

Could easily add a "JobFailed" Event for if X failed sucks or Y failed DT. This could either trigger immediate punishment time of X or as you say additional release time with random punishment.
If you get a second (Configurable) "JobFailed" it could trigger a "SessionFailed" Event that either adds or Max's out the release time and adds to the % of the random effect punishment triggers or does a higher degree of punishment.

The view I have is that as you get better and more comfortable you should be able to make it harder for yourself to succeed.

Current thinking on the Report is to have a Session Summary page at the front and then Job pages for each job done as you suggested. Increases the complexity of it but still shouldn't be too difficult. I'm going to hold off further coding on the Report though until I've re-engineered the release function into a local settings file and added the Event action trigger types. I'm also thinking of moving all the Camera settings into this as well. You'll still have the "Region Modification" (Beta) tab to allow for making things more difficult or easier on a particular job but where the core regions are I think is a personal choice and would benefit from not needing resetting every time. Hopefully won't take long to implement this so can get back on with the Report feautre. List for 0.3 is already growing

Confirmed Future implementations:

• Session Report
  • Either switchable inclussion of photos or a report with and a report without
  • Summary Page and individual job pages
  • More MI including but not limited to:
    • total session time
    • release time
    • # of "PunishmentX" were executed
    • # of "TeaseX" were executed
    • Any others that people want. Please suggest!!
• Move of Release Program and arguments to a local XML file
• Move of event action Program and arguments to a local XML file with action names of Tease1-5, Punishment1-5, JobEnd, Release
  • If say Tease 4 isn't specified in local settings but is used in a session then Tease 1 will be triggered instead
• Random Jobs
  • Currently see this as another job in the list entitled Random
  • Would allow for positioning of defined jobs before and after
  • Have a Min and Max value for number of Random jobs.
  • Have Job settings that would randomise for each job (beyond the current)
    • DT %
    • DVT %
    • Hold Time Reward?
    • Respite On/Off
    • Any others that people can think would be good to add?
• JobFailed Event with settings for failed DT and Failed Sucks
• SessionFailed Event with settings for # of failed jobs

Current Ideas

• Second Camera support for picture taking
• Second Camera support for second set of zones
  • Allow to choose on a job which "Dick" you have to work on or random
  • Special mode requiring a split of efforts between both "Dicks" in a single job
• More graphical interface rather than standard buttons

As always peeps if you have an idea or want a feature adding please feel free to suggest. All will be considered Also if you find any bugs please let me know and I promise to try and fix them in a timely manner

[johns1234]

"Have Job settings that would randomise for each job (beyond the current)"
This is unnecessary I think. The current randomization options in a job are quite good and this could actually lead to new bugs in a section which I would consider pretty stable right now. With the current randomization options within a job and selection of random jobs to perform - that should be sufficient IMO.

I think the most important part is really the local XML file part. After that people could start exchanging files.

[Phoenix]

Easiest one on this (esp from my point of view ) is to keep it as it is and then update/add if needed.

Agree on the Local XML's front. I've started hammering at it and this feature is now 80% implemented now. Hopefully be able to finish and test the last of it tomorrow and do a 0.25 release in the early evening (GMT).

[boundtocum]

Sorry Phoenix, Time to break stuff. Well, trying to get forced quits and weird results by doing things not allowed.
I've had friends tell me I'm not allowed to bug test their software anymore. I'll stop breaking stuff if you want me to.

v0.24 (I should note versions since you have amazing production speeds)
-Suck Settings
--When setting a job it will let you set a min # Sucks higher than a max # sucks. It runs, uses the Min. If you have Random checked then it immediately Force Quits when you click Start Session.

-Suck speed settings
--Under suck speed, same thing with random, but it crashes once the session start timer starts up the Job0.
--If ramp up is checked and set to 0% it crashes.


-Cheat Check
I don't think the toggle is working. I'm getting Failed Cheat, with the box unchecked.

[Phoenix]

No need to apologise

I think I know where the issue is and it should be a quick fix

Cheat check:
Can you recall if it failed on a suck, DT or VDT?
Can you send through the session log file? Or can you extract the section from the log +20ish rows before and after.

Please keep the bugs rolling in! It all helps it become more stable and reliable.

[boundtocum]

Ya, that's it. I just fired it up and tried all sorts of cheating, and it's the V/DTs. If the Deep box is triggered, and the Suck box goes back to red, it triggers a fail. The head box seems independent (head play was checked. I didn't test that config yet.). VDT Fails if either Suck or Deep go back red. All Sucks,DT,VDT require the previous boxes to be all lit at the same time to trigger a success, or start a held timer.

I found a new one while I was checking that. I had a VDTpop up, covered Head, Suck, Deep, Extra Deep, and then my hand caught a shadow that made Head go back red. It was saying deeper on the status bar, but also counting up for held time. I'm pretty sure it failed, but I think I let another box go red. I should use a cardboard cutout instead of waving my hands to make this more uniform. Sorry I don't know what one it was, I'm just PM'ing you the full short log to avoid a text wall here.

[Phoenix]

Found the issue with the cheat check. Came down to a missing additional brackets surrounding a 4 * OR statement in DT and VDT.

I'm not sure what to do with regards to the head zone becoming uncovered. Technical I can see this as a fail scenario / impossible scenario but again I can think of hair etc altering the light to cause it.

I'm going to open it to the forum I think to give guidance as I can see the benefits of leaving it in /correcting to a fail

I know I promised another release this evening but it's been a hell of a week at work this week and I want to make sure the local settings is working as expected. As such I'll work on it to do a release for tomorrow

[johns1234]

I'm not sure what to do with regards to the head zone becoming uncovered. Technical I can see this as a fail scenario / impossible scenario but again I can think of hair etc altering the light to cause it.

Maybe ease the cheat check a little bit and only check that the previous zone before the last covered one is covered. That ensures the right sequence going down.

[johns1234]

I know I promised another release this evening but it's been a hell of a week at work this week and I want to make sure the local settings is working as expected. As such I'll work on it to do a release for tomorrow

Once this works ... I would be interested two "unknown" sessions. 1) a really short one (5 min) with a complete description to test basic events like release and so forth. 2) a real one and the only limits I would set is: no cheat check as that may produce false fails, limit the whole session to about 90 minutes max, and keep the speed reasonable (even when testing with a cardboard going to VDT in 2s is sometimes a fail when you hold it wrong ) - rest like how the time is used and if to show sucks and how many jobs and so forth can/should all be unknown.

[DtTrainee]

First, I want to say: Great piece of software, I like it very much.
Second, a bug report: I seem to experience some trouble with the camera or box checking when trying to load a session.
When I set up the boxes on my dildo and use “set colours“ there is a small green flash of the boxes and then they work (change from red to green when required). If i now load a session that I saved earlier, the camera stops working. The picture does not change anymore. Stopping camera and restarting it does not help.
If i do it the otherway and load my session before setting the boxes, the click to set colours does not flash the boxes green and they stay red all time.
Only way for me to have my previously designed session is to first set the boxes, click on set colours and then edit the default session to my wanted session and avoid loading.
Any hints on how I can load a session and set the boxes in one program run?