@IronHorse@GhoulofGSG9@Airwolf_swe I have two servers running regular NS2 with mods (#1 and #2). I have uploaded male.model from #1 (same size as on #2, should be identical, right?), my ConsistencyConfig.json used until now named "TTO old ConsistencyConfig.json" and the ConsistencyConfig.json with the changes suggested by IronHorse named "TTO #1 ignore model.json" (wasn't sure I did it right and wanted you to confirm). Files can be found here: TTO NS2 Test.zip
The Thirsty Onos # 1 runs IronHorse's version and The Thirsty Onos # 2 runs Ghoul's version of ConsistencyConfig.json. If you want to try it right now Airwolf, make sure # 1 is not running Veil since the new files aren't active until the map changes.
Sucess I could join both Thirst onos server with the changes.
Well server 2 wasent weird since all the consistency check was gone.
Server 1 was also no problem when the model check was gone.
Could do mapchange just fine on both of them.
Both server had Shine admin mod installed.
@ironhorse@GhoulofGSG9 I have the exact md5 checksum as ghoul on my male.model file "7bd7a74b1c39045e2d3bfcc670a0163c"
So I think we managed to narrow it down there is something wrong with the model consistency check making some of us crash.
Dont the official multiplay server have this model consistency check? cause I have no problem joining their servers
@Ironhorse
We did that back in march on the last patch before kodiak patch.
I could join and do mapchange without problems.
All mods was disabled, and the consistency check was on. but I guess we can try that again when Supafred has time.
GhoulofGSG9Join Date: 2013-03-31Member: 184566Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Reinforced - Supporter, WC 2013 - Supporter, Pistachionauts
edited May 2014
Three last things we need to confirm: Is only Shine really causing the issue ( i don't think so ), do mods overall cause the issue ( would be weird ), does the md5 hash of the servers model.file fit?
So I found this UWE Unofficial server 1, Dunno what setting you have on this server.
It was only running Shine administration and Shine NS2 stat mod.
And look at that I crashed at exactly 6% precaching was only using 2gb of RAM, NS2 was only usuing about 0,7Gb of ram when the crash happned.
Loading 'maps/ns2_biodome.level'
Error: PhysX: ConvexHullBuilder: convex hull has more than 255 polygons!
Error: PhysX: Gu::ConvexMesh::loadConvexHull: convex hull init failed!
Error: PhysX: Error cooking body 0 of model models/props/biodome/biodome_container_01_top.model
Building pathing mesh for level maps/ns2_biodome.level
Finished loading 'maps/ns2_biodome.level'
Compiling 'materials/infestation/Infestation.surface_shader'
Compiling 'materials/infestation/infestation_shell.surface_shader'
Error: Couldn't open file 'D:/build/assets/materialsrc/biodome/biodome_glass_01.material'
Error: No shader specified for material 'D:/build/assets/materialsrc/biodome/biodome_glass_01.material' Error: File 'models/marine/female/female.model' failed consistency check!
Im not sure what setting is on that server, but I think we narrowed it down to the consistency check with the model consistency check + eventually Shine administration or Shine NS2 mod.
there seems to be something interfeering between them two, for some of us.
All of my servers male.model has the has the same hash as the one you wrote @GhoulofGSG9.
@Airwolf_swe and I just finished testing the things you asked for.
Default consistency and Shine Admin, Shine NS2Stats, Pregame Plus and NS2+ did not work.
Default consistency and no mods worked.
Default consistency and Shine Admin worked.
Default consistency and Shine Admin and Shine NS2Stats did not work.
Ghoul's consistency and Shine Admin and Shine NS2Stats worked.
Ironhorse's consistency and Shine Admin and Shine NS2Stats worked.
Seems like NS2Stats and some marine consistency check interferes. I hope this helps you. @IronHorse
GhoulofGSG9Join Date: 2013-03-31Member: 184566Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Reinforced - Supporter, WC 2013 - Supporter, Pistachionauts
Now here comes the funny part.
I had the weird idea that as shine get loaded up before the consistency check that might could cause some issues, but while i tested this attempt to fix it with @Airwolf_swe we managed to cause the issue with shine only loaded up ....
Also it doesn't matter when shine loads up, the issue happend still randomly. One time Airwolf could join with no problems, next time he couldn't.
So im pretty much done with all my ideas. There is no difference between server and client model files, the mods don't interfer in any way with the check.
And i'm speaking for all mods im related to. ( ns2+, badges+, shine, ns2stats, pgp )
Now it would be interessting to know how exactly the hashs are created by the engine. Are they hashed from some kind of cache?
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
Have we ruled out any non shine /ns2stats server mods? I am curious if it's just mods in general causing problems. Just put a bunch on there to single this down further
We tried some of the configurations twice with the same result. I can do more tests if @Airwolf_swe is up for it. What kind of tests do you need? I can activate all mods except for NS2Stats (for testing purposes I mean).
I know someone else with this issue and he's running an old PC with Windows XP 32 bits... Maybe something broke with the hashing algorithm when it got changed? Seems the common pattern is 32 bits OS more than specific mods.
GhoulofGSG9Join Date: 2013-03-31Member: 184566Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Reinforced - Supporter, WC 2013 - Supporter, Pistachionauts
edited May 2014
Ok bad news everyone:
After doing some more tests with @Airwolf_swe ( thanks for your time ).
We found out that the issue is caused by any mod, which precaches anything by itself ( basically all larger mods ).
@Mendasp ns2+ just joined the club of issue causing ns2 mods . Also ensl mod etc.
Only good aspect is that until now it was only reported by users with win xp 32 bit. This all points down that this is a familair issue to the extra precache one ....
So i have no idea how we should fix that without engine access, knowlegde about how exactly the hash check works.
Ofc the win xp users are only a small group of ns2 players but its still sad they can't play on any server using a larger mod.
A workaround would be to share the words that server admins of modded server should use a lighten up version of the consistenycheck.json which doesnt includes the marine models (i guess that those are only affacted so far because they are the largest files, which get checked )
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 May 2014
Awesome, at least we have narrowed it down.
Thanks everyone for your help with the matter, and job well done
Although I am unsure what the fix for this would be.. Since UWE has a pretty straightforward stance with how it deals with mods: They are not responsible for them.
So i don't know if this means all large mods have to now do without precaching?? Because more than likely, there will be no engine changes going forward in NS2, which more than likely includes consistency check changes.
Also, that workaround suggested may not work for all, as seen in the first few pages of this thread, some users were failing smaller files like the observatory model.
I like the idea of spreading the word to disable some of the (arguably unnecessary ) strict consistency checking, however.
At least we know what is causing it
Awesome, at least we have narrowed it down.
Thanks everyone for your help with the matter, and job well done
Although I am unsure what the fix for this would be.. Since UWE has a pretty straightforward stance with how it deals with mods: They are not responsible for them.
So i don't know if this means all large mods have to now do without precaching?? Because more than likely, there will be no engine changes going forward in NS2, which more than likely includes consistency check changes.
Also, that workaround suggested may not work for all, as seen in the first few pages of this thread, some users were failing smaller files like the observatory model.
I like the idea of spreading the word to disable some of the (arguably unnecessary ) strict consistency checking, however.
At least we know what is causing it
My ConsistencyCheck Config only checks the map entity models + alien ( not their structures ) models, so yes my workaround works also for that person
Ofc UWE can't allow that check themself, but if admins are rdy to mod their servers i think there is nothing what speaks against that config. ( Marines Models changes don't really have any affect on the balance as aliens have the hive vision anyway and hopefully there won't be any mod messing around with the structure models in a way which allows one site a hugh advantage )
So as i never heard of anyone failing to connect to my server and this is only a certain small usergroup having this issue i can live with the it, not saying that it is great.
Where i see more the problem is that by this issue win xp 32bit users are oviously not able to take part in the ensl.
Great after deleting 570 mb Workshop files and validating(no file) , it finally works again.very fast. 1st connect was an offical Server..., but can i turn sync cloud on again? sry im late....and 570 mb was huge....i have 3 mods.....strange, ok maybe i had more mods. but im sure, it were 3500 filrs and more
im sorry to burst your "everything solved"-bubble, but:
after i spent a good 3 hours to solve the famous "black screen on load", i nuked the install three times in a row to get rid of OP and am quite rabid now....
some details:
Win xp 32 bit, 2Gb Ram
after installing the gam... err the 'frustration', it wanted to optimize itself, which didnt work out, because "game files differ from the server".
following all the steps others had pointed out has no impact at all.
Listen closely please:
1) no mod
2) no beta
3) no steam cloud enabled
4) persists after deletion of %appdata%/ns2 folders
5) happens on localhost (versus ai) and on remote servers
6) does not care if the remoteserver is modded, official, vanilla or broken
7) deleting female.model & male.model / redownloading doesnt help
8) an older (one year ago) build of ns2 worked on the exact same hardware
9) trying the same shit repeatedly in another order doesnt solve it either
10) occurs on fresh install
11) RAM has been 'memtest'ed
12) RAM has more than 15% headroom on crash
ill give the relevant lines of the log:
Error: File 'models/marine/male/male.model' failed consistency check!
Client disconnected (127.0.0.1) Server shutdown
Error: File 'models/marine/female/female.model' failed consistency check!
Main Menu Initialized at Version: 265
Steam Id: 24154610
Error: Attempted to load remote options from a file that does not exist.
Note that i dont want to be ironic here, but a lil snickering has to be uttered:
1) there cant be a mod responsible where no mod is.
2) 32bit cant be the excuse either, neither RAM, since the older build had worked on this very machine (no changes to this machine)
3) as i understand the log, the kodiak-build-update-optimizer does its timeconsuming magic via connecting to localhost. if i get the differing-files-server-client from localhost and additionally the mods on my client are the same as on my localhost server (which they usually are), then it must be bogus or broken or both.
Stop scapegoating mods and OS-architecture and check this *fancy* integrity checks, which are probably breaking this game for a minority. At least everything i percieve, points at integrity checks done wrong somewhere.
Do I understand correctly that x64_128 and x86_128 murmur3 are incompatible? ie, they generate different results, so the hashes cannot be shared across architectures?
Should be documented as such...
If that isnt suspicious.... hashes cant be shared across architectures? What if my ns2 calls into some broken murmurhash3_x86 and compares it with one generated via x64? wouldnt that be funny? This could explain alot.
Well, well... as i have come to write this post... i need to say this: the bug-fixing performance of UWE is pretty substandart... Actually im pretty upset due to this game being a major PITA. I am neither recommending this game, nor UWE's games in general to anyone in the near future.
GhoulofGSG9Join Date: 2013-03-31Member: 184566Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Reinforced - Supporter, WC 2013 - Supporter, Pistachionauts
edited May 2014
@krysopath There was never said that this issue was fixed, i just did some tests and found out that it only happens at win xp 32bit and cetain mods.
Seems like this happens general based on your log which would just validate my theory that somehow the cache gets hashed instead of the files which might gets easily corrupted at 32 bit clients.
Happens this ("Resampling uncompressed animations at 1/2 frame rate to conserve memory") every time before the issue occurs?
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
edited May 2014
Im just amazed that pc loads ns2, let alone run it. :-O
But the game added more stuff every big patch so memsize could be a issue I guess.
RANDOM IDEA.. (ok, I did some consistency file digging but no time to test)
Check if your time in windows is correct! Timezone, time, everything.
VERIFY it vs a internet server! Be sure it worked.
Thanks for the documentation.
Since you didn't provide your techsupport.zip we are just taking you at your word that you are not running any mods.. hope you are doubly sure and are using your log as a means to verify.
I can't even verify if you pass the minimum requirements, as a result?? (your RAM gives me doubt..)
No one has said this issue is fixed.
It definitely started occurring when we switched to murmur hashing and seems to effect 32 bit users / those with low amount of ram. (remember your videocard impacts this value)
But to be very honest with you, I am surprised you are this upset given you are running a no longer maintained OS that is 13 years old and using an architecture that hasn't been shipped with any retail product for the past 8 years. Since we don't know your CPU or Video card, who knows how incompatible your hardware is.
32 bit OS users represent 11% of all steam users and UWE has devoted QUITE A BIT OF RESOURCES in the past to ensure their product remained compatible and bug free for them.
They've even gone so far to cannibalize the game in many areas for the rest of the user base in order to ensure this.
And now, this is the only bug that plagues 32 bit users, and it is being investigated. In case you are unaware, this game launched almost 2 years ago and UWE can no longer dedicate resources to it. This is why bug fixes related to the engine have been slow recently. But now we have a community development team who are going to try to pick up where they left off.
So in short, while I get you are upset you cannot play something you paid for, I do not sympathize with your reaction given the other factors involved. (a] It's being worked on b] Your old PC)
I definitely agree that this new hash checking method is more than likely the root of the issue. It's in our sights.
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 May 2014
Now that you uploaded your tech support file, I can inform you that your PC is below the minimum required specifications to play this game. (Which btw, are unanimously decided as being too low to play a minimum of 30 fps, already)
Your single core processor is the main culprit.. but to be honest with you, every single part of your system is sub par and 14 years old.
So be upset if you'd like, but you should never have been able to run this game in the first place due to the age of the hardware.
Take care.
You could probably run games from around 10 years ago without issues, but your whole architecture is bottlenecked. I would be surprised if you could run NS2 faster than 5-10 FPS on minimum settings.
I'm afraid it's time for you to upgrade, as your system is on average 7-8 years old and does not meet NS2's minimum system requirements and thus cannot be guaranteed to play NS2 properly. Ns2's MINIMUM requirement for CPU is a Core 2 Duo 2.6 ghz - but a 3Ghz Core2Duo chip is recommended. There were huge architectural changes between the Pentium series and the Core series of chips and I'm afraid your CPU just isnt powerful enough.
sorry for my rant, if this was upsetting for you. The "Resampling..." happens everytime, but seems to be unrelated. It happens even on a successful connect.
Just for the sake of argument: Please do know that i know my system well enough. And if you want to search a excuse, then you need to try harder. My system specs arent in question, but upgrading my hardware wont fix issues with hash-generation & consistency checking. Also it wont help my friends, who struggle to launch it on recent hardware. On Release I bought five copies of this game for five different pcs. Of this five pcs, four are suited well enough to run this game. But actually it does launch on 2 of them. You probably may think thats well enough for a game which is released since two years, but i certainly dont think so. Its wasted money. And coming back to the game after two years just to see that it is as mature as on release gives really nice vibes (read rant).
well it was uploaded the moment I created the initial post. PLease dont try to cover up, that you missed it. Because you did, while you cherrypicked my system specs.
OP: Removing the entry , "*.model" in the ConsistencyCheck.json (if that was the right filename) makes the game launch, optimize and connect to any server I was trying to connect to. Yeah it runs with ~20fps with small teams and few structs
sorry for my rant, if this was upsetting for you. The "Resampling..." happens everytime, but seems to be unrelated. It happens even on a successful connect.
Just for the sake of argument: Please do know that i know my system well enough. And if you want to search a excuse, then you need to try harder. My system specs arent in question, but upgrading my hardware wont fix issues with hash-generation & consistency checking. Also it wont help my friends, who struggle to launch it on recent hardware. On Release I bought five copies of this game for five different pcs. Of this five pcs, four are suited well enough to run this game. But actually it does launch on 2 of them. You probably may think thats well enough for a game which is released since two years, but i certainly dont think so. Its wasted money. And coming back to the game after two years just to see that it is as mature as on release gives really nice vibes (read rant).
well it was uploaded the moment I created the initial post. PLease dont try to cover up, that you missed it. Because you did, while you cherrypicked my system specs.
OP: Removing the entry , "*.model" in the ConsistencyCheck.json (if that was the right filename) makes the game launch, optimize and connect to any server I was trying to connect to. Yeah it runs with ~20fps with small teams and few structs
best of wishes,
krysopath
We allready knew that this could be kind of fixed by modifying the ConsistencyCheck.json, the for me important part is that it happens to you without any mods.
I would love to have a log validating this because this would at least change the issue from "being caused by some mods" to "being cause by vanilla"
Also i wasn't upset by your post it was just there was never said it was fixed, just that the state was caused by mods (so nothing uwe has to really care about ) and could be worked around be lighting up the ConsistencyCheck.json.
I only wanted to confirm that removing the *.model checks solves this for me. Mayhaps i caused confusion due to my wording. I wanted to highlight that the current attitude towards solving this problem is dead wrong IMHO. It felt like some two people where jumping to wrong conclusions regarding mods and responsibility of bugfixing.
I provided a log from a vanilla install (made some days ago), which threw the known error. Henceforth change of issue is necessary. But if people just like to bash on my hardware, then this wont happen. Im afraid i cant get this attitude into my head. Why should a slow processor render hash-generation broken?
("well yes, if its coupled with win xp and low ram, barbecue can reach escape velocity"-type of argument)
In my opinion its the bad practice of implementing esoteric and untested algorythms without proper testing. And this is evident. Sorry, this renders me angry.
If i can of some use providing some more evidence, give me a hint!
Comments
The Thirsty Onos # 1 runs IronHorse's version and The Thirsty Onos # 2 runs Ghoul's version of ConsistencyConfig.json. If you want to try it right now Airwolf, make sure # 1 is not running Veil since the new files aren't active until the map changes.
Well server 2 wasent weird since all the consistency check was gone.
Server 1 was also no problem when the model check was gone.
Could do mapchange just fine on both of them.
Both server had Shine admin mod installed.
@ironhorse @GhoulofGSG9 I have the exact md5 checksum as ghoul on my male.model file "7bd7a74b1c39045e2d3bfcc670a0163c"
So I think we managed to narrow it down there is something wrong with the model consistency check making some of us crash.
Dont the official multiplay server have this model consistency check? cause I have no problem joining their servers
Yes, the official servers are using the same exact default consistency checking.
@SupaFred
The next thing to rule out obviously, is: Then have airwolf attempt to join.
Then we will have it narrowed down enough.
Good work, fellas
We did that back in march on the last patch before kodiak patch.
I could join and do mapchange without problems.
All mods was disabled, and the consistency check was on. but I guess we can try that again when Supafred has time.
Quote from march:
It was only running Shine administration and Shine NS2 stat mod.
And look at that I crashed at exactly 6% precaching was only using 2gb of RAM, NS2 was only usuing about 0,7Gb of ram when the crash happned.
Loading 'maps/ns2_biodome.level'
Error: PhysX: ConvexHullBuilder: convex hull has more than 255 polygons!
Error: PhysX: Gu::ConvexMesh::loadConvexHull: convex hull init failed!
Error: PhysX: Error cooking body 0 of model models/props/biodome/biodome_container_01_top.model
Building pathing mesh for level maps/ns2_biodome.level
Finished loading 'maps/ns2_biodome.level'
Compiling 'materials/infestation/Infestation.surface_shader'
Compiling 'materials/infestation/infestation_shell.surface_shader'
Error: Couldn't open file 'D:/build/assets/materialsrc/biodome/biodome_glass_01.material'
Error: No shader specified for material 'D:/build/assets/materialsrc/biodome/biodome_glass_01.material'
Error: File 'models/marine/female/female.model' failed consistency check!
Im not sure what setting is on that server, but I think we narrowed it down to the consistency check with the model consistency check + eventually Shine administration or Shine NS2 mod.
there seems to be something interfeering between them two, for some of us.
@Airwolf_swe and I just finished testing the things you asked for.
Default consistency and Shine Admin, Shine NS2Stats, Pregame Plus and NS2+ did not work.
Default consistency and no mods worked.
Default consistency and Shine Admin worked.
Default consistency and Shine Admin and Shine NS2Stats did not work.
Ghoul's consistency and Shine Admin and Shine NS2Stats worked.
Ironhorse's consistency and Shine Admin and Shine NS2Stats worked.
Seems like NS2Stats and some marine consistency check interferes. I hope this helps you.
@IronHorse
I had the weird idea that as shine get loaded up before the consistency check that might could cause some issues, but while i tested this attempt to fix it with @Airwolf_swe we managed to cause the issue with shine only loaded up ....
Also it doesn't matter when shine loads up, the issue happend still randomly. One time Airwolf could join with no problems, next time he couldn't.
So im pretty much done with all my ideas. There is no difference between server and client model files, the mods don't interfer in any way with the check.
And i'm speaking for all mods im related to. ( ns2+, badges+, shine, ns2stats, pgp )
Now it would be interessting to know how exactly the hashs are created by the engine. Are they hashed from some kind of cache?
After doing some more tests with @Airwolf_swe ( thanks for your time
We found out that the issue is caused by any mod, which precaches anything by itself ( basically all larger mods ).
@Mendasp ns2+ just joined the club of issue causing ns2 mods
Only good aspect is that until now it was only reported by users with win xp 32 bit. This all points down that this is a familair issue to the extra precache one ....
So i have no idea how we should fix that without engine access, knowlegde about how exactly the hash check works.
Ofc the win xp users are only a small group of ns2 players but its still sad they can't play on any server using a larger mod.
A workaround would be to share the words that server admins of modded server should use a lighten up version of the consistenycheck.json which doesnt includes the marine models (i guess that those are only affacted so far because they are the largest files, which get checked )
Thanks everyone for your help with the matter, and job well done
Although I am unsure what the fix for this would be.. Since UWE has a pretty straightforward stance with how it deals with mods: They are not responsible for them.
So i don't know if this means all large mods have to now do without precaching?? Because more than likely, there will be no engine changes going forward in NS2, which more than likely includes consistency check changes.
Also, that workaround suggested may not work for all, as seen in the first few pages of this thread, some users were failing smaller files like the observatory model.
I like the idea of spreading the word to disable some of the (arguably unnecessary ) strict consistency checking, however.
At least we know what is causing it
My ConsistencyCheck Config only checks the map entity models + alien ( not their structures ) models, so yes my workaround works also for that person
Ofc UWE can't allow that check themself, but if admins are rdy to mod their servers i think there is nothing what speaks against that config. ( Marines Models changes don't really have any affect on the balance as aliens have the hive vision anyway and hopefully there won't be any mod messing around with the structure models in a way which allows one site a hugh advantage )
So as i never heard of anyone failing to connect to my server and this is only a certain small usergroup having this issue i can live with the it, not saying that it is great.
Where i see more the problem is that by this issue win xp 32bit users are oviously not able to take part in the ensl.
im sorry to burst your "everything solved"-bubble, but:
after i spent a good 3 hours to solve the famous "black screen on load", i nuked the install three times in a row to get rid of OP and am quite rabid now....
some details:
Win xp 32 bit, 2Gb Ram
after installing the gam... err the 'frustration', it wanted to optimize itself, which didnt work out, because "game files differ from the server".
following all the steps others had pointed out has no impact at all.
Listen closely please:
1) no mod
2) no beta
3) no steam cloud enabled
4) persists after deletion of %appdata%/ns2 folders
5) happens on localhost (versus ai) and on remote servers
6) does not care if the remoteserver is modded, official, vanilla or broken
7) deleting female.model & male.model / redownloading doesnt help
8) an older (one year ago) build of ns2 worked on the exact same hardware
9) trying the same shit repeatedly in another order doesnt solve it either
10) occurs on fresh install
11) RAM has been 'memtest'ed
12) RAM has more than 15% headroom on crash
ill give the relevant lines of the log:
Note that i dont want to be ironic here, but a lil snickering has to be uttered:
1) there cant be a mod responsible where no mod is.
2) 32bit cant be the excuse either, neither RAM, since the older build had worked on this very machine (no changes to this machine)
3) as i understand the log, the kodiak-build-update-optimizer does its timeconsuming magic via connecting to localhost. if i get the differing-files-server-client from localhost and additionally the mods on my client are the same as on my localhost server (which they usually are), then it must be bogus or broken or both.
Stop scapegoating mods and OS-architecture and check this *fancy* integrity checks, which are probably breaking this game for a minority. At least everything i percieve, points at integrity checks done wrong somewhere.
https://code.google.com/p/smhasher/wiki/MurmurHash If that isnt suspicious.... hashes cant be shared across architectures? What if my ns2 calls into some broken murmurhash3_x86 and compares it with one generated via x64? wouldnt that be funny? This could explain alot.
Well, well... as i have come to write this post... i need to say this: the bug-fixing performance of UWE is pretty substandart... Actually im pretty upset due to this game being a major PITA. I am neither recommending this game, nor UWE's games in general to anyone in the near future.
best of wishes,
krysopath
Seems like this happens general based on your log which would just validate my theory that somehow the cache gets hashed instead of the files which might gets easily corrupted at 32 bit clients.
Happens this ("Resampling uncompressed animations at 1/2 frame rate to conserve memory") every time before the issue occurs?
But the game added more stuff every big patch so memsize could be a issue I guess.
RANDOM IDEA.. (ok, I did some consistency file digging but no time to test)
Check if your time in windows is correct! Timezone, time, everything.
VERIFY it vs a internet server! Be sure it worked.
Some perhaps useful info:
http://support.microsoft.com/kb/314054
http://us.generation-nt.com/answer/how-verify-time-synchronization-help-102039582.html#
If the primary time / ntp server fails, use another!
GL and hope it works
Thanks for the documentation.
Since you didn't provide your techsupport.zip we are just taking you at your word that you are not running any mods.. hope you are doubly sure and are using your log as a means to verify.
I can't even verify if you pass the minimum requirements, as a result?? (your RAM gives me doubt..)
No one has said this issue is fixed.
It definitely started occurring when we switched to murmur hashing and seems to effect 32 bit users / those with low amount of ram. (remember your videocard impacts this value)
But to be very honest with you, I am surprised you are this upset given you are running a no longer maintained OS that is 13 years old and using an architecture that hasn't been shipped with any retail product for the past 8 years. Since we don't know your CPU or Video card, who knows how incompatible your hardware is.
32 bit OS users represent 11% of all steam users and UWE has devoted QUITE A BIT OF RESOURCES in the past to ensure their product remained compatible and bug free for them.
They've even gone so far to cannibalize the game in many areas for the rest of the user base in order to ensure this.
And now, this is the only bug that plagues 32 bit users, and it is being investigated. In case you are unaware, this game launched almost 2 years ago and UWE can no longer dedicate resources to it. This is why bug fixes related to the engine have been slow recently. But now we have a community development team who are going to try to pick up where they left off.
So in short, while I get you are upset you cannot play something you paid for, I do not sympathize with your reaction given the other factors involved. (a] It's being worked on b] Your old PC)
I definitely agree that this new hash checking method is more than likely the root of the issue. It's in our sights.
Did noone try my idea yet? I must admit im curious.
Your single core processor is the main culprit.. but to be honest with you, every single part of your system is sub par and 14 years old.
So be upset if you'd like, but you should never have been able to run this game in the first place due to the age of the hardware.
Take care.
Your system is running a Pentium 4 3Ghz with HT - this CPU is 10+ years old.
Information here: http://ark.intel.com/products/27497/Intel-Pentium-4-Processor-supporting-HT-Technology-3_00-GHz-1M-Cache-800-MHz-FSB
Your OS Windows XP is now 13 years old and no longer supported by Microsoft with any patches. It was released on October 25, 2001.
Your 2GB RAM is enough to run your OS, an antivirus and maybe a webbrower with a couple of tabs before it starts to slow down significantly.
Your Geforce 240 GPU is from around 2008-2009, making it 5-6 years old (sourceL http://en.wikipedia.org/wiki/GeForce_200_series)
You could probably run games from around 10 years ago without issues, but your whole architecture is bottlenecked. I would be surprised if you could run NS2 faster than 5-10 FPS on minimum settings.
I'm afraid it's time for you to upgrade, as your system is on average 7-8 years old and does not meet NS2's minimum system requirements and thus cannot be guaranteed to play NS2 properly. Ns2's MINIMUM requirement for CPU is a Core 2 Duo 2.6 ghz - but a 3Ghz Core2Duo chip is recommended. There were huge architectural changes between the Pentium series and the Core series of chips and I'm afraid your CPU just isnt powerful enough.
We made sure that ppl with this issue did "fullnukes" after obbys guide abit earlier in this thread.
sorry for my rant, if this was upsetting for you. The "Resampling..." happens everytime, but seems to be unrelated. It happens even on a successful connect.
@IronHorse @Obraxis
Just for the sake of argument: Please do know that i know my system well enough. And if you want to search a excuse, then you need to try harder. My system specs arent in question, but upgrading my hardware wont fix issues with hash-generation & consistency checking. Also it wont help my friends, who struggle to launch it on recent hardware. On Release I bought five copies of this game for five different pcs. Of this five pcs, four are suited well enough to run this game. But actually it does launch on 2 of them. You probably may think thats well enough for a game which is released since two years, but i certainly dont think so. Its wasted money. And coming back to the game after two years just to see that it is as mature as on release gives really nice vibes (read rant).
@IronHorse, well it was uploaded the moment I created the initial post. PLease dont try to cover up, that you missed it. Because you did, while you cherrypicked my system specs.
OP: Removing the entry , "*.model" in the ConsistencyCheck.json (if that was the right filename) makes the game launch, optimize and connect to any server I was trying to connect to. Yeah it runs with ~20fps with small teams and few structs
best of wishes,
krysopath
We allready knew that this could be kind of fixed by modifying the ConsistencyCheck.json, the for me important part is that it happens to you without any mods.
I would love to have a log validating this because this would at least change the issue from "being caused by some mods" to "being cause by vanilla"
Also i wasn't upset by your post it was just there was never said it was fixed, just that the state was caused by mods (so nothing uwe has to really care about ) and could be worked around be lighting up the ConsistencyCheck.json.
I wanted to know if it worked ;p
I only wanted to confirm that removing the *.model checks solves this for me. Mayhaps i caused confusion due to my wording. I wanted to highlight that the current attitude towards solving this problem is dead wrong IMHO. It felt like some two people where jumping to wrong conclusions regarding mods and responsibility of bugfixing.
I provided a log from a vanilla install (made some days ago), which threw the known error. Henceforth change of issue is necessary. But if people just like to bash on my hardware, then this wont happen. Im afraid i cant get this attitude into my head. Why should a slow processor render hash-generation broken?
("well yes, if its coupled with win xp and low ram, barbecue can reach escape velocity"-type of argument)
In my opinion its the bad practice of implementing esoteric and untested algorythms without proper testing. And this is evident. Sorry, this renders me angry.
If i can of some use providing some more evidence, give me a hint!
best of wishes,
krysopath