Hey, so I'm curious if there's an easy way to force-evaluate a variable when it's like:
[[Buy $weapon.id|Buy]]
To make this work, I had to resort to this:
<a data-passage="Buy">Buy $next_weapon.id</a>
Which works fine. But is less succinct than some kind of shortcut to force-evaluate things. Anything like this available?
Comments
Let's say...
This usually only gives me [object][dagger] instead of Hello!, no matter what kind of configuration I give it. I've tried $weaponIDs[$weapon["id"]], $weaponIDs["" + $weapon.id], and if I just try $weaponIDs["dagger"] it works.
The problem I have is...
So... is there are secret here? Because I can do it in javascript easy. I just tested it quickly by:
And that puts "Hello!" in $temp, so it works.
So... is there a way to get this to work, outside of wrapping it in javascript? I can do that if I need to, but I'm wondering if there might be a cute work around I can use for this?
And this works too. So, is this roundabout way what we currently need to do?
Doesn't evaluate $weapons[$weapon.next].cost or $weapons[$weapon.next] when for instance <<print>>ed, it does do the calculations correctly. So, it might just be an issue of representation and not actual usability. But, having said that, it would be great if things like strings could be printed out as well.
Oh, and while I'm here,
Wherever there's a $temp, $weapon.next failed to work. So, it actually worked that first time, but failed in the subsequent ones.
IOW, you'll need to use one of the following:
I have no idea what you're trying to say, or think you're trying to say, here. Try again?
Also, what are $weapons and $weapon.next supposed to be? I'm assuming that $weapons is either an object or array, and $weapon.next is an index/key, but having the specifics is kind of important.
And it works very well, but I encountered this situation again:
So, the issue I was having before was one of display. But that was solved with the <<= macro. I'll be using that from now on, now that I know about it.
But with this passage (which relates to the original question), I have inconsistent results, as seen with the pic.
So, using the raw variable works in this situation, regardless of complexity. But the other <<= and <<print macros don't. But it does work if I use the <a data-passage= convention.
Generally though, I like the <<= macro. So thanks for the help. I think I overlooked it because of the minimal docs on it. But, now I know, it's cool.
Often times I do want to print directly to the page. Other times I just want to evaluate the expression so I can use it. So... what's the solution here?
This is essentially evaluating the "complex" structure and storing the simple string in $temp2.
Then we use the simple variable to play with string concatenation. So, is this the best way to go about things?
eg. $weapons[$weapon.next].name
The above requires a number of steps to determine a result:
note: the following is only an approximation of what is happening!
a. Transpose all $variables with their real variable references: b. Determine the value of State.variables.weapon.next c. Determine the value of the "smallSword" array element's name variable:
I've decided to go with:
And I'll try to use raw variables when I can, but as a final resort, I'm glad I can fall back on something like this:
It seems to be failsafe. The trick is knowing when this might be needed without extensively testing these things. Anyway, I'm moving on from this.
That fails because you're trying to use a variable with the dot notation, which you cannot do. Dot notation is only available when you're using the actual property name and the property name is a valid identifier, all other property access (incl. using a variable) must use the square bracket notation.
Those both failed because you're trying to use markup (macros in this case) within the wiki link markup, which you cannot do. The wiki link markup only accepts either plain text or TwineScript expressions.
Yeah, fair enough. I had it that way because I was following the tutorial game. I think the idea was to be able to eventually store attributes of items so you could present different combinations, dependent on what the requirement was.
So, not just a mechanism to iterate through. They way they originally had it was very much a linked list, but they mentioned being able to store just strings instead, and I did that.
But, I think the endgame of it was to enable different aspects of the items to be pulled when the user wanted to see different things.
I haven't progressed much beyond where she left it. But I like the idea of combinations, so I might see now to go about this. Not just for a combat game. But for other aspects, items meeting needs. Some items meeting them more easily than others, etc. It's interesting.
But, go ahead and just use simple stuff if you want. In the meantime, I'll be looking at how to do these combination things she talked about.
The solution is fairly straight forward, create a second datamap using the weapon ids as the keys and an array of possible upgrade weapon id's as the values.
Something like the following, which has not been tested:
A weapon might have different qualities. The big sword might have bigger impact, but slower to swing. The biggest might only be accessible if you meet the strength requirement for it.
But beyond that. If it's a social game, then other attributes may be in play. Items that you buy to enhance your glamour factor. Items that attach some special credence.
Those are the kinds of combinations she was inherently talking about. Not just for her tutorial game, but for things to explore. I probably won't talk anymore about this until I have some kind of system that plays with this. But, currently I'm working on other things. I will come back to combinations though, since it seems fun.
I look forward to seeing the system you end up designing and implementing.