Messages

61

Feature Requests / Re: Assignement information on the soldiers' roster in the Employees screen

« on: September 06, 2015, 07:39:28 pm »

Currently, on the Employees screen, all the soldiers appear in the same roster with no life bar nor affectation information. What could be of some help when you organize your soldiers in a large base (16 soldiers or more) is the knowledge of those who are currently affected to any transports and eventually, those who are wounded.

I confirm that in 2.6, there is an icon for soldiers affected to a transport plane. Moreover, the name of wounded soldiers is displayed with a different color so it is pretty easy to know who is hurt.

62

Coding / Re: Using cmake to setup build env

« on: September 05, 2015, 08:14:25 pm »

BTW, I've also made a bundle with the dependencies only. It allows to compile everything with MinGW and everything excepted uforadiant with MSVC 2013.

Note that to use it, with cmake, you can set cmake variable UFOAI_DEPENDENCIES_DIR to where you unzip the bundle.
You can also create a windows env variable UFOAI_DEPS set to where you unzip the bundle to help cmake find the dependencies.

Do you want me to upload it somewhere ?

63

Discussion / Re: Feedback on 2.5-2.6

« on: August 29, 2015, 12:11:30 am »

Concerning the UFOs, I usually never try to take them down. I can barely kill scouts and do not see them often. I usually let them fly and go when they land. I understand that in the story, UFOs are much better than human crafts but it makes almost useless to try to take them down before getting UFO technology.

64

Tactics / Re: Ninja playstyle possible?

« on: August 29, 2015, 12:04:47 am »

IMHO, close combat is suicide. To not get killed by aliens, you will have to get close and kill. You will not have time to check the surroundings for another alien and, if there is one, your soldier is dead. And that will happen so often that you will keep rookies during the whole game...

65

Discussion / Re: Feedback on 2.5

« on: August 28, 2015, 11:57:29 pm »

I've played 2.6 lately. Again, thanks for this great game, it is really nice and well done ^^

I like the new GUI. It is not very easy to understand at first because there is no difference between clickable buttons and the rest of the GUI. For my first game, it was not straight forward to get to the screen allowing to recruit soldiers.
During the game, I've not seen many bugs. The only one I have seen is when I try to transfert a soldier from a base to another (with his equipment), some weird stuff is added to the cargo (for example weapons or aircraft stuff).

Apart from that, I have nothing to say except some balancing tweaks.
IMHO, strength is too important compared to the rest. In my game style, I do not use armour because it reduces so precious TU and it usually is not enough to save the soldiers.
I do not use reaction fire either because it is also too expensive on TU and it is usually not enough to kill an alien anyway.
I like the changes about smoke grenades. It forces us to be carefull when using them and is pretty well balanced since there is no way to win a combat with less than 6 losses for me without them. Not talking about the games where you start with some aliens with direct vision on our troups.

BTW, the changes about reaction fire are nice (the timer). It makes it easier to understand how it works. I remember that during my first games (in 2.5 a year ago), I even thought it was broken... I do not use it because I think it is not usefull but at least, it is easy to understand how it works now.

66

Coding / Re: Using cmake to setup build env

« on: August 27, 2015, 08:39:23 pm »

I've updated my repo to allow to output executables in the correct directory when using MSVC (instead of Debug/Release)

67

Coding / Re: Using cmake to setup build env

« on: August 26, 2015, 10:52:46 pm »

Note that I've updated my fork (after rebasing) if you want to try:
https://github.com/hwoarangmy/ufoai

68

Coding / Re: Using cmake to setup build env

« on: August 26, 2015, 10:14:44 pm »

I'm done with cmake. I could build all the projects on:
- MinGW32 with WinXP
- MinGW64 with Win7
- GCC with Ubuntu
- MSVC with win7 (except uforadiant as there are too many dependencies related to GTK)

I had to make some changes to allow compilation with MSVC. Moreover, this compiler has seen a few problems I've fixed.

I've also created a bundle with mingw/msvc dependencies. If the path is given to cmake (by filling corresponding field or by creating an env variable), all the dependencies should be found automatically.

Do you want me to create a github pull request ?

69

Coding / Re: Using cmake to setup build env

« on: August 25, 2015, 01:19:10 am »

I'm almost done with what I wanted to do. I could build all the projects with Windows and Linux. All of them are optional (only UFO and GAME checked by default).
However, I'm lacking quick description for the projects:
- GAME: "Build the library handling the battlescape"
- UFO2MAP: "Build the tool to compile maps"
- UFODED: ?
- UFO: "Build the main game"
- UFOMODEL: ?
- UFOSLICER: ?
- UFORADIANT: "Build UFO AI editor"
- UFOTESTALL: "Build unitary tests"

If someone could fill unknow projects (or complete the other ones if needed), it would be nice.

I'm also building a package with UFO AI dependencies only (allowing to build with any code-blocks/MinGW anyone has installed instead of having to use a full bundle)

Now, I'm going to try to build the game with an older computer with MinGW32 (I've currently used MinGW64) and with MSVS2013 (except radiant and maybe testall because they have too many dependencies). If I can build it with MSVS2013, I will add required dependencies in the bundle.

70

Coding / Re: Using cmake to setup build env

« on: August 17, 2015, 09:54:03 am »

But on linux after running cmake you can just do make ufo game to build just the game, so most helpful to windows user (but now that I think VS should have something similar...)

Well, it is always possible to compile only one project but the point with turning them optional is to not ask for dependencies. This way, if you disable uforadiant, for example, cmake will not ask for GTK (or at least won't complain if it is missing)

Linux executables don't have icons

Ok, nice to know

Well we currently have SDL2 taking priority over SDL (and the worst bugs are already fixed ) so this is maybe backwards, but OK for starting.

Ok. So, I will change so that SDL2 is chosen in priority to SDL.

For consistency I'd have to say yes please.

Ok. I will do that.

Note that I won't be around for a few days so I won't have time to do requested changes now. I will do them once I'm back ^^

71

Coding / Re: Using cmake to setup build env

« on: August 16, 2015, 11:03:20 am »

There seems to be no support for SDL2?

It works with both. I've tested on windows with SDL2 (I downloaded) and SDL (from the package). Both worked. You just have to choose the corresponding includes you want and the libraries.

Also yes, having the option to turn projects on and off would be nice, as for dependecies, I gues that would be most useful for windows user I'd think?

I guess that most users won't use radiant and it has many dependencies so it could be nice to be able to turn it off. And if we are there, we can do the same for all.

BTW, note that I've simplified the rc files to allow choosing the path. Do you want me to change the codeblocks projects in build/projects to match ?
Moreover, I don't know how to choose the icon on linux (the equivalent to the rc files). Do you know how does it work ?

EDIT: I've installed SDL2/SDL2-mixer/SDL2-ttf and I confirm it works when we change the include paths/libraries. I remember having read news about bugs in UFOAI when using SDL2. Later, the makefile can be changed to look for SDL2 before SDL.
Note that I've tested and if SDL2 is installed but not SDL, SDL2 is not found

EDIT2: If you want to try, I've updated the commit in my repo so that if SDL is found, it is used. And if not, it will search for SDL2.

72

Coding / Re: Using cmake to setup build env

« on: August 16, 2015, 12:56:57 am »

I'm done with the first version. I've tested on Linux and it builds successfully on my Ubuntu as well as on windows.
I've rebased tonight and made the required changes due to lua.

Note that I've tried to follow what was done on the makefiles while working on cmake. But I couldn't test on Solaris or MacOSX.

If you want to integrate it, I can make a pull request on guthub.

The next steps, if you want, could be to turn building projects optional (with only game + ufo checked by default).
It might also be a good idea to allow to enter a dependency path so that users can compile without having to mess with the dependencies (that would be very close to the codeblocks current zip but with the dependencies only).

To test, you can have a look:
https://github.com/hwoarangmy/ufoai

WDYT ?

73

Coding / Re: Using cmake to setup build env

« on: August 11, 2015, 10:55:32 pm »

I've tried with a newer version of glib (the one bundled with the latest gtk version) and, as expected, it fixes the compilation problem with mutex functions.

Concerning cmake,  could make it work and found a way to use icons with only a small modification of the rc files. ATM, they use a flag to know if they should use a relative path. I've removed the flag and replaced it with the path to use. That makes the rc file more straight forward.

Concerning the bundle, I can make a new one to fix the issue by replacing glib headers + libs. Do you want me to do that ?

Concerning cmake, I'm testing on linux.

74

Coding / Re: Using cmake to setup build env

« on: August 11, 2015, 12:29:50 am »

Yes, I had this error when using the headers/libraries from the codeblocks+mingw package.
The error comes from this commit:
https://github.com/hwoarangmy/ufoai/commit/bf841a7ff5325e10775cae7a67eaf7ebea67a30f#diff-3062a8827676e9b846c0ac56236a4744L340

because g_mutex_init and the mutex related functions are not found. For my tests, I've rolled back this commit and it worked.
If I am not mistaken, those functions are from glib. I guess your Linux distros have more recent glib. The best would probably be to update the bundled glib. I will try with a new version and tell you if it works.

Concerning cmake, I was able to build all the projects (including radian). There were too many dependencies so I didn't want to mess with gtk and all their dependencies. That's why I used the package libraries. For cmake finding module, I will assume there is 1 include directory per needed library (in the bundle, the include directory will be the same for all dependencies).
Now, the last missing thing is the icon ^^

Then, I will try on linux

75

Coding / Re: Using cmake to setup build env

« on: August 08, 2015, 10:34:45 pm »

Well, actually, it was easier than I expected. I choose to not use a bundle for dependencies to try the latest versions I can find. Note that I use code blocks with MinGW64.
ATM, I can build every project excepted uforadiant because it needs gtk. I've downloaded gtk dev libraries but it seems an older version is used in this project as I get errors complaining that only gtk/gtk.h should be included (from what I've seen, many files here include gtkwidget or only what they need - which seems not the way to do in the new version).
Because of that, I've downloaded ufoai codeblocks zip to get the includes and libraries used in the project (since I cannot use the latest version, the easier is to use this one).

For finding the dependencies, I've tried to use the scripts bundled with cmake as much as possible (because they probably include more search paths than the ones I will think of - especially on environments I don't know like MAC OS). Fortunately, I could find those for most of the required dependencies.

Once I get uforadiant to compile, I will have a look with linux (with Ubuntu running in virtualbox). I guess it will be easier as with windows, no dependency is found by itself.

That is bad, since it should have a positive effect on code stability if you're able to compile and/or debug using various tools, and developer interest can rise.

Yes, finding people who want to join an open source project is hard enough to not have them have to change the environment they like.
The good point with cmake is that it sets up the environment you like (be it MSVC, codeblocks MinGW, ...) by itself. The problem with maintaining project files is that when there is no more coder using it (for example MSVC), it will die fast (when a new file is addedn for example). When using cmake, you had a new file in the makefile and it will change all configurations ^^ (even some you had never tried and even knew they exist)