There will not be a changelog for beta 242. Rather than looking for testing of specific changes (This is what is done internally, anyway) we are seeking the 'vibe' the 'feel' and the anecdotal issues people encounter when they try out the build.
What good would it be to have someone with high framerates beta test performance optimization? Or spending hours playing maps that haven't been touched and never getting to the map at the end of the mapcycle that have been remapped extensively?
Some of you are really kind of missing the point here. The purpose of releasing this beta build is not to get detailed feedback about if players think Babblers play better or not, or even if people are getting better FPS (though if you are it is good to report it). It is to look for script errors and crashes and game breaking bugs, which don't require you to know what has been changed. Did a babbler jump at you and suddenly you couldn't move anymore? Did your FPS get cut in half for some reason? Do you not see infestation at all or something? These are the sort of things we really want to make sure are sorted out BEFORE we release the patch, and what we are focused on at this point, not getting into a balance discussion regarding Babblers. So, really, the more people playing this beta build and testing it out and reporting issues, the less likely there will be some surprise nasty bugs that spring up in the patch, requiring a hotfix.
I'm assuming the goal here is to get as many people as possible to test the build to maximize the likelihood of finding game-breaking bugs. If that's the case then at least a small amount of effort should be spent on making people want to play it IMO. Just write a brief summary changelog saying that it has some major performance improvements as well as some buffs to Babblers. If somebody downloads the beta specifically because they're excited about the babblers and want to try them out, why is that a bad thing? They'll tell you if the build breaks in the process. The news post would also have been a great opportunity to explain the cyst thing. If you can persuade people to actually jump in and play full-sized games in the build then that seems like the ideal scenario to me.
There will not be a changelog for beta 242. Rather than looking for testing of specific changes (This is what is done internally, anyway) we are seeking the 'vibe' the 'feel' and the anecdotal issues people encounter when they try out the build.
What good would it be to have someone with high framerates beta test performance optimization? Or spending hours playing maps that haven't been touched and never getting to the map at the end of the mapcycle that have been remapped extensively?
Some of you are really kind of missing the point here. The purpose of releasing this beta build is not to get detailed feedback about if players think Babblers play better or not, or even if people are getting better FPS (though if you are it is good to report it). It is to look for script errors and crashes and game breaking bugs, which don't require you to know what has been changed. Did a babbler jump at you and suddenly you couldn't move anymore? Did your FPS get cut in half for some reason? Do you not see infestation at all or something? These are the sort of things we really want to make sure are sorted out BEFORE we release the patch, and what we are focused on at this point, not getting into a balance discussion regarding Babblers. So, really, the more people playing this beta build and testing it out and reporting issues, the less likely there will be some surprise nasty bugs that spring up in the patch, requiring a hotfix.
I'm assuming the goal here is to get as many people as possible to test the build to maximize the likelihood of finding game-breaking bugs. If that's the case then at least a small amount of effort should be spent on making people want to play it IMO. Just write a brief summary changelog saying that it has some major performance improvements as well as some buffs to Babblers. If somebody downloads the beta specifically because they're excited about the babblers and want to try them out, why is that a bad thing? They'll tell you if the build breaks in the process. The news post would also have been a great opportunity to explain the cyst thing. If you can persuade people to actually jump in and play full-sized games in the build then that seems like the ideal scenario to me.
Also the reason I think having it as a mod would helpful, although I see the reasoning behind having it the way it is. I'll still try but having to download a patch each time to swap between the two versions could get old quickly, especially for those with slow connections or limited data plans.
Maybe's it's about time we see a different method of testing, like having a Natural Selection 2 Beta downloadable on Steam that contains the in-progress version of the next patch.
Thank you for doing this! This has to be one of the best things to come from NS2 since release. No longer will we be subjugated by the opinions of the testers.
There will not be a changelog for beta 242. Rather than looking for testing of specific changes (This is what is done internally, anyway) we are seeking the 'vibe' the 'feel' and the anecdotal issues people encounter when they try out the build.
What good would it be to have someone with high framerates beta test performance optimization? Or spending hours playing maps that haven't been touched and never getting to the map at the end of the mapcycle that have been remapped extensively?
Some of you are really kind of missing the point here. The purpose of releasing this beta build is not to get detailed feedback about if players think Babblers play better or not, or even if people are getting better FPS (though if you are it is good to report it). It is to look for script errors and crashes and game breaking bugs, which don't require you to know what has been changed. Did a babbler jump at you and suddenly you couldn't move anymore? Did your FPS get cut in half for some reason? Do you not see infestation at all or something? These are the sort of things we really want to make sure are sorted out BEFORE we release the patch, and what we are focused on at this point, not getting into a balance discussion regarding Babblers. So, really, the more people playing this beta build and testing it out and reporting issues, the less likely there will be some surprise nasty bugs that spring up in the patch, requiring a hotfix.
And, as Asraniel said, the infestation not showing up on the alien map is a temporary measure. Hopefully we can get some kind of fix in before the patch goes live, but if not, I'm sure there will be something soon after. We are really focused on performance, since that seems to be what everyone has been asking for, and in order to make some of these big increases it may involve breaking some things, at least temporarily.
Yes but what we're saying is if you would show a little effort, you'd get many more players to test the beta and a greater likelyhood that bugs won't get through to the even larger player base.
Remember how you couldn't attack as any class if you had babblers attached to you? How the fuck does that get by the playtesters, rofl. That tells me that not a single play tester put babblers on themselves, or anyone.
So you are replicating every cyst and it's properties to the client, regardless of whether or not he can actually see them on the map?
Why not introduce a separate minimap marker entity that doesn't do anything except holding data about the location and type of the building and whether or not it's under attack? Each building keeps a reference to it's entity, so it can update it as needed.
Or are you referring to the overhead of drawcalls for the actual minimap texture of each structure?
Its like any player or structure on the minimap, where its location, orientation, and whether its taking/dealing damage is sent to all the relevant clients afaik.
At first it seemed weird that it would cause any performance problems, but when you multiply all the potential minimap-viewable entities by the number of times the minimap is updated, it turns out to be an issue.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited March 2013
Disagree zek.
What if the patch contained no balance changes or anything interesting? Maintenance patches need testing across varying computers too.
This is optional and is meant for compatibility / bug testing. If you wish to help participate in this, cool, every bit helps.
But if you're looking for fun games or the latest balance change this isn't for you, and you can't expect uwe to accommodate such a thing for every patch either :-/
Those experiencing issues with this build, ensure you're not connecting to a favorited server, and then please provide as much info as possible.
Even feel free to pm me
Thanks!
There will not be a changelog for beta 242. Rather than looking for testing of specific changes (This is what is done internally, anyway) we are seeking the 'vibe' the 'feel' and the anecdotal issues people encounter when they try out the build.
What good would it be to have someone with high framerates beta test performance optimization? Or spending hours playing maps that haven't been touched and never getting to the map at the end of the mapcycle that have been remapped extensively?
Some of you are really kind of missing the point here. The purpose of releasing this beta build is not to get detailed feedback about if players think Babblers play better or not, or even if people are getting better FPS (though if you are it is good to report it). It is to look for script errors and crashes and game breaking bugs, which don't require you to know what has been changed. Did a babbler jump at you and suddenly you couldn't move anymore? Did your FPS get cut in half for some reason? Do you not see infestation at all or something? These are the sort of things we really want to make sure are sorted out BEFORE we release the patch, and what we are focused on at this point, not getting into a balance discussion regarding Babblers. So, really, the more people playing this beta build and testing it out and reporting issues, the less likely there will be some surprise nasty bugs that spring up in the patch, requiring a hotfix.
And, as Asraniel said, the infestation not showing up on the alien map is a temporary measure. Hopefully we can get some kind of fix in before the patch goes live, but if not, I'm sure there will be something soon after. We are really focused on performance, since that seems to be what everyone has been asking for, and in order to make some of these big increases it may involve breaking some things, at least temporarily.
Yes but what we're saying is if you would show a little effort, you'd get many more players to test the beta and a greater likelyhood that bugs won't get through to the even larger player base.
Remember how you couldn't attack as any class if you had babblers attached to you? How the fuck does that get by the playtesters, rofl. That tells me that not a single play tester put babblers on themselves, or anyone.
basically... show a tad bit more effort, imo.
Assumptions like that are silly, as a matter of fact it was indeed spotted by the playtesters but the deadline was already there by the time it was ...
You know what, everyone please stop derailing this thread with: To help or not to help out the devs by opting into the beta branch, because of "reasons"
Instead, if you're interested at all in helping the devs out, please provide p_logall, and potential script errors. I will actively snip any post that's not on topic... Let's try and make this thread a tad bit more useful, shall we
I'm still not able to start a server or explore in the build 242 beta. I have posted about this in tech support, but haven't been able to find a solution. Is there something I can do in the beta to provide more data so we can track down why this is happening? I'd love to be able to track down what is causing this. I used to be able to start servers and explore, and then it got busted many builds ago and hasn't worked since.
Disagree zek.
What if the patch contained no balance changes or anything interesting? Maintenance patches need testing across varying computers too.
Then say that, why the secrecy? I just don't get it. We're all adults here, we can handle up front honesty about what is and isn't in the patch. Worst case scenario somebody tries to offer balance feedback and gets ignored, not the end of the world. Case in point, 242 did contain a controversial change and it's all we're talking about now in spite of the absence of a changelog.
douchebagatronCustom member titleJoin Date: 2003-12-20Member: 24581Members, Constellation, Reinforced - Shadow
edited March 2013
started the game, got 30 fps in menu when I normally get 70 in the menu. tried to join a server and it stayed at 30 fps through loading. was in the server for 1 second, when the game froze up. I never got the option to submit a crash report. This happens every time I launch the game.
This application has requested the Runtime to terminate in an unusual way.
Please contact the application's support team for more information.
Date: 03/16/13
Time: 18:48:46
--------------------------------------------------------------
Build 242
Steam initialized
Render Device: ATI Radeon HD 5700 Series (8.17.10.1172)
Sound Device: Speakers (High Definition Audio Device) stereo
Record Device: Microphone (High Definition Audio Device)
Loading config://ConsoleBindings.json
Loading config://FavoriteServers.json
Main Menu Initialized at Version: 242
Steam Id: 2430118
Resource 1102d970
Resource ec8d6e0
Resource f909d48
Resource f9385e0
Resource f8f8ba8
Resource fbda3c0
Resource f842b80
Resource f9172c8
Resource 15b610e8
Resource fbb30c0
Resource 15af1e20
Resource fd4f030
Resource fba47f8
Resource fb907a0
Resource f8f3458
Resource 15b40a98
Error: IDirect3DDevice9::Reset to 1440x900 failed (Invalid call)
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Error: Direct3DDevice::Unable to get render target data
Connecting to server 74.122.197.230:27015
Loading config://ConsoleBindings.json
Loading config://FavoriteServers.json
Loading 'maps/ns2_refinery.level'
Error: Couldn't open file 'models/cinematics/exoreveal/page_1_panels_1-11 - onosemerges/camera7.model'
Building pathing mesh for level maps/ns2_refinery.level
Finished loading 'maps/ns2_refinery.level'
Error: Couldn't open file ''
Error: Couldn't open file ''
edit: finally got to submit a crash report.
also, sometimes it will crash on startup and not even load up.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
the lack of cysts on the map kind of (really) sucks, is it really that much overhead to keep a client-side copy?
You would not believe just how performance hungry those things are
Actually, there is a kinda archeological issue here - ages ago, the original cyst came with a single infestation entity. When the minimal was added, the infestation was made into a minimal-blip, so for each cyst you dropped, you created 3 entities - the cyst, the infestation and the infestations minimal blip.
Many months later, infestation was re-written into the current full infestation. Among other things, this involved having a cube of infestation around each cyst, so a cyst now had upto 6 infestations ... Each with its own mapblip... So dropping a cyst now generated upto 13 entities.
Ouch. Kinda cool that the engine was fast enough that this was not immediately noticed - endgames can easily have 100+ cysts, so... In a way, too bad - fixing this looks to improve worst case performance by a measly 5-10%.
In 242, infestation was rewritten and is no longer an entity, and are derived from its owner on client and server. So they are no longer transmitted over the network, and are also faster to run.
As a sideeffect, infestations are no longer mapblips, so they don't show up on the minimap anymore.
Though I'm pretty confident they will in the final 242 - there is already an (efficient) patch for it in the internal bug database.
So you are replicating every cyst and it's properties to the client, regardless of whether or not he can actually see them on the map?
Why not introduce a separate minimap marker entity that doesn't do anything except holding data about the location and type of the building and whether or not it's under attack? Each building keeps a reference to it's entity, so it can update it as needed.
Or are you referring to the overhead of drawcalls for the actual minimap texture of each structure?
Its like any player or structure on the minimap, where its location, orientation, and whether its taking/dealing damage is sent to all the relevant clients afaik.
At first it seemed weird that it would cause any performance problems, but when you multiply all the potential minimap-viewable entities by the number of times the minimap is updated, it turns out to be an issue.
Well, I only know the Unreal way of replication:
Each Actor has a special section in script for a Replication Statement. The statement defines which variables are sent to the client (so only a small set of variables actually needs to be replicated, the rest might not even be important to the client or Actor or is handled via clientside prediction) and under which boolean conditions (the usual relevancy conditions are still checked separately). Some are only replicated when the Actor is not on a dedicated server, some only during the very first replication, some only if some other variable is set, some only if the Actor is rendered as mesh, etc.
Two other properties are NetPriority and NetUpdateFrequency. The latter defines how many times per second the server will try to update the Actor for other clients. The Priority defines how often an Actor is updated compared to other Actors, so some get more bandwidth than others. For the radar did I set the frequency to be the same as the actual update frequency on the radar - you don't really see the difference between 0.05 and 0.01, for instance.
Another important aspect is that the server keeps each variable for each client mirrored on it's own side. So the server knows at every time what value a variable has on a client through replication (it does not know when that value changes on the client side through prediction, but the server is not interested in that after all) and will actually check every time during the network update if the current value on the server side matches the already replicated value on that respective client. That may seem like an incredible memory and processing overhead, but it is actually worth the bandwidth and client update that is spared that way when you only replicate a value if it actually changed.
So I don't know which of these rules apply to Spark as well, but the way I solved the radar problem in a UT2k4 mod was to create a separate "marker Actor", set it to be always relevant to all clients and attached it to the Actor it was supposed to mark on the radar. This way it got updated on the server and allowed me to replicate it's own Location and Rotation values to the clients without requiring the marked Actor to be actually relevant to the client, which would have caused the full replication for that Actor to kick in. This way I basically had a lightweight Actor for replication. And if that full replication is really the problem, it could work here as well.
And, as Asraniel said, the infestation not showing up on the alien map is a temporary measure. Hopefully we can get some kind of fix in before the patch goes live, but if not, I'm sure there will be something soon after. We are really focused on performance, since that seems to be what everyone has been asking for, and in order to make some of these big increases it may involve breaking some things, at least temporarily.
In 242, infestation was rewritten and is no longer an entity, and are derived from its owner on client and server. So they are no longer transmitted over the network, and are also faster to run.
As a sideeffect, infestations are no longer mapblips, so they don't show up on the minimap anymore.
Is the pre 242b way related to why spectators can't see cysts on the map?
Sorry if I'm "not constructive" or "being negative" or "whining" or "blaming the poor devs" or whatever.
But there are changes and tradeoffs that make sense, and there are decisions that are just plain bad.
Making the interface more frustrating (and not by a small degree) is just stupid.
Even for "performance reasons". Even "temporarily". The game already runs. People have been playing for the last 5 months.
Though I'm pretty confident they will in the final 242 - there is already an (efficient) patch for it in the internal bug database.
Pheeeeeeeeeeeewwwwwwwwwwwww!!!!
Quite frankly, without that patch, releasing 242 is, for me, just plain unprofessional. Such a big change in a finished game for technical reasons sounds just unprofessional to me. If you can't do it right, don't do it at all (and you can do it right, you are not stupid).
Nobody forces you to release the cyst change (right? :P) if you can just wait 1 or 2 weeks until a real solution is found (apparently you're very close). The game won't lose players or fail to gain new players, for performance reasons, in that timeframe. Seriously.
I don't want to be unfriendly, don't take this as "complaint", I appreciate the dev communication and openness you do despite the obvious drawbacks (other developers don't have these discussions because nobody ever learns about these things), this is just a piece of criticism I think you UWE guys should hear. Appearing unprofessional is not a light issue. Maybe I'm the only one who thinks so, but I wouldn't bet on that.
Hopefully the cyst change will be in the same build as the minimap fix patch, so all this was just moot.
Remember how you couldn't attack as any class if you had babblers attached to you? How the fuck does that get by the playtesters, rofl. That tells me that not a single play tester put babblers on themselves, or anyone.
basically... show a tad bit more effort, imo.
Wtf. Try to join the PT group yourself, or do something else helpful.
More effort....did you ever have a job in your life or at least try to think about what UWE may do all day?
Then say that, why the secrecy? I just don't get it. We're all adults here, we can handle up front honesty about what is and isn't in the patch. Worst case scenario somebody tries to offer balance feedback and gets ignored, not the end of the world. Case in point, 242 did contain a controversial change and it's all we're talking about now in spite of the absence of a changelog.
The second post did mention it in the thread you would leave feedback in / discover the beta , so I don't get the secrecy comment.. that and It's already been mentioned generating change logs isn't an easy task, not to mention once again its not of importance for the purpose of this beta. Which is stated clearly in that same post.
Getting reports of a known missing feature is small compared to the bug reports and crashes like the users are posting. In the same way balance posts could be ignored, like you said. So I fail to see the difference except to spend extra effort and dev time for an inaccurate ever changing log to appease the curious?
Hope that clears things up/ settles it, instead of derailing the thread?
: looks at kouji:
as much as i want to defend uwe, he's got a point here - people only have so much tolerance for 'they're a small team/indie company' - people judge based on results, so it can be pretty damaging if these kinds of seemingly obvious bugs make it into a release build. i know there are a lot of bugs that are brought up by the PTs that don't get addressed in the timeline of a patch, but i wonder if it really would affect them so much to slow down a little and make sure the patch is as polished as possible before releasing. I mean, it always seems like there's some last-minute changes included in the release builds that make bugs happen, and then they have to hotfix. Shouldn't they rather just not include the last-minute changes?
And, as Asraniel said, the infestation not showing up on the alien map is a temporary measure. Hopefully we can get some kind of fix in before the patch goes live, but if not, I'm sure there will be something soon after. We are really focused on performance, since that seems to be what everyone has been asking for, and in order to make some of these big increases it may involve breaking some things, at least temporarily.
This was all that was needed to be said on the minimap change then. The reason some were harping on it is because it was not only a technical change but a balance concern as well. Everyone here (I believe I can say with confidence) is all for any FPS gain or server performance increase but this change in particular was of importance when marines have a slight edge in the current build as it can make khammander (as snoozey as it is) harder.
Thanks for all your efforts and I will try to give the beta build another go tonight.
as much as i want to defend uwe, he's got a point here - people only have so much tolerance for 'they're a small team/indie company' - people judge based on results, so it can be pretty damaging if these kinds of seemingly obvious bugs make it into a release build. i know there are a lot of bugs that are brought up by the PTs that don't get addressed in the timeline of a patch, but i wonder if it really would affect them so much to slow down a little and make sure the patch is as polished as possible before releasing. I mean, it always seems like there's some last-minute changes included in the release builds that make bugs happen, and then they have to hotfix. Shouldn't they rather just not include the last-minute changes?
Patches would never be released because there is always something else to fix/polish. At some point you just have to slap a 'ship it' sticker on it and move on.
This patch is fucking horrible. It is the worst patch ever since NS2 was released. Immediately after starting the beta patch, multiple things went wrong.
First, there are tons of bugs. My game crashed twice.
The FPS tanked
And I don't know what the developers did but my primary gaming computer burst into flames.
Then finally, my pet cat spontaneously combusted.
Logged into the beta build yesterday didn't have any problems. Went to log into tonight got into the game and the client crashed I believe this was due to the steam pop up. Closed the steam pop up and logged back into the server and had no problems. I didn't get a chance to actually play against anyone since no one was on the test servers. Maybe another time.
Also I'm noticing micro stuttering as I rotate my view. I never have noticed this before tried to adjust my settings while I was just running around on the map solo but it didn't help at all.
Comments
You know what they say. You can't make an omelette without shooting some eggs.
Or something like that.
I'm assuming the goal here is to get as many people as possible to test the build to maximize the likelihood of finding game-breaking bugs. If that's the case then at least a small amount of effort should be spent on making people want to play it IMO. Just write a brief summary changelog saying that it has some major performance improvements as well as some buffs to Babblers. If somebody downloads the beta specifically because they're excited about the babblers and want to try them out, why is that a bad thing? They'll tell you if the build breaks in the process. The news post would also have been a great opportunity to explain the cyst thing. If you can persuade people to actually jump in and play full-sized games in the build then that seems like the ideal scenario to me.
Also the reason I think having it as a mod would helpful, although I see the reasoning behind having it the way it is. I'll still try but having to download a patch each time to swap between the two versions could get old quickly, especially for those with slow connections or limited data plans.
Thank you for doing this! This has to be one of the best things to come from NS2 since release. No longer will we be subjugated by the opinions of the testers.
Yes but what we're saying is if you would show a little effort, you'd get many more players to test the beta and a greater likelyhood that bugs won't get through to the even larger player base.
Remember how you couldn't attack as any class if you had babblers attached to you? How the fuck does that get by the playtesters, rofl. That tells me that not a single play tester put babblers on themselves, or anyone.
basically... show a tad bit more effort, imo.
At first it seemed weird that it would cause any performance problems, but when you multiply all the potential minimap-viewable entities by the number of times the minimap is updated, it turns out to be an issue.
What if the patch contained no balance changes or anything interesting? Maintenance patches need testing across varying computers too.
This is optional and is meant for compatibility / bug testing. If you wish to help participate in this, cool, every bit helps.
But if you're looking for fun games or the latest balance change this isn't for you, and you can't expect uwe to accommodate such a thing for every patch either :-/
Those experiencing issues with this build, ensure you're not connecting to a favorited server, and then please provide as much info as possible.
Even feel free to pm me
Thanks!
I lol'd. Thanks for that.
Please provide as much feedback as you can when you do try it, away from our evil influence!
Assumptions like that are silly, as a matter of fact it was indeed spotted by the playtesters but the deadline was already there by the time it was ...
You know what, everyone please stop derailing this thread with: To help or not to help out the devs by opting into the beta branch, because of "reasons"
Instead, if you're interested at all in helping the devs out, please provide p_logall, and potential script errors. I will actively snip any post that's not on topic... Let's try and make this thread a tad bit more useful, shall we
Then say that, why the secrecy? I just don't get it. We're all adults here, we can handle up front honesty about what is and isn't in the patch. Worst case scenario somebody tries to offer balance feedback and gets ignored, not the end of the world. Case in point, 242 did contain a controversial change and it's all we're talking about now in spite of the absence of a changelog.
Does that means you got performance improvement?
I get the following error
edit: finally got to submit a crash report.
also, sometimes it will crash on startup and not even load up.
Actually, there is a kinda archeological issue here - ages ago, the original cyst came with a single infestation entity. When the minimal was added, the infestation was made into a minimal-blip, so for each cyst you dropped, you created 3 entities - the cyst, the infestation and the infestations minimal blip.
Many months later, infestation was re-written into the current full infestation. Among other things, this involved having a cube of infestation around each cyst, so a cyst now had upto 6 infestations ... Each with its own mapblip... So dropping a cyst now generated upto 13 entities.
Ouch. Kinda cool that the engine was fast enough that this was not immediately noticed - endgames can easily have 100+ cysts, so... In a way, too bad - fixing this looks to improve worst case performance by a measly 5-10%.
In 242, infestation was rewritten and is no longer an entity, and are derived from its owner on client and server. So they are no longer transmitted over the network, and are also faster to run.
As a sideeffect, infestations are no longer mapblips, so they don't show up on the minimap anymore.
Though I'm pretty confident they will in the final 242 - there is already an (efficient) patch for it in the internal bug database.
Well, I only know the Unreal way of replication:
Each Actor has a special section in script for a Replication Statement. The statement defines which variables are sent to the client (so only a small set of variables actually needs to be replicated, the rest might not even be important to the client or Actor or is handled via clientside prediction) and under which boolean conditions (the usual relevancy conditions are still checked separately). Some are only replicated when the Actor is not on a dedicated server, some only during the very first replication, some only if some other variable is set, some only if the Actor is rendered as mesh, etc.
Two other properties are NetPriority and NetUpdateFrequency. The latter defines how many times per second the server will try to update the Actor for other clients. The Priority defines how often an Actor is updated compared to other Actors, so some get more bandwidth than others. For the radar did I set the frequency to be the same as the actual update frequency on the radar - you don't really see the difference between 0.05 and 0.01, for instance.
Another important aspect is that the server keeps each variable for each client mirrored on it's own side. So the server knows at every time what value a variable has on a client through replication (it does not know when that value changes on the client side through prediction, but the server is not interested in that after all) and will actually check every time during the network update if the current value on the server side matches the already replicated value on that respective client. That may seem like an incredible memory and processing overhead, but it is actually worth the bandwidth and client update that is spared that way when you only replicate a value if it actually changed.
So I don't know which of these rules apply to Spark as well, but the way I solved the radar problem in a UT2k4 mod was to create a separate "marker Actor", set it to be always relevant to all clients and attached it to the Actor it was supposed to mark on the radar. This way it got updated on the server and allowed me to replicate it's own Location and Rotation values to the clients without requiring the marked Actor to be actually relevant to the client, which would have caused the full replication for that Actor to kick in. This way I basically had a lightweight Actor for replication. And if that full replication is really the problem, it could work here as well.
Sorry if I'm "not constructive" or "being negative" or "whining" or "blaming the poor devs" or whatever.
But there are changes and tradeoffs that make sense, and there are decisions that are just plain bad.
Making the interface more frustrating (and not by a small degree) is just stupid.
Even for "performance reasons". Even "temporarily". The game already runs. People have been playing for the last 5 months. Pheeeeeeeeeeeewwwwwwwwwwwww!!!!
Quite frankly, without that patch, releasing 242 is, for me, just plain unprofessional. Such a big change in a finished game for technical reasons sounds just unprofessional to me. If you can't do it right, don't do it at all (and you can do it right, you are not stupid).
Nobody forces you to release the cyst change (right? :P) if you can just wait 1 or 2 weeks until a real solution is found (apparently you're very close). The game won't lose players or fail to gain new players, for performance reasons, in that timeframe. Seriously.
I don't want to be unfriendly, don't take this as "complaint", I appreciate the dev communication and openness you do despite the obvious drawbacks (other developers don't have these discussions because nobody ever learns about these things), this is just a piece of criticism I think you UWE guys should hear. Appearing unprofessional is not a light issue. Maybe I'm the only one who thinks so, but I wouldn't bet on that.
Hopefully the cyst change will be in the same build as the minimap fix patch, so all this was just moot.
More effort....did you ever have a job in your life or at least try to think about what UWE may do all day?
Getting reports of a known missing feature is small compared to the bug reports and crashes like the users are posting. In the same way balance posts could be ignored, like you said. So I fail to see the difference except to spend extra effort and dev time for an inaccurate ever changing log to appease the curious?
Hope that clears things up/ settles it, instead of derailing the thread?
: looks at kouji:
This was all that was needed to be said on the minimap change then. The reason some were harping on it is because it was not only a technical change but a balance concern as well. Everyone here (I believe I can say with confidence) is all for any FPS gain or server performance increase but this change in particular was of importance when marines have a slight edge in the current build as it can make khammander (as snoozey as it is) harder.
Thanks for all your efforts and I will try to give the beta build another go tonight.
EDIT: Like Wheeee I also C2D on load on Refinery.
https://dl.dropbox.com/u/78956004/client-0317-042947.plog
https://dl.dropbox.com/u/78956004/client-0317-042247.plog
First, there are tons of bugs. My game crashed twice.
The FPS tanked
And I don't know what the developers did but my primary gaming computer burst into flames.
Then finally, my pet cat spontaneously combusted.
None of those are what springs to mind.
Also I'm noticing micro stuttering as I rotate my view. I never have noticed this before tried to adjust my settings while I was just running around on the map solo but it didn't help at all.