Hard Light Productions Forums
Hosted Projects - Standalone => The Babylon Project => Topic started by: 0rph3u5 on August 25, 2007, 04:53:17 pm
-
You want to play "Raider Wars" without problems? - You will be helped!
List of Bugs - created from the community's posts:
Major:
- CTDs in "Slipping the Nose"
- CTDs in "The Wheel Turns"
Minor:
- voice acting errors in "Nobody Expects" (almostTM fixedTM)
- message/voice acting errors in "Slipping the Nose" (fixedTM)
- "broken" Brakirii vessel in "Nightmare Scenario" (fixedTM)
- background mismatches (fixedTM)
- "Protect Freighters"-directive in "Boarding Party" (fixedTM)
- Briefing Icos (fixedTM)
anything else?
EDIT: I failed to find the related Mantis-Issues to the CTDs ... do they exisit?
-
As far as I know, no.
And I'm going to need much more detailed advice on just what causes the problem unless the game crashes the first time I try the mission.
-
how can we help ? should we try to reproduce the bugs and post the CTDs ?
-
how can we help ? should we try to reproduce the bugs and post the CTDs ?
Yeah would be cool of you to try that with debug build (normal and INF - don't forget to hide (cut+paste to anywhere but you TBP/data-folder) any additional tbls with you do it with a normal debug-build) and post what comes up...
-
I am not sure if I understand this.
-
Basically find a set of conditions which will always make the mission crash. Then put it in Mantis so I can try them out myself.
-
The crash is pretty consistent. If you try the mission I doubt you'll be disappointed.
-
there seems to be a problem. freespace always crashs (I mean real crash) on turning the wheel.
-
something like that:
fs2_open_3_6_9 caused an Access Violation in module fs2_open_3_6_9.exe at 001b:00608b4e.
Exception handler called in FreeSpace 2 Main Thread.
Error occurred at 8/30/2007 20:01:50.
C:\Games\The Babylon Project\fs2_open_3_6_9.exe, run by Elias.
2 processor(s), type 586.
1521 MBytes physical memory.
Read from location 00000004 caused an access violation.
Registers:
EAX=10481ff8 CS=001b EIP=00608b4e EFLGS=00010202
EBX=c5290ca5 SS=0023 ESP=0012f884 EBP=0012f8d4
ECX=10481ff8 DS=0023 ESI=0109ca74 FS=003b
EDX=00000004 ES=0023 EDI=0109cafc GS=0000
Bytes at CS:EIP:
8b 02 89 45 c0 8b 4a 04 89 4d c4 8b 52 08 89 55
Stack dump:
0012f884: 0001f67c 00000009 0012f7e8 7c91ee18 0012f8dc 7c91ee18 7c920570 10481ff8
0012f8a4: 01817a98 c36d4ee9 41329b19 c528bc2d 1d318168 0109cafc 0109ca74 023507f0
0012f8c4: 01396c90 3ea20dd0 3cdba17c 3f72bdde 0012f92c 00608ede 0012f904 0012f918
vvvvvvvvv more of this stuff
and again
fs2_open_3_6_9 caused an Access Violation in module fs2_open_3_6_9.exe at 001b:00608b4e.
Exception handler called in FreeSpace 2 Main Thread.
Error occurred at 8/30/2007 19:59:16.
C:\Games\The Babylon Project\fs2_open_3_6_9.exe, run by Elias.
2 processor(s), type 586.
1521 MBytes physical memory.
Read from location 00000004 caused an access violation.
Registers:
EAX=104b27e8 CS=001b EIP=00608b4e EFLGS=00010202
EBX=43d6ed3b SS=0023 ESP=0012f884 EBP=0012f8d4
ECX=104b27e8 DS=0023 ESI=0109ca74 FS=003b
EDX=00000004 ES=0023 EDI=0109cafc GS=0000
Bytes at CS:EIP:
8b 02 89 45 c0 8b 4a 04 89 4d c4 8b 52 08 89 55
Stack dump:
0012f884: 0001f67c 00000009 0012f7e8 7c91ee18 0012f8dc 7c91ee18 7c920570 104b27e8
0012f8a4: 018086f0 c458a54d c294d4bf 43d975f6 224a2d20 0109cafc 0109ca74 023507f0
0012f8c4: 01396c90 bf7339d1 3cebde6a be9f0867 0012f92c 00608ede 0012f904 0012f918
vvvv and a lot of stuff
-
See if you can get it to crash using the debug build. If you can, post the fs2_open.log from your data folder.
-
-I finally found some time to run another go-
UPDATE:
MAJOR BUGS:
- no crashes on IFF changes; wrong alarm
- CTD in "The Wheel Turns" confirmed, trying to determine cause
MINOR BUGS:
- changed the event with the directive "Protect Freighters" in "Boarding Party" so the directive will show up from start
- fixed the briefing icons
@kara:
here is my FS2_open log - I ran "The Wheel Turns" with the debug-variant of the build you gave me(various times in a row) but it keeps on crashing BTW this build creates a lot of graphical errors...
I'm looking if I can find a cause in the mission's SEXPs
[attachment deleted by admin]
-
I'm looking if I can find a cause in the mission's SEXPs
Kara might see this as taking a somewhat overly aggressive stance towards SCP now he's part of their team... but... it's worth baring in mind that no SEXP error should ever make the game crash to desktop. If the mission doesn't do what it's supposed to do that's different.
-
Actually I agree with you 100%. At the very worst a SEXP error should at least display a warning\error\assertion in debug mode.
-
It was not my intentention to insult someone - sry if I did
I just wanted to stress that I'm doing all I can at my end to find something that might be a lead to the cause or the cause itself and that I'm therefor turning the mission file upside down
and maybe I've found something... details later
-
You didn't insult me. I'm really grateful you have sorting out these issues on your agenda Orph. Isolating which SEXPs if any are causing the crashes sounds like a fantastic idea. If there are logic problems in the mission and fixing those fixes the crashes, that's great! I just didn't want you to think that it's your job to remove SEXPs that should work just because they crash the game engine. That's curing the symptom not the problem. Kara seems predictably reasonable about this so if you're in doubt ask him. As I will likely vanish now for a few days.
Thanks again to both of you for taking an interest.
-
I never though of completely removing stuff from your missions permantently -- I don't feel I've the right to do that
(but there are some things I don't understand esspecially about TWT - check your pms)
but I finally isolated something which has something to do with the crash in "The Wheel Turns"...
the crash does not appear if you keep at least a distance 4k-5k to the centauri cruisers --- :confused: :confused:
EDIT: I ran some other missions including the Vorchan to see if it has something to do with the ship or its weapons - negative on that
EDIT2:
"Slipping the Nose" went without a hitch in the second go -- this time is just sticked closer to the gibralta and the GOD than usual and all of a sudden it works.... wierd
EDIT3:
Warning: Null vec3d in vec3d normalize.
Trace out of vecmat.cpp and find offending code.
File: VecMat.cpp
Line: 806
Call stack:
------------------------------------------------------------------
physics_apply_shock() weapon_area_apply_blast() shockwave_move() shockwave_move_all() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816fd7()
------------------------------------------------------------------
this poped up on various occasions -- aynthing significant?
-
It means there's an extremely minor issue with a model. A number of our models have such issues. The game engine never used to bug about it. Those were the days. I miss them. On some systems the debug build will actually crash because of this warning. Which renders the debug build useless.
-
debug crashed right at the beginning on my machine and we got this:
Warning: Too many ship classes before 'Sinclair's Aurora'; maximum is 130, so only the first 130 will be used
File:J:\src\cvs\fs2_open_3_6_9.final\code\ship\Ship.cpp
Line: 2879
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
parse_shiptbl() parse_modular_table() ship_init() game_init() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
what did i done wrong ? and what's that INF-debug ?
-
That's not a crash it's a warning and a justified one. Just ignore the too many ship class warnings.
-
BUT:
if i choose "no", the bug just appears over and over and over again
if I choose "yes" the game crashes totally
if i choose "cancel" the game quits (like it should)
the debug_inf seems to work, but I dont know the difference between the INF and the normal debug
-
Debug Inf supports over 120 ships - normal debug just support 120
for TBP it is safer to use the INF debug
-
Doh. That's my bad. I've just realised I gave you the latest CVS build rather than the latest Inferno CVS build for the 3.6.9 branch. Simply change the filename on the .tbm file and it should work again (or complain about missing ship classes).
I'll build you an Inferno build (one that can handle more than 130 ship classes) if it causes you problems.
As for the null vec error that could be a possible cause of the crashes actually. But I'd be expecting to get divide by zero errors if that was the case.
-
As for the null vec error that could be a possible cause of the crashes actually. But I'd be expecting to get divide by zero errors if that was the case.
I just wanted to know what that is 'cause it looked suspicious to me and kept on popping up on various ocasions
-
my tbp installer always lauched the normal fs2open and fred, instead of the inf versions. Now I know why the ships of the first ones were missing in my game ! I hope this won't create problems with my campaign now, 5 missions are already finished but I used the normal fred and fs2open.
additionally, i have to report a ctd in hell and back and even during debug, i got no error log.
And i got
During loading of Turning the wheel and Profit&Loss and Nobody expects
Warning: Ship is not a support ship!
File:J:\src\cvs\fs2_open_3_6_9.final\code\Parse\SEXP.CPP
Line: 13314
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
eval_sexp() eval_when() eval_sexp() mission_process_event() mission_eval_goals() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
During nobody expects
Warning: Null vec3d in vec3d normalize.
Trace out of vecmat.cpp and find offending code.
File:J:\src\cvs\fs2_open_3_6_9.final\code\Math\VecMat.cpp
Line: 803
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
vm_vec_normalize() vm_vec_normal() get_tangent_point() create_path_to_point() create_model_path() ai_find_path() ai_dock_with_object() ai_process_mission_orders() ai_frame() ai_process() ship_process_post() obj_move_all_post() obj_move_all() game_simulation_frame() game_frame()
------------------------------------------------------------------
are those normal ?
-
As for the null vec error that could be a possible cause of the crashes actually. But I'd be expecting to get divide by zero errors if that was the case.
Our models have always had these issues. They never caused crashes, in fact the game engine never even mentioned them until late in it's development.
-
well, for that, Nobody expects seems to work.
For the background issues:
During load of Preemtive measures I:
Warning: Trying to add a bitmap that does not exist in stars.tbl!
File:J:\src\cvs\fs2_open_3_6_9.final\code\Starfield\StarField.cpp
Line: 3127
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
stars_load_background() stars_load_first_valid_background() parse_bitmaps() parse_mission() parse_main() mission_load() game_start_mission() game_enter_state() gameseq_set_state() game_process_event() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
Warning: Failed to add starfield bitmap 'neb_grene4' to the mission!
File:J:\src\cvs\fs2_open_3_6_9.final\code\Starfield\StarField.cpp
Line: 3459
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
stars_load_first_valid_background() parse_bitmaps() parse_mission() parse_main() mission_load() game_start_mission() game_enter_state() gameseq_set_state() game_process_event() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
question: is that the broken Brakiri vessel you are refering to ? During loading of Nightmare Scenario:
Warning: Ship "BK Cassan" has an invalid ship type (ships.tbl probably changed). Making it type 0
File:J:\src\cvs\fs2_open_3_6_9.final\code\Mission\MissionParse.cpp
Line: 3315
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
parse_objects() parse_mission() parse_main() mission_load() game_start_mission() game_enter_state() gameseq_set_state() game_process_event() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c816d4f()
------------------------------------------------------------------
And again, I want to repeat that I had a CTD on "Hell and back" but without a error message in debug, can anyone confirm ?
Additionally, I played through "Slipping the nose" now multiple times and it worked (???). Just got one crash, during the "Brakiri Cruiser(...)fire" message, but again, with no error message even in debug.
-
Warning: Ship is not a support ship!
that's normal and harmless
Warning: Null vec3d in vec3d normalize.
I've asked that before (few posts up) and it appears that it is normal
Warning: Trying to add a bitmap that does not exist in stars.tbl!
Warning: Failed to add starfield bitmap 'neb_grene4' to the mission!
that is a wierd typo (grene instead of green) in the mission file - I've got no idea how it got there unless IPA used the ordinary text editor to modify his missions - fixed under the pointer "Background Mismatches"
Warning: Ship "BK Cassan" has an invalid ship type (ships.tbl probably changed). Making it type 0
noted and fixed various times - - maybe the fixed mission file I've posted sometime in the other thread about the Bugs in RW is still around
Vidmaster, can you tell me what you did before it crashed while playing "Hell and Back"?
EDIT: Currently I'm starting a Mantis issue on this --- all description I can give is pretty blurry, that is why it might be cloesed soon...
EDIT2: Mantis issue is out - #0001485
-
hermes had already shown up and I was dogfighting, sry that's it.
-
When you guys get a good bug fix game engine build can you include me in the beta testing? I would like to do a little FREDing.
-
When you guys get a good bug fix game engine build can you include me in the beta testing? I would like to do a little FREDing.
sure - PM me once you have the time and I'll upload a package with the mission file including the current fixes and a CVS build Kara gave me for you
-
Hmmmm. That's odd. I played through The Wheel Turns and it worked just fine for me.
I'll upload the build I was using in a little bit and people can test it out.
-
Hmmmm. That's odd. I played through The Wheel Turns and it worked just fine for me.
did you stay close to those 3 Vorchans?
AND please check the "CTDs on Raider Wars"-Mantis issue (ID No. 0001485)
there had been an more elaborate update -- maybe that is just what you might need to trace down the cause of these CTD
-
Might want to look into why it is that your wingmates never seem to listen to you.
"Form on my wing"
*waits five minutes*
"SAY, I SAID FORM ON MY WING"
They say: "DROOOOOOOL IM WEETAUDDED."
:doubt:
-
Okay. Found a potential cause of the crash in TWT.
The EA Maintbots have no weapons. At one point in the game though it appears that they are trying to strafe the Vorchans. The problem with this is that the game figures out how to strafe by working out where the guns are and pointing them at the enemy ship. Except the maintbots have no guns. So the position information for the guns is nonsense.
I'm not sure what I can do about this. I'm not entirely sure that this is something that should have a code solution (or at least not a simple one). Giving the maintbots a very low power welding torch with an incredibly short range should be enough to solve the problem. Giving them different orders (return to the station) might also work.
I notice mission 9 also has maint bots in it. The cause is likely the same one.
-
i new he is brilliant ;) :nod: :nod: :nod:
-
equiping the mainbot with two gun points (1 primary/1 secondary) would basically fix it?
-
As far as I could see it was only the primaries that were causing the crash because the game uses them to determine which way the ship should be facing.
But if you just gave the ship gunpoints you might find that the game now crashes due to having gunpoints and no weapon for them. So I'm not certain what to advise.
-
As far as I could see it was only the primaries that were causing the crash because the game uses them to determine which way the ship should be facing.
But if you just gave the ship gunpoints you might find that the game now crashes due to having gunpoints and no weapon for them. So I'm not certain what to advise.
just extracted model and tbl do add the gunpoint (X your finger Modelview wants to play along) and get it suitable gun...
better tried and failed than never having tried at all
EDIT: ModelView played along -- now anybody got an empty tbm for me?
EDIT2: *gets on making a 0 damage beam just for the main bot*
EDIT3: would re-flagging the mainbot to something else than "fighter" solve the problem too? but that would break the current AI orders of course
-
Giving it something other than fighter or bomber would prevent the bug. It only shows up if the AI is in AIM_STRAFE mode and only fighters and bombers will enter that mode.
I'm not sure what ai class you can stick the maintbot in other than one of those two though.
-
Mainbot with guns (http://www.hard-light.net/forums/index.php/topic,49406.new.html#new)
-
Consider shipping the fixed FRED too. My understanding of the Thunderbolt mission save crash bug is that it's a FRED only bug. So you would not need to replace the 3.6.9 game executable.
-
Okay... just ran some tests with the new mainbot - works fine, CTD did not appear, although there are now some wild mainbots around with overblown self-confidence
-
how about ordering them to play dead ? or maybe to follow waypoints ?
-
Order them to Kamikazi the Vorchans :)
-
For great justice! :D
-
http://www.hard-light.net/forums/index.php/topic,49392.0.html
is he talking about turning the wheel ?
had a crash on boarding party, but it wasn't the debug. Tried to reproduce it, but failed. I am not sure what I did, it was some time after I had took the BP out. Strange.
-
Just played TBP. Great work! :yes: :yes: Having the CTD on 'Slipping the Noose' when the GOD satellite powers up its beam weapons. Attempted it twice and crashed twice at the same spot :mad:
Tried running it in OpenAL and Direct3D.
Any updates on fixes for this prob
Thnx
Azhren
-
how about ordering them to play dead ? or maybe to follow waypoints ?
well for "Slipping The Nose" I guess IPA will think of something...
for the "The Wheel Turns" I'm currently working on some "expermential" bits and pieces to "improve" that mission - and I will think of the mainbots on that occasion for sure
http://www.hard-light.net/forums/index.php/topic,49392.0.html
is he talking about turning the wheel ?
no he is talking about "Midnight on the Firing Line" (the 1st mission of Raider Wars; not the 1st episode of b5 season 1)
since this is a problem which does not replicate I tend to ignore it (but I don't know if IPA or kara will think of takeing care about it)
Just played TBP. Great work! :yes: :yes: Having the CTD on 'Slipping the Noose' when the GOD satellite powers up its beam weapons. Attempted it twice and crashed twice at the same spot :mad:
Azhern,
we are on that problem right now and Karajorma and I have worked out a fix... it has to be perfected and that is what I'll do for sure until the end of the month
-
no he is talking about "Midnight on the Firing Line" (the 1st mission of Raider Wars; not the 1st episode of b5 season 1)
I've never ever seen a crash on that mission. It's always been rock solid.
-
Azhern,
we are on that problem right now and Karajorma and I have worked out a fix... it has to be perfected and that is what I'll do for sure until the end of the month
[/quote]
Thanx for the update. Keep up the great work!
Azhren
-
Chiming in to confirm that the Wheel Turns (Raider m 3) crashes everytime so far here, usually while I'm in the process of immedaitely disabling the narn freighters after they turn hostile. (I've not attempted to first kill their fighters and then disable)
What is puzzling to me that there doesn't seem to be any crash dump generated on this Vista x64 - all I get is this: :confused:
Problem signature
Problem Event Name: APPCRASH
Application Name: fs2_open_3_6_9.exe
Application Version: 1.0.0.1
Application Timestamp: 4598d08b
Fault Module Name: fs2_open_3_6_9.exe
Fault Module Version: 1.0.0.1
Fault Module Timestamp: 4598d08b
Exception Code: c0000005
Exception Offset: 00208b4e
OS Version: 6.0.6000.2.0.0.256.1
Locale ID: 1035
Additional Information 1: 06c0
Additional Information 2: d2739954b1a0cd3e4d79778155d25e53
Additional Information 3: 26e1
Additional Information 4: 5a03a9be6cbda5fa3d40e45e607fa57a
Extra information about the problem
Bucket ID: 471808703
Problem signature
Problem Event Name: APPCRASH
Application Name: fs2_open_3_6_9_debug-INF.exe
Application Version: 1.0.0.1
Application Timestamp: 45a603f7
Fault Module Name: fs2_open_3_6_9_debug-INF.exe
Fault Module Version: 1.0.0.1
Fault Module Timestamp: 45a603f7
Exception Code: c0000005
Exception Offset: 00318bb0
OS Version: 6.0.6000.2.0.0.256.1
Locale ID: 1035
Additional Information 1: 2468
Additional Information 2: e23ed73b76aba7093cce9a0dc93aaf36
Additional Information 3: 5392
Additional Information 4: 9382dc70fd74eef0ccdd0dbcc3400dc5
-
@nrm:
the bug you are experiencing is the same as the one Azhren found - but it impacted at different point in the campaign...
the cause of this bug is known by now (thanks to karajorma) and I have already finished a *very basic* fix which should help getting rid of this bug
therefor a fixed version of Raider Wars and a patch for TBP are underway but they will take their time to complete
-
question for kara. You are working of a fix for some of the issues, especially for raider wars, yes ?
So, why not include a few other things to solve some silly problems:
- why can't the Psi Fury glide, but the normal can ? Hell, it is almost the same fighter !
- why can't the Thunderbolts glide at all ? there are supposed to be even more responsive and agile as the old furies
- up, lelft, right, down thrust seems a bit underpropulsed on all the furies, compared to the other fighters. The fury was designed to to exactly that, so why don't give it a little bit more thrust. Currently, it is just senseless
- aren't the drazi shooting yellow beams instead of red in the show ? maybe a color change of the drazi beam cannon would be appropriate
-
I have no problem with all Star Furies (not all fighters) having glide enabled. We never saw alien ships on the show flying in a newtonian fashion so I would not add glide to those ships on those grounds alone. Up/down/left/right thrust is a different matter. The AI doesn't move in those directions and doesn't know how to handle a player doing it. Unless you want to make the game extremely easy I would leave movement in those directions in it's current toned down state.
These are all extremely minor upgrades though and will just serve to distract from important things, like bug hunting and fixing stability. The drazi beam colour comment is getting into "too much time on hands" territory. If you start pointing out inaccuracies that small this thread is going to get rather large. There are lots. Don't worry about them. Write some missions instead.
-
question for kara. You are working of a fix for some of the issues, especially for raider wars, yes ?
I'm only responsible for dealing with code problems. I'm not actually on the TBP team so nothing else is my responsibility.
-
- why can't the Psi Fury glide, but the normal can ? Hell, it is almost the same fighter !
- why can't the Thunderbolts glide at all ? there are supposed to be even more responsive and agile as the old furies
- up, lelft, right, down thrust seems a bit underpropulsed on all the furies, compared to the other fighters. The fury was designed to to exactly that, so why don't give it a little bit more thrust. Currently, it is just senseless
- aren't the drazi shooting yellow beams instead of red in the show ? maybe a color change of the drazi beam cannon would be appropriate
that's stuff for IPA and me and NOTHING FOR THIS THREAD
Psi Furies and TBolts can glide, problem is that only players do that; don't think we did not discuss the speed of the thrusters one or the other time in the team -- and it is sufficent eblive me
I checked Season 5 -- the Drazi fire red beams on centauri prime
-
[Further spamming of this bug fixing thread by Vidmaster removed by the moderator]
-
is this spam, too ?
- it is possible to fire in the Intro Cutscene of RaiderWars by hitting "fire", you don't see the shots, but you hear the fury firing. You CANNOT in the epiloge. But it's somewhat silly during the attack on Ragesh3
- in PM-PartI, if you press Alt-J when you are NOT in range of the Hermes, you cannot jump out but the Hermes does. You are left behind, the mission doesn't end. (I don't know if that problem occurs in other missions too.)
-
Nah. Both of those sound like legitimate bugs to me. Looking Alpha 1's weapons should deal with the first one quite easily.
-
is this spam, too ?
No those are bugs - as well you know :).
-
of course know, that was some irony
- the alt-j bug seems only to exist on PM-Part I
- question about ride of the valk: you are allowed to fly badgers there. I am not sure, but are Badgers able to fly in an atmosphere ? I don't think so. I guess the player is supposed to fly a Valk ( hinted by the title ;7) but if you have badgers, you won't choose the slugish Badger. Using it, the mission is a lot less difficult
- I am not sure, but I think some of the directives in the last mission are shown to late, the whole destroy Eris' escot stuff (destroy silver and so on). I flew in, took out the sky serpent and I just got the "kill eris"-one. Finally, after the rest of the fighters were busted and the Gorgon had jumped in and had been disabled, some time after it lauched cooper wing, the "destroy silver, (...) gold,... appeared. :confused: :confused: :confused:
-
- question about ride of the valk: you are allowed to fly badgers there. I am not sure, but are Badgers able to fly in an atmosphere ? I don't think so. I guess the player is supposed to fly a Valk ( hinted by the title ;7) but if you have badgers, you won't choose the slugish Badger. Using it, the mission is a lot less difficult :confused:
welll ... rotv is a story for itself - I'm see cool AI glitch here making all wing do anything but attacking (they run away from the moon like there is no morning)
the problem with the Fury design and atmosphere flight is the Furies lack of aero-dynamics and that the engines are designed for space flight (short bursts...) - the shattered star has no atmosphere and only a limited gravity
- I am not sure, but I think some of the directives in the last mission are shown to late, the whole destroy Eris' escot stuff (destroy silver and so on). I flew in, took out the sky serpent and I just got the "kill eris"-one. Finally, after the rest of the fighters were busted and the Gorgon had jumped in and had been disabled, some time after it lauched cooper wing, the "destroy silver, (...) gold,... appeared. :confused: :confused: :confused:
the directives in RW's missions are stories for themselves (too) - will see if there is some fixing possible
-
I never did figure out what the AI is trying to achieve in ROTV? My only guess is that the valks are trying to get out of the landscape's bounding box for collision avoidance purposes, and I can't honestly believe that. The AI has never seemed that bothered about collision avoidance. So I really don't know. I went though the campaign trying to sort out the directives and in fact objectives to make them more sensible... but I think I ran out of time before getting to Loose Ends :). By all means fix this stuff. You can stop alpha 1 firing in the cutscenes using the lock primaries sexp. I will give you a hand if you like, just drop me a line. I don't think there's much point spending too much time on RW though. Drums of War is a better campaign.
-
and more stuff, again posted by myself :nervous::
1) no problems with the surface in my WIP campaign. The fighters attack, evade and do all the stuff they should do. And they like to run straight into the moon surface while evading. Sure with that collision thing ?
2) I like RW. Story is cool, has some but not too much big battles and it's almost fully voice-acted in acceptable quality. Even included some homages to it in my WIP campaign. (But I like DoW too, of course)
3) in "storm the castle", the second goal just reads as "mission goal text"
4) in "profit & loss", the centauri ani is shown for the first escape pod message. Is this intended ?
-
1) no problems with the surface in my WIP campaign. The fighters attack, evade and do all the stuff they should do. And they like to run straight into the moon surface while evading. Sure with that collision thing ?
Maybe it's a fighter vs bomber thing. Have you tried Badgers in your mission? How do they behave? Anyway it's a game engine issue so there's no way it can be fixed in RW.
in "profit & loss", the centauri ani is shown for the first escape pod message. Is this intended ?
Yes. Although I would have preferred a female ani. :nervous:
-
These will be the last changes I will do to RW before I re-pack it and re-re-release it along with the tbl-changes I made
RW3 - The Wheel Turns
- "disarming" the Mainbots
RW09 - Slipping the Noose
- "disarming" the Mainbots
- ajusting the internal orders of the Serenity Mainbot (EA Mainbot 3)
RW10 - Pre-emptive Measures, part 1
- ajusting Hermes departure cue
RW16 - Loose Ends
- ajunsting some directives
I guess they will come out on Sunday 23rd or Monday 24th
-
Are there any other reproducible and unexplained crashes etc you need me to look at?
-
Include the fighter bayed Shadow Carrier if it's done.
-
Are there any other reproducible and unexplained crashes etc you need me to look at?
No
Include the fighter bayed Shadow Carrier if it's done.
I'll ask whitelight for it
BUT that will cause some hold up and I'll be gone by Monday 1st
-
BUT that will cause some hold up and I'll be gone by Monday 1st
You're in the same position I was in :). Don't worry about the updated pof then. Campaigns can provide that if needed. Get Hip to build you a nice installer and you're done. Thanks very much to you and Kara. You're both great.
-
all done...
I can ship the patch to the core files anytime you want and a missions-only-patch for RW as well
now I've contacted hip about the installer - and in the meantime I'll do a new complete RW package to make the patch obsolate on a long view
-
The most important thing with this release is to keep the TBP directory clean. That means:
* Don't add extra .vp files (no a-RW-patch.vp or a-Core-3.4-patch.vp)
* Don't add loose in data directories (maintbot.pof needs to go in the core vp and not sit in data/models)
For this reason letting Hip build a new complete install will probably be easier than making a patch. At this late stage in the game it's better to have a single TBP 3.5 Final download with instructions to completely delete and uninstall any previous versions before installation.
Just make sure this version is spot on if you can ;).
-
I modified the debug build to not abort on failures (like the standard build).
It crashed when G.O.D opened fire, the last few messages were:
WARNING: "Too many ship classes before 'TS Capital'; maximum is 130, so only the first 130 will be used" at ship/ship.cpp:3036
WARNING: "Trying to add a bitmap that does not exist in stars.tbl!" at starfield/starfield.cpp:3109
WARNING: "Failed to add starfield bitmap 'neb_grene4' to the mission!" at starfield/starfield.cpp:3454
WARNING: "EFF: Unable to load all frames for 'narndebris01-glow.eff', stopping at #53" at bmpman/bmpman.cpp:1810
WARNING: "EFF: Unable to load all frames for 'ea-debris01-glow.eff', stopping at #53" at bmpman/bmpman.cpp:1810
WARNING: "EFF: Unable to load all frames for 'narndebris01-glow.eff', stopping at #53" at bmpman/bmpman.cpp:1810
WARNING: "Ship is not a support ship!" at parse/sexp.cpp:13427
Segmentation fault (core dumped)
I just started looking at the code today, so I don't know much about it.
It looks like there's a ship used, which wasn't loaded.
Maybe this is because of the ship class limit? If so, the mission should work fine with an Inferno build (I haven't tested, because I don't want to restart the campaign again).
One time I disabled some subsystems of G.O.D. and the mission ended fine, too.
-
The answer to your problem is in this very thread. But I'll save you the bother. Go here:
http://www.hard-light.net/forums/index.php/topic,49406