Q to content coders (and maybe writers too)

[adev]

I was working through includes/bess.as trying to make the code easier to understand - so far I have done the following changes:

Throughout the code I have moved minor text variations into parser calls.

I split the dom path of bessGetBlowjob into a separate function to reduce the number of nested conditionals and to group related content together. Code used in both parts (the end of the scene and optionally a common middle part) is located in shared functions.

The second complex sex scene bessGetDoggySelected benefited so much from the added parser calls (reduced line count by 20% and removed most of the clutter between string literals) that I consider it quite readable by now. Sure some things like this bess.cocks[0].cType code is not nice to look at but changes would probably be rather specialised and limited in scope that I don't feel the gain is worth the effort.

While implementing these changes I noticed a wrong pronoun
output(". You moan in delight as [bess.name]’s thick jism bubbles and pours");
if (bTargetVag) output(" into [bess.hisHer] eagerly awaiting womb");
else output(" deep inside of you");
output(".");

a possible duplicate line end
"our starship’s shield efficiency rate."
)
);
output(". Hopefully I’ll be able to save us some credits.”</i>");

and a number of places where adjacent space chars may be written (but I'm not sure if these are merged during display - flash text is a strange mix of plain text and html markup)

I have attached the updated bess.as include and would be interested to know:
Is this generally viewed as an improvement?
Feel scene coders/writers confident to use such a syntax (see notes below)?
Is there interest in merging this into TiTS?
Can this be made better?

Notes:
[|func|a|b] is a new parser tag for a variable number of alternative texts - func is called with texts as args
{pc.pussy vagIdx} is here used as a special notation for [pc.pussy vagIdx] to change tag resolution order, so that the outer tag func can modify the the selected alternative (ie convert it to a normal tag) and resolve the modified tag

how does it work?

tag
[|bess.targetVag|fuck {pc.pussy vagIdx}|fuck {pc.asshole}]
translates into
_ownerClass.bess.targetVag("fuck {pc.pussy vagIdx}","fuck {pc.asshole}");

_ownerClass.bess.targetVag
selects either vagina or ass text depending on a var (eg bess.targetVagIdx = 3 or -1 for ass)
replaces vagIdx with var content
replaces {} with []
returns the parsed string - either of "fuck [pc.pussy 3]" or "fuck [pc.asshole]"

alternatively the following syntax could be implemented:
[|bess.targetVag|fuck [pc.pussy [|bess.targetVagIdx]]|fuck [pc.asshole]]
this resolves innermost tags first - but the end result should be the same
Advantage: normal [tags], more flexible
Disadvantage: would try to resolve [pc.pussy -1] even when there is no pc pussy and anal is selected - this could show up as trace msgs during debugging but the generated text would be discarded

ps: it might be worthwhile to allow 7z archives as attachments, had way less troubles with them in the past

 

[Emerald]

Why man..

 

[Ethereal Dragon]

The guy/gurl is masochistic from what it looks like but if they know what the heck they are doing with the code and everyone knows from codedragon's meltdown at having to code Bess/Ben how cringe worthy it was to code that character. If managing to reduce to amount of code clutter on a character by a considerable amount... 20% well damn that's a good deal of percentage chunk taken out.

 

[Upcast Drake]

Two problems I see with the parser solution:

Having to manually set variables and define functions to use it isn't any less work than an if/else block- although I will say it looks cleaner and is easier to read so long as you know what the function/variable do.

And here's the big one, the parsers are meant to be used by the writers. Trying to teach writers to use these properly when they may not even know what a variable is seems like a pipe dream. If we only want the function and don't intend for writers to use it, why not just use in-line ternary expressions?

EDIT: I thought of one more! With this system you create a layer of abstraction that everyone will have to know to read or edit, whereas everyone who can code knows what if/else is, and most who code know what a ternary expression is. This could also cause problems during debugging, as the parser just spits out "null" when something doesn't happen right instead of likely getting an error in your if/else or ternary that the compiler catches.

Also Gedan said that CoC had something exactly like this and no one used it and it was indeed harder to debug.

 

[Lancer]

I have very little clue as to how to code, and even less in regards to how TITS works, but if you want this to be reviewed by the proper people, I would @ or PM Gedan.

 

[RanmaChan]

I can barely write, let alone code, lol.

 

[Noob Salad]

Could you imagine if all the writers were also coders? Doc organization would be beautiful.

 

[Lkynmbr24]

Yeah... no. Would definitely shy away newer and older writers alike if that's the case... I'd rather focus my creative juices on just... creativity, with that leniency for just having basic knowledge of how parsers and event triggers work.

Also to quote Thomas Bertram:

"Don't fix what isn't broken."​

 

[adev]

"Don't fix what isn't broken."

But what if it is broken? How do you effectively debug/update a complex scene like this? In a mostly text based game there are 2 major types of bugs:
- The wrong line is printed, then I need to see what conditions are tested to reach this line. With the current file this is not really possible as you can't see at a glance which conditions affect the current line. Less lines is good in this case, and I don't get distracted by code that just adds a plural 's'.
- The correct line is printed, but the output is somehow wrong, then I need to concentrate on a single line. With the current setup that single line/paragraph can be split over 10+ lines and even those are interrupted by other code. Additionally parser tags behave pretty much like words - you immediately see if the spaces/line end chars match because the tag is in the text context - right now you have to check several lines of code because sometimes these chars are added in the surrounding text, sometimes they are added in the variable text fragments.

Having to manually set variables and define functions to use it isn't any less work than an if/else block- although I will say it looks cleaner and is easier to read so long as you know what the function/variable do.

That's unfortunately true in cases that do not depend on inherent character properties ( [|mf|a|b] tags simply work because Creature.mf() knows where to find the char gender) - what vagina was selected by the scene has to be explicitly set (although only once for the scene). I tried to use commonly used cases (vagina (x) or ass) or abstract cases (if 1 or else) that the functions could be added to Creature which makes sure that usage is consistent and generally available.

And here's the big one, the parsers are meant to be used by the writers. Trying to teach writers to use these properly when they may not even know what a variable is seems like a pipe dream. If we only want the function and don't intend for writers to use it, why not just use in-line ternary expressions?

Because ternaries -just like REs- are useful tools, but they should be used with caution. And remember these are options - nothing hinders you from writing the code like it is written now.

EDIT: I thought of one more! With this system you create a layer of abstraction that everyone will have to know to read or edit, whereas everyone who can code knows what if/else is, and most who code know what a ternary expression is. This could also cause problems during debugging, as the parser just spits out "null" when something doesn't happen right instead of likely getting an error in your if/else or ternary that the compiler catches.

Isn't the whole point of the tag system to hide complexity to get more readable strings? Every parser tag could be replaced by a function call that is checked by the compiler. It's just like the current flags system which -supposedly- trades ease of use against compiler checking...
And the parser shouldn't return null in the first place - it just doesn't care what getDescription returns. The fact that some functions don't return a useful error indicator doesn't help either...

Also Gedan said that CoC had something exactly like this and no one used it and it was indeed harder to debug.

That's why I ask here - it is an option supposed to make things easier and since tits contributions should have 'parser tags' included (I have no idea how strict that policy is) I need feedback from those who would add them. An option nobody uses can go to the scrap heap.

And while I haven't seen the COC implementation if it is similar to the FOE one I can see that it can get annoying. Even though -as a technical person- I like the option to be able to add custom tags to the parser, it should be the exception. BTW the only functions I have added for Bess' conversion are targetVag and if1 which are IMHO general enough to be added to Creature.

 

[XBoxMaster131]

Oh, @Gedan , where art thou! We need thy infinite wisdom, oh Mighty Code Dragon!

 

[Ormael]

World when all writers would be coders would be too perfect to exist. But as unreal utopy it's nice to dream we can someday get there.

@Lkynmbr24 Do you think Bess/Ben code is not broken and thus may not need fixing? Or you mean smth else when quoting Thomas Bertram?

 

[adev]

Just a note - please stop fixating on Bess, this is not about Bess. References to it just always show up when coding difficulties are mentioned. So far the poor thing is just a (involuntary) test subject for possible improvements...

From what I have read the author is gone and probably no-one wants to continue the work. But complex code should not be the deciding factor for this...

I have not found any real error so far just the minor oversights I mentioned in the starting post.

 

[Upcast Drake]

The current parser tag system is a tool for writers, not for coders. When there are say 1000 possible different cock descriptions, it makes it so they don't have to write variations for all 1000 themselves, they can just do [pc.cock x]. It's about saving writers' time while still making their smut engaging, not about code readability- altho that is a consequence.

I think part of the abstraction problem in this case is the complexity of it. Currently if you get a "null" in your text it means you just miss spelled the tag. With this system, it could mean you never set a variable, or you set it to a value the function doesn't check for, or the function itself could be bugged.

Your system seems usable and I can see how there could be improvements in code readability, but I don't think that's enough to use such a system. The slim benefits don't outweigh the negatives, IMO.

 

[adev]

Currently if you get a "null" in your text it means you just miss spelled the tag. With this system, it could mean you never set a variable, or you set it to a value the function doesn't check for, or the function itself could be bugged.

Or the mapped function returns null... Or the mapped property is null... Unless the first character is upper case, then you get an exception...

 

[Magic Ted]

I'm glad everyone felt the need to chime in with their witty repartee.