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.

Topics - Another Guy

Pages: [1] 2 3
FAQ / Compile...
« on: April 27, 2010, 07:26:12 pm »
Well, I've been away for quite some time, and now I do not seem to be able to do things again.

1) My maps now take forever to compile (look atachment). Used to be fairly quick on same hardware and OS.

2) I can't seem to compile binaries anymore. I double checked settings and all paths are the way I left it last time I compiled right, but for some reason I am getting:

-------------- Build: windows in ufo_tests ---------------

Running target pre-build steps
..\..\contrib\scripts\codeblocks_check.bat ""
ECHO est  desativado.
ECHO est  desativado.
"unable to find bin\WINenvVER"
Compiling: ..\..\src\common\cmd.c
Compiling: ..\..\src\common\cmodel.c
Compiling: ..\..\src\common\common.c
Compiling: ..\..\src\common\cvar.c
Compiling: ..\..\src\common\dbuffer.c
Compiling: ..\..\src\common\files.c
Compiling: ..\..\src\common\http.c
Compiling: ..\..\src\common\ioapi.c
Compiling: ..\..\src\common\list.c
Compiling: ..\..\src\common\md4.c
Compiling: ..\..\src\common\md5.c
Compiling: ..\..\src\common\mem.c
Compiling: ..\..\src\common\msg.c
Compiling: ..\..\src\common\net.c
Compiling: ..\..\src\common\netpack.c
Compiling: ..\..\src\common\pqueue.c
Compiling: ..\..\src\common\routing.c
Compiling: ..\..\src\common\scripts.c
Compiling: ..\..\src\common\tracing.c
Compiling: ..\..\src\common\unzip.c
Compiling: ..\..\src\game\inv_shared.c
Compiling: ..\..\src\game\inventory.c
Compiling: ..\..\src\game\q_shared.c
Compiling: ..\..\src\ports\windows\ufo.rc
Compiling: ..\..\src\ports\windows\win_console.c
Compiling: ..\..\src\ports\windows\win_shared.c
gcc: Files\: No such file or directory
gcc: \(x86\)\MinGW\include: No such file or directory
windres.exe: preprocessing failed.
Process terminated with status 1 (0 minutes, 4 seconds)
1 errors, 0 warnings
Process terminated with status 0 (0 minutes, 4 seconds)
1 errors, 0 warnings

The "Files" and "(x86\)" folders on the last lines seem to be "Program Files (x86)" where MinGW is installed (I'm running Vista 64 bits Ultimate). Strangelly it should be (x86)\ intead of (x86\). I looked into every settings path in Code Blocks and can't seem to find anything wrong like that.

To add some information, I added to muton's old C::B Package MinGW files all files (overwrite) from Mattn wiki package. So I'm pretty sure I have all libs. I even tried after that getting latest MinGW and GTK files from net and overwriting it over my resulting package to have it really up to date. No luck. Then I did the same to C::B files. Still same result.

So making it short: I have all new mattn and old muton's libs (he probably updated his libs on the last year. lol) and updated files of MinGW, GTK, C::B and double checked settings for correct paths.
And it still won't compile most of the files (It does compile however game.dll, ufo2map.exe and uforadiant_brushexport.dll. None of the others).

My best bet it to reset entire SVN folder, since large repository updates (10 months gap) tend to cause some bugs.

In the meanwhile, any ideas?

Coding / Compiling maps too slow
« on: July 14, 2009, 06:28:31 am »
I used to compile all maps in about 1-1.5 hour. Now the process is taking ridiculous 16 hours. No relevant changes on my PC. It was so weird I even checked for virus with 3 distinct antivirus. I even tried shuting down my PC and unplugging power cable for about 5 min to ensure all RAM and buffers were lost, then starting windows and terminating all non critical processes. Then I did the process again. Same slow result.

Was the way maps are compiled changed between now and and july 6th (my last full compile)?

Anyone else with same issue?

Offtopic / Squawks
« on: July 13, 2009, 06:10:13 am »
Some aicraft jokes:

Here are some actual maintenance complaints logged by those Air Force pilots and the replies from the maintenance crews.

(P) = Problem
(S) = Solution

(P) Left inside main tire almost needs replacement.
(S) Almost replaced left inside main tire.

(P) Test flight OK, except auto land very rough.
(S) Auto land not installed on this aircraft.

(P) # 2 propeller seeping prop fluid.
(S) # 2 propeller seepage normal - # 1, # 3, and # 4 propellers lack normal seepage.

(P) Something loose in cockpit.
(S) Something tightened in cockpit.

(P) Evidence of leak on right main landing gear.
(S) Evidence removed.

(P) DME volume unbelievably loud.
(S) Volume set to more believable level.

(P) Dead bugs on windshield.
(S) Live bugs on order.

(P) Autopilot in altitude hold model produces a 200 fpm descent.
(S) Cannot reproduce problems on ground.

(P) IFF inoperative.
(S) IFF always inoperative in OFF mode.

(P) Friction locks cause throttle levers to stick.
(S) That's what they're there for.

(P) Number three engine missing.
(S) Engine found on right wing after brief search.

(P) Aircraft handles funny.
(S) Aircraft warned to straighten up, "fly right," and be serious.

(P) Target Radar hums.
(S) Reprogrammed Target Radar with words


Feature Requests / Production time
« on: July 09, 2009, 12:07:15 am »
I propose the way production happens change to suport large engineer groups in a base.

The way production happens today, if *produt required engineer hours < available engineerson that base*, then the exeding engineer hours is wasted. Max production per hour is one unit.

eg. Assuming one item require 1 engineer hour to produce and u have 100 engineers on the base (with apropriate workshop space), one would expect that over one hour 100 itens would be produced. The way it is handled today, only one item is produced every hour, so it would take 100 hours, wasting the work time of 99 engineers.

If production output gets calculated every 1/10000 hour intead of every hour (prodution would have to support fractions) this could be solved. I propose such large fraction to support any given situation and calculations not involving products of 10 engineer hours (eg. 273 engineer hours with 34 engineers). Maybe even larger (1/100k, 1/1kk...).

Bugs prior to release 2.3 / Electro lasers
« on: July 08, 2009, 07:50:42 pm »
Not sure if it is a bug. Maybe it is intended and I got the wrong idea.

In case Electro lasers are intended to stun the targets, then it is certanly bugged. I went on a mission against 6 aliens with 8 soldiers. 4 of them droped their lethal weapons and used only the electro lasers they had on their backpack to take down 3 aliens (no other weapon hits). Each alien took about ~7 electro laser hits before going down. The other 3 aliens were killed with regular lethal weapons. On victory screen, game stated all 6 aliens as dead. Dunno if it matters, but I was playing on very hard campaing.

Obs: R25053

Bugs prior to release 2.3 / Reload and reaction fire
« on: July 08, 2009, 06:51:28 am »
Reloading weapon seems to ignore TU reservation most of the time. It shouldn't. Since u can't turn reaction fire off once u r out of TU for it, u end up with some TU wasted for that turn. (R25053)

Bugs prior to release 2.3 / Can't start map
« on: July 07, 2009, 03:50:48 am »
I'm having trouble in starting a specific map. Console won't show his name, so I took a screenshot in case map objective helps.

When dropship arrives and I hit enter, game tries to enter map but instantly crashes back to geoscape. Console returns:

ERROR: SV_AddMapTiles: Impossible to assemble map

After that, if I try to enter map again, program crashes telling server is still loaded.

It is the only map I had trouble so far. Deleting and reassembling the maps (.bsp) didn't help.

Edit: Maybe it has to do with the fact I'm using herakles dropship (or not). I deleted the alien base requirement from research.ufo so I could have a faster dropship. However, all other maps simply use firebird model instead and it always works fine for me.

Edit 2: R25029

Bugs prior to release 2.3 / Mail UI
« on: July 07, 2009, 03:02:34 am »
Minor bug, but "gotta report it all"... lol

After reading a mail, link to the mail should lose bright green background (back to dark green) and lose bold font back to normal font. Upon reading a mail, it does lose bold back to normal font, but not the bright green.
However, scrolling up or down the screen will fix this instantly.

Also, if u load another game it will show read/unread mail status of previous game instead of the actual one if u opened and read some mail on the previous game. Again, scroling up or down will fix it instantly.

Edit:  R25029 (thx for the reminder Odie  :D)

Bugs prior to release 2.3 / Craft equipment replacement
« on: July 07, 2009, 02:34:26 am »
On craft (base) screen, player have the option to add a new equipment to a slot that already has one. Game then start a replacement script, removing the previous one to install the new one.

Bug 1: When new weapon is installed, it is installed with no ammo of the apropriate type and sometimes keep the old ammo from the previous equipment (see screenshot).

Bug 2: selecting the ammo box (on right side, bottom of the screen) should list any ammo available on that base for that weapon so u can switch ammo types. Useful for shiva cannon and for when u forget to buy ammo before installing the weapon (or in case it runs out of it). Problem is that no ammo is listed on the left side of the screen so u can't selct and equip it. Code should be even more troublesome if ammo is a virtual one (like D-F tank for aerial laser), I guess.

Edit: R25029

Feature Requests / UFO.exe version
« on: June 27, 2009, 12:05:42 pm »
I propose a new .txt file in the trunk (Version.txt) cointaining the actual revision number of each revision. The format should be %version%.R%revision%. (eg: 2.3.R24882), and should be updated every revision. With a minor changes in UFO.exe C::B project to link to this file content, this could result that every compilation shows the actual revision version on the UFO.exe file (on file details).
Nice touch uh? Also easier to keep track of revisions for everyone from the game main executable.

Discussion / Promotion and civ kills.
« on: June 26, 2009, 04:50:07 pm »
Medals.ufo states max number of killed civs as one of the promotion criterias.
Which of this options apply on this case?
  • Global number of civs killed;
  • Number of civs killed in missions that soldier participated;
  • Number of civs directly killed by that soldier;
  • Other.

Bugs prior to release 2.3 / Production
« on: June 25, 2009, 07:14:14 pm »
I have an UFO Fighter on my main production base. It's being disassembled (the same one) for the 4th time now. Production seems to be keeping track of it as it has a negative number on it (should be 1 on first disassemble, -1 for each additional one, so now -2). I'm some hours away from fulling an antimatter storage with a single fighter.  :P
On another base it disassembled a (single) harverster twice, then game declared disassemble was finished.
Very weird...

[attachment deleted by admin]

Bugs prior to release 2.3 / Hospital
« on: June 23, 2009, 11:41:04 pm »
Weird text in hospital screen on soldiers.

Obs: R24808

[attachment deleted by admin]

Discussion / Numbered UFOs
« on: June 23, 2009, 11:15:46 pm »
I see that at some point in the last revisions u guys got the new UFOs appearing on the geoscape to be numbered according to their appearence as X-COM used to be. Even better, a number for each craft type. Very nice to keep track of UFOs. Welldone!

Edit: I'd like to sugest this also appeared on geoscape message log:
eg. "Our radar detected a new UFO (Harvester #23)"

Bugs prior to release 2.3 / UFO model on geoscape
« on: June 23, 2009, 10:37:37 pm »
For some eason, as soon as an UFO appears on radar, its model seems to be missing. It appears once u let time run though.

Obs: R24808

[attachment deleted by admin]

Pages: [1] 2 3