[1.3b75] onInitChange()

[aliasmask]

We recently had another event like handler added to MT, Wiki: onTokenMove() done in the style of onCampaignLoad where it is a macro on a lib token.

Can we get onInitChange() added as well. People have rebuilt init panels just so they can hook in events. How likely can this be done and what kind of limitations would there be? It would be nice if this was called for anything that changed Wiki: getInitiativeList() json object.

[CoveredInFish]

I just tried and have a working "solution". I hooked it only into initiativeNext (java not macro). And i reused much of the onTokenMove-code and did not understand all of that - so I probably did not this thing well.

My point is .. if I could do this its probably not to hard to do it right.

If you're interested heres my patch:

Patch

Code: Select all

### Eclipse Workspace Patch 1.0
#P maptool
Index: src/net/rptools/maptool/model/InitiativeList.java
===================================================================
--- src/net/rptools/maptool/model/InitiativeList.java	(revision 5401)
+++ src/net/rptools/maptool/model/InitiativeList.java	(working copy)
@@ -17,11 +17,14 @@
 import java.beans.PropertyChangeListener;
 import java.beans.PropertyChangeSupport;
 import java.io.Serializable;
+import java.math.BigDecimal;
 import java.util.ArrayList;
 import java.util.Collections;
 import java.util.Comparator;
+import java.util.HashSet;
 import java.util.List;
 import java.util.ListIterator;
+import java.util.Set;
 
 import javax.swing.Icon;
 
@@ -29,6 +32,10 @@
 
 import net.rptools.maptool.client.AppPreferences;
 import net.rptools.maptool.client.MapTool;
+import net.rptools.maptool.client.MapToolVariableResolver;
+import net.rptools.maptool.client.functions.AbortFunction.AbortFunctionException;
+import net.rptools.maptool.client.ui.zone.ZoneRenderer;
 
 /**
  * All of the tokens currently being shown in the initiative list. It includes a reference to all
@@ -90,6 +97,8 @@
      */
     private boolean hideNPC = AppPreferences.getInitHideNpcs();
     
+    private static final String ON_INIT_CHANGE_CALLBACK = "onInitChange";
+    
     /*---------------------------------------------------------------------------------------------
      * Class Variables
      *-------------------------------------------------------------------------------------------*/
@@ -290,6 +299,9 @@
         setCurrent(newCurrent);
         setRound(newRound);
         finishUnitOfWork();
+        
+        initChangeEvent();
+
     }
 
     /**
@@ -573,6 +585,7 @@
             return;
         LOGGER.debug("Token Init update: " + ti.getId());
         MapTool.serverCommand().updateTokenInitiative(zoneId, ti.getId(), ti.isHolding(), ti.getState(), indexOf(ti));
+    
     }
 
     /** @param aZone Setter for the zone */
@@ -606,6 +619,83 @@
         return Collections.unmodifiableList(tokens);
     }
 
+    /**
+     * Calls the macro event onInitChange
+     * 
+     */
+    
+    public void initChangeEvent() {
+    	Token token = getInitMacroToken(ON_INIT_CHANGE_CALLBACK);
+		Token iniToken = this.getToken(this.getCurrent());
+		if (token != null) {
+			try {
+				MapToolVariableResolver newResolver =new MapToolVariableResolver(null);
+				newResolver.setTokenIncontext(iniToken);
+				String resultVal = MapTool.getParser().runMacro(
+						newResolver,
+						iniToken,
+						ON_INIT_CHANGE_CALLBACK + "@"
+						+ token.getName(), "", false);
+				if(resultVal != null && !resultVal.equals(""))
+				{
+					MapTool.addMessage(new TextMessage(TextMessage.Channel.SAY, null, MapTool.getPlayer().getName(), resultVal, null));
+				}
+			} catch (AbortFunctionException afe) {
+				// Do nothing
+			} catch (Exception e) {
+				MapTool.addLocalMessage("Error running "
+						+ ON_INIT_CHANGE_CALLBACK + " on "
+						+ token.getName() + " : " + e.getMessage());
+			}
+		}
+    }
+    
+    /**
+     * I stole this from jfrazierjr onTokenMove stuff.
+     * wish i could reused that code but ... well its so private
+     * @param macroCallback
+     * @return
+     */
+	private static Token getInitMacroToken(final String macroCallback) {
+		List<ZoneRenderer> zrenderers = MapTool.getFrame().getZoneRenderers();
+		for (ZoneRenderer zr : zrenderers) {
+			List<Token> tokenList = zr.getZone().getTokensFiltered(
+					new Zone.Filter() {
+						public boolean matchToken(Token t) {
+							return t.getName().toLowerCase().startsWith("lib:");
+						}
+					});
+
+			for (Token token : tokenList) {
+				// If the token is not owned by everyone and all owners are GMs
+				// then we are in
+				// its a trusted Lib:token so we can run the macro
+				if (token != null) {
+					if (token.isOwnedByAll()) {
+						continue;
+					} else {
+						Set<String> gmPlayers = new HashSet<String>();
+						for (Object o : MapTool.getPlayerList()) {
+							Player p = (Player) o;
+							if (p.isGM()) {
+								gmPlayers.add(p.getName());
+							}
+						}
+						for (String owner : token.getOwners()) {
+							if (!gmPlayers.contains(owner)) {
+								continue;
+							}
+						}
+					}
+				}
+				if (token.getMacro(macroCallback, false) != null) {
+					return token;
+				}
+			}
+		}
+		return null;
+	}
+
     /*---------------------------------------------------------------------------------------------
      * TokenInitiative Inner Class
      *-------------------------------------------------------------------------------------------*/
@@ -732,5 +822,8 @@
             getPCS().fireIndexedPropertyChange(TOKENS_PROP, tokens.indexOf(this), old, isHolding);
             getPCS().fireIndexedPropertyChange(TOKENS_PROP, tokens.indexOf(this), oldState, aState);
         }
+        
+
+         
     }
 }

[Craig]

Let's add this to the 1.4 feature list we really need to stop adding new functionality to 1.3 otherwise we will never finalize 1.3 and start 1.4

[Cweord]

Let's add this to the 1.4 feature list we really need to stop adding new functionality to 1.3 otherwise we will never finalize 1.3 and start 1.4

Why do I get a feeling of Deja Vu from this comment

[aliasmask]

I'm all for having 1.4. As I understand it, those patching 1.3 still are not working on 1.4. Do we have a date where the pieces of 1.4 come together for testing?

[jfrazierjr]

Do we have a date where the pieces of 1.4 come together for testing?

Heh... I don't expect a usable build of 1.4(a decent portion(not all) of the current functionality is intact in some way) for at least 6-8 months after development begins in earnest, which it has not as of yet.

[aliasmask]

Ah. I heard some hints that 1.4 was closer than I thought. With 6 to 8 months, maybe I should go pick up a java book so I can help out with development. I've programmed in basic, pascal, mips, masm, fortran, c, c++, visual basic and coldfusion with supporting roles in html, css and javascript. Coldfusion, html, css and javascript I just taught myself rather than having a class teach me. I've written some cool luas for WOW back in the day too. I should probably learn java although I have a fuzzy idea of how it works. I just haven't written any code or had the chance to apply it to anything. I learn more by doing.

This question is probably more for Az since I think he teaches java, but what do you recommend for a beginner with a good grasp on programming with an object oriented language?

[Azhrei]

... I should probably learn java although I have a fuzzy idea of how it works. I just haven't written any code or had the chance to apply it to anything. I learn more by doing.

To be honest, I've been impressed with how quickly you picked up the MTscript language, especially given it's many "features".

This question is probably more for Az since I think he teaches java, but what do you recommend for a beginner with a good grasp on programming with an object oriented language?

Since you said you learn more by doing I'm going to suggest that you walk through the Sun Java tutorials. If you already have some background in OO programming, then I would suggest that you first try a few simple Java applications such as the ones in the tutorial. You'll understand the OO behind them quickly and can focus on the language itself. I'm guessing you'll speed right through the first few tutorials as they deal with language basics. Work through the first 6 trails under "Basics", then the GUI trail, and perhaps the Generics, Internationalization, and 2D Graphics trails under the "Specialized" category.

Once you've finished the tutorials a good book might be Killer Game Programming in Java by O'Reilly (they're at ora.com). It covers a topic pertinent to MapTool development and takes a structured approach similar to the tutorials (one concept at a time, but at a fairly rapid-fire speed). You could even skip the tutorials and go straight to the book, but you save money for a little while by doing the tutorials first.

[aliasmask]

To be honest, I've been impressed with how quickly you picked up the MTscript language, especially given it's many "features".

Thanks for the compliment. The wiki documentation was a big help and to me most languages are the same so it mostly comes down to syntax and ordering. I did the alias spell lib as my learn-the-language project and found the MTscript is pretty robust. I'm excited as to what can be accomplished by integrating javascript and having a db server. Tables would be so much better if you could write to them via a macro.

Thanks for the advice and I'll get started on those tutorials.

[Rumble]

Aliasmask, I'll second Azhrei's recommendation about the Java tutorials. In fact, that's pretty much exactly what I did. I had no prior experience with object-oriented programming (or really much beyond a little web scripting and a C class in grad school), but using those tutorials and wading in up to my neck in the MapTool source worked out pretty well for me.

On the other hand, MT's source code is large and sprawling, so I don't know if my approach was a good idea, or I was just too stubborn to realize I was in too deep.

I still don't know much about it, but I can do a few things to my satisfaction and it's fun, which is why I keep after it. And yes, the Sun tutorials are really well done.

[KaylaKaze]

Ah. I heard some hints that 1.4 was closer than I thought. With 6 to 8 months

Hahaha. That's funny. They've been saying 1.4 is coming out any time now for over 3 years. I seriously think 1.4 is a myth; it's referred to so people stop asking for various features.

Then again, maybe since Duke Nukem Forever and Diablo 3 are finally coming out, there's a small chance.

[Rumble]

There is a healthy discussion of what is planned for 1.4 in terms of ripping up MapTool's internals and rearranging them. I understand about 1.3% of it, and don't think I'll be able to help even though I'm in on the conversation.

However, the job is decidedly nontrivial, and in addition to the required discussion about "how the hell do we do this correctly?," I think there's a strong temptation to rearrange pencil drawers and clean closets rather than break the thing open.

[KaylaKaze]

There is a healthy discussion of what is planned for 1.4 in terms of ripping up MapTool's internals and rearranging them. I understand about 1.3% of it, and don't think I'll be able to help even though I'm in on the conversation.

However, the job is decidedly nontrivial, and in addition to the required discussion about "how the hell do we do this correctly?," I think there's a strong temptation to rearrange pencil drawers and clean closets rather than break the thing open.

Personally, if I were doing it, I'd use a plugin structure. I'd make the core of the code be plugin handling, networking, and frame handling. Things like map, chat, init panel, library, etc, would be a plugin. The core of the plugin communication would be an event hash. Each program loop, each plugin checks the hash to see if any messages are directed at it. This would allow each piece to be updated individually, even by a completely separate team, without needing to affect the core. If someone needs something for their game that MT can't do, they could just make a plugin for it.

It's probably far too late to do this sort of structure, if it's not already in 1.4 though. But just a thought.

I code in things other than java though, so I'm not sure how well java handles things like dynamic runtime libraries.

[jfrazierjr]

There is a healthy discussion of what is planned for 1.4 in terms of ripping up MapTool's internals and rearranging them. I understand about 1.3% of it, and don't think I'll be able to help even though I'm in on the conversation.

However, the job is decidedly nontrivial, and in addition to the required discussion about "how the hell do we do this correctly?," I think there's a strong temptation to rearrange pencil drawers and clean closets rather than break the thing open.

Personally, if I were doing it, I'd use a plugin structure. I'd make the core of the code be plugin handling, networking, and frame handling. Things like map, chat, init panel, library, etc, would be a plugin. The core of the plugin communication would be an event hash. Each program loop, each plugin checks the hash to see if any messages are directed at it. This would allow each piece to be updated individually, even by a completely separate team, without needing to affect the core. If someone needs something for their game that MT can't do, they could just make a plugin for it.

It's probably far too late to do this sort of structure, if it's not already in 1.4 though. But just a thought.

I code in things other than java though, so I'm not sure how well java handles things like dynamic runtime libraries.

This is exactly what we are planning. We will be using OSGi specification and taking much of the existing code to force into a plugin architecture while rebuilding a few things from scratch (such as the vbl and much of the map rendering pipeline). As build number get higher, there will be more plugins as we split functionality from the old code(which may have been contained in one of many bigger plugins) and create new bundles. What we won't be doing is building the whole thing from the ground up as then it would never get finished(hmm some people could say that about 1.3.. )