Ever played a COG that was just TERRIBLE? Have you ever been infuriated by some idiot in the comments? Ever majorly screwed up on a COG game that you made or maybe lost progress on the coding?
Share these utter tales of crappyness please.
Rise of heros sucked donkey kong balls
1 Like
āInfuriated by some idiot in the commentsā ā no thank you. Ragging on published games is fair play (although really, do we need another thread about it?), but keep it civil when it comes to commenters.
I think many of the āHosted Gamesā are more fun and certainly a better value for money; some of the latest official games just donāt have the spark that dragon, broadsides, romance and vampire did. Probably because itās outside authors, not Adam/Dan/Jason.
But yeah, thatās my only gripe really.
I guess my suggestion is, make it hosted/official based on game quality, not author experience.
Oh and we could do with a select few more commands in choicescript, *goto_sceneref for e.g.
@Harlox, I intensely disliked Heroes Rise because of the way it railroads you into behaving stupidly to justify its heavily contrived plot, but Iāve already griped about that elsewhere in this forum.
@CJW Yep, Iād dearly love to see arrays added to choicescript, and Iād also really like to be able to use curly braces in more types of statements, like in printable ones.
I donāt like rise too but the worse are the faerie game is horrible!
also what gripe mean in English in Spanish mean flu so Iām confused 
To the City of the Clouds was just ghastly, and The Fleet was too blunt.
@MaraJade A āGripeā is a complaint, effectively.
I donāt like the forum softwareā¦ but I think noone does.
And I donāt like how clumsy many games handle sexuality.
@loelet - Good point, the forum software could do with an upgrade or a replacement, but I guess itās far from a top priority for them 
@P_Tigras Oh, yesā¦ Well, I could literally go on for hours about new features/commands Iād like.
I just today forked/made a pull-request for the *goto_sceneref - it took me all of five lines and four minutes to do and seems to work perfectly, I donāt understand why things like that were excluded. Youād think there was a special reason - and there might be - though if there is, it beats me.
As for arrays, you can actually simulate them (or well, objects) with *setref and *gotoref etc (I do this in the inventory system) - so I can live without them for now. Donāt get me wrong, Iād like to see them, but I did look at it myself and it wouldnāt be a ten minute task, so I can understand their absence thus far.
What would be nice is an official command for creating dynamic variables during gameplayā¦ As it stands any *systems* are limited to the amount of variables you pre-define, without the use of *script.
Your comment about curly braces intrigues me, could you expand on that? Iāve never been in a situation where Iāve wanted to use them that I canāt.
Heroes Rise: Chugga-chugga-chugga-chugga-CHOO-CHOO!
City in the Clouds: Way, way too immature and full of random, brainless sex (and that was just the demo).
Also, I agree with the problem with the forum software. Specifically, it puts all the posts in all the various categories together on the front page, cluttering stuff up and making it impossible to sequester the random spam from the actually valuable posts (and because off-topic posts arenāt segregated, this encourages random spamming everywhere as a part of the forum culture, so people take the excuse to start threadcrapping in threads where actual work is being done).
Canāt we adopt something like phpbb?
@MaraJade: As @Drazen has explained, gripe is a synonym for complain.
@CJW: Iām not sure if you realize it, but you answered your own inquiry regarding curly braces. If we could use curly braces in a *temp statement, we would then be able to create dynamic variables via a loop. Currently, itās fully possible to construct a string dynamically via ā&ā and to indirectly reference it via curly braces. What we lack is a way to make that string a variable name. If *temp {newtempvar} were to work, we would be able to use loops to dynamically generate as many variables as we need, and this particularly annoying issue would be solved.
@Ramidel, @Drazen: I didnāt care for City in the Clouds either. I was one of the beta-testers and just couldnāt bring myself to finish it. At least I finished Heroes Rise, although my feelings for CitC were more along the lines of apathy than the anger I felt towards Heroes Rise. And that in a lot of ways is worse. The problem with HR is that it succeeded in making me care, and then chained me to my seat as my character did one stupid thing after another against my will. The fury I felt toward HR after it railroaded me is unique and unmatched by anything else here.
I donāt like that Hosted Games are hidden on the frontpage behind a link called āMake your own gamesā.
This would be easier, it doesnāt use {} but rather just works like *set_ref, only with variable creation.
E.g.
ChoiceScript
*temp new_variable
*set new_variable "foo"
*temp_ref new_variable
*setref new_variable "I'm the value of a variable that was set and created dynamically!"
${foo}
Scene.js Function
Scene.prototype.temp_ref = function temp_ref(variable) {
var stack = this.tokenizeExpr(variable);
var reference = this.evaluateValueToken(stack.shift(), stack);
this.temps[reference] = null;
}
Youād also need to add ātemp_refā:1 to Scene.validCommands object at the bottom of the file.
ā¦If itās this easy to do though, why hasnāt it been done? I really want to know, there must be a reason, right? 
@loelet I think Jason already said something on that in another thread last year, suffice to say, they donāt plan on changing it, but I see exactly where youāre coming from.
@CJW I most definitely agree that there should be a way to do this, and I was just as surprised as you that there isnāt. Iām undecided on whether or not a new *tempref function is the optimal solution however, but I do grant that it would be a little more straightforward than coding *temp to handle both ${} and {} since it would just be a matter of reusing a bunch of functions that have already been created.
I do have some concerns regarding the overall temp_ref function you listed above however. The first is that it does not call validateVariable to ensure that the variable it is attempting to create is legal. So no error message will be generated when an attempt to create it fails. The second has to do with the relative merits of calling evaluateValueToken as your code above does, versus calling evaluateExpr instead as *set and *setref do, although *setref does call both. Iām undecided regarding this second issue however. evaluateValueToken often calls evaluateExpr while evaluateExpr always calls evaluateValueToken so that bit of cross-pollination obscures things a bit and I havenāt spent enough time tracing them both through to form a definite opinion. Iām thus interested in knowing if you considered using evaluateExpr instead, and if so, what your reasoning was for picking evaluateValueToken over evaluateExpr.
@loelet This is my pet peeve too. I think another tab between Our Games and Blog called Hosted Games would be wonderful. The intentional hiding of the Hosted Games under Make Your Own games seems like a real shame.
@P_Tigras You have a good eyeā¦ That is the bare minimum code that will *work*, as I just threw it together in five minutes (to prove that itās not particularly difficult to implement).
I completely forgot to include any checks or error catches (shame on me).
Validation of the variable - at the least - should definitely be included.
As for evaluateExpr - it does exactly what it says on the tin, it evaluates an expression.
An Expression: A collection of symbols that jointly express a quantity.
*set var (5+10)
^That involves an expression
*temp_ref foo
^That doesnāt - and canāt - all you can specify is a single value.
There is never any expression to evaluate.
evaluateValueToken āturns a number, string, or var token into its valueā
Though you may notice if the string or token involves parenthesis, it will pass on the value to evaluateExprā¦ ;D
ā I understand this might sound like a poor explanation, especially when you look at the use ātokenizeExprā <- Obviously there is an expression here.
ā*temp variableā is, in itself, an expression. Once evaluated the command PLUS the value will equal a quantity (the new variable in this case). Iām sorry if this isnāt clear, Iām not particularly great at explaining these things.
Remember that *set and *setref āsetā variables and *temp creates variables, so itās not a particularly good comparison!
*set involves two values: The variable to be set + The value itās being set to.
*temp involves one value: The name of the variable being created.
Version of *temp_ref with var validation:
Scene.prototype.temp_ref = function temp_ref(variable) {
var stack = this.tokenizeExpr(variable);
var reference = this.evaluateValueToken(stack.shift(), stack);
try {
this.validateVariable(reference);
} catch (e) {
throw new Error(e.message);
}
this.temps[reference] = null;
};
@CJW I can think of situations however where it is both convenient and efficient to create a variable from an expression. I very much want to be able to do things in choicescript like:
tempref "inv"&(1+currentInvSize)
So as long as itās a legal variable name that is generated by the expression, I consider expression evaluation a desired ability. And as far as illegal variables like 15 (5+10 in your previous example) are concerned, thatās what validateVariable is for. Furthermore, evaluateExpr does allow for situations where there is only a single argument such as in a simple *if statement. So it is quite a bit more flexible than the manner in which it is used in *set and *setref.
Regarding the added tryā¦catch, validateVariable already throws an error message internally which breaks out of the game, so it seems a bit redundant to add another.
*set pointer āinvā&(1+currentInvSize)
*temp_ref pointer
Would work.
I understand the desire to combine the commands, but itās only an extra line.
And yes, youāre right, it does. Though having multiple error catches isnāt a bad thing in my opinion.