Realtime HP updating
Warderbrad
shows a healthbar above the icons. I would really like to be able to
have Maptools get info from IPlay4E to populate the healthbar. I
remember that there were comments about having realtime tracking, has
this moved forward?
Andrew Reutter
That would be the Combat API. It doesn't exist yet; it is in the
definition stages. You might want to check out the earlier posts in
this group to see what has been discussed, and perhaps to contribute.
I don't know what sort of scripting is available in Maptool, but you
could get started on writing code against the iplay4e APIs that are
already available. Docs are available on the group home page. Before
you can call the Combat API, you'll need to be authenticated, for
instance - and nothing is stopping you from getting that part written
now.
If you get anything written for Maptools, it would be sweet if you'd share it!
Cheers,
Andrew
David Pidcock
I'm considering writing an integration into Maptools as well.
Right now, it's all just thoughts, no code..
That said, if you're familiar with the idea of Model-View-Controller,
I plan to use MapTool as the controller and view, and iPlay4e as the
Model.
So MapTools will initially download the XML from iplay4e, and parse it
out into it's own internal representation (a Token, in its
parlance). Then, inside MapTool we use the usual dice-rolling
features and so on, and update internal state of the tokens.
Periodically, we'd need to be able to push those changes back to
iPlay4e to keep the common model in-sync.
Challenges :
Subscribe or Not? - I think there's going to be problems if Maptool
allows temporary state (health, surges etc) to be controlled from
outside maptools... not the least of which is data conflicts and
possible staleness across the network. (Not to mention possible
authority issues - GM/player trust, or player mistake etc)
Pushing - how often? Should every state change be immediately pushed
back to iPlay4e? Or should we 'bundle up" the changes and send them
periodically?
Pulling - I expect that structural changes (e,g. when the character
levels up) might be worth doing automatically when maptools connects
and authenticates - but it might be better if we could query iPlay4e
for a "last uploaded date". Alternatively, just put a big red button
somewhere that says "sync from iplay4e!"
The more I think about it, the more work it becomes :)
Andrew Reutter
> That said, if you're familiar with the idea of Model-View-Controller,
> I plan to use MapTool as the controller and view, and iPlay4e as the
> Model.
Sounds right to me.
> Challenges :
> Subscribe or Not? - I think there's going to be problems if Maptool
> allows temporary state (health, surges etc) to be controlled from
> outside maptools... not the least of which is data conflicts and
> possible staleness across the network. (Not to mention possible
> authority issues - GM/player trust, or player mistake etc)
It should certainly be the case that one system be the master for all
temporary state changes, even if they're ultimately stored at iplay4e.
Different folks will want to have different master systems, though; I
think that will be more of a usage thing than an architectural thing.
> Pushing - how often? Should every state change be immediately pushed
> back to iPlay4e? Or should we 'bundle up" the changes and send them
> periodically?
The iplay4e web interface can really be considered a "client"
(view/controller) of the iplay4e brain (model). It pushes changes
back immediately after a set of operations completes. For instance,
using second wind is two variable changes - marking the power used and
changing hit points. It sends them in a batch.
That's purely a usage of the API, though; the web service supports
arbitrarily sized batches of variables.
> Pulling - I expect that structural changes (e,g. when the character
> levels up) might be worth doing automatically when maptools connects
> and authenticates - but it might be better if we could query iPlay4e
> for a "last uploaded date". Alternatively, just put a big red button
> somewhere that says "sync from iplay4e!"
The benefit of the second approach is that you don't have to wait for
me to write code ;-> But yet, I should be storing the "last uploaded"
data for each character and representing it in the SearchResult node
that represents it (see the Search API doc on the group page).
> The more I think about it, the more work it becomes :)
Heh. Bi-directional integration would not be trivial. But reading
from iplay4e has now been done a few times and all the wrinkles are
ironed out. Most, anyway.
By the way, I mis-spoke a little when I said the Combat API didn't
exist. Most of it does, it's just not documented. I put out a call
for someone to write up a group page by reverse-engineering the Ajax
queries the current web client makes, but got radio silence ;->
Cheers,
Andrew
David Pidcock
On Jul 15, 4:10 pm, Andrew Reutter <andrew.reut...@gmail.com> wrote:
> > That said, if you're familiar with the idea of Model-View-Controller,
> > I plan to use MapTool as the controller and view, and iPlay4e as the
> > Model.
>
> Sounds right to me.
>
> > Challenges :
> > Subscribe or Not? - I think there's going to be problems if Maptool
> > allows temporary state (health, surges etc) to be controlled from
> > outside maptools... not the least of which is data conflicts and
> > possible staleness across the network. (Not to mention possible
> > authority issues - GM/player trust, or player mistake etc)
>
> It should certainly be the case that one system be the master for all
> temporary state changes, even if they're ultimately stored at iplay4e.
> Different folks will want to have different master systems, though; I
> think that will be more of a usage thing than an architectural thing.
have as little impact on iPlay4e's architecture as possible. If I can
get MapTools to talk web (outside it's own built-in networking, that
is), then I can send you AJAX-like calls, and you won't have to do
much of anything :)
> > Pushing - how often? Should every state change be immediately pushed
> > back to iPlay4e? Or should we 'bundle up" the changes and send them
> > periodically?
>
> The iplay4e web interface can really be considered a "client"
> (view/controller) of the iplay4e brain (model). It pushes changes
> back immediately after a set of operations completes. For instance,
> using second wind is two variable changes - marking the power used and
> changing hit points. It sends them in a batch.
> That's purely a usage of the API, though; the web service supports
> arbitrarily sized batches of variables.
>
> > Pulling - I expect that structural changes (e,g. when the character
> > levels up) might be worth doing automatically when maptools connects
> > and authenticates - but it might be better if we could query iPlay4e
> > for a "last uploaded date". Alternatively, just put a big red button
> > somewhere that says "sync from iplay4e!"
>
> The benefit of the second approach is that you don't have to wait for
> me to write code ;-> But yet, I should be storing the "last uploaded"
> data for each character and representing it in the SearchResult node
> that represents it (see the Search API doc on the group page).
I also think the "push to sync" idea is probably better anyway, since
it puts in the hand of the user. Automation isn't always all that :)
> > The more I think about it, the more work it becomes :)
>
> Heh. Bi-directional integration would not be trivial. But reading
> from iplay4e has now been done a few times and all the wrinkles are
> ironed out. Most, anyway.
>
> By the way, I mis-spoke a little when I said the Combat API didn't
> exist. Most of it does, it's just not documented. I put out a call
> for someone to write up a group page by reverse-engineering the Ajax
> queries the current web client makes, but got radio silence ;->
time, so who knows how long it will take for me to get this going :/
That said, I'd be happy to put up any info that I can glean for those
who follow :)
The basic interface is pretty simple..
* Download XML
* send AJAX commands to modify state.
It's the work that goes on inside MapTools that will be the hardest
part ..
1/ creating tokens from the XML, (not to mention creating tokens for
other DDI elements, such as monsters -gotta have tokens for the
enemies!)
2/ creating a framework for sending AJAX commands out of maptools to
iplay4e - one that can be exposed to MapTools macros ..
3/ creating a maptool MACRO framework that works with the above.
(see. www.rptools.net )
Those two are pretty big.
Brad Sumner
The biggest thing for me and the reason I was looking at this was not having to duplicate the work of my players since they were already tracking HP. I wish I knew how to do this coding as I quickly realized I was way over my head with it.
On Jul 15, 2010 6:56 PM, "David Pidcock" <eraz0...@gmail.com> wrote:
On Jul 15, 4:10 pm, Andrew Reutter <andrew.reut...@gmail.com> wrote:
> On Thu, Jul 15, 2010 at 5:47 PM, David Pidcock <eraz0rh...@gmail.com> wrote:
> > That said, if you...
Oh sure - I'm talking purely from my intentions. I actually hope to
have as little impact on iPlay4e's architecture as possible. If I can
get MapTools to talk web (outside it's own built-in networking, that
is), then I can send you AJAX-like calls, and you won't have to do
much of anything :)
> > Pushing - how often? Should every state change be immediately pushed
> > back to iPlay4e? Or ...
Sweet.
> That's purely a usage of the API, though; the web service supports
> arbitrarily sized batches of...
I'll take a look at that - after the authentication doc .
I also think the "push to sync" idea is probably better anyway, since
it puts in the hand of the user. Automation isn't always all that :)
> > The more I think about it, the more work it becomes :)
>
> Heh. Bi-directional integration wou...
Heh. Well that would certainly be of help to me. I don't have lots of
time, so who knows how long it will take for me to get this going :/
That said, I'd be happy to put up any info that I can glean for those
who follow :)
The basic interface is pretty simple..
* Download XML
* send AJAX commands to modify state.
It's the work that goes on inside MapTools that will be the hardest
part ..
1/ creating tokens from the XML, (not to mention creating tokens for
other DDI elements, such as monsters -gotta have tokens for the
enemies!)
2/ creating a framework for sending AJAX commands out of maptools to
iplay4e - one that can be exposed to MapTools macros ..
3/ creating a maptool MACRO framework that works with the above.
(see. www.rptools.net )
Those two are pretty big.
> > On May 19, 5:27 am, Andrew Reutter <andrew.reut...@gmail.com> wrote:
> >> Warderbrad,
>
> >> ...
Andrew Siefer
Musing on the subject, that would work perfectly using the methods we're already discussing once iplay4e implements monsters: the DM would create a full encounter within iplay4e with both players and monsters, then MapTool and inCombat connect in and do what they need to do. And there would be much rejoicing.
Andrew S.
Nazim
dreams a similar dream. I'm glad to see so many folks working on this.
I think Maptool implementation would be a fantastic thing. Having said
that, I'd like to highlight a few future enhancements that might be
relevant. I know almost nothing about programming, but I have done a
lot of Excel work, and I know that if I don't plan ahead it's harder
to add new things in sometimes.
The first possible enhancement is the optional components in the
iplay4e die roller: http://code.google.com/p/iplay4e/issues/detail?id=116
Since character builder files don't support quite a few details, I
imagine players will input a lot of notes there. Personally, when/if
this gets implemented, my shifter will add in shifting damage bonuses,
a versatility bonus, extra striker damage, and so on. I don't think
wizards has any interest in including a max damage or crit damage in
their power cards, but this would be where that feature is also
implemented (although I imagine that's even further down the road).
Reading these options (after all, the info will be pretty standard) in
Maptools or other clients would add utility to the final user
interface.
The same goes for power customization: http://code.google.com/p/iplay4e/issues/detail?id=90#c6
I imagine this will be a bit more complicated, but it's probably
closer to being implemented in iplay4e, so maybe that bring the
workload down to an acceptable weight. I'm hoping Andrew Reutter
already has some ideas of how he's going to implement this.
Personally, I just think a relatively big comment field would work
fine. Again, this field (or however the feature is implemented) should
show up in clients. As an example, my warforged fighter has two feats
that I would mention in Cleave's customization field: warforged
tactics adds +1 to hit when the target is next to an ally (I *always*
forget about this), and he can turn the secondary target damage into
ongoing damage on the main target. The latter (adding optional ongoing
damage) is more interesting to maptools automation, but I imagine it
would be a pain to implement for unqualified users. So I'm not
suggesting that maptools do that bit of lifting. But it might be
useful for you guys to explore if the information on customized powers
can be formatted in some particular way to make it legible.
Networked "campaign bonuses" ( http://code.google.com/p/iplay4e/issues/detail?id=86
) such as the bonus elves grant to everyone's perception or the bonus
a warlord gives when using Action Points may be something to keep in
mind as well, especially if they become integrated with the above two
items at some point in the future.
Finally, integration with Google calendar ( http://code.google.com/p/iplay4e/issues/detail?id=96
) is on the roadmap (albeit admittedly probably somewhat remote). I'm
not sure what this enhancement is supposed to be exactly, but it
sounds like it could be something for you guys to bear in mind. Or
not.
I hope that this doesn't come across as if I were telling you guys
what to do. I raise these potential issues only in the hope of making
their future implementation somewhat easier, and therefore... eh... be
all it can be.
On Jul 15, 9:58 pm, Andrew Siefer <tasie...@gmail.com> wrote:
> As long as we're on the topic I'll throw out my dream situation:
> MapTools, iplay4e, and inCombat 4e all sync up in whatever way makes
> sense. That way if a player changes their HP on iplay4e it's
> automatically reflected in both inCombat and MapTools. At the same
> time, if I set a condition on a monster within inCombat then that
> condition is reflected in MapTools.
>
> Musing on the subject, that would work perfectly using the methods we're
> already discussing once iplay4e implements monsters: the DM would create
> a full encounter within iplay4e with both players and monsters, then
> MapTool and inCombat connect in and do what they need to do. And there
> would be much rejoicing.
>
> Andrew S.
>
> On 7/15/2010 7:20 PM, Brad Sumner wrote:
>
>
>
>
>
> > The biggest thing for me and the reason I was looking at this was not
> > having to duplicate the work of my players since they were already
> > tracking HP. I wish I knew how to do this coding as I quickly
> > realized I was way over my head with it.
>
>
> >> On Jul 15, 4:10 pm, Andrew Reutter <andrew.reut...@gmail.com
> >> Those two are pretty big.
>
> >> > > On May 19, 5:27 am, Andrew Reutter <andrew.reut...@gmail.com
> >> > >> Warderbrad,
>
> >> > >> ...- Hide quoted text -
>
> - Show quoted text -
Andrew Reutter
> have as little impact on iPlay4e's architecture as possible. If I can
> get MapTools to talk web (outside it's own built-in networking, that
> is), then I can send you AJAX-like calls, and you won't have to do
> much of anything :)
I was mostly commenting on your own architecture - but I'm glad to
hear that the interface I already have will suffice ;->
> I'll take a look at that - after the authentication doc .
> I also think the "push to sync" idea is probably better anyway, since
> it puts in the hand of the user. Automation isn't always all that :)
Yep. Especially if you want to allow different use cases; some folks
might _want_ to let their players modify HP then pull those changes
into MapTools. The "pull now" button should probably be available all
the time if you're interested in satisfying that use case.
If you do, you'll need to call _two_ URLs when the button is pressed:
/view gets the static character XML (e.g. max HP)
/initialize gets the dynamic character JSON (e.g. current HP)
> Heh. Well that would certainly be of help to me. I don't have lots of
> time, so who knows how long it will take for me to get this going :/
> That said, I'd be happy to put up any info that I can glean for those
> who follow :)
>
> The basic interface is pretty simple..
> * Download XML
> * send AJAX commands to modify state.
Yep. To push data back, you'd call:
/characters/savestate
Some JSON contains the variables to update.
The JSON details are easily seen pulling up a character in Firefox
with the Firebug console enabled.
And there you have the Combat API, in short. The "initialize" and
"savestate" URLs, with details of the JSON, are all there is to it.
Cheers,
Andrew
Andrew Reutter
would want iPlay4e to be the canonical location for state data. You'd
push when your tool made changes, and poll occasionally for updates.
The polling is the part I don't yet support in an efficient manner,
and I wouldn't want anyone to start polling in an inefficient manner.
Cheers,
Andrew
Andrew Reutter
Don't worry how you're coming across, man, feedback and
recommendations are always appropriate.
It was good to think about these before we get in too deep. Details below.
On Fri, Jul 16, 2010 at 8:57 AM, Nazim <nazim...@gmail.com> wrote:
> The first possible enhancement is the optional components in the
> iplay4e die roller: http://code.google.com/p/iplay4e/issues/detail?id=116
> Since character builder files don't support quite a few details, I
> imagine players will input a lot of notes there. Personally, when/if
> this gets implemented, my shifter will add in shifting damage bonuses,
> a versatility bonus, extra striker damage, and so on. I don't think
> wizards has any interest in including a max damage or crit damage in
> their power cards, but this would be where that feature is also
> implemented (although I imagine that's even further down the road).
> Reading these options (after all, the info will be pretty standard) in
> Maptools or other clients would add utility to the final user
> interface.
Currently, there are <Condition> nodes under each power.
Customizations will likely add more condition nodes, and such nodes
will have new attributes that describe the extra dice and so on.
It should be safe to implement things based on what's there currently;
I will ensure that any changes are backwards-compatible. So while
those functions may not be immediately available, 3rd party developers
can add them in once the format expands.
> The same goes for power customization: http://code.google.com/p/iplay4e/issues/detail?id=90#c6
My previous response is also applicable here; user customization will
affect the XML for the character, so code that consumes that XML will
also magically inherit any customization.
> Networked "campaign bonuses" ( http://code.google.com/p/iplay4e/issues/detail?id=86
> ) such as the bonus elves grant to everyone's perception or the bonus
> a warlord gives when using Action Points may be something to keep in
> mind as well, especially if they become integrated with the above two
> items at some point in the future.
I'm not as sure about how this would work. Probably as an expansion
of the campaign XML format again.
> Finally, integration with Google calendar ( http://code.google.com/p/iplay4e/issues/detail?id=96
> ) is on the roadmap (albeit admittedly probably somewhat remote). I'm
> not sure what this enhancement is supposed to be exactly, but it
> sounds like it could be something for you guys to bear in mind. Or
> not.
I don't think it's relevant. This ticket was basically to just let
you embed a Google calendar in your campaign view for session
planning; I don't intend to actually communicate with it in any way.
Cheers,
Andrew
Andrew Siefer
state info for NPCs from inCombat to MapTools would only work "out-of-
the-box" once iPlay4e supports monsters. PCs would work fine today,
as you say. I think now that the Combat API has been explained a
little more I'll have to toy around with it inside inCombat.
Polling is a bit tricky though, I agree. I've been mulling it around
for the past couple days and I think the most efficient solution for
inCombat might be to poll every time the "Next" button is clicked.
There still exists a small chance that you might not see changes if
the player doesn't change things until after the DM clicks Next, but a
refresh button could handle those cases. I think any other solution
either involves too much polling or has a much higher chance of
missing updates that the DM needs.
Shrug, I'll see how it works in testing.
Andrew S.
On Jul 16, 12:09 pm, Andrew Reutter <andrew.reut...@gmail.com> wrote:
> Most of this could be accomplished even without monster support. You
> would want iPlay4e to be the canonical location for state data. You'd
> push when your tool made changes, and poll occasionally for updates.
>
> The polling is the part I don't yet support in an efficient manner,
> and I wouldn't want anyone to start polling in an inefficient manner.
>
> Cheers,
> Andrew
>
> > As long as we're on the topic I'll throw out my dream situation: MapTools,
> > iplay4e, and inCombat 4e all sync up in whatever way makes sense. That way
> > if a player changes their HP on iplay4e it's automatically reflected in both
> > inCombat and MapTools. At the same time, if I set a condition on a monster
> > within inCombat then that condition is reflected in MapTools.
>
> > Musing on the subject, that would work perfectly using the methods we're
> > already discussing once iplay4e implements monsters: the DM would create a
> > full encounter within iplay4e with both players and monsters, then MapTool
> > and inCombat connect in and do what they need to do. And there would be
> > much rejoicing.
>
> > Andrew S.
>
> > On 7/15/2010 7:20 PM, Brad Sumner wrote:
>
> > The biggest thing for me and the reason I was looking at this was not having
> > to duplicate the work of my players since they were already tracking HP. I
> > wish I knew how to do this coding as I quickly realized I was way over my
> > head with it.
>
Andrew Siefer
slowly coming to realize that conditions could pose an ... inconvenience
... for everything we're discussing. I thought I'd bring this up to the
list so others can pipe up and tell me whether I'm on track here or if
I'm crazy.
The issue I see is that iPlay4e uses simple strings for each condition.
This isn't a bad thing by itself: it's simple, it's efficient, and it
works. However, when you start integrating with combat trackers or
mapping tools then this becomes a minor problem as those programs will
have to make their best guess as to whether each string corresponds to a
given Condition (as defined by the PHB). To be a little more clear:
suppose a player wishes to set themselves as dazed on their iPlay4e
character sheet. Simple enough, most users will type either "dazed" or
"Dazed." These strings are easy enough to search for in the JSON and
correspond to the PHB's Dazed condition. But what about immobilized?
Will most players type out the whole word or will they truncate it to
"immob?" Or for that matter, how many players will misspell the word as
"immobolize?" Now as an application searching for the Immobilized
condition I have to search for "immobilized," "immobolized,"
"Immobilized," "Immobolized," "immob" and "Immob." Not a showstopper by
any means, it's easy to code those things, but the application is still
just making it's best guess as to what the user meant. And we haven't
even covered durations, such as "immobilized (save)" or "immobilized til
end of gnoll 1's turn."
So this leads me to wonder if it might be better for iPlay4e to expand
the way that users input conditions so that they can "quickpick" the
main conditions but also still enter a generic string if needed. This
would allow some standardization around which strings are used for the
various conditions. Just to throw out a quick example, if the user
quickpicks the Immobilized condition then iPlay4e will always store the
string "immobilized" for that. No backend changes here, just frontend.
There's my thoughts, and if I'm making a mountain out of a molehill then
don't be afraid to say so. I just want to alleviate as many integration
pains as we can as we progress down this Combat API path.
Andrew S.
David Berg
formatted list you stand a much better chance of having an application
understand what was entered. I do this in both javascript and Flash
for KOTLL. Having a selectable option is a very good and definitely a
sound recommendation. I would agree with the need for a free text
entry option as well. However, I believe the most important thing for
a combat system to have is well structured duration information.
If you are interested, here is a good start for a list that players
may use. It is very broad and not limited to 4e.
http://www.kotll.com/general/3eprofiler/public_profiler/EffectsList.html
Just my 2 cents,
Dave
Nazim
(for example: dominated also causes dazed and CA to appear), if it's
not too much trouble.
chad
On Jul 21, 2010, at 6:26 AM, Nazim wrote:
> It would be neat if conditions populated the other related conditions
> (for example: dominated also causes dazed and CA to appear), if it's
> not too much trouble.
There are fewer of these than there used to be (pre errata), and it could
get tricky to track interrelated effects, but it would be neat if the kinks could
be worked out. By way of example, Dominate does NOT apply the Dazed
condition any more, but it instead has an effect that's almost the same.
(Why'd they make the change? Because there are effects that a creature
could trigger if Dazed, and they weren't supposed to be used if Dominated).
Quite a number of conditions, including Dominated, make the target grant
Combat Advantage, so the concept is still sound. CA points out one of the
trickier interactions to exceptions-based design: there are many conditional
CA effects -- grant CA to everyone, all the time, or just to me, or just to allies,
or just versus ranged and melee powers, or...
On the iphone UI, I can see a place for a variant of the calendar picker:
[Condition roller] [beneficiaries] [end condition]
covers the cases that come to mind right now -- if the end condition is
``end/start of M's [next] turn'', we have a convenient place to hang a tag for
who applied the condition. If it's Save Ends, we might want a way to add
such a tag, and we probably want a way to say `[Save Ends (penalty)]'. I
suspect that we can do without explicitly including the penalty, but others
may disagree.
Sorry if this is too much details at once -- I used to play on-line via MapTool
quite a lot, and I've spent more thought on automating condition tracking
than is probably good for anyone.
I also have a designed-but-not-implemented iphone app as a learning
project that would love to hook into this info in the theoretical future where
I actually get around to building it.
Hope this helps,
*Chad
hook
Andrew Reutter
DM, want to create a "flabbergasted" condition I should be free to do
so. So any third party products that want to read that info from
iplay4e will need to support that as well.
That said, I _do_ intend to eventually create a picklist of the
standard conditions, with the standard "first letter capitalized"
presentation. So you can go ahead and write code that attempts to map
the value from iplay4e to your list, with the expectation of an exact
match instead of a best guess - as long as a mapping miss is
gracefully handled.
Andrew Reutter
see myself getting to it anytime soon. Nothing stops third party
products from showing both "Dazed" and "Grants combat advantage" when
iPlay4e just says "Dazed", though.
Cheers,
Andrew