Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: WMCoolmon on March 26, 2005, 09:22:39 pm
-
make[1]: *** No rule to make target `ship/ai.cpp', needed by `ai.o'. Stop.
make[1]: Leaving directory `/usr/src/fs2_open/code'
make: *** [all-recursive] Error 1
Yeah, almost certainly my fault for moving the AI files in CVS. Not sure how to fix it though.
Edit: meh...
code/Makefile: render/3dsetup.cpp ship/afterburner.cpp ship/ai.cpp \
code/Makefile: render/3dsetup.cpp ship/afterburner.cpp ship/ai.cpp \
code/Makefile:ai.o: ship/ai.cpp
code/Makefile: if $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT ai.o -MD -MP -MF "$(DEPDIR)/ai.Tpo" -c -o ai.o `test -f 'ship/ai.cpp' || echo '$(srcdir)/'`ship/ai.cpp; \
code/Makefile:# source='ship/ai.cpp' object='ai.o' libtool=no \
code/Makefile:# $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -c -o ai.o `test -f 'ship/ai.cpp' || echo '$(srcdir)/'`ship/ai.cpp
code/Makefile:ai.obj: ship/ai.cpp
code/Makefile: if $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT ai.obj -MD -MP -MF "$(DEPDIR)/ai.Tpo" -c -o ai.obj `if test -f 'ship/ai.cpp'; then $(CYGPATH_W) 'ship/ai.cpp'; else $(CYGPATH_W) '$(srcdir)/ship/ai.cpp'; fi`; \
code/Makefile:# source='ship/ai.cpp' object='ai.obj' libtool=no \
code/Makefile:# $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -c -o ai.obj `if test -f 'ship/ai.cpp'; then $(CYGPATH_W) 'ship/ai.cpp'; else $(CYGPATH_W) '$(srcdir)/ship/ai.cpp'; fi`
code/Makefile.am: ship/ai.cpp \
code/Makefile.in: render/3dsetup.cpp ship/afterburner.cpp ship/ai.cpp \
code/Makefile.in: render/3dsetup.cpp ship/afterburner.cpp ship/ai.cpp \
code/Makefile.in:ai.o: ship/ai.cpp
code/Makefile.in:@am__fastdepCXX_TRUE@ if $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT ai.o -MD -MP -MF "$(DEPDIR)/ai.Tpo" -c -o ai.o `test -f 'ship/ai.cpp' || echo '$(srcdir)/'`ship/ai.cpp; \
code/Makefile.in:@AMDEP_TRUE@@am__fastdepCXX_FALSE@ source='ship/ai.cpp' object='ai.o' libtool=no @AMDEPBACKSLASH@
code/Makefile.in:@am__fastdepCXX_FALSE@ $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -c -o ai.o `test -f 'ship/ai.cpp' || echo '$(srcdir)/'`ship/ai.cpp
code/Makefile.in:ai.obj: ship/ai.cpp
code/Makefile.in:@am__fastdepCXX_TRUE@ if $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT ai.obj -MD -MP -MF "$(DEPDIR)/ai.Tpo" -c -o ai.obj `if test -f 'ship/ai.cpp'; then $(CYGPATH_W) 'ship/ai.cpp'; else $(CYGPATH_W) '$(srcdir)/ship/ai.cpp'; fi`; \
code/Makefile.in:@AMDEP_TRUE@@am__fastdepCXX_FALSE@ source='ship/ai.cpp' object='ai.obj' libtool=no @AMDEPBACKSLASH@
code/Makefile.in:@am__fastdepCXX_FALSE@ $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -c -o ai.obj `if test -f 'ship/ai.cpp'; then $(CYGPATH_W) 'ship/ai.cpp'; else $(CYGPATH_W) '$(srcdir)/ship/ai.cpp'; fi`
-
I've got fixes for that already so don't worry about it. I was holding off on the update for you-know-what but I'll get it all fixed/updated in the next few hours.
-
So close...and yet so far. :sigh:
/usr/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lGLU
collect2: ld returned 1 exit status
make[1]: *** [fs2_open_r] Error 1
make[1]: Leaving directory `/usr/src/fs2_open/code'
make: *** [all-recursive] Error 1
-
Originally posted by WMCoolmon
So close...and yet so far. :sigh:
:lol:
Maybe this will help some:
[taylor@dragon include]$ rpm -qf /usr/lib64/libGLU.so
xorg-x11-devel-6.8.1-12.FC3.21
[taylor@dragon include]$ rpm -qf /usr/lib64/libGLU.so.1
xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21
You'll need to make sure that you have the plain .so to build with so you're probably missing a devel package in there somewhere.
-
Hmm, I'm using XFree86 (Comes with Yoper by default) and MesaLib conflicts with it, apparently.
-
Hmm, well if it's got the headers and everything then just symlink to one of the existing libs (assuming they are there). That's all the .so is anyway, "libGLU.so -> libGLU.so.1.3"
-
:eek2: It works! With sound, too, after modifying my asoundrc file. (This is nothing short of impressive as the Audigy 2 NX isn't really supported by OpenAL, except at 48khz - although maybe at 22khz as well)
Graphics are, hmm, in a state of flux...the Boanegres, Triton, Pegasus, and Hercules don't seem to be effected (Although the Boanegres and Pegasus look like the textures are slightly lower-res than in Win32 FS)
Sample image:
-
I got those graphic-errors in Trainig-Missions a time ago...
But now it all seems to be OK...
-
Originally posted by WMCoolmon
:eek2: It works! With sound, too, after modifying my asoundrc file. (This is nothing short of impressive as the Audigy 2 NX isn't really supported by OpenAL, except at 48khz - although maybe at 22khz as well)
You sould be able to change the sample rate with the reg option you added a while back. I haven't really tested it but that is what it uses now.
Graphics are, hmm, in a state of flux...the Boanegres, Triton, Pegasus, and Hercules don't seem to be effected (Although the Boanegres and Pegasus look like the textures are slightly lower-res than in Win32 FS)
Hmm, I had that happen too last night but it only did it once and the next time I ran the game it was fine. Hasn't done it since. I do get similar strange effects in multiplayer though, never single player. Haven't been able to track it down but if it's going to start hitting single player too then I need to find the problem.
-
I tried again today and had the same problem. I tried it briefly with 1024x768, then switched to 1280x1024 as the same ships seemed to be having the same problems.
The following ships don't have corruption problems, but do seem to have lower-res textures than I remember from Win32. Command lines are the same, files should be the same, as I've symlinked to the mediaVPs in my FS2 dir.
Boadicia (The asteroid texture and floaty things on the bottom are uncorrupted, the ship texture is, however.)
Boanegres
Triton (Normal)
Pegasus
Hercules (Normal)
Bakha
Ptah
Bes (Looks normal and as hi-res as ever)
Edjo
Dis
Belial
Rahu
Cmdline:
./fs2_open_ex -spec -glow -pcx32 -jpgtga -nomotiondebris -2d_poof -rlm -dualscanlines -ship_choice_3d -targetinfo -3dwarp -snd_preload -loadonlyused (-nosound)
fs2_open.ini
[Default]
VideocardFs2open=OGL -(1280x1024)x32 bit
LastPlayer=WMCoolmonS
ScreenshotNum=9
-
Hi!
I just wanted to say, that you forgot an semicolon in
code/ship/shiphit.cpp line 2360 ;)
EDIT:
And, unfortunately, I get an SEGFAULT when I want to enter the techroom...
There are no ships in the lab and the normal missions don't work, too (SEGFAULT or missionparse.cpp error) :(
Oops... I'm seeing that there are many CVS-Commits...
So I think I'll just have to be patient ;)
-
Looks like you forgot a lot of things, WMC. :p
As per your CVS comment, I direct you here...
http://www.breathalyzer.net/
-
It should all be fixed now Mr_Maniac. Didn't try any of the armor stuff but the parsing and syntax problems are fixed.
@Goob: hehehe, I'd almost swear that WMC was drunk during those commits. One commit for the basic code and four more to fix problems. And after all that it still wouldn't compile and wouldn't parse ships.tbl. I'm still laughing at that. :D But of course my terminal went freaky on me and kept recalling previous commands whenever I hit backspace so perhaps it was just some planetary alignment thing. ;)
-
:lol:
What happened was that I wrote all the code out, starting with the class, then went on to the member functions, global functions, and finally the individual hooks in ships.tbl and weaponstbl, plus the ship_do_damage stuff, making minor modifications. I was trying to be quick about it.
Then I went on to do other stuff. But in the back of my head, I was still going over everything, and that's where those extra commits came in; I'd remember that I forgot to set a variable equal to a function or something, fix it, commit it, thinking I'd gotten it working properly.
This was all compounded by the fact I was working from within Anjuta, for the first time, and was getting a crapload of errors about SDL.h missing (although I didn't touch the files and had compiled it before.) I assumed that was some bizarre interaction since I'd uninstalled/reinstalled a half-dozen libraries since I last tried to compile the source - although I did try to get rid of all the compiler errors. :doubt:
OTOH, the sauce that came with the instant Chicken Chou-Mein did smell a little odd... :p
-
In file included from ai/aigoals.cpp:573:
./parse/sexp.h:1543: error: storage size of `Sexp_help' isn't known
./parse/sexp.h:1543: error: storage size of `Sexp_help' isn't known
make[1]: *** [aigoals.o] Error 1
make[1]: *** Waiting for unfinished jobs....
In file included from ./playerman/player.h:197,
from ai/aicode.cpp:855:
./parse/sexp.h:1543: error: storage size of `Sexp_help' isn't known
./parse/sexp.h:1543: error: storage size of `Sexp_help' isn't known
make[1]: *** [aicode.o] Error 1
make[1]: Leaving directory `/home/maniac/sources/fs2_open/code'
make: *** [all-recursive] Error 1
;)
-
Uhm?
//WMC - moved here from FRED
typedef struct sexp_help_struct {
int id;
char *help;
} sexp_help_struct;
sexp_help_struct Sexp_help[];
It's initialized in sexp.cpp, does it have to be a pointer? :wtf:
-
Originally posted by WMCoolmon
It's initialized in sexp.cpp, does it have to be a pointer? :wtf:
Yes, if it's sized dynamically. Otherwise it doesn't know how large to make it since how it's used doesn't correspond with how it's defined.
-
Originally posted by taylor
Yes, if it's sized dynamically. Otherwise it doesn't know how large to make it since how it's used doesn't correspond with how it's defined.
It isn't sized dynamically, so you should be able to get away with
extern sexp_help_struct Sexp_help[];
in the header. Please also remove the extraneous commas at the end of the new arrays in sexp.cpp, or my version of gcc will implode. Thanks.
-
Ahh, yeah, the extern would help.
I looked at the new SEXPs arrays but didn't see any difference between the commas in them and the old SEXP array. I'm sort of reluctant to change them, as that's how every other array in the code is defined, AFAIK, and there's never been any trouble with those. Are you sure it isn't just because of the missing extern (I just fixed that in CVS, btw)
-
Originally posted by WMCoolmon
I looked at the new SEXPs arrays but didn't see any difference between the commas in them and the old SEXP array. I'm sort of reluctant to change them, as that's how every other array in the code is defined, AFAIK, and there's never been any trouble with those. Are you sure it isn't just because of the missing extern (I just fixed that in CVS, btw)
I haven't actually tried it yet, but I know my gcc often has issues with stuff like that. I'll give it a shot and complain again if it really breaks, though.
-
Newest make error:
In ship.cpp, "TARGET_SHIP_IGNORE_FLAGS" isn't declared...
So ship.cpp doesn't compile...
-
Add the line indicated below in ship.cpp, at the beginning of the code in the file (this starts around line 1588):
int Ai_render_debug_flag=0;
#ifndef NDEBUG
int Ship_sphere_check = 0;
int Ship_auto_repair = 1; // flag to indicate auto-repair of subsystem should occur
extern void render_path_points(object *objp);
#endif
extern int TARGET_SHIP_IGNORE_FLAGS; // <----- Add this line here
and you should be able to compile it.
-
Thanks Alpha0, but I only wanted to report it ;)
-
Should be fixed in CVS
-
@WMCoolmon: Sorry, but it isn't...
I always use the newest CVS-Tree and still this error occures...
-
It showed up in the CVS log mailing but never actually hit the tree. That's happened a few times with my stuff too. It looks like it goes in but actually doesn't. I've already got it ready to go back in during my next commit later today.
-
As opposed to other stuff going in but looking like it doesn't? Ugh. This is even worse. :(