Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: QuantumDelta on August 19, 2009, 10:54:47 am
-
It's an observation and probably one that's going to get me flamed but that's happened before :P
There are a lot of code optimisations that 'lets the truer intent of the code' come out.
The thing is, the 'truer intent of the code' (bombs blowing up pilots immediately when shot down, rather than doing virtually no damage but shaking up the screen loads, beams doing raw damage to subsystems if they happen to impact the fighter/bomber on that hull position, superior sub system damage from collisions/weapons because of better coding allowing for more precise impact calculations).
These have an effect on gameplay, and they add up (as well as the still not-locked down AI skill improvements).
At the same time (I realise some of these aren't code related) things like subsystem 'hardpoints' on ships haven't been 'fixed' (read; Sathanus/Demon weapon systems, Hecate engine systems, etc).
Missile Physics /tracking hasn't been upgraded(fixed) to work with the upgraded(fixed) AI.
Friendly AI hasn't been improved equally to Hostile AI (presumably this is because of sexps).
Beams not kicking people around as much as they did (anti fighter beams had quite a significant kinetic kick that forced your fighter to turn when it was hit).
Now the bit that will likely need me needing some protective gear;
The former is shrugged off as "This is what V wanted it to really be like." and that may be true, but consider;
A) It doesn't hold true for all of the user made missions.
B) It is reasonable to assume V knew about the limitations due to the engine mechanics when they designed the missions (and although I don't have unblinding faith in V) it's reasonable to assume that they tweaked the missions to be higher difficulty because some of these pieces of code didn't work properly.
The latter is shrugged off as either someone-elses job (which, sure is fine but you see it adds to the problem), and/or "it's how it was in retail, why change it?"
Hense the philosophical problem.
SCP has a 'don't change vanilla gameplay without a flag' approach, which is great, but little bits of change are seeping in and being tolerated, similarly to the discussion in the Cain remodel threat, 2 turrets in place of 1, actually might very well break some of the older (FS1 Port and FS2 Multi especially) missions because the model is normally used to engage enemy caps, and as such it prefers to show it's underside (read; sides on the turrets) to the opposing capital ships.
It may not seem like much in a world of beamfree helios bombers but in missions with subachs and tornados and no beams it's likely to have a noticeable (perhaps not critical) difference.
Again, little bits of changes seeping in.
Unfortunately I don't know enough to fix it, and from some of the lookins I've had a couple people do for me (Chief/E/cc and a few others) some of them might not be fixable, but stuff I hope can be done to mitigate the changes if they're not directly fixable.
Uhh, discuss I guess? :P
-
V has had major deadline issues from what can be determined from the code. Basically game had to be released even though developers know it had issues. So they covered things up both in code and data.
-
I suggest you read up on the AI Profiles table. There's lots of options in there that can be switched on or off to give you a more 'authentic' FS2 Retail (or, for that matter, FS1 Retail) feel, or you can toggle on some of the things that the SCP has enhanced.
-
His point is there are things that are changed but not tied to a flag being enabled. The defaults for anything in that table should be the retail behavior. If it's not, then that's wrong.
-
There are a lot of code optimisations that 'lets the truer intent of the code' come out.
Really? As you don't have access to the SCP internal, nor are you a regular visor to the #scp IRC channel, nor have you released any of your own builds, I would be very interested to know how you managed to acquire this stunning insight into the motivation of SCP members.
The thing is, the 'truer intent of the code' (bombs blowing up pilots immediately when shot down, rather than doing virtually no damage but shaking up the screen loads, beams doing raw damage to subsystems if they happen to impact the fighter/bomber on that hull position, superior sub system damage from collisions/weapons because of better coding allowing for more precise impact calculations).
Such cutting-edge features! You must have access to a secret experimental build that I know nothing about. Taylor and I especially would love to know where you found a build with an updated and optimized collision model.
Missile Physics /tracking hasn't been upgraded(fixed) to work with the upgraded(fixed) AI.
Friendly AI hasn't been improved equally to Hostile AI (presumably this is because of sexps).
Hmm, what upgraded AI? And what sort of sexps are these that apply to the entire engine as opposed to varying from mission to mission?
The former is shrugged off as "This is what V wanted it to really be like."
[citation needed]
little bits of change are seeping in and being tolerated, similarly to the discussion in the Cain remodel threat, 2 turrets in place of 1, actually might very well break some of the older (FS1 Port and FS2 Multi especially) missions
Where did the SCP "threaten" to remodel the Cain? The SCP's responsibility is code, not models. You may be confusing us with the FreeSpace Upgrade Project.
You're ranting in a way that makes no sense; you're ascribing features and enhancements to the FreeSpace engine which haven't even been implemented. It's like you're applying conspiracy theory to the SCP. :wtf:
Now, I agree that things have accidentally been changed over the years, but we make every effort to catch those changes as soon as they happen and fix them. Rule #1 in the SCP is, and has been since the beginning, "Maintain compatibility with retail". That means that playing FSO with no mods should be balanced the same as playing retail FS2 with no mods.
If little changes are creeping in here and there we definitely want to know about them, but we have been paying attention to this all along. I don't know where you get the idea that we haven't. It's like going up to Apple and demanding why they haven't yet released this iPod that you're hearing so much hype about.
Only one of your claims makes any sense to me, and that's the "fighter beam whack" change which is a known issue. I'd really like to see side-by-side comparison of the other issues, if they are as noticeable as you say.
-
Really? As you don't have access to the SCP internal, nor are you a regular visor to the #scp IRC channel, nor have you released any of your own builds, I would be very interested to know how you managed to acquire this stunning insight into the motivation of SCP members.
This is how it's been explained to me in #hard-light when I've quizzed some of the people who /are/ releasing recent builds.
It wasn't meant in a malicious way, nor did I get the impression that it was meant "it's changed, that's the way it was meant to be (for vanilla)."
Such cutting-edge features! You must have access to a secret experimental build that I know nothing about. Taylor and I especially would love to know where you found a build with an updated and optimized collision model.
In Vanilla if you ram something it was uncommonly possible to lose an entire subsystem because of collision damage.
On SCP if you ram something you regularly lose an entire subsystem, or the majority of a subsystem because of collision damage.
Subsystems take seriously increased damage from direct beam impacts and weapon blasts as well -> impact physics.
I don't care if you say you've changed the code related to these issues directly or not, reality is, it's changed.
Hmm, what upgraded AI? And what sort of sexps are these that apply to the entire engine as opposed to varying from mission to mission?
We've been having trouble locking it down, I say we, I mean anyone who's cottoned on/tested what I've been talking about.
AI in several of the validated vanilla (1.20), community missions (pack 3) exceed the maximum potential for AI from vanilla.
Their ability to shred a human fighter has increased very noticeably on insane on STV, TDiC, RB, and others, these missions have not changed in the 7 year gap, nor have they changed in the 2 second gap between different Execs.
[citation needed]
V has had major deadline issues from what can be determined from the code. Basically game had to be released even though developers know it had issues. So they covered things up both in code and data.
There's a sort of one in the thread?
But yea that expression was thrown around a couple times during the investigation into the code.
Where did the SCP "threaten" to remodel the Cain? The SCP's responsibility is code, not models. You may be confusing us with the FreeSpace Upgrade Project.
s/threat/thread, FSU or SCP if it gets in the VPs it's a part of the same problem (it doesn't seem like a movement in turrets will likely be in the VPs - but it was simply an example).
You're ranting in a way that makes no sense; you're ascribing features and enhancements to the FreeSpace engine which haven't even been implemented. It's like you're applying conspiracy theory to the SCP. :wtf:
Actually at the moment this isn't ranting, nor an attack, nor a flame.
You however are being snide and sarcastic.
I'm not a rookie, Goober, sorry, but despite my gap in activity I've been around PXO longer than you, so try not to talk down to me and try not to put words in my mouth.
The thread was a simple start to remind/engage people that standards are slipping, for whatever reasons, and they should not.
It's not aimed at anyone in particular, no names were mentioned, no strawmen were drawn up and no projects were flamed.
Now, I agree that things have accidentally been changed over the years, but we make every effort to catch those changes as soon as they happen and fix them. Rule #1 in the SCP is, and has been since the beginning, "Maintain compatibility with retail".
And so it should be, my point is it's not the current reality. The thread was simply to bring that to light, again, not to flame anyone. (Also, I don't think it was a cast iron rule when the source code was first released that gameplay should be maintained because I remember a lot of little tweaks and crap being put in which VASTLY changed multi, a lot of people, including myself complained heavily about it, but most people had given up arguing with certain block heads (most, all? of whom aren't here anymore ...(?)) and lost interest by the time Quiz and a few others brought people round a pov that lead to it being fixed.
It got fixed but/and no one was really there to talk about it, from what I recall.
That means that playing FSO with no mods should be balanced the same as playing retail FS2 with no mods.
Thusly, this thread.
If little changes are creeping in here and there we definitely want to know about them, but we have been paying attention to this all along. I don't know where you get the idea that we haven't. It's like going up to Apple and demanding why they haven't yet released this iPod that you're hearing so much hype about.
Only one of your claims makes any sense to me, and that's the "fighter beam whack" change which is a known issue. I'd really like to see side-by-side comparison of the other issues, if they are as noticeable as you say.
What would I need to do to show this on several subjective points (*like hard to describe ai improvements >.>)?
It's not like a picture or fraps is going to be reproducible in exact detail.
All I can really do is ask the people who I have been discussing it with to pipe up about it.
And it's worth noting that since I have had such a long break from this that my perspective has jumped from vanilla to present missing all the gradual increments in between.
It's also worth noting that this problem is more observable in multi and on insane - less trafficked areas of the game these days compared to the solo campaign (*although a difference is observable on certain missions, an easier one to note this on is Hate the Traitor, (on insane ofcourse) but it's still not going to be something you're going to easily see unless you regularly slaughter vanilla insane AI).
-
I'd like to see the beam whack returned to retail status...but otherwise I think Goob is correct.
The friendly AI complaint makes no sense because friendly and hostile ships use the same AI. The levels are often set differently in FRED, but a friendly General and an enemy General are the same.
-
Quite a valid point in regards to the friendly AI, but it was example spinning about suggestions of stuff that hadn't been fixed compared to that, 'that is'.
Also hostile ai orders tend to be several degrees more complicated in the community mission packs compared to friendly ai which is mostly expected to be taken up by the pilots (either by there actually being 4 or whatever of you, or by orders, on comms, which still leaves the player's ai limited compared to the hostile AIs, so although far from as major as I made out in example; there's still often going to be a difference).
-
There is a valid point here. Friendly AI is almost always not as heavily scripted as the enemy AI, and if it is ordered around by a player it will be pretty single-mindedly fulfill the player's wishes, thus seeming stupider than the equivalent enemy AI.
-
Well first things first. The goal of the SCP is to make the game engine better while maintaining perfect compatibility with Retail. This is, and always has been our goal.
The Goal of FSUP and the media VPs is to make the game the way it should have been if V had access to our technology.
In other words you can't play with the media VPs and complain it's different from retail. It's meant to be. Maybe not very different, but different nonetheless. The only way you can judge how close to retail the engine has remained is if you're playing with no mods and only retail data. If when you play with retail data you spot a difference, then it's a bug. Report it in Mantis and someone will look at it (be warned that AI bugs are amongst the hardest to solve cause the change is so small).
On the other hand, acting like the SCP are slipping is just going to get you ignored or a response like Goober's. We're only able to solve bugs we know about. And if no one has reported the issues you've mentioned, then no one can fix them either.
-
Uh, if I recall correctly, QuantumDelta has mentioned that he does NOT play with the MediaVP's or has had them turned off whenever noticing the issues that he has been describing.
If I'm wrong or mis-remembering something (like, for example, I'm confusing him with somebody else from the same conversation), I'm sure it will get clarified quickly enough.
And while the MediaVP's may make COSMETIC and GRAPHICAL improvements to the main campaign, weapons and what not, we have NOT, to my knowledge, ever adjusted anything out of true to the value of Canon first followed by consistency. Which will always err on the side of :v: canon. (Tech Descriptions for loadouts not actually matching the models hardpoints and vis versus).
So, the game being played with or without the mediavps should make absolutely no difference in terms of the mechanics, but it is always stressed to check against retail to be sure. Because all our motto is "Make Things Look Better"
Now, that having been said, there are still some occasional mission edits that DO take place. Like, compensating for spatial differences with the Hecate model vs it's Retail version. Or correcting the Sexp overflow that :v: had in a mission that Fred_Open barf's all over itself on. And that, frankly, really should be it. Everything should still take place in the same order and same place and time in the MediaVP's as it does in retail. And if not for things like $Texture Replace and the Backgrounds being in DDS and the Skybox, you could still load the missions into the Retail Exe.
-
Well the comment about the Cain's extra turret is obviously media VP related and through most of QuantumDelta's posts I'm getting the feeling he's treating the SCP and FSUP as a single entity when they obviously aren't.
And while I understand that FSUP aren't trying to make big changes to the game there are minor differences that you don't particularly care about (minor turret placement changes for high poly models, etc) which are probably of the same sort of level QD is talking about.
More importantly, a hell of a lot of the things he is on about could very easily be due to the Media VP data rather than the SCP code. So before either side spends lots of time looking, it needs to be established where the cause actually is.
-
as usual i hope im not getting this ass backwards and completely wrong , but are we not mainly talking about how the AI reacts within the game ?
and as far as i can see the only AI tables are in the fs root vp and there arent any within the mvps ...
i have no idea how this is happening but for me i think part of it is down to optimisations and the game speeding up and being more accurate , it feels a lot more like TBP at the moment when playing on the higher levels within multi ..
anyway i am glad that this is being discussed as it means ppl are playing , people are testing and people are interested enough to care
-
I do apologise again, I've been going over this a lot with the peeps in irc and I didn't really context the post right, I can easily see how it looks like I'm talking about MediaVPs effecting the game and stuffs, and whilst they could, I can't really say I've noticed them doing so (they're mostly artsy, right?).
FsPort is obviously a bit different, and I made a second thread about those things without really processing it with this problem, since during single player campaigns the AI difference is often far less noticeable even on insane (dunno why!), and I figured (my main blah with avenger) that it wouldn't have effected it much, on re-analysis, it really is just the better shield management.
Anyway.
When we do play multi we don't play it with any mediavps enabled for a number of reasons (my PC is mildly old and can't handle everything on max + MVPs + several clients, so it's just less fuss to run with none than filter them down until it's stable/smooth enough, not any of your lots problems :P), the two other reasons are that we got accused of cheating enough when we were originally playing PXO... not having hacked table files etc pop up for us puts the newer pilots a bit at ease when we pick up 60 kills on a mission where they've ended up in respawn 5 minutes before us, and finally - we kinda wanted to build up full medals/captain ranks before anything squadwarish happened because we're far less likely to play coop once it does.
Hense the couple people who have posted who have spoken to me on IRC have mentioned these aren't MVP related and that I'm not just making this up.
I'm very very aware that these mostly unnoticed changes aren't going to be seen unless you regularly play with the best scripted AI (read; for difficulty, not events) missions, which are mostly Cetanu's, Su-teph's, and Lonewolf's multiplayer missions. We haven't (that said) been able to lock down what's causing the difference to be so pronounced in some missions whilst not visible at all in others, we've scanned heavily up to about 5513 (nightlys) and .10 final so we've been checking the sexps effects, the direction we've been looking is ai_tables/ai_profiles, but as you say I have no access to the code. (Even if I did, I don't know enough, like I said in my first post, to identify a significant code entry to the problem).
Perhaps saying slipping was the wrong idea but the impression I got from the guys in #hard-light when originally dealing with it (over 2 weeks ago) was that these changes had been accepted as originally intended yet obfuscated by either bugs or coverup rushed jobs by V, as it became more evident that some of the changes I was talking about weren't particularly minor on insane in some of the missions in multi-mission.vp they began to realise it was going to need addressing and fixing.
As evident in this post though, without a clear and exact expression of the difference (which we still can't find) these unintentional changes couldn't be put on mantis in any clear way, which is sorta why it's a forum-debate-post instead of a bug report.
I'm not saying "FIX IT NAO", because despite being one of the most involved in looking into this and beyond a few (probably silly) ideas, I don't know exactly what the difference is.
But the AI seems to;
Tracks pilots slightly better than vanilla.
Shoots slightly more than vanilla.
Evades (makes better use of shields and CMs) better than vanilla.
However unless it's shooting at someone it doesn't particularly turn faster, nor acquire a new target faster than vanilla.
Once you break weapons lock (them pointed at your lead indicator) they become pretty useless (well ok not useless but back to vanilla AI, useless in comparison).
Subsystem damage calculations has definitely changed (improved?), if an Anti fighter beam is firing at you and you're in an Eri/mk2/few other ships with crap right on the nose, if you're pointed straight at it an annoyingly large portion of the time that system will be gone, in missions like The Die is Cast where you don't get a support ship and every respawn is ridiculously valuable, it's very very noticeable.
Part of the problem I had with the athena on fsport as well, since a lot of it's sub systems are on it's extremities it harshly suffers from this problem, further compounding it's collision problem :P, probably wouldn't have posted about it (collision damage I can tollerate) if it weren't for the fact that the mission I'd been flying 5 minutes before had ended badly 3 or 4 times only due to the fact that it's sensors had gone long enough for objectives to be failed, it was the main reason I was holding off rants :P.
So, again, apologies, stuff that's clear in my head doesn't always come out in text immediately as clearly, my bad. :blah:
-
Go easy on him guys, I think he's got a lot of valid points. Also, I believe another user was able to fire up the retail exe and confirm some differences in AI behavior in various missions, which means that despite our best efforts, there _are_ gameplay differences between retail and SCP. Was that you andicirk?
-
I think its just realistic to assume there are (unintentional) differences. Hell, how many bug fixes alone have been made to FS2 source during the last six(?) years? It'd be a damn miracle if there are no side effects *at all*. Another question is whether those differences are noticeable or not..
-
Well, if changes have been made that affect the ai in adverse ways, it may mean we need to adjust the default ai_profile table to be a closer match to the observed behavior of the retail exe, when in use with current SCP code. Even if the numbers themselves don't match, if the behavior becomes closer then it could be needed. This is assuming we can't actually identify particular code changes that have led to this behavior and 'fix' them so they don't have such effects.
-
Oh, boy. Dangerous stuff. Keep in mind that most campaigns probably use default AI settings, so if that changes, it may make things a bit wonky.
-
Actually, most campaigns (AFAIK) don't. Hell, the MediaVP's missions up until recently did not have "$AI Profile: FS2 RETAIL" defined in them.
They got defined to make sure that if the default assumption to load that in absence of a flag ever broke, it would still be calling to it.
Granted, I haven't exactly looked into all the missions for all the campaigns.
-
...Eh. I had made a note to myself to respond in full to this, but various events popped up in the interim and now the urgency is gone. :) Let me just highlight a few points:
You however are being snide and sarcastic.
I'm not a rookie, Goober, sorry, but despite my gap in activity I've been around PXO longer than you, so try not to talk down to me and try not to put words in my mouth.
The thread was a simple start to remind/engage people that standards are slipping, for whatever reasons, and they should not.
It's not aimed at anyone in particular, no names were mentioned, no strawmen were drawn up and no projects were flamed.
I was being snide and sarcastic because your original post warranted it. :p Note however that I didn't (and don't) hold any hard feelings about it. And I freely acknowledge that you weren't maliciously targeting anyone.
And so it should be, my point is it's not the current reality.
Fair point; let's do something about it. :)
[snip]
I pretty much agree with karajorma's whole post here, especially the last paragraph.
Hense the couple people who have posted who have spoken to me on IRC have mentioned these aren't MVP related and that I'm not just making this up.
I'm very very aware that these mostly unnoticed changes aren't going to be seen unless you regularly play with the best scripted AI (read; for difficulty, not events) missions, which are mostly Cetanu's, Su-teph's, and Lonewolf's multiplayer missions. We haven't (that said) been able to lock down what's causing the difference to be so pronounced in some missions whilst not visible at all in others, we've scanned heavily up to about 5513 (nightlys) and .10 final so we've been checking the sexps effects, the direction we've been looking is ai_tables/ai_profiles, but as you say I have no access to the code. (Even if I did, I don't know enough, like I said in my first post, to identify a significant code entry to the problem).
Another good set of points. I do remember that SCP's multiplayer support was severely deficient until quite recently, thanks to karajorma's efforts on that front. It was apparently such a problem that people reguarly used Tom's Build which was basically retail with FS2NetD thrown in. Unfortunately, that led to a mutually-reinforcing situation where people used Tom's Build because SCP contained too many bugs, but the SCP team didn't fix the bugs because they were never reported, but they were never reported because people used Tom's Build.
As evident in this post though, without a clear and exact expression of the difference (which we still can't find) these unintentional changes couldn't be put on mantis in any clear way, which is sorta why it's a forum-debate-post instead of a bug report.
I'm not saying "FIX IT NAO", because despite being one of the most involved in looking into this and beyond a few (probably silly) ideas, I don't know exactly what the difference is.
This is a good sumamry of the situation, as well as a good response to it.
Anyway, this is basically just to say that neither I nor the SCP bear QuantumDelta any ill will, and if there are bugs in the code, let's find them and fix them.
-
I've been waiting! :p
It honestly wasn't my intent to upset anyone and I'm glad we cleared it up, I've had lots of theories about what 'might' be wrong and such, but ultimately I think it's going to come down to isolating the subtle AI behaviour changes one at a time.
The most impacting Multiplayer change (which is also actually seen in single player too on higher difficulties), is that the AI have a penchant for pointing themselves at the players target reticle, and never ever stopping, to the point that if the human doesn't move out the way or kill the AI the AI will just ram the human and keep firing (this is without MVPs and on the same missions the behaviour is absent on retail builds), the AI is so accurate and so 'glued' to the lead reticle of your ship it's not actually worth it (even in a light fighter) to try to dodge the AI's aim, even at my skill level I can't reliably enough dodge their shots using tricks that would send any pilot in the world out of their chair, because of this behaviour well balanced missions in multi are currently very-difficult-to-impossible (though subsequent to these posts we have started being able to beat these missions, either by taking the AI on head to head one at a time or running away and avoiding them as much as possible whilst completing objectives, but anyway) due to the number of enemies that inhabit multi missions (*only the busiest single player missions match up to a typical multi mission).
- This change, we had assumed came from the AI tables, but this turned out to be untrue.
A great many people on IRC helped out looking, but it wasn't until Wanderer started throwing old builds at me (which I tested in quick succession) that we managed to lock down the problem a bit, we still don't know what caused it, but the behavioural change is between 3.6.7 and build some time later, unfortunately we ran out of builds - there was still +-400-500 revisions to check through.
The change is very distinctive, AI - even on insane have a tendency to 'flinch' whilst you fire at them (this lowers the incoming DPS on the player AND upsets AI aim which becomes more accurate the longer it's pointed at a target), this twitch or flinch in the SCP builds this behaviour is at the very best 'extremely, extremely rare', and at worst - non-existent (not actually true, since I've seen it, once, couldn't repeat it with the same ship on the same mission after trying dozens of times, though).
I'd previously assumed it was stuff like super_attack triggering and 'staying on', because other aspects of AI behaviour had remained less changed.
For a concise list of observed changes (not extensive but all I can think of atm);
AI; shield management has dramatically increased.
AI; "not flinching" leading to super-AI accuracy, even to the point where they push the turning limits on their ship.
AI; missile evasion / CM launching is greatly improved (leading to dumbfire missiles on occasion (CM fired almost simultaneously to Missile launch, doesn't bother me much since I don't use aspect seekers if given the choice but I imagine it could annoy some people :P)
AI; Now bombs like a player (well, an ok one), leading to fleets of incoming bombs from wings of bombers (they fire -> change bank, -> fire, etc)
AI; Shivans use "slide" far, far more effectively on some missions haven't worked out what causes it solidly (*looks like collisions and/or target swapping mostly) but they can circle strafe a player.
Subsystem damage - seems a bit high (possibly due to more CPU time free to calculate it), this is most obvious with beams (AAA) but that may also be related to the lack of beamwhack, it is however visible with primaries that have smaller projectiles (subach/kayser/SDG) as well.
Collision damage - especially subsystem damage from collisions seems to be much more punishing, especially on multilplayer (collision physics was always a bit screwed up on multi, the client had a tendency to take a little more damage than the host, but at the moment this has been exacerbated massively - skimming a capital ship at very low speed can leave your fighter on very little hull, or even destroy your ship), it's very difficulty to furball properly because of it (*ramming used to be a tactical decision, now it's near suicide).
Bombs - seem to be significantly harder to shoot down on Multi (their tracking isn't correct - even lag adjusted), they also seem to be very slightly harder to shoot down from behind on Single/As host, but on multi it's virtually impossible, they also don't always report if they have been shot down to the clients - which leaves the clients chasing bombs which aren't there.
Beam accuracy - now this one might raise a few eyebrows, but beams were somewhat inaccurate at the best of times when they were introduced, beams could never be dodged or evaded (*'cept by ducking around a corner whilst they powered up), they either hit, or they miss, currently they seem to use the normal AI code for aiming, and thus have increased weapon accuracy, leading to them virtually never (*never in some cases)missing, when they would have previously missed ~30% of the time.
SCP builds seem to randomly completely lose sync between host and clients (very rare) - it used to happen with laggier clients on Retail, but currently it happens even with sub 100 pings.
The client sometimes crash when the host jumps whilst the client is in respawn (about to get the respawn screen, after their ship has exploded) - Believing this to be a retail bug, but I don't really remember, also other than this condition I'm not sure exactly what causes this.
Another old bug that's gotten slightly worse; Secondaries on ships that are warping in (trebs at a Ravana front beams for example) seem to 'miss' for no discernible reason other than the capships speed is over ~100 or whatever the actual speed is (hard to judge sometimes, but it seems to be just over 100 that this behaviour begins).
Debris - another old bug, not really one that has been made worse by SCP but one that would be greatly appreciated to be fixed. On the host side, Debris is rendered correctly, however on the client side, it's rendered completely differently, different sized debris, different directions of travel, and the real ones obviously are totally invisible, so clients end up 'dying for no reason' on occasion because debris has clouted them in the face.
..I know there's a couple I've missed, but there's a descriptive list of the ones I remember right now. :<
- sorry I didn't reply to your PM on IRC btw Goober, I was sleepin' peacefully :p
*Edited to try to make the subject of each slightly easier to read.
-
A great many people on IRC helped out looking, but it wasn't until Wanderer started throwing old builds at me (which I tested in quick succession) that we managed to lock down the problem a bit, we still don't know what caused it, but the behavioural change is between 3.6.7 and build some time later, unfortunately we ran out of builds - there was still +-400-500 revisions to check through.
Aha! Excellent work; this is precisely what needs to be done to track down the problems. :) It basically comes down to three steps:
1) Identify what is wrong (which, as you have said, is sometimes harder than one thinks)
2) Pinpoint the revision where the behavior changed
3) Fix the bug, or tie it to an AI flag
Running out of builds is problematic but not a game breaker. What you need to do is schedule a time when you and another coder (or anyone who can check stuff out of CVS and compile builds) can be on the #scp IRC channel. Then you narrow the time period down using the divide and conquer strategy.
-
Right, I tried to do a few builds, but couldn't get it to compile. VS2008 is too modern to do it, apparently; someone with VC 2005 or something close to it should try it.
Anyway, the svn log tells me that between revision 2211 and 2605 (the range that it was narrowed down to), there were 29 commits that altered files in the ai/ directory.
Revision: 2604
Author: wmcoolmon
Date: 05:18:55, Freitag, 6. Januar 2006
Message:
turret-target-order SEXPs, ship thrusters
----
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/parse/sexp.cpp
Modified : /trunk/fs2_open/code/parse/sexp.h
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Revision: 2571
Author: wmcoolmon
Date: 09:08:42, Donnerstag, 29. Dezember 2005
Message:
Codebase commit, most notably including objecttypes.tbl
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aigoals.cpp
Modified : /trunk/fs2_open/code/ai/aigoals.h
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/debris/debris.cpp
Modified : /trunk/fs2_open/code/fireball/fireballs.cpp
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/fs2open_pxo/Client.cpp
Modified : /trunk/fs2_open/code/fs2open_pxo/TCP_Client.cpp
Added : /trunk/fs2_open/code/globalincs/def_files.cpp
Added : /trunk/fs2_open/code/globalincs/def_files.h
Modified : /trunk/fs2_open/code/globalincs/globals.h
Modified : /trunk/fs2_open/code/globalincs/pstypes.h
Modified : /trunk/fs2_open/code/graphics/2d.cpp
Modified : /trunk/fs2_open/code/graphics/2d.h
Modified : /trunk/fs2_open/code/graphics/gropengl.cpp
Modified : /trunk/fs2_open/code/graphics/gropengltnl.cpp
Modified : /trunk/fs2_open/code/hud/hudparse.cpp
Modified : /trunk/fs2_open/code/hud/hudsquadmsg.cpp
Modified : /trunk/fs2_open/code/hud/hudsquadmsg.h
Modified : /trunk/fs2_open/code/hud/hudtarget.cpp
Modified : /trunk/fs2_open/code/iff_defs/iff_defs.cpp
Modified : /trunk/fs2_open/code/io/keycontrol.cpp
Modified : /trunk/fs2_open/code/lab/lab.cpp
Modified : /trunk/fs2_open/code/menuui/barracks.cpp
Modified : /trunk/fs2_open/code/menuui/techmenu.cpp
Modified : /trunk/fs2_open/code/mission/missioncampaign.cpp
Modified : /trunk/fs2_open/code/mission/missioncampaign.h
Modified : /trunk/fs2_open/code/mission/missionhotkey.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.h
Modified : /trunk/fs2_open/code/missionui/missionbrief.cpp
Modified : /trunk/fs2_open/code/missionui/missiondebrief.cpp
Modified : /trunk/fs2_open/code/missionui/missionscreencommon.cpp
Modified : /trunk/fs2_open/code/missionui/missionscreencommon.h
Modified : /trunk/fs2_open/code/missionui/missionshipchoice.cpp
Modified : /trunk/fs2_open/code/missionui/missionweaponchoice.cpp
Modified : /trunk/fs2_open/code/model/model.h
Modified : /trunk/fs2_open/code/model/modelinterp.cpp
Modified : /trunk/fs2_open/code/model/modelread.cpp
Modified : /trunk/fs2_open/code/nebula/neb.cpp
Modified : /trunk/fs2_open/code/network/multi_campaign.cpp
Modified : /trunk/fs2_open/code/network/multi_ingame.cpp
Modified : /trunk/fs2_open/code/network/multi_obj.cpp
Modified : /trunk/fs2_open/code/network/multi_pinfo.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Modified : /trunk/fs2_open/code/network/multiteamselect.cpp
Modified : /trunk/fs2_open/code/network/multiutil.cpp
Modified : /trunk/fs2_open/code/object/collideshipship.cpp
Modified : /trunk/fs2_open/code/object/objectsort.cpp
Modified : /trunk/fs2_open/code/parse/parselo.cpp
Modified : /trunk/fs2_open/code/parse/parselo.h
Modified : /trunk/fs2_open/code/parse/sexp.cpp
Modified : /trunk/fs2_open/code/playerman/managepilot.cpp
Modified : /trunk/fs2_open/code/playerman/playercontrol.cpp
Modified : /trunk/fs2_open/code/ship/afterburner.cpp
Modified : /trunk/fs2_open/code/ship/shield.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Modified : /trunk/fs2_open/code/ship/shipfx.cpp
Modified : /trunk/fs2_open/code/species_defs/species_defs.cpp
Modified : /trunk/fs2_open/code/starfield/starfield.cpp
Modified : /trunk/fs2_open/code/stats/scoring.cpp
Modified : /trunk/fs2_open/code/stats/scoring.h
Modified : /trunk/fs2_open/code/weapon/beam.cpp
Modified : /trunk/fs2_open/code/weapon/flak.cpp
Modified : /trunk/fs2_open/code/weapon/flak.h
Modified : /trunk/fs2_open/code/weapon/weapon.h
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Revision: 2545
Author: taylor
Date: 05:32:44, Donnerstag, 22. Dezember 2005
Message:
GCC knows that fix == int so it hates the utility functions here, for sanity sake just rename them to type specific to avoid rampant casting
----
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Revision: 2506
Author: taylor
Date: 04:17:48, Dienstag, 6. Dezember 2005
Message:
cleanup some debug log messages:
note that a nprintf() with "Warning" or "General" is basically the same thing as mprintf()
make sure that OpenAL init failures always get to the debug log
----
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Modified : /trunk/fs2_open/code/cmdline/cmdline.cpp
Modified : /trunk/fs2_open/code/hud/hudparse.cpp
Modified : /trunk/fs2_open/code/lab/wmcgui.cpp
Modified : /trunk/fs2_open/code/menuui/techmenu.cpp
Modified : /trunk/fs2_open/code/parse/scripting.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/sound/ds.cpp
Revision: 2505
Author: taylor
Date: 04:15:47, Dienstag, 6. Dezember 2005
Message:
add a couple of Assert()'s that it doesn't otherwise check for
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Revision: 2488
Author: wmcoolmon
Date: 20:07:49, Sonntag, 4. Dezember 2005
Message:
Final commit of codebase
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/bmpman/bmpman.h
Modified : /trunk/fs2_open/code/cmeasure/cmeasure.cpp
Modified : /trunk/fs2_open/code/cmeasure/cmeasure.h
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/hud/hudtarget.cpp
Modified : /trunk/fs2_open/code/io/keycontrol.cpp
Added : /trunk/fs2_open/code/lab
Added : /trunk/fs2_open/code/lab/lab.h
Added : /trunk/fs2_open/code/lab/lua.cpp
Added : /trunk/fs2_open/code/lab/wmcgui.cpp
Added : /trunk/fs2_open/code/lab/wmcgui.h
Added : /trunk/fs2_open/code/menuui/storybook.cpp
Added : /trunk/fs2_open/code/menuui/storybook.h
Modified : /trunk/fs2_open/code/missionui/missionshipchoice.cpp
Modified : /trunk/fs2_open/code/model/model.h
Modified : /trunk/fs2_open/code/nebula/neb.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Modified : /trunk/fs2_open/code/object/object.cpp
Modified : /trunk/fs2_open/code/object/object.h
Added : /trunk/fs2_open/code/parse/lua.cpp
Added : /trunk/fs2_open/code/parse/lua.h
Modified : /trunk/fs2_open/code/parse/parselo.cpp
Added : /trunk/fs2_open/code/parse/python.cpp
Added : /trunk/fs2_open/code/parse/python.h
Added : /trunk/fs2_open/code/parse/scripting.cpp
Added : /trunk/fs2_open/code/parse/scripting.h
Revision: 2478
Author: Goober5000
Date: 10:08:44, Donnerstag, 24. November 2005
Message:
bah, forgot a colon
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Revision: 2477
Author: Goober5000
Date: 09:46:11, Donnerstag, 24. November 2005
Message:
* cleaned up mission_do_departure
* fixed a hidden crash (array index being -1; would only
be triggered for ships w/o subspace drives under certain conditions)
* removed finding a new fighterbay target because it might screw up missions
* improved clarity, code flow, and readability :)
* added custom AI flag for disabling warpouts if navigation subsystem fails
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/ai.h
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Modified : /trunk/fs2_open/code/ai/ai_profiles.h
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/io/keycontrol.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Modified : /trunk/fs2_open/code/ship/subsysdamage.h
Revision: 2476
Author: taylor
Date: 08:27:14, Donnerstag, 24. November 2005
Message:
fix fred2 startup crash (we probably need to Assert() this case so it doesn't easily happen again)
----
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Revision: 2464
Author: phreak
Date: 01:46:26, Mittwoch, 23. November 2005
Message:
Calculate player repair timer when the support ship docks to him.
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Revision: 2457
Author: taylor
Date: 16:01:18, Montag, 21. November 2005
Message:
little cleaner, lot more friendly to 64-bit archs (long type is usually 64-bit there)
----
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Revision: 2454
Author: Goober5000
Date: 04:51:03, Montag, 21. November 2005
Message:
remove old files
--Goober5000
----
Deleted : /trunk/fs2_open/code/ai/ai_settings.cpp
Deleted : /trunk/fs2_open/code/ai/ai_settings.h
Revision: 2453
Author: Goober5000
Date: 04:47:51, Montag, 21. November 2005
Message:
bah and double bah
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/ai_profiles.cpp
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/parse/parselo.cpp
Modified : /trunk/fs2_open/code/parse/parselo.h
Revision: 2451
Author: Goober5000
Date: 03:43:37, Montag, 21. November 2005
Message:
change from "setting" to "profile"; this way makes more sense
--Goober5000
----
Added : /trunk/fs2_open/code/ai/ai_profiles.cpp
Added : /trunk/fs2_open/code/ai/ai_profiles.h
Modified : /trunk/fs2_open/code/ai/aibig.cpp
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/asteroid/asteroid.cpp
Modified : /trunk/fs2_open/code/cmeasure/cmeasure.cpp
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/hud/hudets.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.h
Modified : /trunk/fs2_open/code/object/object.cpp
Modified : /trunk/fs2_open/code/ship/afterburner.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/shiphit.cpp
Modified : /trunk/fs2_open/code/weapon/beam.cpp
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Revision: 2450
Author: Goober5000
Date: 02:53:57, Montag, 21. November 2005
Message:
add a flag to re-enable shockwaves damaging subsystems (from FS1)
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/ai_settings.cpp
Modified : /trunk/fs2_open/code/ai/ai_settings.h
Modified : /trunk/fs2_open/code/ship/shiphit.cpp
Revision: 2449
Author: Goober5000
Date: 01:52:19, Montag, 21. November 2005
Message:
whoops
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/ai_settings.cpp
Revision: 2448
Author: Goober5000
Date: 01:50:02, Montag, 21. November 2005
Message:
add ai_settings.tbl
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/ai.h
Added : /trunk/fs2_open/code/ai/ai_settings.cpp
Added : /trunk/fs2_open/code/ai/ai_settings.h
Modified : /trunk/fs2_open/code/ai/aibig.cpp
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/asteroid/asteroid.cpp
Modified : /trunk/fs2_open/code/cmdline/cmdline.cpp
Modified : /trunk/fs2_open/code/cmdline/cmdline.h
Modified : /trunk/fs2_open/code/cmeasure/cmeasure.cpp
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/hud/hudets.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.h
Modified : /trunk/fs2_open/code/object/object.cpp
Modified : /trunk/fs2_open/code/parse/parselo.h
Modified : /trunk/fs2_open/code/ship/afterburner.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Modified : /trunk/fs2_open/code/ship/shiphit.cpp
Modified : /trunk/fs2_open/code/weapon/beam.cpp
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Modified : /trunk/fs2_open/projects/MSVC_6/code.dsp
Revision: 2415
Author: wmcoolmon
Date: 02:04:02, Dienstag, 8. November 2005
Message:
More warnings instead of Int3s/Asserts, better Lua scripting, weapons_expl.tbl is no longer needed nor read, added "$Disarmed ImpactSnd:", fire-beam fix
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/bmpman/bmpman.cpp
Modified : /trunk/fs2_open/code/bmpman/bmpman.h
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/gamesnd/eventmusic.cpp
Modified : /trunk/fs2_open/code/globalincs/pstypes.h
Modified : /trunk/fs2_open/code/globalincs/windebug.cpp
Modified : /trunk/fs2_open/code/hud/hudparse.cpp
Modified : /trunk/fs2_open/code/mission/missionbriefcommon.cpp
Modified : /trunk/fs2_open/code/model/modelread.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Modified : /trunk/fs2_open/code/object/collideshipweapon.cpp
Modified : /trunk/fs2_open/code/parse/lua.cpp
Modified : /trunk/fs2_open/code/parse/lua.h
Modified : /trunk/fs2_open/code/parse/parselo.cpp
Modified : /trunk/fs2_open/code/parse/parselo.h
Modified : /trunk/fs2_open/code/parse/scripting.cpp
Modified : /trunk/fs2_open/code/parse/sexp.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/weapon/beam.cpp
Modified : /trunk/fs2_open/code/weapon/weapon.h
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Revision: 2387
Author: wmcoolmon
Date: 07:45:00, Sonntag, 30. Oktober 2005
Message:
Codebase commit - nebula.tbl, scripting, new dinky explosion/shockwave stuff, moving muzzle flashes
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/cmdline/cmdline.cpp
Modified : /trunk/fs2_open/code/debris/debris.cpp
Modified : /trunk/fs2_open/code/freespace2/freespace.cpp
Modified : /trunk/fs2_open/code/graphics/2d.cpp
Modified : /trunk/fs2_open/code/graphics/2d.h
Modified : /trunk/fs2_open/code/graphics/font.cpp
Modified : /trunk/fs2_open/code/lab/lab.cpp
Modified : /trunk/fs2_open/code/model/modelinterp.cpp
Modified : /trunk/fs2_open/code/nebula/neb.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Modified : /trunk/fs2_open/code/object/collideshipweapon.cpp
Modified : /trunk/fs2_open/code/object/collideweaponweapon.cpp
Added : /trunk/fs2_open/code/parse/lua.cpp
Added : /trunk/fs2_open/code/parse/lua.h
Added : /trunk/fs2_open/code/parse/python.cpp
Added : /trunk/fs2_open/code/parse/python.h
Added : /trunk/fs2_open/code/parse/scripting.cpp
Added : /trunk/fs2_open/code/parse/scripting.h
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/shipfx.cpp
Modified : /trunk/fs2_open/code/weapon/flak.cpp
Modified : /trunk/fs2_open/code/weapon/flak.h
Modified : /trunk/fs2_open/code/weapon/muzzleflash.cpp
Modified : /trunk/fs2_open/code/weapon/muzzleflash.h
Modified : /trunk/fs2_open/code/weapon/shockwave.cpp
Modified : /trunk/fs2_open/code/weapon/shockwave.h
Modified : /trunk/fs2_open/code/weapon/weapon.h
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Added : /trunk/fs2_open/lua
Added : /trunk/fs2_open/lua/lapi.c
Added : /trunk/fs2_open/lua/lapi.h
Added : /trunk/fs2_open/lua/lauxlib.c
Added : /trunk/fs2_open/lua/lauxlib.h
Added : /trunk/fs2_open/lua/lbaselib.c
Added : /trunk/fs2_open/lua/lcode.c
Added : /trunk/fs2_open/lua/lcode.h
Added : /trunk/fs2_open/lua/ldblib.c
Added : /trunk/fs2_open/lua/ldebug.c
Added : /trunk/fs2_open/lua/ldebug.h
Added : /trunk/fs2_open/lua/ldo.c
Added : /trunk/fs2_open/lua/ldo.h
Added : /trunk/fs2_open/lua/ldump.c
Added : /trunk/fs2_open/lua/lfunc.c
Added : /trunk/fs2_open/lua/lfunc.h
Added : /trunk/fs2_open/lua/lgc.c
Added : /trunk/fs2_open/lua/lgc.h
Added : /trunk/fs2_open/lua/liolib.c
Added : /trunk/fs2_open/lua/llex.c
Added : /trunk/fs2_open/lua/llex.h
Added : /trunk/fs2_open/lua/llimits.h
Added : /trunk/fs2_open/lua/lmathlib.c
Added : /trunk/fs2_open/lua/lmem.c
Added : /trunk/fs2_open/lua/lmem.h
Added : /trunk/fs2_open/lua/loadlib.c
Added : /trunk/fs2_open/lua/lobject.c
Added : /trunk/fs2_open/lua/lobject.h
Added : /trunk/fs2_open/lua/lopcodes.c
Added : /trunk/fs2_open/lua/lopcodes.h
Added : /trunk/fs2_open/lua/lparser.c
Added : /trunk/fs2_open/lua/lparser.h
Added : /trunk/fs2_open/lua/lstate.c
Added : /trunk/fs2_open/lua/lstate.h
Added : /trunk/fs2_open/lua/lstring.c
Added : /trunk/fs2_open/lua/lstring.h
Added : /trunk/fs2_open/lua/lstrlib.c
Added : /trunk/fs2_open/lua/ltable.c
Added : /trunk/fs2_open/lua/ltable.h
Added : /trunk/fs2_open/lua/ltablib.c
Added : /trunk/fs2_open/lua/ltests.c
Added : /trunk/fs2_open/lua/ltm.c
Added : /trunk/fs2_open/lua/ltm.h
Added : /trunk/fs2_open/lua/lua.h
Added : /trunk/fs2_open/lua/lualib.h
Added : /trunk/fs2_open/lua/lundump.c
Added : /trunk/fs2_open/lua/lundump.h
Added : /trunk/fs2_open/lua/lvm.c
Added : /trunk/fs2_open/lua/lvm.h
Added : /trunk/fs2_open/lua/lzio.c
Added : /trunk/fs2_open/lua/lzio.h
Modified : /trunk/fs2_open/projects/MSVC_7/Freespace2.sln
Modified : /trunk/fs2_open/projects/MSVC_7/Freespace2.vcproj
Modified : /trunk/fs2_open/projects/MSVC_7/code.vcproj
Revision: 2386
Author: Goober5000
Date: 00:09:31, Sonntag, 30. Oktober 2005
Message:
multiple ship docking implemented for initially docked ships
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/aigoals.cpp
Modified : /trunk/fs2_open/code/gamesnd/eventmusic.cpp
Modified : /trunk/fs2_open/code/hud/hudsquadmsg.cpp
Modified : /trunk/fs2_open/code/hud/hudwingmanstatus.cpp
Modified : /trunk/fs2_open/code/mission/missionhotkey.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.h
Modified : /trunk/fs2_open/code/missionui/missionscreencommon.cpp
Modified : /trunk/fs2_open/code/missionui/missionshipchoice.cpp
Modified : /trunk/fs2_open/code/missionui/missionweaponchoice.cpp
Modified : /trunk/fs2_open/code/network/multi_ingame.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Added : /trunk/fs2_open/code/object/parseobjectdock.cpp
Added : /trunk/fs2_open/code/object/parseobjectdock.h
Modified : /trunk/fs2_open/code/parse/sexp.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Modified : /trunk/fs2_open/code/ship/shipfx.cpp
Modified : /trunk/fs2_open/projects/MSVC_6/code.dsp
Revision: 2347
Author: Goober5000
Date: 00:22:41, Sonntag, 23. Oktober 2005
Message:
rolled back UnknownPlayer's commit
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/aibig.cpp
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/model/modelread.cpp
Revision: 2344
Author: unknownplayer
Date: 06:28:17, Samstag, 22. Oktober 2005
Message:
Added -UseNewAI command line option to force the game to always use
the SCP AI changes. As of now there's some problem in gr_d3d_set_render_target
that crashes the game when it gets to a mission.
----
Modified : /trunk/fs2_open/code/ai/aibig.cpp
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/cmdline/cmdline.cpp
Modified : /trunk/fs2_open/code/cmdline/cmdline.h
Modified : /trunk/fs2_open/code/graphics/grd3dbmpman.cpp
Modified : /trunk/fs2_open/code/model/modelread.cpp
Modified : /trunk/fs2_open/projects/MSVC_2003/Freespace2.vcproj
Revision: 2310
Author: Goober5000
Date: 09:22:24, Freitag, 14. Oktober 2005
Message:
removed an unneeded parameter and renamed some stuff
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/hud/hudartillery.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/weapon/weapon.h
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Revision: 2298
Author: taylor
Date: 19:21:11, Montag, 10. Oktober 2005
Message:
remove NO_NETWORK
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/ai/aigoals.cpp
Modified : /trunk/fs2_open/code/ai/aiturret.cpp
Modified : /trunk/fs2_open/code/asteroid/asteroid.cpp
Modified : /trunk/fs2_open/code/bmpman/bmpman.cpp
Modified : /trunk/fs2_open/code/debris/debris.cpp
Modified : /trunk/fs2_open/code/fs2open_pxo/Client.cpp
Modified : /trunk/fs2_open/code/fs2open_pxo/TCP_Client.cpp
Modified : /trunk/fs2_open/code/fs2open_pxo/TCP_Socket.cpp
Modified : /trunk/fs2_open/code/fs2open_pxo/udpsocket.cpp
Modified : /trunk/fs2_open/code/globalincs/globals.h
Modified : /trunk/fs2_open/code/hud/hud.cpp
Modified : /trunk/fs2_open/code/hud/hudartillery.cpp
Modified : /trunk/fs2_open/code/hud/hudconfig.cpp
Modified : /trunk/fs2_open/code/hud/hudescort.cpp
Modified : /trunk/fs2_open/code/hud/hudlock.cpp
Modified : /trunk/fs2_open/code/hud/hudmessage.cpp
Modified : /trunk/fs2_open/code/hud/hudobserver.cpp
Modified : /trunk/fs2_open/code/hud/hudreticle.cpp
Modified : /trunk/fs2_open/code/hud/hudshield.cpp
Modified : /trunk/fs2_open/code/hud/hudsquadmsg.cpp
Modified : /trunk/fs2_open/code/hud/hudtarget.cpp
Modified : /trunk/fs2_open/code/hud/hudtargetbox.cpp
Modified : /trunk/fs2_open/code/hud/hudwingmanstatus.cpp
Modified : /trunk/fs2_open/code/irc/irc.cpp
Modified : /trunk/fs2_open/code/menuui/barracks.cpp
Modified : /trunk/fs2_open/code/menuui/mainhallmenu.cpp
Modified : /trunk/fs2_open/code/menuui/optionsmenu.cpp
Modified : /trunk/fs2_open/code/menuui/optionsmenumulti.cpp
Modified : /trunk/fs2_open/code/menuui/playermenu.cpp
Modified : /trunk/fs2_open/code/mission/missiongoals.cpp
Modified : /trunk/fs2_open/code/mission/missionlog.cpp
Modified : /trunk/fs2_open/code/mission/missionlog.h
Modified : /trunk/fs2_open/code/mission/missionmessage.cpp
Modified : /trunk/fs2_open/code/mission/missionparse.cpp
Modified : /trunk/fs2_open/code/mission/missiontraining.cpp
Modified : /trunk/fs2_open/code/missionui/chatbox.cpp
Modified : /trunk/fs2_open/code/missionui/missionbrief.cpp
Modified : /trunk/fs2_open/code/missionui/missiondebrief.cpp
Modified : /trunk/fs2_open/code/missionui/missionpause.cpp
Modified : /trunk/fs2_open/code/missionui/missionscreencommon.cpp
Modified : /trunk/fs2_open/code/missionui/missionshipchoice.cpp
Modified : /trunk/fs2_open/code/missionui/missionweaponchoice.cpp
Modified : /trunk/fs2_open/code/missionui/redalert.cpp
Modified : /trunk/fs2_open/code/nebula/neblightning.cpp
Modified : /trunk/fs2_open/code/network/fs2ox.cpp
Modified : /trunk/fs2_open/code/network/multi.cpp
Modified : /trunk/fs2_open/code/network/multi_campaign.cpp
Modified : /trunk/fs2_open/code/network/multi_data.cpp
Modified : /trunk/fs2_open/code/network/multi_dogfight.cpp
Modified : /trunk/fs2_open/code/network/multi_endgame.cpp
Modified : /trunk/fs2_open/code/network/multi_ingame.cpp
Modified : /trunk/fs2_open/code/network/multi_kick.cpp
Modified : /trunk/fs2_open/code/network/multi_log.cpp
Modified : /trunk/fs2_open/code/network/multi_obj.cpp
Modified : /trunk/fs2_open/code/network/multi_obj.h
Modified : /trunk/fs2_open/code/network/multi_observer.cpp
Modified : /trunk/fs2_open/code/network/multi_oo.cpp
Modified : /trunk/fs2_open/code/network/multi_options.cpp
Modified : /trunk/fs2_open/code/network/multi_pause.cpp
Modified : /trunk/fs2_open/code/network/multi_pinfo.cpp
Modified : /trunk/fs2_open/code/network/multi_ping.cpp
Modified : /trunk/fs2_open/code/network/multi_pmsg.cpp
Modified : /trunk/fs2_open/code/network/multi_rate.cpp
Modified : /trunk/fs2_open/code/network/multi_respawn.cpp
Modified : /trunk/fs2_open/code/network/multi_team.cpp
Modified : /trunk/fs2_open/code/network/multi_update.cpp
Modified : /trunk/fs2_open/code/network/multi_voice.cpp
Modified : /trunk/fs2_open/code/network/multi_xfer.cpp
Modified : /trunk/fs2_open/code/network/multilag.cpp
Modified : /trunk/fs2_open/code/network/multimsgs.cpp
Modified : /trunk/fs2_open/code/network/multiteamselect.cpp
Modified : /trunk/fs2_open/code/network/multiui.cpp
Modified : /trunk/fs2_open/code/network/multiutil.cpp
Modified : /trunk/fs2_open/code/network/psnet.cpp
Modified : /trunk/fs2_open/code/network/psnet2.cpp
Modified : /trunk/fs2_open/code/network/stand_gui-unix.cpp
Modified : /trunk/fs2_open/code/network/stand_gui.cpp
Modified : /trunk/fs2_open/code/object/collideshipweapon.cpp
Modified : /trunk/fs2_open/code/object/object.cpp
Modified : /trunk/fs2_open/code/parse/sexp.cpp
Modified : /trunk/fs2_open/code/playerman/managepilot.cpp
Modified : /trunk/fs2_open/code/playerman/playercontrol.cpp
Modified : /trunk/fs2_open/code/popup/popupdead.cpp
Modified : /trunk/fs2_open/code/radar/radar.cpp
Modified : /trunk/fs2_open/code/radar/radarorb.cpp
Modified : /trunk/fs2_open/code/ship/afterburner.cpp
Modified : /trunk/fs2_open/code/ship/awacs.cpp
Modified : /trunk/fs2_open/code/ship/shield.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Modified : /trunk/fs2_open/code/ship/shipfx.cpp
Modified : /trunk/fs2_open/code/stats/scoring.cpp
Modified : /trunk/fs2_open/code/stats/stats.cpp
Modified : /trunk/fs2_open/code/weapon/beam.cpp
Modified : /trunk/fs2_open/code/weapon/emp.cpp
Modified : /trunk/fs2_open/configure.ac
Revision: 2289
Author: wmcoolmon
Date: 11:13:29, Sonntag, 9. Oktober 2005
Message:
Added warpin/warpout speed override values to ships.tbl
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/object/collidedebrisship.cpp
Modified : /trunk/fs2_open/code/object/collideshipship.cpp
Modified : /trunk/fs2_open/code/ship/ship.cpp
Modified : /trunk/fs2_open/code/ship/ship.h
Modified : /trunk/fs2_open/code/ship/shipfx.cpp
Modified : /trunk/fs2_open/code/ship/shipfx.h
Revision: 2285
Author: wmcoolmon
Date: 05:13:13, Sonntag, 9. Oktober 2005
Message:
Much better laser weapon/pof handling, removed a couple unneccessary
warnings (used to try and track down a bug)
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Modified : /trunk/fs2_open/code/weapon/weapon.h
Modified : /trunk/fs2_open/code/weapon/weapons.cpp
Revision: 2282
Author: wmcoolmon
Date: 21:29:08, Samstag, 8. Oktober 2005
Message:
Attempt to fix crash bug on 'Mystery of the Trinity'
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Revision: 2281
Author: wmcoolmon
Date: 20:46:38, Samstag, 8. Oktober 2005
Message:
Error checking for dock error
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
Revision: 2228
Author: Goober5000
Date: 03:41:21, Samstag, 24. September 2005
Message:
this isn't needed because of is_support_allowed
--Goober5000
----
Modified : /trunk/fs2_open/code/ai/aicode.cpp
-
This is a good read. Interesting to think that the SCP accidentally enhanced the hostile AI...
-
ah. The Sync problem was traced down to a WMC blunderbuss commit; I wouldn't be surprised if this were traced down too.
Next time I'm on IRC I'll work on this, assuming someone hasn't by then.
-
So basically all these balance issues are because of a simple oversight?
-
So basically all these balance issues are because of a simple oversight?
Possibly, but it's still unclear what the oversight was/is...
For the record, I'm taking great pains to make sure my AI changes don't mess with retail behavior. I hope they succeed. :)
-
So basically all these balance issues are because of a simple oversight?
It's neither simple nor should it have been an oversight. It's a preventable problem caused by not adhering to proper procedure. Two major things are wrong with that massive commit: first, several features were committed all at once, instead of one at a time. Second, the features were not tested sufficiently before being added to source; it was as if the coder took everything on top of his desk and dumped it on someone else's desk.
I bear some of the blame for this because I haven't been consistent in enforcing the coding and source control standards. Those omnibus (which I called blunderbuss because they're at high risk for blunders) feature commits are just the sort of thing we should NOT be doing. They hide bugs at the time because the sheer amount of code makes it hard to tell what changed; and they hide bugs later on because you can't go back and make one incremental build per incremental feature. In fact, just a week ago when I tracked down the Sync bug, it took me six hours to create a differential build because I had to disentangle one feature from all its dependencies. There was a stretch of 30-odd commits which ALL had severe compile errors.
WMC and Bobboau were the worst offenders, but every coder is susceptible to this if he doesn't take precautions. Things should be done one-at-a-time, and carefully. I got nervous when I saw that giant Antipodes merge the other day; I really hope that those features were tested individually before they were merged into trunk...
-
I got nervous when I saw that giant Antipodes merge the other day; I really hope that those features were tested individually before they were merged into trunk...
Me too - I took a long time checking that one out before committing it.
It's been tested by at least 4 people (probably more than most features :P ), however the feedback on the Antipodes post wasn't as comprehensive as I was expecting (the four testers provided a lot of feedback through IRC).
-
AI; Now bombs like a player (well, an ok one), leading to fleets of incoming bombs from wings of bombers (they fire -> change bank, -> fire, etc)
Most of the other behaviour problems aren't very easy to convey (*without using fraps, which, well you'll see my FPS on this screenie..), but this one, I have a pretty pretty screenie for it xP
(http://i19.photobucket.com/albums/b177/QuantumDelta/ShivanSwarmBombs.jpg)
(http://i19.photobucket.com/albums/b177/QuantumDelta/ShivanSwarmBombs2.jpg)
Couple people been complaining this one has been breaking missions with bombers in it.
I'm exceptionally good at shooting down bombs (that cruiser, what you don't see, is there are also a wing of nahema on the OTHER side of it/the bomb explosions in the second shot, coming in with 16 bombs as well, the ship still lasted another 60 seconds), and there are still missions I find _very_ difficult because of this one ;P
'tis the next one to track down I imagine, after we get together and nail down the "never gonna give you up" one.
-
This affects SP too? I always felt like bomber interception has been stupidly hard.
-
Bomber interception is made harder by several currently compounded bugs.
A) Bombs are virtually (*I'm not sure I've ever managed it?) impossible to shoot down from directly behind, and the closer you are to 'directly behind' in angle, the harder the bombs are to shoot down, in the past bombs just blew up if you shot 'near' them (they still do if you shoot them from the side to a degree), but now you can actually put primaries right through the bombs and it not hit.
B) Bombers are being augmented, more than any other ships by the 'improved shields' AI, this is ridiculously noticeable on FSPort missions where you have to use an avenger vs a target, because they adjust their shields into the quadrants you're shooting at like a player would (well, better than most players TBH :P).
C) Bombers are using the oft-used player trick of swapping secondary banks to fire more bombs, more rapidly, now - this is further abused by the fact that AI doesn't have a 'missile lock' their aspect seekers are locked the moment you're on screen or in range (earlier, even in some rare cases).
This means that they can literally turn into a ship and dump off 3-6 Helios level bombs at almost pointblank range in a matter of a second or two (not sure I've seen 3 (or 6) bombs in 2 sec before though).
At the moment I'm mostly countering this by letting anyone around me (AI/Players) shoot the bombers, whilst I exclusively shoot bombs, because if you try to do both you'll run out of weapon energy. :p
I've seen it in every single mod I've played, on vanilla, and with mvps.
Most of these behavioural changes do carry over between all the mods.
-
This Bomber-fires-many-bombs bug is indeed very evident in single-player as well.
You can particularly see it in the Warzone (http://www.hard-light.net/forums/index.php?topic=65293.0), mission "Northwest Passage"
In that mission, there is a stage where several Seraphim jump in and almost instantly fire multiple warheads each at near-point-blank at one of your convoy.
It's currently impossible to pass that mission, because even if you're sat ready at aimed at their arrival point you can only destroy one of the pair before the other has fired six warheads, which is more than enough to destroy any of your convoy ships.
The bombers in this mission (Nahema and Seraphim) definitely fire off six warheads each in almost every playthrough, so it's probably a good mission for testing.
-
I believe there is a flag to allow that behavior but it definitely should be off in retail and the MediaVPs. The commit of that flag and what it controls might be a good place to start the search for the change in behavior though.
-
...A) Bombs are virtually (*I'm not sure I've ever managed it?) impossible to shoot down from directly behind, and the closer you are to 'directly behind' in angle, the harder the bombs are to shoot down, in the past bombs just blew up if you shot 'near' them (they still do if you shoot them from the side to a degree), but now you can actually put primaries right through the bombs and it not hit...
I thought I it had always been so.
[EDIT]Corrected a rather funny typo.
-
...A) Bombs are virtually (*I'm not sure I've ever managed it?) impossible to shoot down from directly behind, and the closer you are to 'directly behind' in angle, the harder the bombs are to shoot down, in the past bombs just blew up if you shot 'near' them (they still do if you shoot them from the side to a degree), but now you can actually put primaries right through the bombs and it not hit...
I don't remember the bombs being any different than now, they still explode when you shoot "next" to them, it doesn't matter from where are you shooting. You might want to check this also: if you try to shoot down a bomb that's too close to the target you won't be able to do so, only the target itself seems to be capable of destroying those bombs, might be a code/table thing.
-
If you're too close to bombs and your weapons aren't exactly in the centre of your ship you need to adjust slightly :P
In regards to shooting them down, they haven't changed that much besides a reduction in functional rear and front hitbox size, you can assume you wont shoot a bomb from behind, whereas if you're to the side of the bomb you can shoot 'around' it and 'miss' but still cause the bomb damage (in most cases destroying it), this doesn't happen much/at all from behind.
On multi this problem is extreme, since bombs don't seem to track properly to clients (read; they can't shoot them from the side, and moving in behind them means hitbox problems :P).
Trust me, there's a difference ;\
Go back and play some fs2 retail if you don't believe me :<
-
I concur that bomb hitboxes seem to have changed.
-
Do you get this problem in 3.6.10 as well? Or is it only 3.6.11 builds that suffer from this?
-
I believe there is a flag to allow that behavior but it definitely should be off in retail and the MediaVPs. The commit of that flag and what it controls might be a good place to start the search for the change in behavior though.
There is? If so, it's not in ai profiles... at least not on the wiki...
-
I believe there is a flag to allow that behavior but it definitely should be off in retail and the MediaVPs. The commit of that flag and what it controls might be a good place to start the search for the change in behavior though.
There is? If so, it's not in ai profiles... at least not on the wiki...
I think he means;
$smart secondary weapon selection:
FS2 Open, 3.6.10 or earlier:
* If set, enables the new secondary weapon selection method (including proper use of bomber+ missiles)
Edit;
Also, confirmed, bomber improved bomb dropping behaviour isn't present in 3.6.10 Final Kara :P
They still launch what seems like more bombs than they used to, but no where near what is in current SCP (*side note, I'm not SURE they launch more bombs than they used to in Final, it just 'looked' like it, but) there is a definite and significant difference that I imagine anyone would be able to observe playing Apocalypse and watching the scene I posted pics from above right at the start of the mission, between final and .5615, for example.
-
I believe there is a flag to allow that behavior but it definitely should be off in retail and the MediaVPs. The commit of that flag and what it controls might be a good place to start the search for the change in behavior though.
There is? If so, it's not in ai profiles... at least not on the wiki...
I think he means;
$smart secondary weapon selection:
Ah. Well, after digging through the code a bit, I'm pretty sure that $smart secondary weapon selection doesn't make the AI change secondary banks more quickly. At least, not directly...still investigating.
Edit;
Also, confirmed, bomber improved bomb dropping behaviour isn't present in 3.6.10 Final Kara :P
They still launch what seems like more bombs than they used to, but no where near what is in current SCP (*side note, I'm not SURE they launch more bombs than they used to in Final, it just 'looked' like it, but) there is a definite and significant difference that I imagine anyone would be able to observe playing Apocalypse and watching the scene I posted pics from above right at the start of the mission, between final and .5615, for example.
Hmm. What happens in, say, 5542?
EDIT: Link to build:
http://www.mediafire.com/?sharekey=767261bd3368c539b64026cfc0611236e04e75f6e8ebb871
-
I was actually asking about the bomb radius thing more than the bomb dropping thing.
-
Actually that seems to be different too (harder to tell then with the bomber drop million bombs thing tho :P), bomb radius seems to be a fair bit bigger on pre-5548 builds (couldn't find a windows build which was 5545, but 5541 and 5548 have what FEELs to be quite a big difference).
Enhanced Bomber behaviour wasn't in 5548 either btw.
-
Actually that seems to be different too (harder to tell then with the bomber drop million bombs thing tho :P), bomb radius seems to be a fair bit bigger on pre-5548 builds (couldn't find a windows build which was 5545, but 5541 and 5548 have what FEELs to be quite a big difference).
Enhanced Bomber behaviour wasn't in 5548 either btw.
Aw blast. 5549 was big AI commit of mine, so it's looking like that's the culprit (for some things anyway). Time to figure out how I screwed up bombers...and if I screwed up anything else in the process...
-
Aw blast. 5549 was big AI commit of mine, so it's looking like that's the culprit (for some things anyway). Time to figure out how I screwed up bombers...and if I screwed up anything else in the process...
Well I haven't tested 5549 yet, I'll do that now - I had to pop out earlier.
Edit;
Heh, that's not even subtle, the bomber AI change is in 5550 ;)
-
Aw blast. 5549 was big AI commit of mine, so it's looking like that's the culprit (for some things anyway). Time to figure out how I screwed up bombers...and if I screwed up anything else in the process...
Well I haven't tested 5549 yet, I'll do that now - I had to pop out earlier.
Edit;
Heh, that's not even subtle, the bomber AI change is in 5550 ;)
So, the change is in 5550 but NOT 5549? Or did you only test 5550?
Another thing to watch out for is that between 5543 and 5549 (inclusive) there was another bug that had to do with afterburner (it was fixed in 5550). Make sure you aren't confounding with that.
-
Only tested 5550, 5548, and 5541 (*closest available from the nightly forum :P)
-
Here's a 5549 for you.
http://www.mediafire.com/?sharekey=767261bd3368c539b64026cfc0611236e04e75f6e8ebb871
-
Okay;
5549, bombers launch 4 bombs on their way into the Ptah-Nu at the start of Apocalypse.
5550, bombers launch 12 bombs on their way into the Ptah-Nu at the start of Apocalypse.
It's _definitely_ 5550 :P
-
Maybe that 'unreachable' code wasn't so unreachable after all?
-
Okay;
5549, bombers launch 4 bombs on their way into the Ptah-Nu at the start of Apocalypse.
5550, bombers launch 12 bombs on their way into the Ptah-Nu at the start of Apocalypse.
It's _definitely_ 5550 :P
And I assume you still get the 12-bomb thing in the latest nightlies...
5550 is a fairly small commit by Kara, with the following changes:
Change #1: Fix afterburner bug.
Change #2: Remove unreachable code.
Change #3: Added some missing typecasts dealing with ships taking off or landing at a hangar bay.
None of those things seem like they should have any impact at all on bombs. Very strange. To be honest, I haven't a clue what's going on there.
Maybe there's some other subtle difference between nightly builds the builds I've been giving you? Here's a 5550 that I built, if you want to check:
http://www.mediafire.com/?sharekey=767261bd3368c539b64026cfc0611236e04e75f6e8ebb871
Maybe that 'unreachable' code wasn't so unreachable after all?
Maybe, but I don't see how. It's of the form
if (Stuff)
{
do stuff
return
}
else
{
do other stuff
return
}
unreachable code here
Seems pretty unreachable to me...
EDIT: Besides, that code has to do with primary weapons, not secondaries.
-
I'm doing a couple of 'before-and-after' builds here to confirm as well.
As Sushi said (while I was typing), the changes don't look like they should have any effect on bombs, even if the 'unreachable' wasn't actually so.
(EDIT)
I don't see the multi-bomb bug in a debug build of 5550.
I'll have a look to see what the next change to AI code was.
Aha - build 5551 has several very big changes in HUGE_SECONDARY stuff, intended as a bugfix to Mantis 1987.
I'll do a build to check, but that looks to be a likely culprit.
-
http://www.hard-light.net/forums/index.php?topic=65395.0
This was my 5550 build x_X
-
...and I'm not seeing it in 5551 either.
I may have utterly screwed up the build process somewhere... going to jump to a build I *know* had it.
(EDIT) Yes, I did screw up the build process. Didn't force a rebuild of /code so the post above is complete tosh. (Still not too familiar with MSVC++)
I'll try that again, this time with Stupid turned off...
-
/soothes Tomo
-
Thanks QuantumDelta, that makes me feel a lot better.
Yes, this does appear in 5550.
I'm seeing Seraphim fire double bombs in 5550, and single bombs in 5549.
And now I'm going to bed before I make an even bigger fool of myself.
-
The only possible explanation is that fixing the afterburner thing is somehow having a knock on effect. Try changing that back to the way it was and see if the problem fixes itself (or I'll try later today).
-
I've done some partial merges between 5549 and 5550, but I'm not seeing conclusive differences.
With just the Afterburner edit, Seraphim 'occasionally' fired double warheads in a couple of runthoughs.
With just the other edits, they also did...
Going to do a bit more - and is there somewhere I can upload these builds to?
I tried to attach them but they are ever so slightly too large.
-
Quite off-topic, but I can't help but think this when I read through this:
The Shivans...
We can rebuild them...
Better... Stronger... Faster...
...
Hey, wait... no, we don't!!!
-
Ok, this is weird.
I'm definitely seeing the multi-bombing bug in SirKnightly's build 5548 - a veritable storm of bombs coming from these Seraphim.
It appears to affect Seraphim much more than the other Shivan bombers in this mod though. (FSCRP_Warzone)
(Edit)
From my testing, this bug appears somewhere between 5515 and 5541
Can someone check my findings?
(Edit)
Further to that, I think this particular change is happening between 5521 and 5522
[attachment deleted by admin]
-
Aha. 5522 was Sushi's ginormous AI commit. Sushi needs to take another look at it then.
-
Hopefully this a final "This is where this happened thing". This one is getting to be like pin the tail on the donkey.
-
Well lets see Sushi's AI fixes involve the use of afterburners if I recall. From reading this the behavior seems to have changed in Kara's afterburner change as well. Sushi just recently fixed an afterburner bug. So did the behavior change again since that commit (5614)?
-
Sushi's 5522 commit was his merge of ai_profiles into the AI struct. And it looks like he didn't do it right at all (for one thing, he uses array references as integer values all over the place). As soon as I get time I'm just going to revert his whole commit.
-
Sushi's 5522 commit was his merge of ai_profiles into the AI struct. And it looks like he didn't do it right at all (for one thing, he uses array references as integer values all over the place). As soon as I get time I'm just going to revert his whole commit.
Aw, crap.
I'll be on IRC in a couple of hours.
-
I'm glad I'm not the only one that noticed the uber bomber issue. On a number of missions in Procoyn Insurgency this was me :mad:
-
I finally got around to debugging this, and it should be fixed in 5618.
It turns out I committed a truly terrible crime: I forgot to initialize some variables. Meaning those variables can be set to ANYTHING when fs2_open runs. Variables which happen to control the AI fire-delay scale for secondary weapons. Including bombs. Meaning the delay between bomb firing could be forever... or zero. And it could be different for different ships, and for different people running the program, and even different every time you load the same stinking mission.
A terrible oversight, I know, but fortunately easily remedied. Please make sure the 5618 fix works. I did my own testing to verify, and bombing behavior now appears to be the same between 5618, 3.6.10 final, and retail FS2.
-
Okay two more things;
The shield management (enhanced shield control behaviour by SCP AI) behaviour is also from the same build, 5522 as far as I can see, played the mission a couple times on 5521 and 5522 and the behaviour is definitely different (no mods/same difficulty (insane), just apocalypse a bunch of times and watched the nephilim/nahema shields).
I need some peeps to corroborate/refute my testings when someone has some time.
The bomber behaviour is definitely fixed in 5618 (Unless I've had a bunch of playthroughs with it randoming to the default behaviour :P), and the bomb 'difficulty to shoot downiness' is still there (especially in multi as described in the post on page 2, though this might be unrelated?).
-
I used QuantumDelta as a guinea pig for an experiment. In this experiment I created a new AI profile that contained only default values. QuantumDelta tested it fairly well and said there's not much, if any difference to default fs2_open AI. Which debunks my theory of FS2 Retail AI profile being b0rked.
So this leads to two possibilities;
1) Current default AI profile default values are not same defaults that the retail FS2 had.
2) There is still code issues causing AI to not to behave like it did in retail.
First should be fairly trivial matter to double-check for anyone who has SVN access. Second is hairy mess, if there's a code issue that causes this difference in AI behavior, it affects all AI profiles no matter what values are being used. Which means that once this AI code bug has been sorted out, there's fairly big chance it will affect mission and gameplay balance of any mod and total conversion, whether they are using custom AI profiles or not.
-
Number 1 is not the problem; the default profile has been checked very carefully to have the same exact values as in retail FS2. In effect, it was moved from being hard-coded in the source code, to being read from the hard-coded file.
It's gotta be number 2 -- and, in fact, I suspected as much based on my testing of ST:R. The first priority should be to fix the AI incompatibility. Once that's done, if anything has dramatically changed, we can add a new AI profile option to activate the "buggy" AI that mods relied on.
-
Right. So for every AI difference we see between Retail and FSO, we need:
1. Clearly defined example of what the difference is.
2. The ability to reproduce the problem (otherwise nearly impossible to debug).
3. When the difference appeared.
QD's been doing a great job at bringing things up so far... but we should probably put a comprehensive list of outstanding AI bugs together somewhere. I guess Mantis is the right place for that.
-
I've mantis one of them last week end :)
-
I have been absolutely rushed off my feet since late November, so I apologise for my absence.
I haven't forgotten about this and I have in mind that Fury asked me to address/list what bugs/peculiarities are left.
Honestly, I want to double check my entire list, because I want to be sure, and right now the only one I /am/ very sure of is the 'not-flinching' which is of course my biggest bugbear.
Anyway, I will get back to giving feed back on as many builds as I can on the issues I find as soon as I can, but needless to say thanks to Sushi and several other peoples hard work a lot of them are indeed either fixed or a lot better these days (...though I'm still considering using one of Fury's AI builds for /everything/ >.>).
Like I said, I want to test through before I make another (current) list.
The previous list was all constructed before Sushi spotted his slight mistake.
-
QD, you might want to check out this thread: http://www.hard-light.net/forums/index.php?topic=65138.0
-
Right, christmas finally gave me the time to check through most of the stuff I had left to check.
I should point out that although I am distinctly aware that it isn't retail behaviour and is still slightly harder than retail AI - Fury's AI is significantly more 'true to freespace' than SCPs current AI, However, most of the bugs in quotes have been fixed.
AI; shield management has dramatically increased.
AI; "not flinching" leading to super-AI accuracy, even to the point where they push the turning limits on their ship.
AI; missile evasion / CM launching is greatly improved (leading to dumbfire missiles on occasion (CM fired almost simultaneously to Missile launch, doesn't bother me much since I don't use aspect seekers if given the choice but I imagine it could annoy some people :P)
AI; Now bombs like a player (well, an ok one), leading to fleets of incoming bombs from wings of bombers (they fire -> change bank, -> fire, etc)
AI; Shivans use "slide" far, far more effectively on some missions haven't worked out what causes it solidly (*looks like collisions and/or target swapping mostly) but they can circle strafe a player.
Subsystem damage - seems a bit high (possibly due to more CPU time free to calculate it), this is most obvious with beams (AAA) but that may also be related to the lack of beamwhack, it is however visible with primaries that have smaller projectiles (subach/kayser/SDG) as well.
Collision damage - especially subsystem damage from collisions seems to be much more punishing, especially on multilplayer (collision physics was always a bit screwed up on multi, the client had a tendency to take a little more damage than the host, but at the moment this has been exacerbated massively - skimming a capital ship at very low speed can leave your fighter on very little hull, or even destroy your ship), it's very difficulty to furball properly because of it (*ramming used to be a tactical decision, now it's near suicide).
Bombs - seem to be significantly harder to shoot down on Multi (their tracking isn't correct - even lag adjusted), they also seem to be very slightly harder to shoot down from behind on Single/As host, but on multi it's virtually impossible, they also don't always report if they have been shot down to the clients - which leaves the clients chasing bombs which aren't there.
Beam accuracy - now this one might raise a few eyebrows, but beams were somewhat inaccurate at the best of times when they were introduced, beams could never be dodged or evaded (*'cept by ducking around a corner whilst they powered up), they either hit, or they miss, currently they seem to use the normal AI code for aiming, and thus have increased weapon accuracy, leading to them virtually never (*never in some cases)missing, when they would have previously missed ~30% of the time.
SCP builds seem to randomly completely lose sync between host and clients (very rare) - it used to happen with laggier clients on Retail, but currently it happens even with sub 100 pings.
The client sometimes crash when the host jumps whilst the client is in respawn (about to get the respawn screen, after their ship has exploded) - Believing this to be a retail bug, but I don't really remember, also other than this condition I'm not sure exactly what causes this.
Another old bug that's gotten slightly worse; Secondaries on ships that are warping in (trebs at a Ravana front beams for example) seem to 'miss' for no discernible reason other than the capships speed is over ~100 or whatever the actual speed is (hard to judge sometimes, but it seems to be just over 100 that this behaviour begins).
Debris - another old bug, not really one that has been made worse by SCP but one that would be greatly appreciated to be fixed. On the host side, Debris is rendered correctly, however on the client side, it's rendered completely differently, different sized debris, different directions of travel, and the real ones obviously are totally invisible, so clients end up 'dying for no reason' on occasion because debris has clouted them in the face.
The remaining bugs are below;
AI; "not flinching" leading to super-AI accuracy.
Subsystem damage - seems a bit high (possibly due to more CPU time free to calculate it?), this is most obvious with beams (AAA) but that may also be related to the lack of beamwhack, it is however visible with primaries that have smaller projectiles (subach/kayser/SDG) as well as missiles, subsystems seem to take 'clearer damage', I'm not suggesting the value of subsystem damage on the weapons involved have changed, because even (see below) collision subsystem damage is dramatically higher.
Collision damage - especially subsystem damage from collisions seems to be much more punishing, especially on multilplayer (collision physics was always a bit screwed up on multi, the client had a tendency to take a little more damage than the host, but at the moment this has been exacerbated massively - skimming a capital ship at very low speed can leave your fighter on very little hull, or even destroy your ship), it's very difficulty to furball properly because of it (*ramming used to be a tactical decision, now it's near suicide for clients).
Bombs - seem to be significantly harder to shoot down on Multi (their tracking isn't correct - even lag adjusted), they also seem to be very slightly harder to shoot down from behind on Single/As host, but on multi as a client it's virtually impossible, they also don't always report if they have even been shot down to the clients - which leaves the clients chasing bombs which aren't there, and being unable to shoot down ones that are. <----- this needs some double checking from other people please!
SCP builds seem to randomly completely lose sync between host and clients (very rare) - it used to happen with laggier clients on Retail, but currently it happens even with sub 100 pings, causes are completely unknown too (or, at least, no one has suggested one to me, happens most regularly on knife fight (very busy mission) and the cold sword (relatively quiet mission)).
The client sometimes crash when the host jumps whilst the client is in respawn (about to get the respawn screen, after their ship has exploded) - Believing this to be a retail bug, but I don't really remember, also other than this condition I'm not sure exactly what causes this.
Another old bug that's gotten slightly worse; Secondaries on ships that are warping in (trebs at a Ravana front beams for example) seem to 'miss' for no discernible reason other than the capships speed is over ~100 or whatever the actual speed is (hard to judge sometimes, but it seems to be just over 100 that this behaviour begins, basically, sometimes missiles will go through the ships hull, other times it will impact (Even if you've aimed it correctly) on the subsystem and do no damage).
Debris - another old bug, not really one that has been made worse by SCP but one that would be greatly appreciated to be fixed. On the host side, Debris is rendered correctly, however on the client side, it's rendered completely differently, different sized debris, different directions of travel, and the real ones obviously are totally invisible, so clients end up 'dying for no reason' on occasion because debris has clouted them in the face.
A few of the multi-only bugs will probably have to be fixed for WiH to be practical online.
-
A few of the multi-only bugs will probably have to be fixed for WiH to be practical online.
Bluh?
-
About the test.. have you used retail data or mediavps or some other dataset?
-
For comparison I stuck mostly to one build, I did update to 5716, and after that I was using the build immediately after the countermeasure fix, which I can't find the number of now (knew I forgot something/shouldn't have deleted it).
All comparisons are "vanilla" SCP vs Patch 1.20 Retail.
Any further tests will be done on the latest but I'm pretty much done again now.
-
I was referring to the game data as it should preferably be kept the same regardless of the exe in use. That is SCP builds should also be tested against the retail data.
-
He only runs with retail data.
-
Vanilla = SCP with retail data (no MVPs).
Retail = Retail ;D
Sorry, but yea, in multi I only run with Vanilla setups as Fubar pointed out.
MVP usage doesn't change these things though, it's there with or without them (*all actual tests done without though).