2.5 Test #3 - PLAYTEST - Sunday 9th March - 20:00 GMT, 4pm EST, 1pm PST

With Trickster out busy dodging bullets and bombs, he can't organize or attend tests anymore, so I suppose I ought to organize some tests now (Programmer's doing organizing? This can't end well.)

Still haven't pushed out any of the few features I have stashed away because I want to be certain that all the major bugs are gone. I've fixed the prone stuff and crashing from impacts on ragdolls, so we finally have something playable now. My permissions on SVN are still fucked though, so if they're still fucked an hour or two before the test, I'll post the updated binaries and have someone else do the commit for me.

After the test, all bug reports can just go in this thread, and I want everyone posting bugs they experienced. I'd rather several people post the same bug a few times over a person not posting one because they think someone else has posted.

Finally, I'll be making a locked stickied thread for consolidating all the reported bugs. That way the discussions can be in the actual testing threads and there'll be a post above the rest of the threads giving the run-down on what problems there still are. The only time someone doesn't have to report a bug is if I've already put it in the stickied thread. If it isn't, assume that I don't know about it and it needs to be reported.

EDIT: I've decided to change the time to 4PM EST and 1PM PST on the basis of Daylight Savings time changing in the United States before it changes in Europe. For people not in the United States, it should still be the same, if you base your time off of whatever time it is in the UK.

 

I wasnt sure about scheduling a test this week because I didnt know how bugfixing was coming.

This clashes with lazybums pug

 

Derp, fuck, you're right. This is what happens when you let a programmer do scheduling. It'll be on Sunday then, unless people want it at like 2 PM PST/10PM GMT on Saturday.

 

Go for the different day.

 

I've updated SVN with new dlls from candles, make sure to update.

Also, please (as usual) update before the test just to make sure there haven't been any last minute changes.

 

Something I found by accident:

In current Empires if you get killed by a turret that spawns with the map and therefor has no owner, the killmessage would just be the turret symbol and the player that get killed.

On coast today in svnpires we noticed that it sais "ERRORNAME <turret symbol> <playername>"

 

So I fucked up with Daylight Savings Time and didn't realize that the US pushes it's clocks an hour ahead two weeks before Europe does. I've decided to move the test to 1 PM PST and keep it at 8 PM GMT, because it'll be easier to tell people that arrive at 12 PM PST to just come back in an hour or have them check the thread instead of trying to get people in Europe to arrive an hour earlier when it's hard to get a message out to all of them.

 

Minor thing: right mouse clicking with the mortar (alternate fire) brings up the minimap but in a very glitchy way

 

• Players spawning inside each other on District at the second NF flag. (map issue?)
• Unproning while someone is standing on top of you causes both players to get stuck in each other.
• Weird stuck looping sounds coming from a random specific location. (Old bug, no known reproduction steps. Tends to happen most with ML Turrets.)
• Chromehtml spiking in the +showbudget panel.
• HE Cannon only has 10 ammo.

 

Huge FPS drop compared to SDK 2007 version on certain machines (for me i7-3610QM, 12GB DDRIII and NVIDIA Geforce GTX 675M running Windows 7).
+showbudget shows that most of it is because of "Unaccounted" actions.

Compare SDK 2007:
http://cloud-4.steampowered.com/ugc/594778719149257720/7A3A66F6F2E288B92EFF67C4AFADB25ACF5437F5/

with SDK 2013
http://cloud-3.steampowered.com/ugc/594778719148826974/F41BA382DF9D081EC561BC747CE3FEAE223B3D69/

I cannot believe that you only get 70 FPS with above machine specs on an empty map.
On canyon it can even drop from 250 to ~100...

Even if (on some machines) you don't notice any bad performance,
you may have a look what causes the high number of "Unaccounted" actions,
because they are not present in SDK 2007 version.

 

Think this has always been like that. (or it has for a long time atleast)

This test completely slipped my mind until just there now

 

If you get stuck on random vertices on the buildings, you can get killed. There's a spot that is definite in the NF vehicle factory which is located on the grey band of metal beside the entrances, you can jump "into" it, and I was walking over the BE refinery and randomly got stuck and died. 100% reproducible on the NF vehicle factory.

 

Does this happen on current empires?

For bug reports please only post things that are caused by the port if possible or else candles will be here forever fixing bugs

 

yes current empires and past empires.

 

it happened to me too. i like jumping into buildings and i don't believe it ever happened to me in regular empires

 

In normal Empires, you can get stuck on random vertices, but it won't kill you. There's some problem with the buildings that causes the game to think the player is falling until either their position is so extreme in one direction that the game thinks you're out of the world and kills you, or your velocity gets so high that you SLAM! into the ground and die instantly.

Regarding the fixability of it, I have no idea why it does it. To be specific, I have no idea why the game thinks there's nothing under the player when it happens and I have no idea why certain parts of certain models would do it over others.

For the frame issues, the problem is that "Unaccounted" is pretty hard to account for. Essentially, it's everything that isn't already listed in the budget panel, which, as anyone can imagine, is an awful lot of things. Plus, if it's something that isn't consistent from machine-to-machine, it makes it very hard to find a cause. I actually gain ~25% frames in the port.

I'm wondering if it might be a compiler thing that likes my computer and doesn't like yours though. That's a definite possibility.