Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Grug

Pages: 1 2 [3] 4
Tactics / Re: Capturing live hovernet/combat hovernet and bloodspider/c.b.s
« on: February 01, 2014, 02:28:41 pm »
Because they are mechanical devices rather than alien creatures (although with an alien brain?), I don't think you can capture them. I'm sure one of the research docs mentions something like this, but I haven't been able to find it again.

This isn't a definitive answer, just my experience thus far.

Tactics / Re: Research confusion
« on: January 29, 2014, 03:04:08 am »
I must ask however, is a 2.4 savegame playable correctly in 2.5? Or I should better start from the beginning?
A 2.4 savegame is playable, but only marginally. Your solider's stats will be lower than that of a new recruit in 2.5 due to changes in how equipment and TU's are allocated. I don't know of any thing that might affect tech tree type stuff, but it would be far safer to start from scratch to avoid any bugs like that.

Also, there are sometimes several soldiers that get the reaction fire simultaneously and the solider that is going to take the shot might not be the best option (they might be better placed to cover a different angle, etc and so keeping their reaction fire could be advantageous). Some way to select which of the available soldiers takes the shot would be handy.

Discussion / Re: Interceptions
« on: January 25, 2014, 08:15:49 am »
Moving slightly forward. What about the possibility of launching interceptors when no alien ship is detected? it would be nice to do in order to escort a dropship or to try to detect an hidden alien base but to my knowledge it's not possible at least in version 2.5. I miss a lot this feature available in the old XCom.
You can launch a ship at any time from the aircraft page in the base view. Select the aircraft you wish to launch and if it has a pilot and is at home, there should be an icon in the front of the text under "Status:". Clicking this launches the aircraft.

Bugs in stable version (2.5) / Re: Fullscreen mouse grab
« on: January 14, 2014, 09:10:31 am »
Take your time playing. A dev should know the game he is programming ;)

Looking for bugfixes all by yourself is tough. With a little help from the other teammembers it's much easier. And that's part of the fun...
Sure, certainly planning on interacting with the other devs once I join the team (I'm actually lurking in IRC incognito)...

I wasn't actively looking for bugs to fix, just playing the game and fixing things as I came across them that's all. ;-)

Bugs in stable version (2.5) / Re: Fullscreen mouse grab
« on: January 13, 2014, 06:20:53 pm »
Pushed it to both master and 2.5. Sorry for the delay.
No probs. Was just checking it wasn't forgotten.

You must be a rather qualified dev if you can find the line of code you need even in the ufoai src ;)
lol, thanks. Wasn't super hard, just a little grepping.

Needless to say that such persons are of course invited to deliver more patches of even join the team.
Yeah, I've been thinking I'd love to join the team. Been looking around for little bits and pieces here and there to submit patches for, but I also wanted to really play the game seriously (rather than just here and there for a week or so every couple of releases) before requesting to join the team more officially.

Bugs in stable version (2.5) / Re: Fullscreen mouse grab
« on: January 13, 2014, 05:57:01 am »
well, that is something i would accept a patch for even for 2.5. let ctrl+g work in fullscreen might be useful.
I just cleared my local changes and noticed that this hasn't gone in to the 2.5 branch yet

Bugs in stable version (2.5) / Re: Fullscreen mouse grab
« on: December 27, 2013, 12:41:51 pm »
well, that is something i would accept a patch for even for 2.5. let ctrl+g work in fullscreen might be useful.
This just removes the else block containing the warning and turns the full screen test into the else block. Works for me so far.
Code: [Select]
diff --git a/src/client/input/cl_input.cpp b/src/client/input/cl_input.cpp
index 4407034..ad15cf2 100644
--- a/src/client/input/cl_input.cpp
+++ b/src/client/input/cl_input.cpp
@@ -941,8 +941,7 @@ void IN_Frame (void)
-               /* don't allow grabbing the input in fullscreen mode */
-               } else if (!vid_fullscreen->integer) {
+               } else {
                        /* grab the pointer */
                        Com_Printf("Switch grab input on\n");
@@ -950,9 +949,6 @@ void IN_Frame (void)
-               } else {
-                       Com_Printf("No input grabbing in fullscreen mode!\n");
-                       Cvar_SetValue("vid_grabmouse", 0);

Bugs in stable version (2.5) / Re: Fullscreen mouse grab
« on: December 27, 2013, 07:57:35 am »
Ctrl+G doesn't work in fullscreen so you still have to go to the options to disable fullscreen to toggle it with Ctrl+G.

Bugs in stable version (2.5) / Fullscreen mouse grab
« on: December 26, 2013, 02:39:29 pm »
Is there any reason that mouse grab is disabled in fullscreen mode?

I have multiple monitors, but run the game in full screen on a single monitor. In order to enable mouse grab after starting the game, I need to go into the options, disable fullscreen, enable mouse grab and just don't restart. I also re-enable fullscreen (also without restarting) otherwise the next time I restart the game it will appear windowed.

I have commented out the code stopping input grabbing in fullscreen mode and done some initial testing without any noticeable problems. I'll post if I come across any.

Have you thought about adding a textfile to the game download that includes the answer to the security question?- I'd think spambots wouldn't want to download almost a gig of data?
That's an interesting point. Maybe have a message on the loading/main menu screen, somewhere that doesn't require searching, but small so as to be unobtrusive.

That would make it harder to change if necessary as not everyone would have the same version of the game, etc

Bugs in stable version (2.5) / Re: LE_NotFoundError / back to geoscape
« on: December 16, 2013, 03:03:30 pm »
A major battlescape bug has been fixed recently. Try a new nightly.
I just got this on Fuel Dump with 2.5 compiled from 176d977 (Duke's screen res fix commit on 12-12-13).

Code: [Select]
ERROR: LE_NotFoundError: Could not get LE with entnum 27 of type: 3 (src/client/battlescape/events/event/world/e_event_entperish.cpp:44)

This is an issue I have been having, and I suspect it is linked to the everlasting smoke grenades and incendiary grenades, which is an issue tagged as resolved on the bug tracker, but is still extant on the oct 12th build. I also suspect that when we get an updated stable build this issue will be solved...
I have run into this issue in my 2.5 game and so compiled latest 2.5 and it is fixed so just need to wait for the next 2.5 build.

Bugs in stable version (2.5) / Re: Missing screen resolutions
« on: December 13, 2013, 02:19:32 am »
Hmm. Rereading your post, it sounds like this patch is even more important for 2.5, right ?
Yeah, it seems it isn't necessary for 2.6-dev as the resolution detection works. The problem is with 2.5 and so should be committed to the ufoai_2.5 branch.

Bugs in stable version (2.5) / Re: Missing screen resolutions
« on: December 12, 2013, 03:46:53 pm »
Ok... so an update:

The most recent Debian 2.5 packages seem to default to 1024x768 in the bottom left of a 1920x1080 screen.
2.6-dev correctly detects 1920x1080 but sets both monitors to shared output. It also gives the correct full screen resolutions (3840x1080 and 1920x1080) in the options. Using SDL_VIDEO_FULLSCREEN_HEAD=0 does limit it to only display on a single monitor.

My concern however was with the almost stable 2.5, especially if it will finally get an official release in Debian (and derivatives) and other distros. It might put people off if they get this odd sized and misaligned screen, especially as there is no way to fix it in the options, you need to edit the config file and specify the height & width manually.

So after adding my own definition (24) for 1080p to cl_video.cpp and compiling the code, it still defaults to 1024x768 in a bigger window (so there is no detection happening there), but the option does appear in the list of available modes in the Options, and when selecting it and restarting the game, it does restart at the correct res.

I think this little change would make life easier for newbies to get into the game if we can't fix the detection issue for 2.5

Code: [Select]
diff --git a/src/client/cl_video.cpp b/src/client/cl_video.cpp
index ed74f43..dab46fb 100644
--- a/src/client/cl_video.cpp
+++ b/src/client/cl_video.cpp
@@ -70,7 +70,8 @@ static const vidmode_t vid_modes[] =
        { 1400, 1050, 20 }, /* samsung x20 */
        { 1440,  900, 21 },
        { 1024,  600, 22 }, /* EEE PC */
-       {  800,  480, 23 }  /* OpenPandora */
+       {  800,  480, 23 }, /* OpenPandora */
+       { 1920, 1080, 24 }  /* 1080p */

Pages: 1 2 [3] 4