Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: chief1983 on August 29, 2012, 11:26:03 am
-
RC9 here. (http://www.hard-light.net/forums/index.php?topic=82558.0) Go there.
(http://scp.indiegames.us/img/irrelephant.jpg)
Should be the last one. I present RC8, with improved sound and no head.ani stuttering!
Previous 3.6.14 RC7 Release Thread (http://www.hard-light.net/forums/index.php?topic=81558.0)
Important!!
As always, you need OpenAL installed. Linux and OS X come with it but Windows users will need to get Creative's OpenAL installer (http://connect.creativelabs.com/openal/Downloads/oalinst.zip).
Important!!
Also, since the internal code linking for TrackIR was revised, an external DLL is now required for FSO to use TrackIR functions.
The following DLL is simply unpacked in to you main FreeSpace2 root dir.
TrackIR is only supported on Windows.
TrackIR SCP DLL (http://www.mediafire.com/download.php?ihzkihqj2ky) (Mirror (http://swc.fs2downloads.com/builds/scptrackir.zip)) (Mirror (http://scp.fsmods.net/builds/scptrackir.zip)) (Mirror (http://scp.indiegames.us/builds/scptrackir.zip))
Launchers, if you don't have one already:
All platforms: wxLauncher (http://www.hard-light.net/forums/index.php?topic=67950.0) (ongoing project for a unified launcher)
Windows: Launcher 5.5g (http://swc.fs2downloads.com/files/Launcher55g.zip) (Mirror (http://scp.fsmods.net/builds/Launcher55g.zip)) (Mirror (http://scp.indiegames.us/builds/Launcher55g.zip)) (Mirror (http://www.mediafire.com/?wdvzn7hhhzh418m))
OS X: Soulstorm's OS X Launcher 3.0 (http://www.hard-light.net/forums/index.php/topic,51391.0.html)
Linux: YAL (http://www.hard-light.net/forums/index.php/topic,53206.0.html) or by hand (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Graphics_Settings) or whatever you can figure out.
Known issues:
- The now-standard Inferno builds have trouble converting retail pilots. You might experience crashes. Post logs.
- See the list of Fix for next release (http://scp.indiegames.us/mantis/search.php?project_id=1&status_id%5B%5D=10&status_id%5B%5D=20&status_id%5B%5D=30&status_id%5B%5D=40&status_id%5B%5D=50&priority_id%5B%5D=40&priority_id%5B%5D=50&priority_id%5B%5D=60&sticky_issues=on&sortby=last_updated&dir=DESC&per_page=200&hide_status_id=-2) bugs - mark a bug as an elevated priority (high, urgent, immediate) to get it included in that filter.
- Here is the filter for Target 3.6.14 (http://scp.indiegames.us/mantis/search.php?project_id=1&status_id%5B%5D=10&status_id%5B%5D=20&status_id%5B%5D=30&status_id%5B%5D=40&status_id%5B%5D=50&sticky_issues=on&target_version=3.6.14&sortby=last_updated&dir=DESC&hide_status_id=-2) bugs.
Shaders
In order to leverage changes in the shader code since 3.6.12, these are to be used to over-ride the MediaVPs shaders (place in mediavps_3612/data/effects) or in use for any mods.
Includes the Animated/Cloakmap shaders as well as optimized pixel lighting fragment shaders.
Shaders_for_3614_August_08th.zip (http://swc.fs2downloads.com/builds/Shaders_for_3614_August_08th.zip) (Mirror (http://scp.fsmods.net/builds/Shaders_for_3614_August_08th.zip)) (Mirror (http://scp.indiegames.us/builds/Shaders_for_3614_August_08th.zip)) (Mirror (http://blueplanet.fsmods.net/E/stuff/Shaders_for_3614_August_08th.zip))
MD5: 8bd0d689fd16c681a7710400352b8f68
(http://scp.indiegames.us/img/windows-icon.png) WINDOWS Builds
Inferno Builds
If you don't know which one to get, get the third one (no SSE). If you don't know what SSE means, read this: http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
You can use freely available tools like CPU-Z (http://www.cpuid.com/softwares/cpu-z.html) to check which SSE capabilities your CPU has.
fs2_open_3_6_14_RC8.zip (http://swc.fs2downloads.com/builds/WIN/fs2_open_3_6_14_RC8.zip) (Mirror (http://scp.fsmods.net/builds/WIN/fs2_open_3_6_14_RC8.zip)) (Mirror (http://scp.indiegames.us/builds/WIN/fs2_open_3_6_14_RC8.zip))
This one is based on the SSE2 Optimizations from the MSVC Compiler.
MD5: a26b19d0a11b09b5fcd37ba5c1cc7156
fs2_open_3_6_14_RC8_SSE.zip (http://swc.fs2downloads.com/builds/WIN/fs2_open_3_6_14_RC8_SSE.zip) (Mirror (http://scp.fsmods.net/builds/WIN/fs2_open_3_6_14_RC8_SSE.zip)) (Mirror (http://scp.indiegames.us/builds/WIN/fs2_open_3_6_14_RC8_SSE.zip))
This one is based on the SSE Optimizations from the MSVC Compiler.
MD5: c0b9c5b8b0ae0f3b3abdccb25fe715a1
fs2_open_3_6_14_RC8_NO-SSE.zip (http://swc.fs2downloads.com/builds/WIN/fs2_open_3_6_14_RC8_NO-SSE.zip) (Mirror (http://scp.fsmods.net/builds/WIN/fs2_open_3_6_14_RC8_NO-SSE.zip)) (Mirror (http://scp.indiegames.us/builds/WIN/fs2_open_3_6_14_RC8_NO-SSE.zip))
MD5: a086519764e9d21b4bc9c3c9bc00b982
What are those SSE and SSE2 builds I keep seeing everywhere?
Your answer is in this topic. (http://www.hard-light.net/forums/index.php?topic=65628.0)
(http://scp.indiegames.us/img/mac-icon.png) OS X Builds
Inferno Build
FS2_Open-3.6.14_RC8.dmg (http://swc.fs2downloads.com/builds/OSX/FS2_Open-3.6.14_RC8.dmg) (Mirror (http://scp.fsmods.net/builds/OSX/FS2_Open-3.6.14_RC8.dmg)) (Mirror (http://scp.indiegames.us/builds/OSX/FS2_Open-3.6.14_RC8.dmg))
MD5: a8fafca4aef2ffa0966f4285a8a3ecf6
(http://scp.indiegames.us/img/linux-icon.png) LINUX Builds
Inferno Build
fs2_open_3.6.14_RC8.tar.bz2 (http://swc.fs2downloads.com/builds/LINUX/fs2_open_3.6.14_RC8.tar.bz2) (Mirror (http://scp.fsmods.net/builds/LINUX/fs2_open_3.6.14_RC8.tar.bz2)) (Mirror (http://scp.indiegames.us/builds/LINUX/fs2_open_3.6.14_RC8.tar.bz2))
MD5: 770db76b3db53b2e4c7512b888f3fcfc
Source Code Export
fs2_open_3_6_14_RC8_src.tgz (http://swc.fs2downloads.com/builds/fs2_open_3_6_14_RC8_src.tgz) (Mirror (http://scp.fsmods.net/builds/fs2_open_3_6_14_RC8_src.tgz)) (Mirror (http://scp.indiegames.us/builds/fs2_open_3_6_14_RC8_src.tgz))
MD5: 3b22b7d03d1637c4f4c93819c87f12a1
Changelog since the last RC:
( Additionally, see here: 3.6.13 Changelog (since 3.6.12) (http://www.hard-light.net/forums/index.php?topic=69362.0) )
------------------------------------------------------------------------
r9078 | The_E | 2012-07-31 12:10:22 -0500 (Tue, 31 Jul 2012) | 2 lines
Backport of trunk revision 9077: Remove a define from the builtin shader that was causing clipping issues now that AMD has fixed their driver's behaviour
------------------------------------------------------------------------
r9135 | chief1983 | 2012-08-22 12:04:19 -0500 (Wed, 22 Aug 2012) | 1 line
Backport: Trunk r9080/9081; Prevent garbage collection of texture handles which still have a non-zero load count.
------------------------------------------------------------------------
r9136 | chief1983 | 2012-08-22 13:07:29 -0500 (Wed, 22 Aug 2012) | 1 line
Backport: Trunk r9095; fix for Mantis #2694: homing breaks when free_flight_time is 0; also, correctly set default free_flight_time to retail value of 0.5 second
------------------------------------------------------------------------
r9137 | The_E | 2012-08-22 14:11:24 -0500 (Wed, 22 Aug 2012) | 2 lines
Backport trunk 9109/9112/9118: More efficient handling of ani ressources, fixes ani stuttering. Also allows EFF files as head anis.
------------------------------------------------------------------------
r9138 | chief1983 | 2012-08-22 14:59:21 -0500 (Wed, 22 Aug 2012) | 1 line
Backport: The remaining changes in r9113, since most had been committed in 9054, and the rest is also known as mantis_2266_take3_followup.patch from Mantis 2266.
------------------------------------------------------------------------
r9139 | chief1983 | 2012-08-22 15:00:27 -0500 (Wed, 22 Aug 2012) | 1 line
Backport: Trunk r9127; Adding nameplate textures to the list of texture names that trigger the transparency renderer.
------------------------------------------------------------------------
r9140 | chief1983 | 2012-08-22 15:01:40 -0500 (Wed, 22 Aug 2012) | 1 line
Backport: Trunk r9130; variable tokens can be quite a bit longer than standard tokens due to their unusual format; handle this properly (fixes Mantis #2670)
------------------------------------------------------------------------
r9146 | chief1983 | 2012-08-27 17:46:00 -0500 (Mon, 27 Aug 2012) | 1 line
Revert backport of r8848.
------------------------------------------------------------------------
r9147 | chief1983 | 2012-08-28 10:54:41 -0500 (Tue, 28 Aug 2012) | 1 line
Backport: Trunk r9143; make red-alert not dependent on whether the HUD is visible or not (fixes Mantis #2683)
------------------------------------------------------------------------
r9148 | chief1983 | 2012-08-28 11:14:14 -0500 (Tue, 28 Aug 2012) | 1 line
RC8 BUILD STAGE COMMIT: Sets Revision and Version properties to this commit version.
------------------------------------------------------------------------
-
bout time :D
theres probibly been enough new features implemented since the rc started to go ahead and start the 3.6.16 rc phase :D
-
We'll be merging the new pilot code, and probably doing the first second digit version bump in over half a decade :P
-
So...3.7 soon? :eek:
-
Keep dreamin'.
-
Seeing as how 3.6.14 took the better part of a year just for RC... "soon" is a relative term at this point.
EDIT: For further perspective...
3.6.12 Final - August 04, 2010
3.6.14 RC1 - November 02, 2011
3.6.14 Final - Pending
3.7 Final - Soon (tm)
-
So uh, did the armor.tbl stuff ever make it into 3.6.14?
Can't be assed to trace all of the backports.
Kind of important because if it is in I can start telling people to use 3.6.14 instead of grabbing random not!nightlies.
If not then bah, I'll just keep compiling nightlies for myself...
-
it made it into trunk, but im not sure if its in the rc builds or not. it may have been because it also resolved a couple mantis issues.
-
What was the Trunk commit revision? I'll search the RC log.
-
FINALLY! No stuttering! I held off on updating until now because I knew if I ran into that I'd never be able to play. Just gotta reorganize the stuff in my Freespace folder.
-
it made it into trunk, but im not sure if its in the rc builds or not. it may have been because it also resolved a couple mantis issues.
I know it's in trunk which is why I say nightlies instead of custom builds XD
But pretty much this is why I'm asking - It did resolve mantis'd bugs, but also added a whole lot of features while at it (which is awesome) but may cause some concerns from an RC standpoint.
What was the Trunk commit revision? I'll search the RC log.
r8629 AFAIK.
-
Looks like it's not in 3.6.14. Doubtful it'd be added at this point too.
-
'aight. No worries then, it'll get into a stable build eventually. :P
-
Woop woop!
-
What was the Trunk commit revision? I'll search the RC log.
r8629
http://www.hard-light.net/forums/index.php?topic=78277.msg1595848#msg1595848
i did find an old post of me asking if armor made it in to rc1, but there was never any response to it.
http://www.hard-light.net/forums/index.php?topic=78886.msg1560969#msg1560969
still using all the powers of search fu to find it. i remember seing it in a change log somewhere.
*edit*
i searched all the rc changelogs from 2-8 for the words nuke or armor and there was no reference to my armor patch. rc1 didnt seem to have a changelog on the forum.
probibly the best way to confirm it is to take an armor table and try using the +Difficulty Scale Type: tag, as that was the primary bugfix/feature of the whole thing (not to mention accidental turing completeness :D).
*edit again*
k i used my nukemod armor table, which doesnt use any of the new features yet, and added the +Difficulty Scale Type: flag and got an error, so i guess this is only in trunk and not in the rc builds. im gonna go ahead and mark those features as 3.6.15 (even though they were available in some of the later 3.6.13 nightlies) in the wiki, so as to avoid confusion with modders.
-
8629 isn't anywhere on 3.6.14's commit log (http://svn.icculus.org/fs2open/branches/fs2_open_3_6_14/?date=all&view=query) so I'm fair certain it wasn't backported.
-
yea i wouldnt rush to backport it at this point in the rc cycle. but it does fix at least two mantis bugs.
-
k i fixed the wiki
http://www.hard-light.net/wiki/index.php/Armor.tbl
so it should help ease the support issues with regards to the new armor features.
-
Something weird is going on with collisions. In Apocalypse, the Mentu and Deimos can be flown through by the player, and I reloaded the mission to make sure it wasn't a one-off. I tried to isolate to ship class, but the Deimos in Into the Maelstrom was quite solid. I haven't yet found the same issue in other missions. Reproducible with or without MediaVPs.
EDIT: Hmm... reproducible as far back as RC1, but not 3.6.12.
Can anyone else reproduce?
-
Facebook Wall spammed. Got near-immediate responses from redsniper and Galemp. :wtf:
-
Going to try this build, hopefully it works...
-
double ets here, do I need to do something to make it go away, or is it a code error?
-
double ets here, do I need to do something to make it go away, or is it a code error?
Data problem. See the previous thread (http://www.hard-light.net/forums/index.php?topic=81558.msg1625974;topicseen#msg1625974).
Chief, I think we need to put that (or a summary) into the OP because this is just going to keep coming up.
-
Was there some recommended hud_gauge.tbl that many users downloaded, which is now obsoleted?
-
I really hate that "fix"...
The HUD issue is due to outdated hud_gauges.tbls (likely in the MediaVPs 3.6.12). We'll need to put up a new table I suppose.
-
Wow, nice work guys. Took it for a spin and everything works well. I only ran into one issue and it turns out it was video card related.
When I first ran the new RC with vsync turned on, my frame rates were choppy (screen stuttering) during general play - no animations or anything else going on at the time. I turned on the FPS display and saw that framerates would not keep steady - the framerates quickly vacillated between 30fps and 75fps causing jumpiness and stuttering while turning (turning made it easy to see against the background star field). If I turned off vsync then the frame rates would hold steady at 120FPS and I would have smooth play.
On a whim I decided to try some of my other games (Descent 1 & 2 Rebirth) and strangely, they were experiencing the same FPS choppiness with vsync turned on. I checked the video card settings, especially the one controlling vsync for programs and the setting was correct (application controlled) and no other settings seemed to make a difference.
So I went to AMD's website and downloaded the latest drivers for my ATI FirePro 3D v4800 card and installed them and, surprise, now everything is smooth as glass again with vsync turned on (in all of my games). Very oddly coincidental that it started happening when I switched out the Freespace EXE's (I'm not at all blaming the FS exe - the timing was just surprising).
So remember to update your video card drivers too folks, just to make sure all of your bases are covered. :yes:
-
Malloc Failed!
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
get this error on the mission after defeating The Roman's Blunder
-
God damnit people when are you going to make 3.7 :P
-
I really hate that "fix"...
The HUD issue is due to outdated hud_gauges.tbls (likely in the MediaVPs 3.6.12). We'll need to put up a new table I suppose.
I don't believe the MediaVPs 3.6.12 include a hud_gauges.tbl. I think people have downloaded their own tbl from one of the many threads about it (e.g. ant7 release thread).
Updated tables for mediavps / blueplanet2 / fsport are attached to this mantis issue (http://scp.indiegames.us/mantis/view.php?id=2672) (the mediavps table didn't include 4:3 res settings, I've added the settings from here (http://www.hard-light.net/forums/index.php?topic=69858.msg1382506#msg1382506), updated for the change, and given it a quick test)
-
God damnit people when are you going to make 3.7 :P
Galemp mentioned on Facebook that we should be at 4.x by now. I think he was joking.
-
This build works fine on my end, but I get the impression that 'R' still doesn't target the nearest attacker. Sometimes it does target someone that is attacking me, but sometimes it just doesn't change target, despite the warning gauge flashing.
-
The modifications to targeting keys were reverted to retail behavior because there are still some discussions that need to take place.
-
Malloc Failed!
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
fs2_open_3_6_14_RC8.exe! <no symbol>
get this error on the mission after defeating The Roman's Blunder
Can you try to reproduce this crash when using a Debug build? It will give us more info.
-
It won't happen in the debug, It just crashes with no warning :confused:
-
It won't happen in the debug, It just crashes with no warning :confused:
Does it immediately CTD when you open up the debug build, or does it crash as soon as you reach the mainhall?
-
crashes when i either A.) Manage to get the mission up then restart, or B.) crashes while the mission is loading
-
In that case the debug log is active and will hopefully be recording that is going off
-
The modifications to targeting keys were reverted to retail behavior because there are still some discussions that need to take place.
Actually, there were no modifications made to the R key in .14, there was an inadvertent commit that was reverted but it wasn't the fix for 2659. That was just decided not to be backported at all because it was a retail bug and R is rarely used as it is. The change to fix R and make it cycle will probably be left in trunk, but no changes are being made in 3.6.14.
-
Hey guys. I just got found a bug that should be simple to fix. When you start the game with volume on, go to the options screen from the mainhall, and then switch volume off, the music will keep playing until you attempt to start a mission.
-
because it was a retail bug and R is rarely used as it is.
I use it extensively. :nervous:
-
because it was a retail bug and R is rarely used as it is.
I use it extensively. :nervous:
R as in target the nearest little **** that is trying to rip my engines to shreds? I use it fairly often, usually when one of the AI manage to annoy me enough, which is fairly often....
-
He means using R to cycle through the nearest attacking targets, not to simply target nearest attacker. :p
-
Currently, it does the same thing as H, without cycling.
-
I thought H was supposed to target nearest enemy while R targets nearest ship attacking the player
-
Yeah, except there's a bug that's been in since retail apparently, where it doesn't.
-
I never had issues with R targeting the guy shooting at me....
-
Probably also happened to be the closest hostile to you.
-
Probably also happened to be the closest hostile to you.
depends if you hve just done a run on a warship or freighter/transport
-
Something weird is going on with collisions. In Apocalypse, the Mentu and Deimos can be flown through by the player, and I reloaded the mission to make sure it wasn't a one-off. I tried to isolate to ship class, but the Deimos in Into the Maelstrom was quite solid. I haven't yet found the same issue in other missions. Reproducible with or without MediaVPs.
EDIT: Hmm... reproducible as far back as RC1, but not 3.6.12.
Can anyone else reproduce?
I can't reproduce this with retail assets on RC8, on OS X. Tried the Deimos and Mentu.
-
I haven't tried colliding with ships, but I have also noticed that collisions seem buggy. See this thread (http://www.hard-light.net/forums/index.php?topic=81717.0).
It seems to happen after I've played several missions. I could be following a ship and blasting it full of lasers and missiles, but nothing registers, not even a shield hit. However, exiting FSO and restarting seems to make collisions work again.
It occurs in both the 3.6.14 branch and trunk. From its behavior, I'm guessing it's either a memory leak or a cache problem.
-
K I'm definitely getting some sort of error here and not a random fluke:
Post-RC6 builds (going to check RC7 in a bit) corrupt the mainhall animations, and sometimes leads to a CTD.
-
K I'm definitely getting some sort of error here and not a random fluke:
Post-RC6 builds (going to check RC7 in a bit) corrupt the mainhall animations, and sometimes leads to a CTD.
First: why are you reporting this without a log?
Second: I've seen no such mainhall corruption.
-
I don't think my problem is related to yours Goober. It's very reproducible. I've tried rebooting my computer and clearing the cache. I don't have another pilot file to try that's completed the campaign, but I'd be happy to try someone else's. I tried colliding with everything in the first three missions of the campaign, but so far they all collide. I'm not sure what else to do to isolate this.
It isn't that the ships are set no-collide or anything, weapons fire hits just fine, I can just fly through them. I can also fly through my wingmen in that mission.
The attached log is from RC7 because I forgot to download the debug build of RC8. I don't see anything, but perhaps someone else will.
[attachment removed and sold on the black market]
-
Alan, I haven't checked RC7 or 8, but I've checked builds from 7737 to RC6, and 7737 is the last build without collision issues[which have been adressed in new collision code[which is having its own issues]]. You might want to confirm that.
-
K I'm definitely getting some sort of error here and not a random fluke:
Post-RC6 builds (going to check RC7 in a bit) corrupt the mainhall animations, and sometimes leads to a CTD.
First: why are you reporting this without a log?
Second: I've seen no such mainhall corruption.
Here's three!
Link to Mantis Ticket. (http://scp.indiegames.us/mantis/view.php?id=2709)
[attachment removed and sold on the black market]
-
Ships jumping in and out are visible behind the vortex for me. Is anyone else getting this? http://pastebin.com/tqqpP5Kn
-
Hey, i'm getting the malloc error on diaspora now
Malloc Failed!
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_Diaspora_R1.exe! <no symbol>
fs2_open_Diaspora_R1.exe! <no symbol>
OPENGL32.dll! wglSwapBuffers + 155 bytes
fs2_open_Diaspora_R1.exe! <no symbol>
fs2_open_Diaspora_R1.exe! <no symbol>
fs2_open_Diaspora_R1.exe! <no symbol>
fs2_open_Diaspora_R1.exe! <no symbol>
-
Well, it doesn't use RC8, but we had already been looking into if this is a common issue that was in trunk and backported. Some other Diaspora users have been reporting crashes too, but now that you've confirmed that you got a Malloc error we might be barking up the right tree after all.
-
Alan, I haven't checked RC7 or 8, but I've checked builds from 7737 to RC6, and 7737 is the last build without collision issues[which have been adressed in new collision code[which is having its own issues]]. You might want to confirm that.
Good call. I can reproduce the issue on 7761, but not on 7737.
So, best guess is, this doesn't do what we think it does:
// Valathil - Reinitialize collision checks
obj_remove_pairs(objp);
obj_add_pairs(objp->instance);
-
Slick catch there if that's the problem. I can't make a Windows test build based on .14 at the moment, that removes those lines, but maybe someone else can. Or Valathil might just want to take a closer look at his fix.
-
I would like to see more reasoning than "best guess" first. No offense, but cryptic hints like that aren't exactly helpful.
-
Issue takes place on every build 7761-RC8 and doesn't take place on 7737 and earlier. It would mean it's one of the commits between 7737 and 7761, right?
-
I would like to see more reasoning than "best guess" first. No offense, but cryptic hints like that aren't exactly helpful.
???
Sounds like more than a guess, he narrowed down a range of commits, and found the one in that range that best fits the problem. Short of understanding that code (something I'm not too good at) making a test build without that change would at least show whether or not it's the cause then. But I'm sure Valathil or someone will be weighing in on that before too long with a little more authority on that code.
-
I misunderstood the post, sorry. Brain not work well while sleep-deprived.
-
So it looks like now command keys issue orders in addition to their bound functions, which is a little bit annoying because I have 7-0 bound to look left/up/back/right. Is this an intentional feature? Is there any way to toggle it back to the way it was before?
-
Sorry The E, I hadn't had time to make test builds. However, it looks like build 9165 doesn't have the collision problem, yet it does have Valathil's collision reinit.
I'm working on seeing if I can narrow this down a bit better.
One other odd thing I noticed: in HEAD and 3.6.14 one of my wingmen starts Apocalypse directly in front of me so that I can ram him if I hit the afterburners, but in 3.6.12 that's not the case. Would this be worth tracking down as well? I never got retail to work on this Windows 7 box so I don't have an easy way to compare.
-
Damn, it does? Kobrar had tried some tests last night, including reverting 7750, and was fairly certain that had been causing at least one collision issue I think.
-
I tested 9100, because it has only the old collison system which RC8 has. 9165 has the new one, which, according to what Swifty said on IRC[not sure though], might not even use code from 7750. You would have to swich to old collision system or ask Swifty.
Here are the builds I used.
http://www.mediafire.com/?y00z5y4x300ny6v (http://www.mediafire.com/?y00z5y4x300ny6v)
-
I built 7768 and experienced the collision problem.
I removed Valathil's collision reinit from 7768 and was able to collide with the Mentu.
-
I googled it, and it seems a malloc error means you ran out of memory
-
I googled it, and it seems a malloc error means you ran out of memory
Theoretically, yes. Practically, modern systems will almost never fail due to that (virtual memory being available and all that), unless someone does something stupid like trying to allocate MAXINT bytes of memory.
-
Theoretically, yes. Practically, modern systems will almost never fail due to that (virtual memory being available and all that), unless someone does something stupid like trying to allocate MAXINT bytes of memory.
Any way I can fix it?
-
You would need to take a look at the source code.
-
The reason why commit 7750 derped collision detection whenever change-ship-type was used was because of these lines:
obj_remove_pairs(objp);
obj_add_pairs(objp->instance);
It's supposed to be:
obj_remove_pairs(objp);
obj_add_pairs(OBJ_INDEX(objp));
objp->instance is the index of the ship/weapon/debris etc. What the collision detection system is expecting is an object index. That's obtained through OBJ_INDEX(objp).
Fixed with commit 9234.
-
Bumping a sticky to ask what the status of this is
-
RC9 is ready for release, we're just waiting for it to be uploaded / hosted (I think). And with luck, RC9 will be final *fingers crossed*
-
cool, fingers crossed indeed