RPTools.net

One more "I can't wait to get this done" build, this time b74.

The ChangeLog is available from the Main Page of the wiki; look for the link in the bottom right corner.

This build is mostly cleanup and bug fixes. jfrazierjr's "Visible to Owners Only" patch for tokens and my patch for the ability to read/write file content that is properly localized are probably the biggest. Some changes that are not user-visible were contributed by whited.

I've done the last two dmg builds manually but hopefully I'll have them automated in the future; kind of a pain to do them the way I'm doing them now.

I still have two things I want to add for b75 and both are new features: gioppo sent me patches quite awhile ago for adding VBL automatically when drawing shapes but I haven't been able to do much testing on that yet. And MetaGamer had sent a patch that allows a full map screenshot to be exported and not just what is currently being viewed. Both are a few builds out of date now though, and I'll need some time to re-integrate them.

Also, I believe jay has new builds of CT and IT so we're going to chat tomorrow evening and figure out a way for him to get his builds uploaded. Or some way for him to get them to me for uploading...

(Btw, a few folks have sent me PMs or emails... Even if I haven't specifically replied, don't think you're being snubbed! Some of the topics have required some significant thought on my part and I've been prioritizing my time elsewhere. But I'll get to them all... )

Notes: The owner only visible patch does NOT include any changes to the macro language in this release. That will be changed hopefully in the next few days before b75 is released. Just be aware of this in case you are using this feature and are using things like isVisible() in your macros as it may report results incorrectly when a token has Visible to Owner Only set to true on the token dialog.

Also, for the onTokenMove functionality, for those who are very macro savvy, please give this a go but remember that this is still a beta feature at this point, so be judicious about your experience if you happen to try it in a live game(ie, it may break something) and make sure you backup your campaign file before adding in this functionality. The linked post on the wiki shows an example campaign that wolph42 kindly made to help test this feature. It includes:

• An area where a token cannot enter within one square of another specific token(ie, keep away!)
• A teleporter. When a token is dropped on a specific location (colored), the token is moved to another location on the same or a different map.
• A "door trap" where if a token is moved over a specific trap token(which can be on the hidden layer) and attack roll is made and if the attack hits, the token takes damage.
• A pit trap. Similar to the above with an attack roll, but if attack hits, the image is changed from a floor to an open pit and the token is "trapped". Attempting to move OUT of the pit will require the token to roll above a specific target number. Also note that the token will get a state applied so that movement in and out of the trap can be tracked properly.
  

@Azhrei congrats with the new build and erm are the pm that personal
@jfrazierjr don't give me all the credits for the test campaign file, its was a colab. with you! I'm curious how it will work in the build. Here is the direct link to the test file (for lazy people like me)

Ohhh, Excited for b75 now, I have been wanting the auto VBL for some time now

I think I read somewhere that the test connection function is out for now, but just in case I'm imagining that, the test connection gives me a false negative.

This hilariously caused a major anti-climax because last night, I finished a framework I've been working on for months, got my players excited, then hit "test connection" and had to tell them all the (untrue) bad news. Too bad I didn't just hit "Okay" instead of spending 3 hours troubleshooting my Time Capsule and RCA box haha.

Also, maybe this is another known issue, but when I drop a lot of big (~300k+) background images onto a map, sometimes they "dance" around. They will shift position of their own accord, seemingly to random coordinates. If I continue to drop background images, it will cause Maptools to not save the campaign. Both minor issues...the solution for me is to just switch to another map, then switch back (I guess because it re-caches?); then the save function works again. I'm guessing this has something to do with my stack size and the little "red light" that flashes when I start dropping big background images too quickly, so it might not be a "bug" at all--just too much hastiness on this user's part.

Edit: Just noticed that when I change the size of the window that pops up when you double click a token, the properties page doesn't resize with the window; neither does the config page. Running the mac version of build 74.

Just a quick note: I noticed that 1.3b74 is not linked on the sites front page. It still shows 1.3b72/73 as the latest bug fix release. But if you go into downloads, 1.3b74 is indeed there. I don't know if this was done intentionally or just an oversight, so I thought I'd mention it.

I am prepareing to backup and then test our Hero 6E campaign framework in B74 (we are currently running it under b70). I will let you know if anything crashes and burns.

I am also starting to do a refresher course in Javascript so that when development of 1.4 starts, perhaps I can be a better contributor, at least as far as scripting, and testing, if not developing.

On another note: Has anyone heard from Trevor? Az you are doing a fantastic job... and I am glad the project is moving forward, in some ways more smoothly than ever before, but I am also hoping that someday Trevor returns to the group, as he is very cool individual.

Doh, I probably forgot to add a new "news" item. Thanks for the reminder.

Edit: updated.


Yeah, he's alive and well. I get emails from him occasionally. They're not typically code-related though. He has gotten busy with other things and has told me multiple times, "declare 1.3 done and move on to 1.4!" but I've been reluctant to take on such a huge task by myself. So I've enlisted the help of the regulars here (y'all know who they are already I imagine) and now I can stand on their shoulders and make myself look good with very little work on my own part. Or that's my plan anyway.

Next stop: WORLD DOMINATION!! Muhahahahahahaha!

Naaaah .... before world domination I'd so like to see [enter uber-kewl feature here] in 1.3.

I want to see no more big features in 1.3 so we can get on to 1.4

Yeah, this has bitten far too many people over the years.

This is the deal - that test button is not really a well designed button. Trevor made that a long time ago and it actually contacts a computer of his at his house. When that computer is off or down, the test button fails. LOL. Like I said, not the best design.

If I were to ask Trevor about it, he would say "that button should be taken out" but the good news is that we find it useful and it will be addressed in the future. Something more robust and reliable for sure.

Thanks for the reminder

It contacts his own host at home? I wonder how much traffic he gets

I would have thought that it would request a ping-back from the web server at http://rptools.net/ ...

Well, it used to. But various hosting companies have had various problems so we kept bouncing from one to another. This last one (HostGator) has disabled the ability to open output socket connections, so there's no way to try to connect to the MapTool server.

My plan for 1.4 is to use the public services, like CanYouSeeMe.org. We would have a list of URLs and a list of classes to invoke that know how to interact with that particular URL. That way we could run through a list of them and test each one.

The final results of each test would be fed back to the RPTools.net site so that if one particular URL is failing a lot due to the web site being unreachable or somehow "broken", that URL is taken out of the list that is given to new servers when they are started.

So much code to write and so little time to write it in...

Just mentioning that the "jittery mouse" issue is still present in b74. We jumped straight from b70 where there was no issue. I was running the server and didn't experience the issue, although I only used the "wall" tool. At least two players on separate computers - one using the "burst" template, the other using the "blast" - complained of the issue. They said the template would jump as much as 5 squares while they were using it.

Background was a single JPEG image (no tiles), 50 px/square, 20x30 squares. VBL and Fog were in use. It might be worth mentioning that the map was created in an earlier version of MT, probably b70 but possibly a little earlier (like b68).

On a possibly related note, I was attempting to adjust the grid on the same map. The grid didn't start at the correct position (I'm guessing it started at 0,0 instead of the previous offset but didn't notice) and as I was adjusting it the tokens would pop back in the opposite direction, somewhat unpredictably. After adjusting the grid, the tokens displayed strange behavior on their first movement. The correct path would be highlighted and the correct distance shown, but the token itself would be one square behind (i.e. if the path was two squares the token would only have moved one). On token release it would then jump to the final square of the path. After each token was moved once it no longer exhibited the strange behavior.

Hope this helps!

HA! That's awesome.

They have always done this when you tweak the grid after a map already has tokens on it. Especially so if you offset the grid in any direction by more than one grid size.


Same deal. Both could probably be fixed but somebody has get the time to dig into it.