Thought I would say hello, and introduce myself, hope I can help out...

[ShaneG]

I am pretty much brand new to the game, only found it a few days ago.

My name is Shane, and I also registered on trac, but with the username: Shane. I guess it was taken already in the forum.

I am a software developer, mostly business application development, with a pretty heavy background in image processing, OCR, business process automation, etc.

Lately I have been heavily involved in quite a few large web applications, and have extensive Linux desktop and server experience.

I have done a very small amount of video game programming, with a little bit of Android game development mixed in. Taught a small group of teens an intro to programming class at a Boys and Girls club, and used LibGDX as the platform.

I will admit that I am a bit rusty in C and C++, but they where my first real programming languages learnt back around 1989-1990 right after teaching myself Basic and QBasic.

I started pretty young, wrote my first program in Basic around 1988 at 10 years old to help my Grandmother and I store our family history research information. Back then there wasn't any software that we could find / afford that would help us store our research in a source first fashion, and would allow us to store unconfirmed information gathered while researching our genealogy.

I have worked as a freelance / self employed software developer since 2007, and work from home. I am heavily involved in local Chamber of Commerce activities, and am currently a member of the Chamber Ambassador Committee.

I didn't mean to ramble on, but wanted to give you all a bit of my background.

I am loving the game so far, and hope to learn enough about it to start digging into some of the issues in the trac queue in the near future.

Some questions I have:

1. I notice there are some Git related tickets queued for A18. Is there a plan to migrate away from svn to Git?

2. What areas of expertise are most lacking from the development / support team?

3. Is there any tracking of 3rd party tools used to ensure they stay up to date? (Example: I see the file binares/data/mods/mod/globalscripts/sprintf.js that seems to be used for internationalization. It doesn't appear that any changes to Alexei's sprintf.js since 2010 have been implemented, and in particular there was a change in May of this year that increased the performance by 20%. See: https://github.com/alexei/sprintf.js/issues/6)

Well, I will stop there for now, and I look forward to helping out where I can.

[Pureon]

Welcome to the community Shane

Hopefully one of our talented programmers will be able to answer your questions in more technical detail than I can... if not, I'll give it a go later!

We do have a wiki with some helpful info: http://trac.wildfiregames.com/wiki/GettingStartedProgrammers (You may have found it already)

[feneur]

Hello and welcome Shane

I wouldn't say you rambled, it was interesting to read and get an idea of who you are.

As for your questions:

1. Yes, it's our intention to move from SVN to GIT. There are some issues which needs to be overcome before we can do that though, but I'll leave it to the programmers to do that.

2. Basically most advanced knowledge, most of the easier/smaller tasks have already been completed, which means that it can be a bit hard to get into development at this point.

3. I'll again leave it to the programmers to answer in more detail, but I can answer in general. We try to keep things reasonably up-to-date, but I'm sure there are things we might have missed. I know some libraries/technologies we can't upgrade yet because we still want to support reasonably old compilers (or more generally operating systems).

[leper]

Welcome, now to your questions:

1. I notice there are some Git related tickets queued for A18. Is there a plan to migrate away from svn to Git?

Plans yes, action not so much. The unresolved (more related to implementing and testing it) issues are mostly related to library and autobuild handling (and updating of all of that). We provide win32 autobuilds in SVN so that eg artists do not need to compile the game, but can just run the exe without having to worry about such things. Keeping prebuilt libs and exes in git isn't a good idea because it would bloat the repo size as you have to get the full repo history (ignoring shallow copies).

2. What areas of expertise are most lacking from the development / support team?

Quite a lot of the remaining "big" tasks require some knowledge of the engine, but I'm quite sure that there are enough left to get into development somewhat easily. Just checking trac tickets should give you some ideas, maybe starting with some of the simple tickets (meaning limited in scope of files/logical partitions you have to change) linked from the GettingStarted wiki page[/wiki] would be a good idea.

Another thing that could be considered lacking would be time.

3. Is there any tracking of 3rd party tools used to ensure they stay up to date? (Example: I see the file binares/data/mods/mod/globalscripts/sprintf.js that seems to be used for internationalization. It doesn't appear that any changes to Alexei's sprintf.js since 2010 have been implemented, and in particular there was a change in May of this year that increased the performance by 20%. See: https://github.com/alexei/sprintf.js/issues/6)

For 3rd party code included (not in libraries/) there isn't really a lot of tracking going on. Places where we bundle 3rd party code (again outside of libraries/) would be:

• source/third_party/
  • tinygettext doesn't really have an upstream anymore, but there are some tickets related to synching changes
  • mongoose which changed the license to GPL2 some time ago (which is an issue without the or later clause, as gloox is GPL3) and isn't really used apart from debugging (where it only listens on localhost by default)
  • jsonspirit could probably be updated (slightly outdated and only used for JSON handling in Atlas (the editor))
  • mikktspace is up to date
  • encryption should be checked if there were any significant changes
• build/premake/premake4/ See #1518
• binaries/data/mods/mod/globalscripts/sprintf.js Could you create a ticket for that (and maybe attach a patch to it)?

[ShaneG]

Thanks everyone for the replies. I look forward to helping out where I can.

I am actually glad to know the project will be moving to Git, I quite like it!

One idea regarding storing the Win32 executables in Git would be to use submodules (http://git-scm.com/docs/git-submodule). I would recommend if that approach is taken that the source repo actually be the submodule of the binaries so that developers wanting only code, or on other operating systems don't have to pull in the Win32 executables. Then people wanting to pull in the exe's would just clone the binary repo and would get everything.

I am finishing up a project right now for a client, and will put in some time this weekend on the rest of your comments.

Thanks again,

Shane

[leper]

Using submodules to store the binaries would still make a huge git repo for Windows users to clone. Using SVN for something like that would be a better solution, would still need a way to handle all of that without making it complicated for users. (The issue has been thought about a lot, just missing someone with time and motivation to implement and mainly test it)

[ShaneG]

• binaries/data/mods/mod/globalscripts/sprintf.js Could you create a ticket for that (and maybe attach a patch to it)?

The ticket is created with a patch: http://trac.wildfiregames.com/ticket/2859

I tested it in Linux and and doesn't seem to break anything.

I haven't dug in to the tests to see if there is one to test that sprintf.js is functioning correctly, but they all pass. If there isn't a test I probably should have created one, but maybe I can handle that when I have more time.