Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Nightly Builds => Topic started by: SirKnightly on September 20, 2011, 09:59:17 am
-
Here is the nightly for Windows on 20 Sep 2011 - Revision 7767
Group: Inferno
fso-WIN-Inferno-20110920_r7767.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno-20110920_r7767.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno-20110920_r7767.md5)
Group: Inferno_SSE
fso-WIN-Inferno_SSE-20110920_r7767.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20110920_r7767.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20110920_r7767.md5)
Group: Inferno_SSE2
fso-WIN-Inferno_SSE2-20110920_r7767.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20110920_r7767.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20110920_r7767.md5)
------------------------------------------------------------------------
r7763 | The_E | 2011-09-19 10:53:11 -0500 (Mon, 19 Sep 2011) | 2 lines
Changed paths:
M /trunk/fs2_open/code/ai/aiturret.cpp
Small fix for the logic here
------------------------------------------------------------------------
r7764 | The_E | 2011-09-19 13:01:56 -0500 (Mon, 19 Sep 2011) | 2 lines
Changed paths:
M /trunk/fs2_open/code/ship/ship.cpp
Move this check outside the for loop for better performance
------------------------------------------------------------------------
r7766 | IssMneur | 2011-09-19 21:47:39 -0500 (Mon, 19 Sep 2011) | 3 lines
Changed paths:
M /trunk/fs2_open/code/weapon/weapons.cpp
- renamed +frequency to +period to reflect what the code actually does (as Valathil pointed out)
- +period: or +index: is no longer required for $substitute: (default is +index: 0)
- removed unnecessary check on +period: (1 is now a valid period)
------------------------------------------------------------------------
-
Does that mean every time +frequency: is used, it now has to be changed to +period: ?
Or was the old parsing retained?
-
The old parsing was removed. I just checked the log.
-
Yay, now I only have to fix every weapon table entry that uses substitute.
I <3 you guys
-
Hmm, was this a fairly recent feature though? If this had been around a while that probably shouldn't have been done.
-
We've had substitute for a pretty good while now.
Thing is, I wouldn't have minded it if there was a heads up about this. Instead I'm greeted by a whole bunch of error messages on start up with the latest nightly
Some communication between the coders and modders should at least be possible... right?
-
I personally would think it should be possible. OTOH, they could put a huge announcement up that "Hey, we're changing this feature and removing the old way of parsing things" and still have some folks go, "When did that happen?" a few weeks later because they ignored it.
-
its a risk you run when you use cutting edge features in your mod. so long as its a feature that has not been in an official build, it is subject to change. that said its only a string replace operation in your text editor to fix your mods.
-
The change log contains the following line:
- renamed +frequency to +period to reflect what the code actually does (as Valathil pointed out)
Nowhere do I say that I retained compatibility.
If there is a mod that is released that is using with $substitute: I can put the compatibility parsing in. If someone whines loud enough I may put it back as well, but fundamentally, the problem is, if I leave the +frequency: parsing in then we may subtly break a mod sometime in the future because someone adds an actual +frequency: option. So instead I went with the nosily break it now so it is cannot become an issue in the future.
Of course, you could also just blame Valathil. :drevil: Until he pointed out that +frequency was actually a +period, it hadn't even crossed my mind that I had the wrong noun.
-
It's an unfortunate table change to fix up, but Iss Mneur is right.
For features that are added in nightlies in-between official releases every new feature should be considered subject to change and revision. I don't think the SCP has said anywhere that we retain non-depreciation of features between releases.
Once it's in a final release though I'm sure we'd be more hesitant to make these sort of changes.
-
Again, I don't think that a simple thread with "Heads up for mods using *feature name*, we're likely going to change *this* and *that* in the nearby future. You have here by been informed" is too much too ask. I'm not asking for retained compatibility or anything, as things like these are just changes in the table, its not a huge deal. And I'm duly aware that features in nightlies are not final. It's just the lack of communication between the coders and modders that irks me at times.
-
Indeed.
I noticed that modders found quite a few interesting things out only because somebody (usually I :)) was curious about the changelog in the latest nightly.
-
I don't want to seem like I'm picking sides here... but the changelog has always been enough notice for me. I read it every time I download a new nightly. I'm somewhat of the opinion that the changelog is communication enough. Maybe add a bold/colorized warning in the nightly post.. but that would then just be there for someone who doesn't read the changelog.
All in all, I'm trying to respectfully say, that reading the changelog should be plenty of communication about these matters.
-
I don't want to seem like I'm picking sides here... but the changelog has always been enough notice for me. I read it every time I download a new nightly. I'm somewhat of the opinion that the changelog is communication enough. Maybe add a bold/colorized warning in the nightly post.. but that would then just be there for someone who doesn't read the changelog.
All in all, I'm trying to respectfully say, that reading the changelog should be plenty of communication about these matters.
Well, unless I'm missing something, the only place to get the complete changelog would be checking the svn logs unless you want to check every single nightly thread. It's not very convenient if you're just a modder who doesn't care about the internals of the engine and doesn't want to sift through dozens of log entries per week to see if there's something in there you should take note of.
It would be very handy if there was a separate log/thread/whatever which would contain a list of all changes which modders need to know about (that is, those which break compatibility in some way, such as the +frequency->+period change). Could be as simple as links to the relevant svn revisions.
-
its really hard to get informed about most features because coders can implement em faster than modders can learn how to use em. i was on top of almost every feature in the game till about 2006 when there were just too many of them to keep track of (part of that was due to scripting, and while i was learning lua a bunch of other features came into being that had completely alluded me). modding at the cutting edge has its drawbacks though, your constantly changing things as the features mature. you can easily loose modding time to this kinda stuff. its just part of being on the bleeding edge. these days i find a new surprise almost every time i look at the wiki.
thats why i have a ton of scripts that just dont work anymore, as wmc was still hammering out a consistent paradigm for the system, i was scripting to see what it could do, so when things were drastically altered i figured it was for the better good, and patched what code i could and rewrote the rest, and some work was lost, but im sure my feedback at the time was valuable. so theres nothing wrong with modding on the bleeding edge, its how most of the testing is done. you may loose some work every now and then but when you think about it both engine and mods gain from this kind of stuff.
-
Actually, that's exactly what I do. I got in the habit of reading the changelog every time a new nightly is posted. I do this even if I don't download the nightly. Really, there's not that many nightly releases that should make it difficult. Just start now and keep it up. Make it part of your forum reading routine.
I will concede that the changelog often doesn't contain enough information about some things. But that's easily changed by simply asking any commits to try and be a little more clear. I have seen some that say things like "This breaks parsing, reverting" which leave my wondering what is "this".
But I don't need the coders need to be responsible for yet another thread and sifting through which changes are important enough to go in it. I'd rather the coders spend their time coding. Besides, I know there are some coders that forget to even put their features on the Wiki. Should they add another spot for them to remember to change?
In the end, it's not my decision anyway.
EDIT: Actually reading over the thread again.. it seems people were originally upset about the change that was made and it got turned into a discussion about communication. I can't help but notice that the issue was discovered because of a "communication" thread... To me, it really seems like this can be a civil discussion about keeping the old parsing or not rather than this generic discussion about communication between coders and modders.
-
There's also the online log (https://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query), so you have a place to catch up on all the commits you want between nightlies instead of having to read each thread.
-
There's also the online log (https://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query), so you have a place to catch up on all the commits you want between nightlies instead of having to read each thread.
This web page is not available
The web page at https://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query might be temporarily down or it may have moved permanently to a new web address.
Error 15 (net::ERR_SOCKET_NOT_CONNECTED): Unknown error.
-
There's also the online log (https://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query), so you have a place to catch up on all the commits you want between nightlies instead of having to read each thread.
This web page is not available
The web page at https://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query might be temporarily down or it may have moved permanently to a new web address.
Error 15 (net::ERR_SOCKET_NOT_CONNECTED): Unknown error.
I can access it fine. Maybe it's a problem on your end.
-
Ok fine, take the 's' off (http://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query) :P
-
thanks :D
-
Well, unless I'm missing something, the only place to get the complete changelog would be checking the svn logs unless you want to check every single nightly thread. It's not very convenient if you're just a modder who doesn't care about the internals of the engine and doesn't want to sift through dozens of log entries per week to see if there's something in there you should take note of.
It would be very handy if there was a separate log/thread/whatever which would contain a list of all changes which modders need to know about (that is, those which break compatibility in some way, such as the +frequency->+period change). Could be as simple as links to the relevant svn revisions.
In fact. we have one of those threads already, 3.6.13 ChangeLog (http://www.hard-light.net/forums/index.php?topic=69362.0). Notice how neglected it is. To be honest, SCP has a hard enough time making sure that all of the coders update the wiki for things that they change or add so that there is documentation of the features, let alone yet another place for us to sometimes put things (because you don't want to know about internals of the engine).
Chief just posted the link to the SVN change log, which I think he should include in the template for all nightlies going forward so that those that don't catch every nightly post can still find out what is going on.
Actually, that's exactly what I do. I got in the habit of reading the changelog every time a new nightly is posted. I do this even if I don't download the nightly. Really, there's not that many nightly releases that should make it difficult. Just start now and keep it up. Make it part of your forum reading routine.
I will concede that the changelog often doesn't contain enough information about some things. But that's easily changed by simply asking any commits to try and be a little more clear. I have seen some that say things like "This breaks parsing, reverting" which leave my wondering what is "this".
But I don't need the coders need to be responsible for yet another thread and sifting through which changes are important enough to go in it. I'd rather the coders spend their time coding. Besides, I know there are some coders that forget to even put their features on the Wiki. Should they add another spot for them to remember to change?
In the end, it's not my decision anyway.
EDIT: Actually reading over the thread again.. it seems people were originally upset about the change that was made and it got turned into a discussion about communication. I can't help but notice that the issue was discovered because of a "communication" thread... To me, it really seems like this can be a civil discussion about keeping the old parsing or not rather than this generic discussion about communication between coders and modders.
Indeed, there is only one "nightly" a day posted (sometimes we get Linux or OSX ones as well, but they just rehash the contents of the Windows posts).
Yes, some of the commit messages can be rather useless but most of the time that is because what ever they are changing is actually that unimportant. However, the best way to fix the useless commit messages is to just bug the coder that committed them to elaborate on the change (not another coder that happens to be online, because that will not change the offenders behaviour).
RE: this thread. HLP, we know drama! It seems to me that the original problem was that I didn't announce to the world (in advance) that I was breaking parsing. I suppose the extension to that is that the commit message doesn't explicitly call out that the parsing breaks, which I will keep in mind the next time that I make a break change. I have already posted my reasoning for the change and I still stand by that reasoning. As I noted in the explanation, if I broke a released MOD I will put the legacy parsing in, however, as others have already noted, SCP does not guarantee compatibility between releases never mind between the random shards that are the nightly builds.
-
It seems to me that the original problem was that I didn't announce to the world (in advance) that I was breaking parsing. I suppose the extension to that is that the commit message doesn't explicitly call out that the parsing breaks, which I will keep in mind the next time that I make a break change.
That doesn't change much.
What I'm asking for is a heads up post *before* things get commited and broken.
-
'Kay, here's my silly two cents.
On one hand, this is the nightly board, where things can break at the slightest whim. Modders should be paying attention to the board for new or changed stuff. However, it takes missing one log to be completely thrown out of the loop. Sometimes the nightlies can be crammed full of housekeeping that we might miss a critical change (like all the PVS Studio stuff).
The public SCP board usually has a thread for each large feature that a coder is working on, like Valathil's amazing shader work. I couldn't find one for substitute, just a few threads asking about bugs relating to substitute. For the coders, it might be an idea to have start these sorts of threads normally, one so they can easily announce any changes and can be seen by modders clearly, and so any comments on it can be in a single thread, and not divided into multiple ones that can be lost easily. It would also increase visibility of what the coders are working on.
-
Of course, you could also just blame Valathil. :drevil: Until he pointed out that +frequency was actually a +period, it hadn't even crossed my mind that I had the wrong noun.
Trolololololololoooooo
-
Stoopid sexy Valathil. :nono:
-
This is a veritable tempest in a teapot.
-
I feel its really unforunate (and at times really counter productive, I mean just how many features get added that hardly anyone uses because no modder even know it exists?) that the scp seems intend on keeping everything as untransparant as possible (Alas no, I'm not digging the 'read every svn commit to see if there is anything noteworthy' suggestion much). Axem made a good suggestion, but from the looks at how this is just waved away as something trival I doubt anyone is going to even consider it. :(
At times I wished that every coder was also a modder....
-
Well, uh, if its breaking parsing, change the wiki.
And then when you run the mod an error will pop out, then you can go check the wiki, and fix it.
yay?
Bigger things can (and do) change than parsing which is almost trivial.
Hell, you can't actually play a lot of older campaigns anymore since all the decals/ballistic ammo stuff isn't parsed anymore and spits errors. Nobody complained about that. Why complain about one measly word of one feature that hasn't even been in a single released mod (as of the posting of the nightly)?
Maybe there could be a massive changelog thread every stable release (that filters out all of the housekeeping stuff that no one really cares about), but outside of the SVN logs and the nightly changelog boxes, there's not real way to feasibly note every single change manually...
-
Why complain about one measly word of one feature that hasn't even been in a single released mod
*sigh*
I'm complaining about the lack of communication coming form the coder side of things. At least read the whole thread.
But whatever, I'm probably not going to get taken seriously anyway. Nothing will change and everyone will just say that I'm trying to stir up drama.
I give up.
-
Lurk #SCP? :p
A bunch of people were discussing it there. That's where I found out.
It was found because someone from FotG wanted to substitute every single shot with a 0 lifetime weapon to create a weapon that serves only as a range indicator for a primary bank-slaved turret (done via scripting).
Plenty of information no?
...if only someone would log it.
but who? and where?
It'd be lovely to see that 3.6.13 changelog thread continuously updated, but...people don't do it. So what can you do :/
-
I'm complaining about the lack of communication coming form the coder side of things. ...
But whatever, I'm probably not going to get taken seriously anyway. Nothing will change and everyone will just say that I'm trying to stir up drama.
...
Well, don't be so hasty. I for one agree that some more transparency would be nice. The question though is in exactly how to achieve it.
In this case, it's a feature that exists solely in the .13 build branch, so there is no "Release" compatibility to be kept like there was with Decal (which got broken, yes, and that was my fault and has hopefully since been fixed).
I guess it's expected and accepted that within a dev cycle, that things are "fluid" and not fixed until a Release actually happens. Which is fine, the nightlies do carry that caveat, maybe it needs to be more pronounced.
The only thing I can think of, is in the future, if such a change as the one here takes place, that an immediate follow on post to the log post declares that there has been a change. This does rely on somebody paying attention to the details and being able to keep up with the nightly posts though. I'll try to do that myself, but this also is something that cannot rely on just one person, but could be a feasible system, especially if we can make it a system where the coder that has made the adjustment leads that post if at all possible.
It probably won't do for any sort of -advanced- heads up, but at the very least will give SOME notice that there will definitely be a change in that build which may have a breaking effect on WIP products that may have been relying on it.
We could also consider the possibility of a sticky here in the Nightlies on "Feature Changes" where (by revision) any alterations to behaviour get logged during a dev cycle (so, one for .13, one for .15 and for 3.7.1, 3.7.3, etc) with an attendant discussion thread. Or something. It's something that should probably have some discussion to it, as the point is valid. Expecting that things will change is a far cry different from anybody being able to know about some of the changes in an informative fashion vs. getting proverbially slapped in the face by suddenly having things breaking and not knowing why and then having to find out.
-
Most commits come from several places. Mantis fixes, SCP forum suggestions, hosted project requests, or IRC discussions. The hosted project requests are actually the least transparent of these because the entire forum is private. But, all commits do go through a completely public repository. There's even a mailing list you can be added to if you want immediate notification of commits, although this list itself has not been publicized. We could perhaps use a better system for recording of behavioral changes to the code, but we are a very small team and most of us probably have 0 experience with setting up such a system. If someone would like to spearhead implementing something like that within the SCP, I'd be all for it, but I don't have the time/energy right now to handle it personally.
-
...if you want immediate notification of commits...
For Windows at least (not sure of other platforms) I actually use a utility made by the guy who handles TortoiseSVN (there may also be a Git style application if we ever shift to that) called CommitMonitor (http://tools.tortoisesvn.net/CommitMonitor.html).
You can monitor multiple SVNs and set a "check for changes" frequency, and then view each commits changes. You don't even need to have a checkout for it to work, but I believe you need a working TortoiseSVN install.
-
If you have TortoiseSVN installed, the CommitMonitor automatically uses TortoiseSVN to do the diff.
Sounds like you don't even need TortoiseSVN installed.