Preview of macro additions/changes in b51.

[trevor]

Hey guys, not to worry The macros will stay the same as 1.3 completes.

I'm hopeful to get the javascript integrated as a macro call before 1.3 is final. Then in 1.4 we'll work on migrating the functionality of the current macro system as javascript functions.

To be clear, the macro stuff will be around for a long while. The plan is to provide a new way to do it that should reduce the complexity, reduce the overhead, make it more accessible, and add more power.

[Lindharin]

I think I may have found two bugs in the version that was in the SVN repository this morning.

1. There seems to be a problem with the assert() function. Even a really trivial one like [H: assert( 1==2, "Test") is giving an actual error message, not the assert-type error message.

2. The ability to use carriage returns in a text area isn't working correctly. It looks like it is, but it is somehow breaking any other input fields / string properties that come after it in the form. Here's a campaign file I was using to test that.

In that campaign, target the "A" token, and click the "Show Sheet" button. It will open a frame that displays one element of a class feature property. Click the indicated link to edit that entry.

If you save the dialog without using any carriage returns, you'll get an assert response that says "The fType parameter is not an empty string".

However, if you put in any carriage returns, the assert response will be "The fType parameter is an empty string".

If you edit the dialog macro and move the hidden input field named "fType" to be above the textarea in the form, instead of below it, then that element will never be an empty string, so it is definitely a case of the multi-line text area somehow breaking the trailing end of the macro.args string property.

Is there maybe some hidden whitespace character (like a \r or \n) embedded in the value that is messing up the macro.args string property?

[Craig]

I think I may have found two bugs in the version that was in the SVN repository this morning.

1. There seems to be a problem with the assert() function. Even a really trivial one like [H: assert( 1==2, "Test") is giving an actual error message, not the assert-type error message.

Yeah I already caught this and there is a patch for t.

2. The ability to use carriage returns in a text area isn't working correctly. It looks like it is, but it is somehow breaking any other input fields / string properties that come after it in the form. Here's a campaign file I was using to test that.

Yeah there is a bug with how something is getting called in the macro link. I am looking at now, I think I need to make a small change to how macro links are called from forms to fix it.

I have caught a few more bugs I also plan to run my game tomorrow with the newest build + any fixes I find so that should shake out a bit more

[Craig]

Yeah there is a bug with how something is getting called in the macro link. I am looking at now, I think I need to make a small change to how macro links are called from forms to fix it.

Ok found it, its no where near as bad as I thought (gotta remember next time, morning coffee then post, not the other way around!).

For method=json (values are returned in a json object) carriage returns will be preserved. For string property lists they will be converted into spaces so it wont break the string property list functions.

[jfrazierjr]

Changes

• getTokens()/getTokenNames() now can accept a JSON object with multiple conditions that need to be fulfilled as the second argument.

Am I missing it, or are you also making changes to the other functions to include this code? Specifically, getVisibleTokens() would be SOOO much better if this functionality was available.

[Craig]

Changes

• getTokens()/getTokenNames() now can accept a JSON object with multiple conditions that need to be fulfilled as the second argument.

Am I missing it, or are you also making changes to the other functions to include this code? Specifically, getVisibleTokens() would be SOOO much better if this functionality was available.

One of the conditions you can pass to getTokens() is visible... So only one function that can accept multiple conditions (well 2 if you include the one to get names) is needed.

[DrVesuvius]

Hey guys, not to worry The macros will stay the same as 1.3 completes.

I'm hopeful to get the javascript integrated as a macro call before 1.3 is final. Then in 1.4 we'll work on migrating the functionality of the current macro system as javascript functions.

To be clear, the macro stuff will be around for a long while. The plan is to provide a new way to do it that should reduce the complexity, reduce the overhead, make it more accessible, and add more power.

That's good to know, Trevor. For a minute I was worried that you guys were going to pull an I.E.8 on us.

Thanks for clarifying.

[jfrazierjr]

Changes

• getTokens()/getTokenNames() now can accept a JSON object with multiple conditions that need to be fulfilled as the second argument.

Am I missing it, or are you also making changes to the other functions to include this code? Specifically, getVisibleTokens() would be SOOO much better if this functionality was available.

One of the conditions you can pass to getTokens() is visible... So only one function that can accept multiple conditions (well 2 if you include the one to get names) is
needed.

Oh...Duh.. I must have missed that one when reading the docs...This will save quite a bit of once b51 comes out(as well as make things more readable)

[Lindharin]

Craig, in one of the recent threads on using json, someone said the b51 dev version lets you access a property with json content directly, as in [ myVar = myJsonProperty ] instead of using [ myVar = getProperty("myJsonProperty") ].

Does that mean that any properties with curly braces in them will no longer auto-evaluate? For example, if I had the following properties in b50, then you could do [r:StrBonus] and it would return 4.

Code: Select all

Str: 18
StrBonus: {floor(Str/2)-5 }

In b51 will that still work, or will any non-json {} blocks in our properties need to be changed to [r:] blocks instead?

[Craig]

Craig, in one of the recent threads on using json, someone said the b51 dev version lets you access a property with json content directly, as in [ myVar = myJsonProperty ] instead of using [ myVar = getProperty("myJsonProperty") ].

Does that mean that any properties with curly braces in them will no longer auto-evaluate? For example, if I had the following properties in b50, then you could do [r:StrBonus] and it would return 4.

Code: Select all

Str: 18
StrBonus: {floor(Str/2)-5 }

In b51 will that still work, or will any non-json {} blocks in our properties need to be changed to [r:] blocks instead?

Any non json blocks in default properties will be evaluated as they previously were. Er Just don't try it in the current Subversion code as that doesn't work correctly there but I have sent a patch to Trevor with a bunch of fixes and that is one of them...

So in your above case

Code: Select all

[r: StrBonus]
[r: getProperty("StrBonus")]
[r: getPropertyDefault("StrBonus")]

Would (assuming the property is not set on the token) return

Code: Select all

4
4 
{floor(Str/2)-5 }

[RPTroll]

The functionality in this build is going to ROCK!

Maybe I should take Tuesday off so I can play with Maptool

[osman]

Among all of those changes (some of which are truly awesome), the thing I'm most interested in is:

getInitativeToken() [trusted] returns the id of the token that currently has the initiative.

Mostly because I'm trying to come up with a system to automate tracking of effects (including durations, etc...). And unless I'm missing something, the current set of initiative related macro functions don't provide nearly enough information. In particular, there's no way to get the token that currently has initiative, nor to get a token id given an initiative list offset.

My plan was to support the many 4e effects that last until specific points like "end of the player's next turn." I was going to encode a bunch of metadata about the effect and its expiration into JSON objects, and then use a centralized macro to advance initiative and also auto-expire things. New effects would be scheduled for expiration when (for example) the round number is one higher than it is now, and the actual initiative count is lower than the current player's. But getting the necessary data is currently impossible (or there are functions not documented on the wiki...)

In any case, thanks for the all work, looking forward to playing with lots of this stuff.

[Mathemagician]

Among all of those changes (some of which are truly awesome), the thing I'm most interested in is:

getInitativeToken() [trusted] returns the id of the token that currently has the initiative.

Mostly because I'm trying to come up with a system to automate tracking of effects (including durations, etc...). And unless I'm missing something, the current set of initiative related macro functions don't provide nearly enough information. In particular, there's no way to get the token that currently has initiative, nor to get a token id given an initiative list offset.

My plan was to support the many 4e effects that last until specific points like "end of the player's next turn." I was going to encode a bunch of metadata about the effect and its expiration into JSON objects, and then use a centralized macro to advance initiative and also auto-expire things. New effects would be scheduled for expiration when (for example) the round number is one higher than it is now, and the actual initiative count is lower than the current player's. But getting the necessary data is currently impossible (or there are functions not documented on the wiki...)

In any case, thanks for the all work, looking forward to playing with lots of this stuff.

I have this stuff implemented in my campaign. I have a fairly flexible system (though I didn't entirely make it robust, since it's for my campaign and not general use), but it should give you some idea of how I went about doing things.

Edit: Just decided to post it now, before I forget. Here's the link: http://forums.rptools.net/viewtopic.php ... 49&start=0

[DeviantNull]

I can't seem to get json.equal to work. Not much more to add, it just throws an invalid expression or undefined function depending on if I'm using expanded [] or not.

[Craig]

I can't seem to get json.equal to work. Not much more to add, it just throws an invalid expression or undefined function depending on if I'm using expanded [] or not.

Sorry my fault its a typo (I corrected the original post)
its json.equals()

Try it again,

Code: Select all

[json.equals("[]","[]")] <br>
[json.equals("{}", "{}")] <br>
[json.equals("[1,2]","[]")] <br>
[json.equals("[]","[1,2]")] <br>
[json.equals("[1,2]","[1,2]")] <br>
[json.equals("{a:1}", "{}")] <br>
[json.equals("{}", "{a:1}")] <br>
[json.equals("{a:1}", "{a:1}")]

Should produce

Code: Select all

1
1
0
0
1
0
0
1

If not make sure you have latest updates from subversion