0.73b1 test release 3
Moderator: Moderators
- Foxomaniac
- Posts: 691
- Joined: 18 Jan 2006, 16:59
Are you really really sure you were reviewing the demo with the same spring binary?LordMatt wrote:1. When Quantum and I were reviewing a demo made with the test version, the game was not properly synced either between us or with respect to what actually happened ingame. Things that didn't happen in game, happened sometimes in the demo, but not others times (we watched it three times), such as me losing my com in a demo when I had 30% health in the actual game. It appeared that commands were lost in several situations, also. I have posted the replays to my website here, if that helps.
Was it a hosted replay or local replay?
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
AFAICS the heatcloud= tag in resources.tdf works fine. I tried setting it to e.g. Bark.bmp and wake.tga and it overrides fine (tested with xta armcom dgun). Also commenting out the heatcloud= line seems to make a difference so I'm pretty sure the heatcloud renders fine.Argh wrote:1. The explosion graphic doesn't seem to be drawing at all any more. I'm not sure that was what you were after, Tobi, when you made "explo" the default. I've tried different flavors of TGA, no-go.
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Two more bugs/issues/design flaws with the new keybind system. They're actually more like one bug. The problem is the shift key is used for multiple commands now. This means if you are queuing a bunch of orders up, you have to release the shift key to use other hotkeys. Also, shift+enter being the default for switch to spectator is an annoying bind if you hold the shift key when you start typing for a capital letter or whatever have you. I'd suggest not using shift for anything but queuing unit orders. I'm sure I could fix the second bug myself by changing the default bind, but I'm pretty sure that won't fix the queuing bug.
-
- Spring Developer
- Posts: 374
- Joined: 14 Mar 2005, 12:32
About the keybindings:
The new system is pretty flexible and you'll probably be able to bing everything to your likings. The shift / queue issues people are experiencing are not really issues, but are due to non-standard bindings that happened to get into the test build.
If you have any more questions on the keybindings, please read
https://mail.westberg.se/wsvn/filedetai ... rev=0&sc=0
first before making a post.
The new system is pretty flexible and you'll probably be able to bing everything to your likings. The shift / queue issues people are experiencing are not really issues, but are due to non-standard bindings that happened to get into the test build.
If you have any more questions on the keybindings, please read
https://mail.westberg.se/wsvn/filedetai ... rev=0&sc=0
first before making a post.
I'm sure, Quantum and I just compared their size and timestamp. The replay was hosted over the client, we tried it with Quantum hosting (he was the game host) and with me hosting, and had desyncs each time (without error messages, just different things happening in our versions of the game).Tobi wrote: Are you really really sure you were reviewing the demo with the same spring binary?
Was it a hosted replay or local replay?
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Okay, this just steals focus and delays sync usually, but on two occasions it did start causing sync errors. Is the sync debugger code in the game? How can we use that stuff to trace sync errors? Would submitting replays help?el_matarife wrote:Pressing F10 to record a video desynchs the game for whoever presses it.
The sync debugger is a compile time option - it increases compile time, memory & cpu usage quite a bit.
Also, to use it you need to understand what you're doing - ie. you must be skilled in C++ & debugging and preferably know quite a bit about spring internals. The syncdebugger isn't written for endusers but for developers after all.
Also, to use it you need to understand what you're doing - ie. you must be skilled in C++ & debugging and preferably know quite a bit about spring internals. The syncdebugger isn't written for endusers but for developers after all.
Noticed a couple of bugs:
The << and >> buttons in the build/orders menu for the commander stopped working for me at one stage, but came good again later. i.e. mouse hover over them did not highlight the arrows, and clicking on them did nothing, so I was stuck on page 3 of the commander's orders menu. At the same time, the menu worked fine for other units.
In the AA2.11 mod, the arm lvl 1 minelayer vehicle could not guard other construction units, i.e. build-assist functionality did not work. The same unit in 0.72b1 was able to guard/build-assist other construction units.
The << and >> buttons in the build/orders menu for the commander stopped working for me at one stage, but came good again later. i.e. mouse hover over them did not highlight the arrows, and clicking on them did nothing, so I was stuck on page 3 of the commander's orders menu. At the same time, the menu worked fine for other units.
In the AA2.11 mod, the arm lvl 1 minelayer vehicle could not guard other construction units, i.e. build-assist functionality did not work. The same unit in 0.72b1 was able to guard/build-assist other construction units.
May be a mod issue, but the fact is it behaved differently in 0.72b1 vs 0.73b1, so some change to the engine has caused the bug to show.Das Bruce wrote:Mod issue I'm pretty sure.Belmakor wrote:In the AA2.11 mod, the arm lvl 1 minelayer vehicle could not guard other construction units, i.e. build-assist functionality did not work. The same unit in 0.72b1 was able to guard/build-assist other construction units.
-
- Spring Developer
- Posts: 374
- Joined: 14 Mar 2005, 12:32
Belmakor wrote:The << and >> buttons in the build/orders menu for the commander stopped working for me at one stage, but came good again later. i.e. mouse hover over them did not highlight the arrows, and clicking on them did nothing, so I was stuck on page 3 of the commander's orders menu. At the same time, the menu worked fine for other units.
Same for me.Tobi wrote:I also experienced the GUI hang at one time, but I didn't manage to reproduce it.
Ahh... That would explain it.Tobi wrote:It's probably because canAssist/canBuild etc. is now implemented.
It's happened more than once to me, but I haven't found a way to reliably reproduce the behaviour, unfortunately.I also experienced the GUI hang at one time, but I didn't manage to reproduce it.