With cordite in the air, splintered steel, shell casings and powder burns, there’s only one explanation...
Discuss & improve the game engine.

Moderators: sparcdr, torhu, Tequila

Postby Barto » Wed Jan 04, 2012 5:10 pm

Pardner wrote:The steps I take when upgrading to the newest revision is:
  1. Build new binaries from the repository following Sucalakafufu's tutorial
  2. Clean my qvm folder by running the "mak-clean.bat"
  3. Buiild new qvms by running the "make.bat"
  4. Zip qvms then move qvms and binary to smokinguns folder.
The SVN should not mess the code up at all.

I haven't really followed your tutorial, I still used MinGW and MSYS to compile but it seems that I had to just delete the 'build' folder and recompile it to solve the problem. Thanks for the tip :)

moRtem wrote:So far the only thing that still bothers me a lot is, that (and i have already written it somewhere on the forum) connecting to a server is very slow. I'm never able to join before the first round starts (in SG1.0 connecting was a lot faster).

Another thing is, that most times after a game ends and the server changes map, the client (me) starts to reconnect, and when almost finished, ends up with an error-message (Juaro has the same problem).
I thought i made a screenshot yesterday, but i obviously didn't. I will post one soon. But the error-message says something about "cycled out" (cl_parse* i believe).

I had the same problem in the past, using the svn version solved those issues. I also increased the values of com_hunkMegs, com_soundMegs and com_zoneMegs in the meantime.

Joe Kari wrote:I don't remember anyone doing something for br_cobber.

I once saw this was possible to steal the bag at the first floor without blowing the safe. Just jump on the chairs downstairs and hit the deck. Or maybe use a gatling for some help.
"Chuck Norris had to shorten his beard in the presence of Richard Stallman because two beards that awesome, so close would segfault the universe (again)."
User avatar
Barto
Jeuxlinux Admin
 
Posts: 360
Joined: Fri Oct 23, 2009 5:08 pm
Location: Switzerland



Postby moRtem » Wed Jan 04, 2012 5:50 pm

Pardner wrote:Also, remember that the end goal is to get everybody running 1.1 at some point in time. If this problem continues, it will be less noticeable if everybody is a little slow and nobody joins to start the first round.


Of course, but it seems a bit odd to release a new version which needs longer to load than the old one.


I had the same problem in the past, using the svn version solved those issues.


good to hear


I also increased the values of com_hunkMegs, com_soundMegs and com_zoneMegs in the meantime.


always had good values for this settings, but wouldn't help in this case
User avatar
moRtem
Gunslinger
 
Posts: 284
Joined: Sun Mar 15, 2009 5:56 pm



Postby Joe Kari » Wed Jan 04, 2012 9:42 pm

moRtem wrote:
Pardner wrote:Also, remember that the end goal is to get everybody running 1.1 at some point in time. If this problem continues, it will be less noticeable if everybody is a little slow and nobody joins to start the first round.

Of course, but it seems a bit odd to release a new version which needs longer to load than the old one.

Probably something related to the ioQ3 port (SG 1.0 use Q3, 1.1 branch use ioQ3).
There are probably reasons, or maybe not at all, but this will not change anyway (except if ioQ3's guys do something for it).
User avatar
Joe Kari
SG Team
 
Posts: 879
Joined: Sun Sep 16, 2007 8:44 pm
Location: France



Postby moRtem » Wed Jan 04, 2012 11:44 pm

Joe Kari wrote:Probably something related to the ioQ3 port (SG 1.0 use Q3, 1.1 branch use ioQ3).
There are probably reasons, or maybe not at all, but this will not change anyway (except if ioQ3's guys do something for it).


That's what i thought about aswell when i first tried the beta. But isn't it possible that there went something wrong while porting to ioq3 ?
What i noticed / think is worth to consider:
1) Open Arena also uses ioq3, but i never noticed unusual long loading times there.
2) Is it possible that the "cycle-out"-error that i mentioned is somehow related to this unusual long loading times?
3) Afaik one of your Devs implemented some "phone-home"-feature which tells you the nicks of the players that use the beta. Is it possible that this slows down the connection (since the server doesn't response anymore or w/e) ?
4) The Beta tries to build up connections to any other Server that doesn't exist any longer?

I guess you are able to answer these questions in no time, otherwise don't bother, and let's have a look at it in 1.1b5 on a 1.1-server.
User avatar
moRtem
Gunslinger
 
Posts: 284
Joined: Sun Mar 15, 2009 5:56 pm



Postby Joe Kari » Thu Jan 05, 2012 8:12 pm

If so, Tequila is the man that can answer, since he did the backport.
My knowledge of the code is almost limited to VM's code (mostly game code), I don't know the engine code that much.
User avatar
Joe Kari
SG Team
 
Posts: 879
Joined: Sun Sep 16, 2007 8:44 pm
Location: France



Postby Tequila » Sat Jan 14, 2012 2:06 am

About "phone-home" features, do you mean authorize/update server support ? or really about VoIP ? Btw I don't think VoIP can slow down connections.

As far I know, authorize and update servers are now responding (just tested of course ;)). Btw I know they did not during a long time last year as I migrated my hosting and we forgot to update the related DNS entries. So maybe the authorize/update server failing exchange has delayed a little the login, but now this is no more the case.

If really SG 1.1 is longer to start or connect, this may be a bug related to ioQ3 port. I'll investigate at some time in the future if you really confirm. Anyone else feels SG 1.1 is longer to connect than SG 1.0 ?
User avatar
Tequila
SG Team
 
Posts: 1100
Joined: Thu Nov 15, 2007 11:33 pm
Location: Montpellier, France



Postby moRtem » Sat Jan 14, 2012 10:05 am

Tequila wrote:About "phone-home" features, do you mean authorize/update server support ? or really about VoIP ?


No, i don't mean VoIP.

As far as i remember, you added some code that let you know the nicknames of the players, which are testing 1.1 beta.


So maybe the authorize/update server failing exchange has delayed a little the login, but now this is no more the case.


This had been my suspicion. But if it's solved now, the problem is located somewhere else. (i didn't play in the last 1-2 weeks, but before that, the problem [slow connecting to servers] still persisted)


If really SG 1.1 is longer to start or connect, this may be a bug related to ioQ3 port.


On a sidenote (not sure if i mentioned this before): With 1.0 i usually was the first player who entered the game, while in 1.1 i am never able to enter the game, before the first round started.

I'll investigate at some time in the future if you really confirm.


That would be great - thanks.

Anyone else feels SG 1.1 is longer to connect than SG 1.0 ?


Juaro e.g.

2) Is it possible that the "cycle-out"-error that i mentioned is somehow related to this unusual long loading times?


i took a screenshot now (and noticed, that it is pretty ugly .. probably it doesn't like the resolution of my laptop)

Screenshot
User avatar
moRtem
Gunslinger
 
Posts: 284
Joined: Sun Mar 15, 2009 5:56 pm



Postby sunrise » Sat Jan 14, 2012 3:03 pm

Anyone else feels SG 1.1 is longer to connect than SG 1.0 ?

I can speak for at least 3 guys with different system and different os who noticed the same problem with 1.1b4.
With changing com_soundMegs and com_zoneMegs to "128" and com_hunkMegs to "512" and giving smokin guns full priority in my task manager i reduced the loading time a bit so that im able to join the first round in 8 of 10 cases.
sunrise
Quick Draw
 
Posts: 50
Joined: Wed Jun 16, 2010 6:05 pm



Postby moRtem » Sat Jan 14, 2012 4:55 pm

sunrise wrote:With changing com_soundMegs and com_zoneMegs to "128" and com_hunkMegs to "512" and giving smokin guns full priority in my task manager i reduced the loading time a bit so that im able to join the first round in 8 of 10 cases.


I always had those settings and never am able to join before the first round starts.

On a sidenote: I made a test /map br_cobber in SG1.0 and SG1.1 - on SG1.0 loading time was 5 seconds, on SG1.1b4 it took 15 seconds.
User avatar
moRtem
Gunslinger
 
Posts: 284
Joined: Sun Mar 15, 2009 5:56 pm



Postby Joe Kari » Mon Feb 27, 2012 4:19 am

Barto wrote:I just don't know if it's useful for you but here we go:

I had some fps freeze (count it for 2-3 seconds on a small map and a lot more on huge maps) while using custom compiled .exe (r618) on a 1.1beta4 server (terranova in this case). I think it's just some compatibility error but I hope to not see it in the future release.
I have any problem while playing in a 1.0 server or in LAN. So no worry about it there.

Just about when it happens, it is every time the game needs to calculate a new bunch of polygons like changing of vis area in the map or just even shooting at an enemy's hat.

Okey, I get it now... :(
That's strange, it never happens with linux build, but it happens with windows binary... Sometime it freezes forever...

It is a renderer bug, it's not related to physics. I can reproduce it at will: there are particular place where it happens everytime.

I have checked few revisions (winXP minGW):
r520 is OK
r570 is OK
r576 is OK
r579 has the freezes <---- it all started here
r583 has the freezes
r587 crash at map loading
r591 has the freezes
r594 has the freezes
r620 has the freezes
r621 has the freezes

Since they were a lot of ioq3 backport, I suspect one of those patch to break the whole things.

I'm still trying to figure out whate piece of code is responsible of it.

If someone figure out, please tell me.

EDIT: updated.
User avatar
Joe Kari
SG Team
 
Posts: 879
Joined: Sun Sep 16, 2007 8:44 pm
Location: France



Previous

Return to Code

Show Sidebar
Show Sidebar

User Control Panel