Hi All,

We're nicely underway using GitHub for free collaboration, and are almost ready to greenlight the donation system, and the 'specific feature' projects will be handled by TGC, but the last element we need to look at is the testing of GitHub branches which are not quite ready for merging with the master but do need some external testing to make sure they are fine.

If you would be interested in casting your eye over some new features for ten minutes, you can find the first branch to undergo some testing here: https://github.com/TheGameCreators/GameGuruRepo/tree/Lua_New_Physics_Commands

Essentially, you need to clone the repo then switch to this branch and compile Guru-MapEditor.exe as part of the GameGuru installation. You can then look at the commit notes to see what has been added, and then confirm those additions work as expected and are stable. If you want to have a go, but need help, best to post questions and thoughts here so we can keep the answers in one place. Once we've done this process a few times, I will likely create a Wiki document for it so we have a central place to keep what we have learned easily accessible.

As that happens to be my branch I'd like to point out that I am after more of a code review than a functional test for now, I'm not very conversant with C/C++ stuff so if I've done something really stupid without realising it I'd very much appreciate some feedback on that end of things.

The code I've pushed so far has already had some changes my end so expect another push as soon as those changes have been tested to my satisfaction.

@Lee, is there a definition somewhere for the internal t.tshape variable, i.e. what values it's safe to use. I was a bit puzzled at first that it doesn't match the collisionmode but for now I've used a tshape value of 6 for the sphere (collision mode 2) and plan on adding a cyclinder next so was going to use 7 (neither 6 or 7 seem to be used in the code anywhere but if you have them earmarked for something else let me know).

Are there no beta testers? That sound a bit too complicated for normal users...

Even some beta testers .

Dave

We have beta testers? Why we not give them a compiled version of this branch and let them try it? I find it shouldn´t be the task for a beta tester to compile it. Beta testers should have no clue about the source so they can test it without any knowledge like any other user.

It should be a better way of organizing devs and beta testers than this, like a hidden sub forum or similar.

You don't need to compile the code to cast an expert eye over it and let me know if I've made any glaring mistakes!

I would assume that Lee should be the one to look over the code and see if it is good, bad or indifferent.
Since most GitHub repos have some C++ coding rules created by the author.

Think of branch review and a slice between the contributor and the act of me merging it into the main branch (at which time I cast my eye over every line before anything gets into the main code). This step (if anyone wants the task) allows a contributor to sanity check their work before I take a final look before merging, which means I can spend more time on other areas. The beta build is a stage later on, when the contributions have been merged to the main branch, tested by me, and then handed over to the beta testing group. The public preview is then the stage after the beta build when it goes out to more users to test, which often finds things the smaller groups missed. It's a long process from idea to deliverable, but there is no such thing as too little testing