UFO:Alien Invasion
Development => Coding => Topic started by: TrashMan on August 09, 2008, 12:27:12 am
-
Made a new .exe 1 hour ago - followed the procedure - no errors, no warnings. Game doesn't start...the window opens and closes.
-
without any error message, it's hard (or impossible) to track this down - nothing in the ufoconsole.log, too?
try to execute it from the commandline (cmd.exe start->run on windows)
-
Where is the ufoconsole.log file? I can't find it anywhere
-
Do you have all the needed DLL files? If not, I found it usually works if they are copied from an installed stable version's program file folder.
-
the dll files are in the contrib dir - just copy them all into the game root folder (trunk - were ufo.exe is located, too)
the ufoconsole.log is in your homedir - see the faq for the full path (depends on your os)
-
After I complied the exe I moved it (and the svn-download build folder) into the 2.2.1 instalation folder..all the dlls were already there.
(And yes, I did copy the whole contrib folders and all others the wiki stated to the CodeBlocks home folder)
there is no ufoconsole.log anywhere in the game directory
-
Updated SVN and re-build hte code:
These are the warning I got during compile:
*********************
:: === ufo2map, windows ===
c:\development\mingw\include\jconfig.h:25: warning: "HAVE_STDLIB_H" redefined
c:\development\mingw\include\SDL\SDL_config.h:67: warning: this is the location of the previous definition
:: === ufo, windows ===
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\renderer\r_shader.c:: In function `SH_LoadProgram_ARB_FP':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\renderer\r_shader.c:141: warning: dereferencing type-punned pointer will break strict-aliasing rules
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\renderer\r_shader.c:: In function `SH_LoadProgram_ARB_VP':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\renderer\r_shader.c:191: warning: dereferencing type-punned pointer will break strict-aliasing rules
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\renderer\r_shader.c:: In function `SH_LoadProgram_GLSL':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\renderer\r_shader.c:241: warning: dereferencing type-punned pointer will break strict-aliasing rules
:: === Build finished: 0 errors, 5 warnings ===
-
TrashMan, you might be experiencing the renderer crash I get. What is your hardware? If you use an nVidia card, try the following (in order):
1) disable threaded support for UFO:AI. You can do this in the 3D settings in the nVidia control panel.
2) run UFO:AI in Windows 98 compatibility mode.
The former worked for me until I installed XP SP3, the latter works for me right now.
-
My hardware?:
Windows XP Professions SP2
Intel CoreDuo CPU @2.40GHz
ASUS pB5 Deluxe motherboard
4 GB DDR
GForce 8800 GTX, 756 MB
I'll try what you just said.
EDIT: - Yes, it works now. thanks :)
-
I have a 8800GTX as well, and a friend of mine who has this card reports the same behavior.
-
Spoke too soon. New problem - tactical battle won't start.
I shoot down a UFO or alien attack and I send a dropship to the site.
I hit ENTER once it gets there....nothing. The dropship just sits there till it runs out of fuel and heads back.
-
Did you compile the maps? (It can take hours!)
They are compiled separately from the main game code on Windows. Myself, I just install the latest version of python (I use the Windows binary installer from the quick link right from the front page of the python website) and I make a shortcut on my desktop to the "compile.py" file so that every time I update from SVN and re-compile the game I can click on the shortcut and update the maps.
On the other hand, I've seen this same problem in development builds by random chance, not every SVN version works as good as others.
Checking the console log will also give more helpful information on exactly what the problem is, right at the point where you try to enter the mission.
EDIT: One more thing: Did you compile "Windows" or "Windows_debug" as a target in codeblocks (assuming you aren't using a different compiler) when building the main game? Honestly I don't know exactly how these are different (I'm not much of a coder), but I've noticed it sometimes affects bugs and play issues in the game. (I'm sure the coders here could explain much better.)
-
There is also ufoai\contrib\scripts\compile_maps.bat, but it has some problems.
-
There is also ufoai\contrib\scripts\compile_maps.bat, but it has some problems.
namely?
-
To compile maps, I just use the makefile. Since C::B comes with make.exe this should work for you as well. There should be a Makefile.win in your maps directory. Run make and make it execute that file (refer to the instructions). The advantage of this method is that you don't need to install python.
-
mattn, if there is .bsp, ufo2map can`t write new version of .bsp:
Writing D:\mount\new\ufoai/base\maps\forest\fr_craft_crash_scout.bsp
************ ERROR ************
Error opening D:\mount\new\ufoai/base\maps\forest\fr_craft_crash_scout.bsp for writing: Permission denied
-
To compile maps, I just use the makefile. Since C::B comes with make.exe this should work for you as well. There should be a Makefile.win in your maps directory. Run make and make it execute that file (refer to the instructions). The advantage of this method is that you don't need to install python.
What make.exe? I don't see it in CodeBlocks and the wiki mentions nothing about it.
It mentions having to have python to compile them.... or did you mean ufo2map.exe
I'm a bit confused atm.
-
It's part of MinGW, which is included with C::B. Search for it.
-
Found it...but how to use it...I cna't find any instruction in the folders...no readme or .html files
I suspect it's a comannd line run program, but without knowing the parameters...
-
Sigh. Look it up, it's really not that hard.
-
I wouldn't ask if I didn't have trouble finding.
There are no clear instructions anywhere I checked (wiki, CodeBlocks, MinGW, SNV folders and subfolders)
Has this:
http://ufoai.ninex.info/wiki/index.php/Mapping:Compile
under PARAMETERS got anything to do with it? It looks like it, but if it is , it still doesn't explain how to work with make.exe
-
make -f makefile.win maps
I guess, but I prefer to download the compiled ones:
python contrib/scripts/map-get upgrade
But it also needs python (and I haven't tested it on windows).
-geever
-
I wouldn't ask if I didn't have trouble finding.
When you can't find something on our wiki, there's another place (http://www.google.com/) you can try.
-
erm...so let me get this straight...
Make.exe is in c:\development\etc..
The SVN is on my desktop in the UFO_AI folder, however I copied the base folder to e:\games\UFOAI-2.2.1
Soo..I call the program/function from the e:\games\UFOAI-2.2.1 folder...or from the maps folder?
Cause I tried to call it from the folder in which the makefile.win file is located and it sez:
*** no rule to make target 'maps'. Stop
If I tried it without the last maps bit it cannot find arctic map..the first one ..and jsut spits out an error
-
I use it slightly differently - I renamed Makefile.win to Makefile, and copied it to the UFO:AI root. Then I edited it so the paths make sense again. I did this because this way I can just hit make.exe without any arguments (it will assume the existence of Makefile and attempt to execute rule "all"). This shouldn't be necessary, though. "make -f Makefile.win" when executed in the maps dir should do precisely the same thing. If it fails to build the maps, try posting the entire output here.
-
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Toni>cd..
C:\Documents and Settings>cd..
C:\>e:
E:\>cd minigames
E:\Minigames>cd ufoai-2.2.1
E:\Minigames\UFOAI-2.2.1>cd base
E:\Minigames\UFOAI-2.2.1\base>cd maps
E:\Minigames\UFOAI-2.2.1\base\maps>make -f Makefile.win
..\..\ufo2map.exe -extra "E:\Minigames\UFOAI-2.2.1\base\maps\africa04d.map"
---- ufo2map 1.2.2 ----
extrasamples = true
path: 'E:\Minigames\UFOAI-2.2.1\base\maps\africa04d.map'
gamedir: E:\Minigames\UFOAI-2.2.1\base\maps/base/
Could not load image pk3, searching in directories for images instead
...map: 'E:\Minigames\UFOAI-2.2.1\base\maps\africa04d'
...bsp: 'E:\Minigames\UFOAI-2.2.1\base\maps\africa04d'
************ ERROR ************
Could not load E:\Minigames\UFOAI-2.2.1\base\maps\africa04d
make: *** [E:\Minigames\UFOAI-2.2.1\base\maps\africa04d.bsp] Error 1
E:\Minigames\UFOAI-2.2.1\base\maps>
-------------------------------------------
Strange this is - I copied the base folder from the SVN to the 2.2.1 game install. There were already built maps in there.
-
You might have less frustration and a much easier time simply using python. Heck, on the python website front page there is a "quick link" on the left that goes direct to a windows installer which works fine, isn't a large download (it's rather small in size compared to UFO:AI), and simply letting it use the default install options all the way through the short installation process works fine. After installing it, simply clicking on the compile.py file in windows explorer will do the trick.
I don't see where this desire to avoid python is coming from - yikes, you coders make it sound like using python for the maps is some big deal, like a long, complicated, and painful process to set up when it really isn't. Sorry, I'm not trying to pick on you guys, but grabbing the python installer, running it, and clicking on the compile file to me is very short, simple, and sounds much easier than trying these other methods. Geez...
EDIT: I've also never had the python method give me errors or headaches (in fact it worked the first time), unlike the first time I tried to compile the main game, learn what SVN is, or set up any of the development tools needed to build the game.
Heck, this:
I use it slightly differently - I renamed Makefile.win to Makefile, and copied it to the UFO:AI root. Then I edited it so the paths make sense again. I did this because this way I can just hit make.exe without any arguments (it will assume the existence of Makefile and attempt to execute rule "all"). This shouldn't be necessary, though. "make -f Makefile.win" when executed in the maps dir should do precisely the same thing. If it fails to build the maps, try posting the entire output here.
...sounds much more complicated and difficult to me (a non-coder) than:
1) Go to python progamming website.
2) Download windows installer from "quick links" on left of the front page (It's well marked and conspicuous).
3) Run installer with default choices (nothing fancy, lengthy, or vague, very easy to do!).
4) After install, use standard good old windows explorer to go to the maps folder.
5) Open the compile.py file.
6) Sit back and relax as maps start compiling and updating as needed, unattended.
Yes, the python method is really that easy!
-
Thanks..Python method works without a hitch.
Damn, this map compiling takes forever...lol
So far, only 8 maps are done...:P
-
If you have normal internet, you may try map_get script, may be it will be faster?
-
It's the lighting calculations for day and night maps..it takes forever. ATM it's going over condor_crash04 map
-
Third takes friggin forever..it's still on c**** maps.
I tried using map_get.
Sez there's a version mismatch (updated the SVN just now). When I choose Y anyway it closes and does nothing.
This is irritating as hell!
-
...sounds much more complicated and difficult to me (a non-coder) than:
1) Go to python progamming website.
2) Download windows installer from "quick links" on left of the front page (It's well marked and conspicuous).
3) Run installer with default choices (nothing fancy, lengthy, or vague, very easy to do!).
4) After install, use standard good old windows explorer to go to the maps folder.
5) Open the compile.py file.
6) Sit back and relax as maps start compiling and updating as needed, unattended.
Yes, the python method is really that easy!
1) copy UFOAI\base\maps\Makefile.win to UFOAI\Makefile
2) copy make.exe to UFOAI\
3) edit Makefile and correct two paths
4) run make.exe
5) Sit back and relax as maps start compiling and updating as needed, unattended.
Sounds even easier than what you wrote down there, hmmm? Plus the big advantage to this method is that you don't need to get extra tools to do this. You might think it's no big deal, but when you start to dabble with the rest of the game development you'll find that you have to keep doing this. SVN? Download extra software. Compiling? Download extra software. Run script A? download extra software. Run script B? Download extra software because it's in a different language than script A. So when there's a method for compiling maps that re-uses software you're already using for something else, that is immensely preferrable to getting python from where I stand.
'Course, it didn't work for him, but I'm going to assume he messed it up.
-
Let's fight, please! :D
Windows way vs. Un*x way.
-geever
-
Run compile_maps.bat
-
Run compile_maps.bat
Yup..this one runs way faster than python.Thanks. Hopefully all maps will be compiled by the end of ht day.
-
K, I have one question...how long is the compiling supposed to take? (curretnly it reached farm/farmhouse map)
And I've been looking at hte compiling readouts, and compile_maps.bat and compile.py seem to process different fiels. What gives?
-
How about uploading a zipped mapfile (~100mb) somewhere? If it gets updated from time to time, there is no need for compiling them for hours. The latest changes can be compiled as usual.
-
How about uploading a zipped mapfile (~100mb) somewhere? If it gets updated from time to time, there is no need for compiling them for hours. The latest changes can be compiled as usual.
The map-get script does this way just you don't have to download hundreds of megabytes for a little change.
-geever
-
Except that the map_get script doesn't seem to do anything for me.
Hm...it's currently processing /shelter maps.. at this rate another 3 hours or so.
damn, the whole friggin day...on my rig???? Is this normal????
-
maybe someone should have a look into the codeblocks project files - it's possible to add user defined commands - so maybe calling "make maps" (from a menu point in codeblocks) should be easy to do (once you know how to handle it in c::b)
-
damn, the whole friggin day...on my rig?Huh Is this normal?Huh
Actually, yes, it is normal for it to take hours to compile the maps. That, and if you download pre-compiled ones, they might not be up-to-date.
What I do is if I grab a new SVN copy and don't have any compiled (meaning I have to compile the whole list from scratch) is I let it run overnight.
On a positive note, you should only have to start from scratch like this once, meaning after updating to a new SVN revision, using whatever method you want to use for map compiling should only re-compile the changed maps only. Depending on how long you wait between updating from SVN and how often changes to maps are made, I've found that on my desktop compiling just updates only takes a few minutes (usually).
-
maybe someone should have a look into the codeblocks project files - it's possible to add user defined commands - so maybe calling "make maps" (from a menu point in codeblocks) should be easy to do (once you know how to handle it in c::b)
I'd rather you didn't. I tend to use "rebuild project" because otherwise some things might not compile properly, and I don't want to have to wait for the maps when all I'm interested in is an updated binary.
-
no, that's not what i meant, it would not be related to the build process - but a seperate option in the menubar
-
Strange...all the maps are compiled, but some missions work (I can enter and fight) and some don't. :-\
-
what the console message for those that don't work?
-
What console message? All maps converted. I ran both the phyton script and convert_maps.bat twice after the inital conversion. They just opened and closed after briefly checking the maps.
Hmmmm..one map did spit out some node warning (convert_maps.but) and a few missing textures (convert.py)
The ones that have a tendancy of not showing up are (as I noticed so far) some maps where aliens land. UFO crash maps all seem to work.
-
I've experienced it with +farm. It doesn't have some ufocrash tiles, error message was:
ERROR: Could not find tile: '+craft_crash_fighter' in assembly 'small' (maps/farm.ump)
-geever
-
Confirmed. It is the farm map.
-
Should no longer happen in latest trunk.
-
Still got no map load, but I don't think it's the farm this time. I'll get back to you on that after some more testing.
Oh, with the latest build, the soldiers don't target (the animations don't play). They just stand still as bullet fly around.
-
Oh, with the latest build, the soldiers don't target (the animations don't play). They just stand still as bullet fly around.
what do you mean? Can you please try to nail down the revision this bug was introduced? That would help a lot to fix it.
-
The latest. I updated the SVN right after you posted the farm problem should be fixed, re-complied the maps and the code. 18370 I believe.
And what I mean is the soldiers don't bring up their rifles/launcher/pistols to bear. They just hold them in their arms idly when they shoot.
-
He's asking at which revision this started happening, not which one you're currently using. Back up to a revision you know worked, then update one by one until you find the one where it breaks, then post the revision number here.
-
I told you, 18370.
worked fine before that one.
I update the exe 2-3 times a day.
-
I noticed something else...I got two firebird dropships and 2 teams.
When I select a UFO activity icon on the map both dropship names are listed in the same location - they are overlapping. I can only select the first dropship I had (every other is literally beneath that one, so I can't click on them)
-
Hi, I'm another WinXP/nVidia user who has to run the dev build in "Win98 Compatibility" mode. (AMD dual-core x64 4000+ / GeForce 8800GTS.) Is it known what exactly causes this yet? Debugging (in normal compatibility mode) via C::B results in this: http://pastebin.com/m1a0c765
I'm new to C::B's debugger so tried to analyze this issue using the OllyDbg (http://www.ollydbg.de/) assembly-level debugger, however it throws an exception while loading module "guard32." (How ironic, lol!)
Question about the maps though, is \base\maps\compile.py currently known to spit out tons of lines such as:
...
Could not find texture 'tex_material/metall003'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_furniture/seat001'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_furniture/seat001'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_material/c_black'
Could not find texture 'tex_vehicles/gabstap_a'
Could not find texture 'tex_vehicles/gabstap_a'
Could not find texture 'tex_vehicles/gabstap_a'
Could not find texture 'tex_vehicles/gabstap_a'
...
I'm seeing hundreds, if not thousands of these messages when using the compile.py script. I then ran the Compile_Maps.bat and it compiled a few more maps, with only the "Could not load image pk3, searching in directories for images instead" errors.
Thanks, looking forward to a great game. ;D
-
Sounds like it's definitely related to the 8800GTS. I wonder what happens on 8800GTs?
-
Another flunky error... I made XAW95 reseachable and buildable in singleplayer.
When I save the game and load it, all magazines and weapon in a soldiers inventory are gone. Can't tell if ti's the build for now.
B.t.w. - that dropship error seems to be coming and going.
-
This might not be as much help, as I'm not a coder, but here goes:
Are you using the same savegames between revisions? In many (but not all) cases updating to newer revisions breaks savegames or causes strange behavior. (Hint: If you insist on not starting over unless absolutely necessary, watch the SVN logs when updating.)
Also, I've found from personal experience that the maps should be consistently compiled using the same method, or problems result. I'm not sure why this is true, but for me it's something I've found.
I've also found that the .bat file used on windows to compile maps is rather fast, and yes, it is faster than the python file, although for me the python file never gives me errors or malfunctions.
I'm seeing hundreds, if not thousands of these messages when using the compile.py script. I then ran the Compile_Maps.bat and it compiled a few more maps, with only the "Could not load image pk3, searching in directories for images instead" errors.
In my experience I think this is normal, I've gotten the game to work fine despite the same output when compiling.
EDIT: I'm going to try to upload a new installer shortly, I'll see if I can manage to get a relatively stable build and package it together (for those who want a dev build).
-
While trying to compile the latest trunk:
----------------------------------------
:: === gtkradiant_model, windows ===
..\..\src\tools\radiant\libs\stream\textstream.h:369: warning: `class SingleCharacterOutputStream' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\scenelib.h:204: warning: `class scene::NullNode' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\scenelib.h:815: warning: `class SelectChildren' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\instancelib.h:34: warning: `class InstanceSubgraphWalker' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\instancelib.h:56: warning: `class UninstanceSubgraphWalker' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\instancelib.h:75: warning: `class InstanceSet' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\traverselib.h:115: instantiated from here
..\..\src\tools\radiant\libs\undolib.h:96: warning: `class UndoableObject<TraversableNodeSet>' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\traverselib.h:113: warning: `class TraversableNodeSet' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\traverselib.h:335: warning: `class TraversableObserverRelay' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\render.h:823: warning: `class RenderablePointVector' has virtual functions but non-virtual destructor
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\model\model.cpp:45: warning: `class VectorLightList' has virtual functions but non-virtual destructor
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\model\model.cpp:67: warning: `class PicoSurface' has virtual functions but non-virtual destructor
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\model\model.cpp:287: warning: `class PicoModel' has virtual functions but non-virtual destructor
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\model\model.cpp:529: warning: `class PicoModelNode' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\stream\textstream.h:369: warning: `class SingleCharacterOutputStream' has virtual functions but non-virtual destructor
..\..\src\tools\radiant\libs\stream\stringstream.h:98: warning: `class StringOutputStream' has virtual functions but non-virtual destructor
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\model\plugin.cpp:163: instantiated from here
..\..\src\tools\radiant\libs\modulesystem\singletonmodule.h:66: warning: `class SingletonModule<ModelPicoAPI, ModelPicoDependencies, PicoModelAPIConstructor>' has virtual functions but non-virtual destructor
:: === gtkradiant_entity, windows ===
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:42: glib/gslist.h: No such file or directory
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:: In function `void addUFOFile(const char*)':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:172: error: invalid use of undefined type `struct _GSList'
..\..\src\tools\radiant\include\ifilesystem.h:38: error: forward declaration of `struct _GSList'
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:173: error: invalid use of undefined type `struct _GSList'
..\..\src\tools\radiant\include\ifilesystem.h:38: error: forward declaration of `struct _GSList'
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:180: error: `g_slist_append' undeclared (first use this function)
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:180: error: (Each undeclared identifier is reported only once for each function it appears in.)
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:: In function `void MiscParticle_destroy()':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:197: error: invalid use of undefined type `struct _GSList'
..\..\src\tools\radiant\include\ifilesystem.h:38: error: forward declaration of `struct _GSList'
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:198: error: invalid use of undefined type `struct _GSList'
..\..\src\tools\radiant\include\ifilesystem.h:38: error: forward declaration of `struct _GSList'
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\radiant\plugins\entity\miscparticle.cpp:198: error: `g_slist_remove' undeclared (first use this function)
:: === Build finished: 12 errors, 17 warnings ===
-
I get 19 warnings and no errors. You probably don't have the right libs in your MinGW. Grab the latest C::B package and try again.
Mind you, I have problems compiling too, just not the same ones.
-
Also, are you compiling windows or windows_debug? I find windows works where windows_debug doesn't.
-
windows...and I go the C_B package like, two days ago, updated all the contrib files and everything.
-
Thanks Destructavator, did you get a chance to upload that new package yet? Gtkradiant is not compiling for me either. MinGW was updated using all the libs and binaries I could find from http://www.gtk.org/download-windows.html and still similar errors (http://pastebin.com/m7fac1671) appear (except I found a much newer zlib library elsewhere.)
...\src\tools\radiant\plugins\entity\miscparticle.cpp:42: glib/gslist.h: No such file or directory
This looks like part of the glib library is just-plain missing. The gslist.h file can be found as part of the glib dev package at the above URL, however this didn't fix all the problems for me.
Also as an aside, if any newcomers were curious how to eliminate the "..mingw\include\jconfig.h:25: warning: "HAVE_STDLIB_H" redefined" error from the main project, simply remove the read-only attribute from .\mingw\include\jconfig.h and change the line that reads "#define HAVE_STDLIB_H" to:
#ifndef HAVE_STDLIB_H
# define HAVE_STDLIB_H
#endif
Then re-apply the read-only file attribute. ;)
-
Mattn placed an updated MinGW along with an updated Codeblocks on the beta site. As he said:
there is a new codeblocks+mingw package over at http://mattn.ninex.info - please use that one for compiling new versions
And yes, I just uploaded a new installer, one that works for the game, although the GTKRadiant probably won't work. More details:
http://ufoai.ninex.info/forum/index.php?topic=2830.msg19531#msg19531
-
With the new CodeBlocks installer I still get around 12 errors and 17 warnings.
-
can you publish the logs at http://pastebin.ca ?
-
http://pastebin.ca/1177954
-
glib? I'm pretty sure I have that in my MinGW.
-
Works now..
When I updated codeBlocks, I forgot to copy MinGW and paste it over the old one in the parent folder.
-
I updated my SVN and compiled again - game crashes when I start a campaign.
-
I updated my SVN and compiled again - game crashes when I start a campaign.
Huh, and should we know what is wrong from that much info??
It doesn't crash for me.
-geever
-
Don't ask me - I haven't edited any files, I updated and compiled all maps. I have no clue what's wrong.
EDIT: Tried it again with the latest revision. It's still crashing. WTF could be wrong?
-
give us a revision where this first occured please - and the current revision you are trying
-
18853 is the one I'm currently trying I believe.
The one before was....erm..lemme think..I got the code for that one roughly 12. hours ago, if not more....18850 I think.
I'm not sure...I tried 3 builds so far, the latest one being 18853...all are no more than 24 hours old.
-
tell me about your graphic card please - pastebin the ufoconsole.log and please try to generate a backtrace with the gdb (gnu debugger - see wiki for debugging section)
-
NVidia GForce 8800GTX, 756MB.
as for the ufoconsole.log - I found no log file, since I haven't set up UFO:AI in the debug mode yet. Looking into it now.
Instructions are a tad confusing, so let's see if I got it right.
I should re-build the exe but under Project -> build options I select windows_debug build insted of jsut windows.
I complie and add +set vid_fullscreen 0 +set vid_grabmouse 0 +set developer 1 to the shortcut.
n$ext I run the game and when it crashes it should be a log file?
Cause that's what I did and I can still find no log file...hold on a moment.
Typing condump error in the console shw a message that it dumped something into error.txt, but there is no such file.???
EDIT: I update the svn and run a new build every few hours...still nothing.... :(
-
sorry, but without a meaningful backtrace we can't help you with it - or at an exact revision where it was introduced.
try to lookup the debugging article in the wiki and start gdb from a windows terminal via cmd.exe=>gdb ufo.exe=>run +set vid_fullscreen 0=>bt full (on crash)
your ufoconsole.log is even generated in non-debug mode, see our faq to get the exact path for windows version. somewhere in your application data which is hidden by windows (for whatever reasons)
-
I don't think the path is written in the faq....
EDIT: Ignore that, found it!
Shared Client/Server Info loaded
...107 items parsed
... 32 damage types parsed
... 64 map definitions parsed
... 26 equipment definitions parsed
... 10 inventory definitions parsed
... 22 team definitions parsed
music change to van_theme (from PsymongN3)
execing autoexec.cfg
"version" is "UFO: Alien Invasion 2.3-dev x86 Aug 12 2008 Win32 RELEASE"
S_Music_Start: Playing music: 'music/van_theme'
FS_OpenFile: can't find sound/weapons/bloodspider.ogg
FS_LoadFile: Could not open sound/weapons/bloodspider.ogg
FS_OpenFile: can't find sound/weapons/medikit.ogg
FS_LoadFile: Could not open sound/weapons/medikit.ogg
FS_OpenFile: can't find sound/weapons/irgoggles.ogg
FS_LoadFile: Could not open sound/weapons/irgoggles.ogg
FS_OpenFile: can't find sound/weapons/grenade.ogg
FS_LoadFile: Could not open sound/weapons/grenade.ogg
FS_OpenFile: can't find sound/misc/klonk03.ogg
FS_LoadFile: Could not open sound/misc/klonk03.ogg
FS_OpenFile: can't find sound/weapons/flashbang.ogg
FS_LoadFile: Could not open sound/weapons/flashbang.ogg
FS_OpenFile: can't find sound/weapons/smokeexplosion.ogg
FS_LoadFile: Could not open sound/weapons/smokeexplosion.ogg
FS_OpenFile: can't find sound/weapons/fireexplosion.ogg
FS_LoadFile: Could not open sound/weapons/fireexplosion.ogg
FS_OpenFile: can't find sound/weapons/plasma_grenade.ogg
FS_LoadFile: Could not open sound/weapons/plasma_grenade.ogg
FS_OpenFile: can't find sound/weapons/bolter2.ogg
FS_LoadFile: Could not open sound/weapons/bolter2.ogg
FS_OpenFile: can't find sound/weapons/assaultrifle.ogg
FS_LoadFile: Could not open sound/weapons/assaultrifle.ogg
FS_OpenFile: can't find sound/weapons/machinegun.ogg
FS_LoadFile: Could not open sound/weapons/machinegun.ogg
FS_OpenFile: can't find sound/weapons/sniperrifle.ogg
FS_LoadFile: Could not open sound/weapons/sniperrifle.ogg
FS_OpenFile: can't find sound/weapons/pistol2.ogg
FS_LoadFile: Could not open sound/weapons/pistol2.ogg
FS_OpenFile: can't find sound/weapons/machinepistol.ogg
FS_LoadFile: Could not open sound/weapons/machinepistol.ogg
FS_OpenFile: can't find sound/weapons/smg2.ogg
FS_LoadFile: Could not open sound/weapons/smg2.ogg
FS_OpenFile: can't find sound/weapons/riotshotgun.ogg
FS_LoadFile: Could not open sound/weapons/riotshotgun.ogg
FS_OpenFile: can't find sound/weapons/microshotgun2.ogg
FS_LoadFile: Could not open sound/weapons/microshotgun2.ogg
FS_OpenFile: can't find sound/weapons/flamer_s.ogg
FS_LoadFile: Could not open sound/weapons/flamer_s.ogg
FS_OpenFile: can't find sound/weapons/rpg.ogg
FS_LoadFile: Could not open sound/weapons/rpg.ogg
FS_OpenFile: can't find sound/misc/big_boom.ogg
FS_LoadFile: Could not open sound/misc/big_boom.ogg
FS_OpenFile: can't find sound/weapons/incendiary_rocket.ogg
FS_LoadFile: Could not open sound/weapons/incendiary_rocket.ogg
FS_OpenFile: can't find sound/weapons/grenade_launcher.ogg
FS_LoadFile: Could not open sound/weapons/grenade_launcher.ogg
FS_OpenFile: can't find sound/weapons/deepexplosion.ogg
FS_LoadFile: Could not open sound/weapons/deepexplosion.ogg
FS_OpenFile: can't find sound/weapons/shotgun.ogg
FS_LoadFile: Could not open sound/weapons/shotgun.ogg
FS_OpenFile: can't find sound/weapons/laser.ogg
FS_LoadFile: Could not open sound/weapons/laser.ogg
FS_OpenFile: can't find sound/weapons/heavy_laser.ogg
FS_LoadFile: Could not open sound/weapons/heavy_laser.ogg
FS_OpenFile: can't find sound/weapons/knife.ogg
FS_LoadFile: Could not open sound/weapons/knife.ogg
FS_OpenFile: can't find sound/weapons/stun.ogg
FS_LoadFile: Could not open sound/weapons/stun.ogg
FS_OpenFile: can't find sound/weapons/plasmablade.ogg
FS_LoadFile: Could not open sound/weapons/plasmablade.ogg
FS_OpenFile: can't find sound/weapons/chaingun.ogg
FS_LoadFile: Could not open sound/weapons/chaingun.ogg
FS_OpenFile: can't find sound/weapons/pbeampistol.ogg
FS_LoadFile: Could not open sound/weapons/pbeampistol.ogg
FS_OpenFile: can't find sound/weapons/pbeamrifle.ogg
FS_LoadFile: Could not open sound/weapons/pbeamrifle.ogg
FS_OpenFile: can't find sound/weapons/pbeamcannon.ogg
FS_LoadFile: Could not open sound/weapons/pbeamcannon.ogg
FS_OpenFile: can't find sound/weapons/plasma_s.ogg
FS_LoadFile: Could not open sound/weapons/plasma_s.ogg
FS_OpenFile: can't find sound/weapons/plasma_big.ogg
FS_LoadFile: Could not open sound/weapons/plasma_big.ogg
CL_PrecacheModels: Registered object model: 'weapons/knife/knife' (34)
CL_PrecacheModels: Registered object model: 'weapons/medikit/medikit' (35)
CL_PrecacheModels: Registered object model: 'weapons/irgoggles/irgoggles' (36)
CL_PrecacheModels: Registered object model: 'weapons/fraggren/fraggren' (37)
CL_PrecacheModels: Registered object model: 'weapons/flashbang/flashbang' (38)
CL_PrecacheModels: Registered object model: 'weapons/smokegren/smokegren' (39)
CL_PrecacheModels: Registered object model: 'weapons/stungren/stungren' (40)
CL_PrecacheModels: Registered object model: 'weapons/stungren_alien/stungren' (41)
CL_PrecacheModels: Registered object model: 'weapons/incgren/incgren' (42)
CL_PrecacheModels: Registered object model: 'weapons/plasmagren/plasmagren' (43)
CL_PrecacheModels: Registered object model: 'weapons/bombs/bomb1' (44)
CL_PrecacheModels: Registered object model: 'weapons/needlergun/needler' (45)
CL_PrecacheModels: Registered object model: 'weapons/needlergun/needler_ammo' (46)
CL_PrecacheModels: Registered object model: 'weapons/assault/assault' (47)
CL_PrecacheModels: Registered object model: 'weapons/assault/assault_clip' (48)
CL_PrecacheModels: Registered object model: 'weapons/machinegun/machinegun' (49)
CL_PrecacheModels: Registered object model: 'weapons/machinegun/machinegun_clip' (50)
CL_PrecacheModels: Registered object model: 'weapons/sniper/sniper' (51)
CL_PrecacheModels: Registered object model: 'weapons/sniper/sniper_clip' (52)
CL_PrecacheModels: Registered object model: 'weapons/coilgun/coilgun' (53)
CL_PrecacheModels: Registered object model: 'weapons/coilgun/coilgun_ammo' (54)
CL_PrecacheModels: Registered object model: 'weapons/pistol/pistol' (55)
CL_PrecacheModels: Registered object model: 'weapons/pistol/pistol_clip' (56)
CL_PrecacheModels: Registered object model: 'weapons/pistol2/pistol2' (57)
CL_PrecacheModels: Registered object model: 'weapons/pistol2/pistol2_clip' (58)
CL_PrecacheModels: Registered object model: 'weapons/smg/smg' (59)
CL_PrecacheModels: Registered object model: 'weapons/smg/smg_clip' (60)
CL_PrecacheModels: Registered object model: 'weapons/shotgun2/shotgun' (61)
CL_PrecacheModels: Registered object model: 'weapons/shotgun2/shotgun_clip' (62)
CL_PrecacheModels: Registered object model: 'weapons/shotgunmicro/shotgunmicro' (63)
CL_PrecacheModels: Registered object model: 'weapons/shotgunmicro/shotgunmicro_clip' (64)
CL_PrecacheModels: Registered object model: 'weapons/flamer/flamer' (65)
CL_PrecacheModels: Registered object model: 'weapons/flamer/flamer_ammo' (66)
CL_PrecacheModels: Registered object model: 'weapons/rpg/rpg' (67)
CL_PrecacheModels: Registered object model: 'weapons/rpg/rpg_ammo' (68)
CL_PrecacheModels: Registered object model: 'weapons/rpg/rpg_inc_ammo' (69)
CL_PrecacheModels: Registered object model: 'weapons/grenl/grenl' (70)
CL_PrecacheModels: Registered object model: 'weapons/grenl/grenl_clip' (71)
CL_PrecacheModels: Registered object model: 'weapons/grenl/grenl_ic_clip' (72)
CL_PrecacheModels: Registered object model: 'weapons/grenl/grenl_flechette_clip' (73)
CL_PrecacheModels: Registered object model: 'weapons/grenl/grenl_plasma_clip' (74)
CL_PrecacheModels: Registered object model: 'weapons/bolterrifle/bolterrifle' (75)
CL_PrecacheModels: Registered object model: 'weapons/bolterrifle/bolterrifle_clip' (76)
CL_PrecacheModels: Registered object model: 'weapons/laserpistol/laserpistol' (77)
CL_PrecacheModels: Registered object model: 'weapons/laserrifle/laserrifle' (78)
CL_PrecacheModels: Registered object model: 'weapons/laserheavy/laserheavy' (79)
CL_PrecacheModels: Registered object model: 'weapons/laserrifle/laserrifle_clip' (80)
CL_PrecacheModels: Registered object model: 'weapons/knife/knife' (81)
CL_PrecacheModels: Registered object model: 'weapons/knifemono/knifemono' (82)
CL_PrecacheModels: Registered object model: 'weapons/stunrod/stunrod' (83)
CL_PrecacheModels: Registered object model: 'weapons/kerrblade/kerrblade' (84)
CL_PrecacheModels: Registered object model: 'weapons/plasblade/plasblade' (85)
CL_PrecacheModels: Registered object model: 'weapons/chaingun/chaingun' (86)
CL_PrecacheModels: Registered object model: 'weapons/chaingun/chaingun_ammo' (87)
CL_PrecacheModels: Registered object model: 'weapons/shotgun/shotgun' (88)
CL_PrecacheModels: Registered object model: 'weapons/shotgun/shotgun_clip' (89)
CL_PrecacheModels: Registered object model: 'weapons/xaw95/xaw95' (90)
CL_PrecacheModels: Registered object model: 'weapons/xaw95/xaw95_ammo' (91)
CL_PrecacheModels: Registered object model: 'weapons/pbeampistol/pbeampistol' (92)
CL_PrecacheModels: Registered object model: 'weapons/pbeampistol/pbeampistol_clip' (93)
CL_PrecacheModels: Registered object model: 'weapons/pbeamrifle/pbeamrifle' (94)
CL_PrecacheModels: Registered object model: 'weapons/pbeamrifle/pbeamrifle_clip' (95)
CL_PrecacheModels: Registered object model: 'weapons/pbeamcannon/pbeamcannon' (96)
CL_PrecacheModels: Registered object model: 'weapons/pbeamcannon/pbeamcannon_clip' (97)
CL_PrecacheModels: Registered object model: 'weapons/plaspistol/plaspistol' (98)
CL_PrecacheModels: Registered object model: 'weapons/plaspistol/plaspistol_clip' (99)
CL_PrecacheModels: Registered object model: 'weapons/plasrifle/plasrifle' (100)
CL_PrecacheModels: Registered object model: 'weapons/plasrifle/plasrifle_clip' (101)
CL_PrecacheModels: Registered object model: 'weapons/plasblaster/plasblaster' (102)
CL_PrecacheModels: Registered object model: 'weapons/plasblaster/plasblaster_clip' (103)
CL_PrecacheModels: Registered object model: 'weapons/chaingun/chaingun' (104)
CL_PrecacheModels: Registered object model: 'weapons/chaingun/chaingun_ammo' (105)
FS_OpenFile: can't find models/weapons/autocannon/autocannon.md2
FS_LoadFile: Could not open models/weapons/autocannon/autocannon.md2
FS_OpenFile: can't find models/weapons/autocannon/autocannon.md3
FS_LoadFile: Could not open models/weapons/autocannon/autocannon.md3
FS_OpenFile: can't find models/weapons/autocannon/autocannon.dpm
FS_LoadFile: Could not open models/weapons/autocannon/autocannon.dpm
R_RegisterModelShort: Could not find: 'weapons/autocannon/autocannon'
CL_LanguageInit: language settings are stored in configuration: en
CL_LanguageInit: deflang: en
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'ja' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'th' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'sv' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'sl' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'ru' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'pt_BR' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'it' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'hu' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'el' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'fr' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'fi' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'et' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'da' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'cs' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'es' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'pl' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'de' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'en' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'ja' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'th' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'sv' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'sl' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'ru' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'pt_BR' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'it' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'hu' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'el' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'fr' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'fi' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'et' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'da' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'cs' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'es' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'pl' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'de' found.
CL_LanguageTest: using mo files from 'e:/minigames/ufoai-2.2.1/base/i18n/'
CL_LanguageTest: locale 'en' found.
CL_LanguageTryToSet: en_ZW.utf8
124 static models loaded
...loaded fragment shader shaders/lighting.fp (pid: 1)
...loaded fragment shader shaders/lighting_mtex.fp (pid: 2)
...loaded fragment shader shaders/warp.fp (pid: 3)
...loaded fragment shader shaders/water.fp (pid: 4)
...loaded fragment shader shaders/blur.fp (pid: 5)
...uploaded 5 shaders
Mem_CheckGlobalIntegrity: 0ms
Mem_TouchGlobal: 18 pools touched in 0ms
====== UFO Initialized ======
Priority changed to NORMAL
Found 2 processors
Use both cores
Switch grab input off
]ondump
Unknown command "ondump"
]condump error
Dumped console text to C:\Documents and Settings\Toni\Application Data\UFOAI/2.3-dev/base/error.txt.
-
That was the error.txt
teh console.log is long as hell, but it ends with this:
***
***
RS_MarkResearchable: handling "rs_any_2_autopsies".
RS_RequirementsMet: ORtech: rs_autopsy_O_T / 181
RS_RequirementsMet: ORtech: rs_autopsy_O_S / 182
RS_RequirementsMet: ORtech: rs_autopsy_T_S / 183
met_AND is 0, met_OR is 0
RS_MarkResearchable: Done.
RS_InitTree: Technology tree initialised. 185 entries found.
Sanity check for script data
...buildings ok
...tech ok
...aircraft ok
...menu ok
music change to van_geoscape (from van_theme)
Set server state to 0
CL_SetClientState: Set new state to 2 (old was: 1)
Changing to Singleplayer
S_Music_Start: Playing music: 'music/van_geoscape'
CL_SetClientState: Set new state to 1 (old was: 2)
-
18948 build and STILL crashing when starting a new game (after scrolling text).
I attached error.txt and ufoconsole.log files
[attachment deleted by admin]
-
Make a backtrace with gdb.
-
Hm...strange...I should have gdb installed with CodeBlocks, right?
but the gdb ufo.exe command return that gdb is a unrecognized program...
I'm also not 100% clear on this line:
You should add the Code::Blocks installation folder to your environment path variable (most likely C:\Code::Blocks\bin)
-
there is a gdb.exe in your c::b\mingw\bin folder - add this to the your env path. now you should be able to execute gdb.exe ufo.exe via cmd.exe
-
Refresh my memory.
To set a envoroment path variable I have to write the following in the command window?
path = %PATH%;c:\development\MinGW\bin\gdb.exe
I haven't done this stuff in years, so it's all gone...gah.. I took me a while jsut to remember what a enviroment path variable is! ;D
EDIT: Oh wait, I cna do it in the control panels too...System Properties -> Enviroment Variables... K.. added.
Running cmd.exe.
going into the UFO directory
gdb ufo.exe.... aaaaaaaaan....nothing :-X
-
You should type "run" after that. Come on, it's on the wiki.
-
No, you don't get it - after typing gdb ufo.exe it doesn't enter the gdb console.
it insists that gsb is a unrecognized internal or external command or program...... AAAAARGh.....
-
not "c:\development\MinGW\bin\gdb.exe" but "c:\development\MinGW\bin\"
-
Tried that too.
See for yourself in the pic
[attachment deleted by admin]
-
you must add catalog with gdb to %PATH% envvar. Not setting var %GDB%, not adding path to file. just set PATH, and next run gdb.
-
I just copied gdb.exe to the UFO:AI dir.
-
Hm...strange results
[attachment deleted by admin]
-
that really looks like the vertexbuffer bug which i fixed already - are you sure that you are using latest rev?
-
It says 2.2.1 in the dir there. Did you delete everything first when you checked out trunk? I can't imagine you didn't because otherwise you'd get a ton of errors, but hey, can't be too sure.
-
I overwritten everything with files from the SVN.... the game worked fine before.... This crashing is a recent happening.
-
To explain a bit more in detail.
The 2.2.1 is installed inside one folder and the SVN is downloaded in another. Then I copy/paste hte files from the SVN inot the 2.2.1 and overwrite everything. Game worked without problems for me before.
Should I try another build? Or is there some other test I could try? It seems to always crash when it's about to lead the Geosphere - start a new game or load an old one.
-
the problem here is, that you didn't remove (with the overwrite of existing files) the files that we removed from svn (or renamed)
this might lead to problems
-
Well, I deleted all folders and files except for the maps, models and textures, and then copied them from the SVN. Still crashes....
-
You're not supposed to "copy from SVN". The SVN checkout is a complete package.
-
Yeah, well I test some models and images in-game, so i don't want to mess with the SVN folder and the files in it.
Besides, I just tried starting the game from the SVN folder - the same crash happens.
-
Try to svn-update and rebuild game. And, if you use C::B package, now default project is radiant, so you need to change it manually to ufo.
-
Or just rebuild the whole workspace (from the build menu). That will build all the projects.
-
I have been re-building it and re-compiling the maps after each SVN update I did....am I missing something?
-
I updated everything, re-compiled all maps, re-built the code (copied the radiant and contrib folders to where they should be too)...still I get a geoscape crash.
-
And again...this is getting tiresome.
Hm..maybe if I delete and re-compile all maps...
-
Well, I updated, deleted the old maps folder and replaced all other files. Re-complied the .exe... compiling all maps now. If this doesn't work I'm giving up and removing the game from my HDD completely.
-
If you use SVN, what problems to just checkout, compile and run from svn directory? And don`t forget to copy dlls from contrib/dlls.
PS: current trunk is not a good target to play, to many bugs, to many regressions.
-
I have tried to run from SVN directory too :(
Now I'm waiting for the compile to be done...
It's done...Aaaaaaannnddd.....
*****
FS_LoadFile: Could not open models/weapons/autocannon/autocannon.md3
FS_OpenFile: can't find models/weapons/autocannon/autocannon.dpm
FS_LoadFile: Could not open models/weapons/autocannon/autocannon.dpm
R_RegisterModelShort: Could not find: 'weapons/autocannon/autocannon'
Wrote keys.cfg
R_RunThread: 2212
Could not find menu 'options_input'
-
What about deleting your directory project/.obj en rebuild?
-
You mean this:
C:\Documents and Settings\Toni\Desktop\UFO_AI\build\projects\.objs
from the SVN download folder? I'll try...we'll see if it works.
-
f****! Still crashes on loading... :(
Meh...nothing to do but wait till 2.2.3 comes out.
-
Btw, why don`t you want to use snapshot from Destructavator?
PS: One more time.
You checkout ufoai to an empty dir, and compile binaries with C::B and maps, right?
And next you try to run game?
-
Yep.
I had about enough. I uninstalled everything.
I'll try re-installing the and applying the latest 2.2.3 files, re-compiling the code and all maps. If that doesn't work, nothing will.
-
Jsut so there's no confusion I'll write down my steps here:
1. Uninstalled everything.
2. Installed UFO AI 2.2.1
3. Copied the Base folder from the SVN to the game folder
4. Copied the dll's from the Contrib/Dlls to the main game folder
5. Copied the Contrib folder to the development folder (the one with CodeBlocks and MinGW)
6. I'm no re-compiling the code and after that all the maps.
EDIT:
Hm...CodeBlocks crash...interesting.
-
The codeblocks crash seems to be related to the warning messages. Try removing the last two -W lines from the additional options in the build options of the ufo project. It seemed to help for me.
-
yup..that did it. Thanks.
-
You've finally got it to work?
After compiling everything, don't forget to compile all the maps, then all you have to do is run UFO.EXE.
If you want to package everything into an installer there are additional steps, otherwise, enjoy the game!
For anyone else who has codeblocks crash on them I have a couple of screenshots.
BTW, after compiling, do *not* save anything when quitting if you plan to update from SVN again later, unless you want to have to use the "revert" option with Tortoise SVN, from my experience.
[attachment deleted by admin]
-
I don`t understand nesserity of your second step.
You want to compile 2.3, right?
So, you need just:
— checkout https://ufoai.svn.sourceforge.net/svnroot/ufoai/ufoai/trunk to empty directory
— install correct C::B package
— copy DLLs from contrib dir to rootdir
— compile game, maps
— and run.
-
Good point, I just noticed the second step:
2. Installed UFO AI 2.2.1
This isn't necessary for 2.3, and in fact I think it may mess things up a bit.
I certainly wouldn't recommend mixing revisions like that.
-
We told him that several times before. I don't know why he keeps doing it.
-
You've finally got it to work?
I finally got it to compile.
I'm not compiling all the maps..it will take a while. We'll see if the game works after that. ;)
Crap..I can't recall if I backed up all my models before I uninstalled/deleted the old UFO folder. I sent the Starchaser to you guys, right?
BTW, after compiling, do *not* save anything when quitting if you plan to update from SVN again later, unless you want to have to use the "revert" option with Tortoise SVN, from my experience.
LOL...don't tell me you saved? :D Nah, I didn't do it. I know better. besides, I have to manually setup the post-build step path, so I never forget.
-
Maps compiled....erm. Crap.
When I start the game I get this in the console:
---- filesystem initialization -----
Adding game dir: ./base
Added packfile ./base/0base.pk3 (5 files)
Added packfile ./base/0maps.pk3 (461 files)
Added packfile ./base/0media.pk3 (8 files)
Added packfile ./base/0models.pk3 (1231 files)
Added packfile ./base/0music.pk3 (35 files)
Added packfile ./base/0pics.pk3 (1577 files)
Added packfile ./base/0snd.pk3 (131 files)
Added packfile ./base/0ufos.pk3 (73 files)
using C:\Documents and Settings\Toni\Application Data\UFOAI/2.3-dev/base for writing
Adding game dir: C:\Documents and Settings\Toni\Application Data\UFOAI/2.3-dev/base
executing default.cfg
couldn't execute config.cfg
executing keys.cfg
----- network initialization -------
libcurl/7.16.4 zlib/1.2.2 initialized.
------ server initialization -------
added 7 maps to the mapcycle
----- console initialization -------
Console initialized.
------- video initialization -------
SDL version: 1.2.12
I: desktop depth: 32bpp
I: video memory: 0
I: video driver: windib
I: setting mode 6: 1024x768 (fullscreen: no)
I: set swap control to 0
I: got 8 bits of stencil
I: got 24 bits of depth buffer
I: got double buffer
I: got 8 bits for red
I: got 8 bits for green
I: got 8 bits for blue
I: got 0 bits for alpha
I: got 0 multisample buffers
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 8800 GTX/PCI/SSE2
GL_VERSION: 2.1.2
GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_bindable_uniform GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_buffer_float GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control
max texture units: 4
max texture size: detected 8192
but using 2048 as requested
R_LoadProgram: 'default' loaded.
R_LoadProgram: 'warp' loaded.
SDL_ttf version 2.0.7 - we need at least 2.0.7
------- sound initialization -------
SDL_mixer version: 1.2.8
... audio rate: 44100
... audio channels: 2
... driver: 'dsound'
------- input initialization -------
0 possible joysticks
no joystick found.
--- save subsystem initialization --
added size subsystem (check ff)
added base subsystem (check 0)
added campaign subsystem (check 1)
added hospital subsystem (check 2)
added market subsystem (check 3)
added research subsystem (check 4)
added employee subsystem (check 5)
added aliencont subsystem (check 6)
added production subsystem (check 7)
added aircraft subsystem (check 8)
added messagesystem subsystem (check 9)
added stats subsystem (check a)
added nations subsystem (check b)
added transfer subsystem (check c)
added alien base subsystem (check d)
added xvirate subsystem (check e)
added installation subsystem (check 0)
added messageoptions subsystem (check 1)
----------- parse scripts ----------
Invalid value for property 'num': Could not find menutext id '42'
MN_ParseNode: node with bad body ignored (node "basedefense.basedef_slot_list")
Wrote keys.cfg
MN_ParseMenu: menu "basedefense" have a bad body
-
Maybe you have some files out of date ? no
The error message say to you, your menu_basedefence.ufo file, basedefence menu, basedef_slot_list node, use a wrong 'num' param
At my house, i v got :
text basedef_slot_list
{
pos "40 30"
size "400 600"
// bgcolor "1 1 1 0.5"
format "22 0"
wheel
height "27"
num TEXT_BASEDEFENCE_LIST
mousefx true
click
}
Have you the same?
It can be a file out of date; a script file read after or before another one (problem with OS portability) (i dont know if there are an order for the read of .ufo); a problem with compilator? If any body can check what i say :-)
-
Look, it's obviously because he's mixing with 2.2.1. See his step list on the previous page.
1. Uninstalled everything.
2. Installed UFO AI 2.2.1
3. Copied the Base folder from the SVN to the game folder
4. Copied the dll's from the Contrib/Dlls to the main game folder
5. Copied the Contrib folder to the development folder (the one with CodeBlocks and MinGW)
6. I'm no re-compiling the code and after that all the maps.
-
Although I'm not a real coder, I have to agree with BTAxis, and looking at the log I see it found the pk3 files from the 2.2.1 installation.
When compiling and running from SVN, it should be using un-packaged files, but I'm guessing that since the pk3 files (and possibly other configuration files) from 2.2.1 were present, the game tried to use those and got confused.
A 2.2.1 installation should really be separate from a 2.3 installation.
For using an SVN copy, I'd suggest using a folder *not* anywhere in the "program files" folder, but checking out an SVN copy to a folder in your "my documents" folder, or a folder off the root of your C: drive (such as "C:\ufoai), or if you have multiple partitions, the root of a storage drive, depending on how your system is set up. Heck, if you have a large enough portable or flash drive, I'd imagine you could compile and run it off of that, although there might be a performance issue, but I haven't tried that.
EDIT: One more note: If you happen to use a development build installer for 2.3, (one I uploaded or another), also keep that install *separate* from any SVN copy.
EDIT (again): Another note: Since you've also already messed with your 2.2.1 install, you probably also can't play 2.2.1 again until you re-install it, for now it has probably gone bye-bye, although you might be able to salvage your save-games if you're lucky.
-
IIRC; it needed to be put on top of 2.2.1. .. I though not all the files were in the trunk...DOH!
Well, just plop everything from the SVN in a new folder, eh? Righto...
Speaking if 2.3 install? There is a instalation .exe of 2.3 out? Where? I heard nuttin.
-
Test installers. They're linked in the Windows forum.
-
All files needed for game are in trunk.
And if you compile trunk from sources, you no need to install anything (except dlls from contrib/dlls dir), just start ufo.exe and play.
If you miss *.pk3 files, they are just contain data from accordinaly folders.
-
OH YEAAAAH! Working! F'course, I didn't acutaly play, since I haven't complied the maps, I just started a new game and got the geosphere..which means it workz! now I can finally continue :)
;D
-
Congratulations!
One more tip, to avoid any potential upcoming headaches: When compiling maps, there are several ways to do it (the method I now use is the .bat file), but once you pick a method, stay consistent with it - I've found that sometimes compiling maps one way then compiling new maps with a different method after updating from SVN results in problems.
-
Congratulations :-)
-
I just managed to build the trunk (yay!). I chose not to use the prepackaged Code::Blocks version, but followed the instructions in general at http://ufoai.ninex.info/wiki/index.php/Code::Blocks (http://ufoai.ninex.info/wiki/index.php/Code::Blocks).
For using an SVN copy, I'd suggest using a folder *not* anywhere in the "program files" folder, but checking out an SVN copy to a folder in your "my documents" folder, or a folder off the root of your C: drive (such as "C:\ufoai), or if you have multiple partitions, the root of a storage drive, depending on how your system is set up. Heck, if you have a large enough portable or flash drive, I'd imagine you could compile and run it off of that, although there might be a performance issue, but I haven't tried that.
I chose to have my SVN copy in \My Documents\UfoAI and the only thing that's not working is the compiling of resource files, but that is easily resolved by removing the resource compiler search directory. Apparently spaces are not allowed there, or I messed up something.
As to using a flash drive. This is a very interesting idea that I may give a try if I get bored. Unfortunately I have only one old 1 GB usb stick, which isn't large enough to hold the whole 1.8 GB of the trunk when it's all built and done. Without the base the size gets to something manageable. Now if I only remembered where I have put the usb stick. Maybe this finally gives me an excuse to get a larger+faster one. It would be interesting to pit a fast flash drive against my striped raptors.
I have two problems currently (haven't really had time to test that much), running revision 20275.
- Realtime lightning doesn't really work for me. I mean, works ok until combat (when it's used) and then it eats up enough cpu to make navigating to options with a mouse interesting. I don't really know if it's my system (Pentium M 2.13 GHz, 2 GB memory and GeForce FX 5600) or the game.
- I manage to lose textures switching between windowed and full-screen. It seems all items, some character textures and later the world (globalscape) disappear making them appear as nice white ghosts. Although the globalscape sometimes looks ok, but everytime I get an assertion failure in r_image.c line 1512. Normally I wouldn't switch between windowed/full screen at all, but just happened to do that when I realized that scrolling wasn't that much fun in a windowed environment.
-
is playable?
I try to Skirmish game ,game break at inv_shared.c line 1081 "if (container->scroll)"
try use "map day XXX", game break at sv_init.c "ge->SpawnEntities(sv.name, CM_EntityString());"
-
- Realtime lightning doesn't really work for me. I mean, works ok until combat (when it's used) and then it eats up enough cpu to make navigating to options with a mouse interesting. I don't really know if it's my system (Pentium M 2.13 GHz, 2 GB memory and GeForce FX 5600) or the game.
- I manage to lose textures switching between windowed and full-screen. It seems all items, some character textures and later the world (globalscape) disappear making them appear as nice white ghosts. Although the globalscape sometimes looks ok, but everytime I get an assertion failure in r_image.c line 1512. Normally I wouldn't switch between windowed/full screen at all, but just happened to do that when I realized that scrolling wasn't that much fun in a windowed environment.
well, a fx5600 is maybe not enough to execute the glsl shaders we are using.
use ctrl+g to catch the mouse in the game window (and press it again to release it again). i will have a look at the texture bug asap
-
is playable?
I try to Skirmish game ,game break at inv_shared.c line 1081 "if (container->scroll)"
try use "map day XXX", game break at sv_init.c "ge->SpawnEntities(sv.name, CM_EntityString());"
i don't get these crashes - are you at the latest svn trunk revision? also please don't mix the code from trunk with gamedata files from any other version or revision
-
- Realtime lightning doesn't really work for me. I mean, works ok until combat (when it's used) and then it eats up enough cpu to make navigating to options with a mouse interesting. I don't really know if it's my system (Pentium M 2.13 GHz, 2 GB memory and GeForce FX 5600) or the game.
well, a fx5600 is maybe not enough to execute the glsl shaders we are using.
True on the fx5600. I have a Sapphire Radeon X1950 Pro with 512 MB waiting to get a new fan, but that got put on hold as I need to fabricate a vrm heat spreader from copper and other stuff (life) got in the way. Now it feels like I should get that card up and running. Then again, graphics isn't the most important thing.
The navigating with mouse could be made easier, maybe. I mean, it's easy enough to hit the big button to get to the options screen, but hitting the small checkboxes when the system is under heavy load requires a good deal of patience.
As the slowdown is most noticeable in battle, I will not be the only one experiencing it.
Would it be possible to suspend some thread when the options menu pops up?
-
ufo is not threaded (well, there is a thread for the bsp walking)
if you plan to optimize things, the ai is rather slow, too (might also be related to the pathfinding)
-
Just got a new build 15 minutes ago. Got this while compiling:
Compiling: ..\..\src\tools\ufo2map\brushbsp.c
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\ufo2map\brushbsp.c: In function `SelectSplitSide':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\ufo2map\brushbsp.c:618: error: invalid type argument of `->'
Process terminated with status 1 (0 minutes, 6 seconds)
1 errors, 0 warnings
-
Jeah and abot 20 mins ago I got A syntax error in a related file.
Seems as if someone is programming directly on the svn trunk...
Not a wise Idea I'd say.
-
ALL programming happens on SVN trunk. It's been that way ever since the (re)start of the project.
-
Oh, I have seen it on other projects, that trunk is mainly kept for testing. And therefore should be kept at least compileable and startable.
Thats the reason I was confused when I got a version that I couldn't even compile due to syntax errors.
Developement is usually done on a private copy that is only synchronized with the svn after at least some validation.
Sometimes there are even extra versions for experimental developements (eg that are not to get anywhere stable soon)
But It's yours to decide what has which advantages and disadvantages for you.
-
I think what BTAxis wanted to say is that the trunk is a continuous development branch so every change is committed directly under that branch. Other branches are made for example for the release candidates and the final versioned releases.
Therefore the trunk should always be compilable. If there are any syntax errors then...well, errors happen and somebody has committed an uncompilable code.
Correct me if I am wrong, I am just getting started with this project and its structure [compiled it today for the first time, code was checked out one day before, no errors during compilation, game runs]
-
Some revisions actually don't compile for that reason (especially radiant). Trunk is *supposed* to be compilable at all times (i.e. half-finished work that breaks compilation or execution should not be committed), but especially platform-specific issues tend to pop up from time to time.
-
At the moment users of Mac PPC are welcome to test thrunk ; if the game compile and work. They can test the open/close of the message system; is spinner and checkbox work; is there anyproblem on the aircraft GUI. Imho part of the game where we can have more platform-specific problems. I change some code about menus allocation (r22963 r22970)
We also have many warnings, because we are refactoring many code. It should not make problems for compilation; and will be fixed soon.
-
Running 23247 on XP (plus some pathfinding patch)
- starting a new single campaign, auto-build a base, save
- load that game, open console
- devmap fighter_crash
=> map loads fine, but without soldiers.
That procedure still worked for me about a week ago, sooo questions:
Is it just me ? Or did the devmap behaviour change ?
-
I removed all patches and tried with plain trunk code (rev 23274). Same problem :(
Also tried 'map' and a different map. No soldiers.
I could enter a mission from the campaign (from that same saved game) and had soldiers though.
Even if nobody can fix it or knows a workaround, it would be nice if somone could at least confirm or disconfirm this problem.
t.i.a.
-
Hello.
No body talk about a bug like that right now.
If all your files are up to date (map compiled with last ufo2map, game library compiled (so/dll), game compiled, new save game), an helpfull information is to find the first revision creating this problem. Your computer/OS can also be helpfull.
-
please try to start a map via the skirmish game mode - don't try to start them manually
i still have to fix some stuff around the handling of map spawning.
-
Thx, bayo, a good hint. So I created a fresh savegame, but it didn't work either :(
@Mattn:
Already tried skirmish mode and it works. But it's not very helpful if I want to test pathfinding.
Wilminator has just created a new patch for routing and it looks very promising :)
As the 'stairway bug' has prio 9 in the tracker, may I suggest that fixing devmap spawning is considered prio 10 ? ;)
Do you already know what needs to be done or is there still some bughunting to do ? I tried to venture into that area of the code but couldn't even find the point where the spawning should happen.
-
When pressing ctrl-g, I get "vid_grabmouse is write protected." in my log (rev 23378, XP)
along with the inability to test in windowed mode.
Yesterday's trunk did work.
-
imo we should remove the devmap command completely - this is just a hack - please let me know why skirmish is not the best for testing pathfinding.
-
the devmap command is just settings sv_ai to 0 - this can be done better by a macro definition in autoexec.cfg imo.
btw. do you know g_notu and g_nodamage (useful for maptesting, too)
-
btw. do you know g_notu and g_nodamage (useful for maptesting, too)
No, not yet. I can imagine what g_nodamage does.
What does notu do ? Set alien's TU to 0 ?
Skirmish problems are:
- can't select all the maps I need
- selection of maps need lot's of clicks / time
- aliens interfering (solved by sv_ai ?)
- turns take too long (solved by sv_ai ?)
-
g_notu will not waste TUs while walking around in the map. useful for debugging pathfinding.
-
IC. Thx.
Oh, and I just noticed that ctrl-g works again (rev 23426). Thx to whom it concerns :)
-
If you dont like to click, you also can run a skirmish map from the command line, but i dont remember how, sorry.
-
@bayo: afaik that's what 'map <day|night> mapname' does (devmap is just a specialized form). Or did you think of another command ?
@mattn: I also found out how to start the other maps. Stupid me. I once scrolled through the list and didn't get beyond the point where you have to click 4-5 times on the same mapname, so I thought the list ended somewhere around the letter 'g'...
-
When called from the main menu, map doesn't spawn actors, as far as I know. Skirmish kind of creates a temporary campaign for that.
-
Just re-compiled and got this:
Node behaviour 'airfightmap' doesn't exist
I updated the contrib folder and the dlls, re-compiled the exe...am I missing something?
-
airfight was actually removed from code again (because there is no progress at all and it won't be in 2.3 at all), perhaps some part was not removed correctly.
-
Yeah, it was left in my folder from the former SVN update.
I removed it and the game works.
I can't compile maps anymore tough.
Neither compile.py (sez bunker.map doesn't exist, but it's there) or ufomap.exe (provide argument: map filename) work.
-
> I can't compile maps anymore tough.
Use compile_maps.bat from contrib/scripts
-
Yeah, it was left in my folder from the former SVN update.
I removed it and the game works.
I can't compile maps anymore tough.
Neither compile.py (sez bunker.map doesn't exist, but it's there) or ufomap.exe (provide argument: map filename) work.
Hi Trashman, did u managed to compile the maps in the end?
Or did u encounter issues with compiling (such as they refuse to update the bsp files?).
If so, maybe try to do this painful step:
Recompilation of all maps from fresh. Be warned that it can take some well...... 1 to 2 hrs or more depending on the processors and speed ur PC has.
I am assuming u r running Win32 or in Dos mode (i.e Windows environment).
1) Goto windows explorer (Windows Command Key - the key between your Left CTRL and Left ALT, press that Key and E simultaneously once). (Or Start, Programs, Accessories, Windows Explorer).
2) Browse to ur SVN directory and search for all "bsp" files (i.e. *.bsp).
3) You will get a return on bsp files from within various directories inside - /svn directory/base/maps
4) Delete all the bsp files.
5) Call your command prompt (Start, Run, (or Windows Command Key + R once)), key in "cmd"
6) Browse to your SVN directory (Cd C:\SVN Directory Name here\contrib\scripts)
7) Run the file : Compile_maps.bat (compile_maps <Carriage Return or the Enter Key>)
Wait for the script to finish.... yawns, make coffee, watch an anime or 2, come back and u r done when it says complete.
Cheers!