Page 3 of 3
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 12:42 am
by Zero Angel
N1 and I had a bit of an argument about this on the IRC. I'll post the tail end of the argument.
Code: Select all
<Zero_Angel> I think I would prefer to retain what direction I was going prior to the dropping of a few packets.
<Nielk1> 14ish meters
<Nielk1> no,
<Nielk1> no you would NOT
<Nielk1> unless you were in control of when you lost them
<Nielk1> would you rather be off by 10 meters or 14?
<Nielk1> 100 off instead of 141?
<Nielk1> and that is assuming only a 90 degrees turn
<Nielk1> with a bigger direction change you could be off by as much as 200 meters from a 100 meter movement on packet loss
<Nielk1> IF the controls continued
<Nielk1> people who player internattionaly want to blame the patches for game instability when older versions simply never corrected it right at all
<Nielk1> and now, we make it so the server is stable and its that it isnt doing what they say when their packets are lost...
<Nielk1> DUH
<Nielk1> you may insist that the act you were doing when you lost packets was correct and should continue
<Nielk1> but the simple fact is that that is not sensable for when you arent
<Zero_Angel> No i am insisting the act I *started* doing *before* I started losing packets is what should continue
<Nielk1> and I am telling you you are wrong about that
<Nielk1> you are letting personal feelings get more thought than logic and algorithm
<Nielk1> if it was that way, your experience would be far worse
<Nielk1> you assume it would be better
<Nielk1> it would not
<Nielk1> it is best that the two sides be prevented from getting too differnt, than that a probably incorrect set of prior actions be locked into place
<Nielk1> or would you prefer a lagging client to result in a ship running around in circles or flying off into the enemy base
<Zero_Angel> well that is a good point
<Nielk1> the simple fact is that it is logicly more correct to NOT continue thelast action
<Nielk1> if it was a racing game, you could argue otherwise, because you always go the same direction, you always go forward, your onlyissue would be turns
<Zero_Angel> But then why not have the code extrapolate movement to an extent, but then start to cut off the controls after a predetermined interval (e.g. 3 move packets) to ensure that things don't get too funky?
<Nielk1> ...
<Nielk1> the packet loss itself already has a tolerance...
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 4:08 am
by Nielk1
I sorta wanna see a bunch of units twirling uncontrollably because their inputs jammed on a packet loss now. We could play Yakety Sax over it
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 5:58 am
by Zero Angel
I was in a DM on z15 and noticed that the 'ping' didn't update. It would stay steady at whatever ping I had when I entered the game except when it would flash purple with things like (-5.6%)
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 6:46 am
by jaydenbz2
As people ignored or have no answers for my graphical problems coming with z15, where do I post to get some answers?
Going to try to overwrite the files with z13 ones..hopefully a re-install isn't needed, whatever happened in z15 it really trashed graphics.
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 7:47 am
by Red Devil
that's been addressed in the latest private build.
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 4:11 pm
by GSH
As people ignored or have no answers for my graphical problems coming with z15, where do I post to get some answers?
The water issue has probable been in every 1.3.6.* build. Other two are new to z15. I'm not sure what "answer" you are requiring, as others have already posted their own screenshots, confirming it's not just you. So, sit tight until a fix arrives. Or doesn't.
The water issue comes from it batching a little too many water pieces at once. This is a balancing issue between performance and looks -- DirectX performance is
much better when it draws a lot at once. But, to get transparency to look "right", you have to draw lots of little pieces, allowing combining only when they don't intersect/overlap. Getting it perfect is going to be really hard, unless you like a framerate in single digits.
-- GSH
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 4:22 pm
by GSH
If the host sees a client who's dropping packets moving in one direction, when said client is moving in another direction (due to changing direction during the effect), then simply 'keep' what the host sees and reset the lossy client into whichever heading that the host thought they were going in when the clean worldswap does eventually happen. If it works how I think it works, then would that reduce the effect of a 'bad client' while still keeping the game running smoothly?
And that's what it does right now. When a move hasn't arrived within a half second after it's due at the server, the server just takes a best guess at it -- used to be averaging, now an alpha-beta filter, and sends that move out as authoritative to everyone. Reduces the effect of bad clients to everyone else. It used to make everyone (client & server) guess over and over again while repeatedly re-requesting lost moves -- which could cause some additional lag when it suddenly had authoritative moves from 2-3 seconds ago and had to simulate the lockstep forward 2-3 seconds. At once. Now, it limits how much server (and clients with a good connection to the server) could ever snap forward when lagged but authoritative data is freshly available. If a client's moves got overridden by the server, that's when there will be a local pop as the server's guess didn't agree -- keep looking at the lag column and row for yourself. Ideally, the lag column should be near zero for yourself and the server -- when near zero, that means the clocks agree and packet loss is not high enough to lose five packets in a row. If the numbers are not zero, then see if the numbers are stable or not. That'll help identify if it's clock disagreement or packet loss.
As to pops or issues after a resync, that's what pause join is for. If a client's connection is slow (modem) or lossy, it can take a while for the gamestate to arrive. With pause join off, the server will archive the gamestate, hand it off to be sent, and then the server keeps rolling along. With pause join on, the server waits for all clients to give an explicit acknowledgment that the gamestate arrived and is ready for use. If you insist on multi-continental games, pause join should probably be on if you want to make it smoother for slow/lossy players after resyncs. Or pause join off if you want to explicitly tell slow/lossy clients that their connection to the host is not ideal.
-- GSH
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 5:32 pm
by Red Devil
curious about what happens when your position is altered between resets/resends, like if your ship gets moved by an explosion kick or a big collision; that position is just discarded/ignored, right?
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 9:50 pm
by jaydenbz2
OK, Thanks for the reply.
Good to know it's not just me getting these funny graphical issues...I'll just sit on z13 til a fix comes, that is fine, not playing much online anyway for now.
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Fri Jan 24, 2014 10:01 pm
by Red Devil
other things besides graphics need testing, too
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Wed Jan 29, 2014 5:06 pm
by mase
Got this while playing an IA on dunes using protrectors newest AIP.
The game froze and when tabbing out I saw the error.
Code: Select all
---- Battlezone II Log File ----
//=====================================================
App version: bzone 1.3.6.4z15 Public Beta Jan 18 2014 15:34:49
Windows version: Windows Version: 6.1.7600 '' PlatformID=2
Last few battlezone.log lines (may or may not be relevant):
DIAG| runcodes:159 |17:55:54|54809 |[View] Entering run code [COCKPIT]
DIAG| runcodes:159 |17:55:54|54836 |[Main] Entering run code [MISSION]
DIAG| icroot:193 |17:55:54|54841 |Root window now 1280x1024
DIAG| runcodes:159 |17:55:54|54847 |[Mission] Entering run code [RUN]
DIAG| Planners:3330 |17:55:55|55113 |SetAIP - cfg(Strategii0.aip) team(5)
DIAG| LuaManager:165 |17:55:55|55153 |Lua file 'Strategii0.lua' not found
DIAG| Planners:3330 |17:56:30|90264 |SetAIP - cfg(Strategii1.aip) team(5)
DIAG| LuaManager:165 |17:56:30|90283 |Lua file 'Strategii1.lua' not found
(done)
Exception code: C0000005 (ACCESS VIOLATION) READING from 148F0000h
Message : Exception
Error occurred at 1/29/2014 18:02:04.
C:\Users\mase\Documents\battlezone2\battlezone13bz\bzone.exe, run by mase.
C:\Users\mase\Documents\battlezone2\battlezone13bz\bzone.exe, run by mase.
CPU: 2 processor(s), AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
x86 Family 15 Model 107 Stepping 1
Process Memory : 1455 MB free out of 2048 MB total
Physical memory: 148 MB free out of 1024 MB total
Page(swap) file: 835 MB free out of 2048 MB total
This exe is using 243 MB (105 MB dlmalloc), peak use 247 MB
Fault address: 015016AC 01:002306AC C:\Users\mase\Documents\battlezone2\battlezone13bz\bzone.exe
Registers:
EAX:0055CA60
EBX:0000000B
ECX:00000001
EDX:0055CA60
ESI:148EFFEC
EDI:1088C9C0
CS:EIP:001B:015016AC
SS:ESP:0023:0055BBFC EBP:0055BC0C
DS:0023 ES:0023 FS:003B GS:0000
Flags:00210202
Call stack:
Address Offset1 Offset2 Module SourceFile
015016AC +002316AC 000000AC bzone (bzone): : Matrix::Transform_Vectors_Stride12To16
014D1030 +00201030 00000290 bzone (bzone): : MeshRoot::GetTransformedNormals
014D382C +0020382C 000005CC bzone (bzone): : MeshRoot::Render
014F7884 +00227884 00000174 bzone (bzone): : MeshEnt::Render
01357C11 +00087C11 00000052 bzone (bzone): : GameObject::Render
0131AE0C +0004AE0C 00000012 bzone (bzone): : MeshEnt::Render
013E043F +0011043F 0000007C bzone (bzone): : ENTITY::RenderScene
01357D57 +00087D57 00000142 bzone (bzone): : GameObject::RenderScene
013F2378 +00122378 000000B2 bzone (bzone): : Resolution_Layer_Class::Entity_List_Class::Render
013F26E6 +001226E6 00000084 bzone (bzone): : Resolution_Layer_Class::Render
013F2E8C +00122E8C 0000003A bzone (bzone): : SceneManagerClass::Render
013E04A0 +001104A0 00000027 bzone (bzone): : Submit_All_Entities
0131A111 +0004A111 0000037A bzone (bzone): : Simulate_Cockpit
0131A665 +0004A665 000000A3 bzone (bzone): : Render_Internal_View
01326200 +00056200 00000682 bzone (bzone): : ViewCockpit::Process
013275BD +000575BD 000000A1 bzone (bzone): : ViewManager::Process
0132B7F9 +0005B7F9 000000B9 bzone (bzone): : MissionHandler::RenderOneFrame
0132BBE0 +0005BBE0 0000032A bzone (bzone): : MissionHandler::State::RunState::Process
01329342 +00059342 0000001E bzone (bzone): : MissionHandler::Process
75D698CD +000098CD 00000039 msvcrt (msvcrt): : free
75D698DA +000098DA 00000046 msvcrt (msvcrt): : free
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Wed Jan 29, 2014 7:19 pm
by mase
There have been two occasions now where the commander lost the ability to build. One was at the start of the game, another happened later.
Happened in a strat. Giving command to someone else worked, also when taking it back.
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Wed Jan 29, 2014 11:06 pm
by Zero Angel
mase can you explain that better? Did the 'build' menu on the constructor become 'greyed out' or did something else happen?
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Thu Jan 30, 2014 8:16 am
by mase
Zero Angel wrote:mase can you explain that better? Did the 'build' menu on the constructor become 'greyed out' or did something else happen?
No, since I wasn't commanding.
Re: BZ2 1.3.6.4z15 - Open beta & testing
Posted: Thu Jan 30, 2014 9:19 am
by Zero Angel
@Mase: I noticed a bug where the constructor's build menu can become greyed out and not recover. It happened to me once and Kebbz reported that it also happened to him once. I'm trying to find out as much as I can about this bug in hopes that it can be fixed. If it happens in any game you're in, try to find out more information about it or any other related bugs.