I don't have an interest in an isometric game---not to say this doesn't show promise! Quite the opposite in fact! ...I just never liked the style.---I am only interested in how I can use sprites for my tokens like this. Honestly, I don't need them to move according to the direction the players pull the token, but I would like to be able to use sprites in place of tokens and get them to face different directions easily.

Can anyone point me in the right direction? (I'm sure I shouldn't post this here, but this is the first time I've seen what I'm wanting on here.)

EDIT:

Scratch that. I found it in Bhoritz's signature. xD Thanks, I suppose. Answering me without so much as knowing I asking questions takes a real pro.

I know this is old news, but the more I read the plans and start to get some grasp of the rather enormous task you're about to undertake and the shift it has on the users and the rift it will create with 1.3 campaign files.... why on earth do you name this 1.4 and not 2.0(beta?)? To say the least it's a nice neon sign saying1. incompatible with earlier versions (I 've seen some programs do that before but never in a decimal increase always with a new version)2. the change will be huge, embrace yourself its gonna be a rocky ride3. It's a good sign to the outer world saying that MT is maturing and leaving its 1.0 stadium behind (more of a marketing thing then anything else)

I know this was a decision made (5 years?) ago, but I have to agree.

1.4 is for minor upgrade, i.e. major internal upgrades that add more functionality but don't radically restructure the program...I think this is why the project has stagnated in fact.

You should know semantic versioning - X.Y.Z

X - Major versions. Reserved for huge incompatibilities, major rewrites, and other earth shattering software events.Y - 'Minor' versions. Maybe a bad name because of what the word 'minor' means to a lot of people, but this actually means large functionality changes, which are intended to keep the program more or less the same though.Z - Bugfix versions. This is your 1.3-b91 stuff, the b91 part.

If you and started work on a 2.0 version and kept the door open to 1.4 being NOT a major re-write, 1.4 could have just been the version that got built off of github and had functionality upgrades. As it stands I suspect there is major unwillingness to touch 1.4 because its actually a 2.0, and everything that should have been going into a 1.4 release isn't because of the way you decided to name your rewrite.

That's at least part of the reason, I realize life happens. But, when life happens, its much easier to write bug-fixes and minor re-writes rather than major ones.

So, yeah it does matter, and think the 1.4 label is a giant mistake.

Btw I don't think its too late. A couple forum thread renames, a couple post edits, and you could right your mistake, and probably I imagine be happier for it. Not doing so I think is an example of the sunk cost fallacy:http://www.lifehack.org/articles/commun ... tupid.html

Having made a decision 5 years ago is a terrible reason to keep on going down the wrong path. Its actually a great reason to consider that you made a mistake and right your ship.

Don't get me wrong, its not wrong to work on a 2.0, but in 5 years time maybe someone could have been releasing small patches for the 1.4 line while the major work goes into the 2.0 release.

We have a live one here... I post because the devolpment aspect interests me also because they allow me too. I am glad you are a dev and i am glad you are here it enriches the community.

that being said i think from project stand point it matters little as long as it is consistently applied

From a users standpoint it matters only a little.

That's not true from a developers standpoint. If you're interested in the development aspect, perhaps it would be helpful not to look at things the way a user does. Numbers and names are very important to us, whether or not you happen to care about them.

Through this together in 15 minutes and a few lines of code...Not to rip off MOTE but there was a list of things I wanted to work on as well but figured, heck, I'll wait for MOTE, why reinvent the wheel. But with things being what they are, here we go!

Anyhoo, I want my fancy editor to. (Although, putting the lexicon together will take way more work, may evaluate a few other plugins/repos to see which is easiest. Be nice if I could convert AM's Notepad++ work over...)

Even without full syntax highlighting, we still have basic code folding, line numbers, word wrap, UNDO, mouse right-click copy/paste/menu... There's even support for external loading/saving to local file or via ftp...I've been thinking of a way we could do some better "Framework" development ala GitHub. Imagine LW's framework on Git, AM submits a update to Macro xyz, LM commits, GM's around the world load MT and get a message that there are updates, click a button, bam, new macros/tables/etc. And getting a framework is as easy as cloneURL?

If we're going to improve the macro editor I recommend parser comments. Mote actually ignores all the html comments including code inside which I'm not sure is the best idea, but does solve the blank output issue. Coldfusion uses <!--- parser comment ---> format to ignore code within.

Well, to be clear, this only modifies the dialog panel. But I could look at the parser and if a quick hit add in the HTML style comment block. I haven't played with the parser so not sure what's involved.

I'd like to look into making it a docked window as well, I like how MOTE did that. A little more persistence and maybe tabs to prevent opening/closing the macro everytime.

I'll just post this here. I've been out of the loop some time. (a) There are a lot of issues listed in Github for Maptool. Is that the list "we" work on or is this collected elsewhere? (There used to be a special thread here that Azhrei and others would refer too,) (b) Working with GIT: everybody forks, completes his "issues" and then issues a Pull request for "RPTools" to approve? (Just to confirm.)

I'll just post this here. I've been out of the loop some time. (a) There are a lot of issues listed in Github for Maptool. Is that the list "we" work on or is this collected elsewhere? (There used to be a special thread here that Azhrei and others would refer too,) (b) Working with GIT: everybody forks, completes his "issues" and then issues a Pull request for "RPTools" to approve? (Just to confirm.)

Yes, GitHub is the best place to file bugs as well as where to pick out the ones you want to work on.

Be sure to post in the Issue thread that you're planning to take it on. There may be some design docs or other information that will help.

We currently have the master branch and a dev-1.4-branch. You want to fork the RPTools/maptool repo and then create your branches off of the 1.4 development branch. Try to keep one branch per issue -- they're more likely to get reviewed and merged if they're not monstrously large (!) and keeping one issue per branch is a good way to keep the size down.

For your own testing purposes, you may want to create your own "development branch" off of dev-1.4-branch. For example, call it "my-fixes" or whatever. Then create issue branches off of that. This lets you selectively merge your branches back into your dev-1.4-branch while keeping them separate for the purpose of creating pull requests. But this is up to you.

If you'd like to discuss this more, you can open a new Issue about it.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum