Messages

1021

Coding / Re: MSVC ?

« on: October 12, 2008, 09:22:04 pm »

gcc.

I fired up UFO to take the screenshots, only to find that the strange textures were back to normal (no update, no recompile, no drugs).

However, two problems persist:
- the i18n insists to show german text. I can set it to english in the options menu, but the game stays in german.
- the 'einzelgefecht' feature (nice idea btw) doesn't seem to work. I can select eg. oriental and 'start', but it simply returns to the main menu.

Known bugs or my problem ?

1022

Coding / Re: Event system

« on: October 12, 2008, 01:46:04 am »

@Mattn:
The Schedule_ stuff seems to be only used with battlescape. The above discussion is about geoscape timers.
The code might be reusable, though.

@Rudolfo:
When getting latest svn, I found several occurrences of your name in the log. So I assume you're much more familiar with the code than I am. Hope I didn't tell you too many things you already knew. If I did: Sorry for that

I dug in the code a bit yesterday, and it's a little worse than I thought. It's not just about a missing minutely check in CL_CampaignRun(), it's also that slot->installationTime is given in *full* hours. That is, 2 hours means '2'. Switching that to 120 minutes is not a biggy, but installationTime is also persistent !
So changing the format would break savegame compatibility.

1023

Coding / Re: MSVC ?

« on: October 11, 2008, 11:55:57 pm »

Ok, I managed to install C::B, get latest svn src, build it and - believe it or not - it worked
Well, quite.
I ran into several very obvious bugs (like the textures of items and persons in the recruit and the equip screens are ...uhm ... 'strange').

Which leads to the question: Is that a problem with the current svn code or did I miss something during installation/config ?

1024

Coding / Re: MSVC ?

« on: October 11, 2008, 08:41:47 pm »

@blondandy:
That's the link I used yesterday. Just tried it again minutes ago and it failed again

@Mattn:
Thx. Rapidshare did the trick

1025

Coding / Re: Event system

« on: October 11, 2008, 12:07:14 am »

Ok, now we are talking about the same thing

A queue can be very efficient as far as checking for expiration is concerned. Inserting new timers costs more cpu because the queue is sorted, and cancelling a timer can be a pita. It all depends on the total # of timers, the # of different timer types, the spread of timer duration, the accuracy required and so on. There are various designs for every combination.

However, *before* discussing the most efficient way of timer implementation for UFO:AI, imho we should simply ask one of the devs around here whether timer checking accuracy is really a cpu-problem. Maybe we could have certain timers checked minutely without hurting performance ?

1026

Coding / Re: MSVC ?

« on: October 10, 2008, 10:24:32 pm »

Ouch...that IS a showstopper
My MSVC installation definitely has no clue about ipv6. And the errors I get sound much like they are ipv6-related (addrinfo etc.).

Ok, I decided to give C::B a try and tried to DL your prepackaged zip. But only got between 12 and 42 MB of those 60+ before the DL stops Is that me or your server ?

1027

Tactics / Re: Super-aliens or Alien heroes

« on: October 10, 2008, 01:51:49 am »

I agree with Sophisanmus.
A 'pink Ortnok' would do the trick from the gameplay perspective.
Not nice, but working.

1028

Coding / Re: Event system

« on: October 10, 2008, 01:37:38 am »

I don't know whether a timer queue would be really helpful in the end.

First let's make sure we're talking about the same thing.

In *my* wording, an event is something that comes from *outside* the code, like a user's mouseclick, from the OS or at least from a different thread of the same application (afaik UFO:AI is single-threaded btw).

Installing a new weapon on an aircraft is a *timed process*. We start it, it has a duration, and we can calculate the ending time of that process. So we start a 'timer' and need some code to more or less frequently check if the timer has expired. We could do that in a decentralized way OR put all the timers into a 'timer queue' (which eases checking for expiration, but introduces other problems).

So how is the 'event system' you have in mind different from that ?

1029

Coding / Re: MSVC ?

« on: October 10, 2008, 01:02:07 am »

Uhmm...remember: I'm trying to avoid the installation of MingW/C::B.....
But nevermind, I managed to overcome the features.h prob by creating my own libintl.h, deleting all the macros from features.h.

atm I'm running a brute force q&d attack on the *2.2.1. src* just to figure out if there are any showstoppers.
IF I should succeed, I'll send *clean* patches for 2.3.x, of course

Meanwhile I've been able to compile everything except net.c (which may become a showstopper because I don't know nothing about networking code ). Currently struggling with linking the libs.

1030

Coding / Re: Event system

« on: October 09, 2008, 01:20:34 am »

From my experience, 'check timers at interval x' vs. 'timer queue' is a very complex design decision involving
- # of different event types
- spread of event duration
- dependencies between events (like AMtep lined out).
You can end up with different systems for different intervals.

The example you gave (installing armor) could easily be resolved by checking *certain* events on a minutely basis in CL_CampaignRun (at the price of a little more cpu-usage).

While playing UFO:AI, I never ran into a situation where those 23 minutes were *crucial* to the gameplay.
So do you have another example where a timer queue would really help ?

1031

Coding / Re: MSVC ?

« on: October 08, 2008, 11:42:56 pm »

I went ahead and added the sources from some dirs (namely shared, game, client, common) to my little MSVC-project and tried to compile.
Well, it doesn't look that bad....
Here's what I did so far (hope you understand the ultra-short notation):

- get inttypes.h add include-path
- get stdint.h
- get libcurl package
- define ssize_t in dbuffer.h
#ifndef ssize_t
#define ssize_t int
#endif

- #ifndef _MSC_VER in shared.h around min/max definitions

- problems with net.c, dbuffer.c, scripts.c need further investigation

- get libSDL
- get SDL_mixer
- get libintl

Looks like I'm re-inventing your C::B-package to some extent

Now I ran into this problem: libintl.h includes features.h.
I have learned that features.h is common to many glibc includes, but either I'm too tired or too stupid to google for the *right* link that solves this problem.

Do you (or anyone else) have an idea or a good link ?

1032

Coding / Re: Searching C++ Programmers

« on: October 08, 2008, 08:43:57 pm »

If you have general C++ questions, I might be able to help.

1033

Windows / Re: Problem with interception

« on: October 08, 2008, 08:33:14 pm »

Wait until the UFO is close enough to the base. Dropships have a longer range, so they are offered earlier on dclick UFO.

1034

Coding / Re: MSVC ?

« on: October 07, 2008, 12:17:00 am »

Thanks, Mattn

I finally found some spare time and surfed to the Code::Blocks site (I was particularly pleased to see it is hosted at berliOS ).
The site says it also supports the MSVC compiler. So it seems to me it's NOT UFO:AI's restriction to Code::Blocks or eclipse, it's more a restriction to MingW...

However, I'd like to cling to MSVC. So...

Q1: If I should get it to run with MSVC, would you appreciate if I documented my steps in the wiki ? Or is M$ totally disliked here ?

Q2: I managed to overcome the inttypes.h and stdint.h problems. Next is curl.h. Stupid question: does libcurl automagically come with MingW or has it 'silently' been packaged into the (UFO-)Code::Blocks installation package ? I didn't see it being mentioned in the wiki.

Q3: There is a libcurl-4.DLL in the UFO-dir, but I also found this code (in eg. q_shared.h):

Code: [Select]

#define CURL_STATICLIB
#include <curl/curl.h>
Uhmmm...STATICLIB doesn't really sound like DLL to me. I'm a bit puzzled. I guess a sentence or two from you could save me quite a lot of work to figure that out...

t.i.a.

1035

Discussion / Re: Troop deployment

« on: October 02, 2008, 01:24:29 am »

@dSvenB:
Which version ? 2.2.1 or 2.3.x
Which difficulty level ??
Which mission(s) ?

I myself played 2.2.1 until Aug 2nd (inGame time) and *never* encountered your problem. Actually, I managed to loose *none* of my soldiers
Maybe you should rethink your tactics ??