Re: [warzone2100-dev] Warzone's direction for 2.3 series
I don't think reverting, re-reverting, re-commiting, re-implementing, etc this 'feature' is doing us any good. Let's just keep it as it is until we have know where the real problem is and have the time to fix it properly. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 12, 2010 at 9:13 PM, buginator buginato...@gmail.com wrote: Reading some tickets suggest that it makes things worse, like from this one. http://developer.wz2100.net/ticket/1360, Erm, that ticket refers to a commit that was already reverted. besides the reports on the forums. I don't think any report on the forum point to my commit specifically as the problematic one. I believe it was committed between b9 and b10, which is the same beta for which the template changes were committed, and as mentioned earlier, logs from users complaining about sync seem to point to the template changes being the problem. We could backport it to beta 4, and get people to test that. :P That might be better. With some local testing, I have to agree that the sync was worse than before, when I last tested. But not why. As I mentioned, I'm fine with reverting my commit, but as mentioned before, my commit _does_ fix quite a few bugs, and so I'm not going to do it myself unless I'm reasonably sure it's my specific commit that's causing sync problems. http://developer.wz2100.net/changeset/9942 Most of the time you can't tell there are other sync issues if you don't do LAN games to notice the issues, and only play net games. There've been sync problems since forever. The only question is if my commit made it worse. :P -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On 4/4/10, Guangcong Luo za...@wz2100.net wrote: I think the bMultiMessages change I committed may have made the sync worse, so I guess it should be reverted once again. This is really frustrating, because it really does fix seven different bugs relating to bMultiPlayer having an unexpected value. (Background: Much of the code assumes bMultiPlayer is TRUE if in a multiplayer/skirmish game, and FALSE in campaign. However, bMultiPlayer can be FALSE in a multiplayer game because turnOffMultiMsg messes with it. I thought my code was the most reliable way to fix the problem, but apparently it was unsuccessful.) This hasn't been reverted yet any reason why not? If you don't have time, then specify which revisions need to be reverted, and I can do it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 12, 2010 at 8:21 PM, buginator buginato...@gmail.com wrote: This hasn't been reverted yet any reason why not? If you don't have time, then specify which revisions need to be reverted, and I can do it. Because it's unclear whether or not it's actually caused any sync problems - recent sync logs seem to point to the template code as the problem. And it _does_ fix several bugs. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On 4/12/10, Guangcong Luo wrote: On Mon, Apr 12, 2010 at 8:21 PM, buginator wrote: This hasn't been reverted yet any reason why not? If you don't have time, then specify which revisions need to be reverted, and I can do it. Because it's unclear whether or not it's actually caused any sync problems - recent sync logs seem to point to the template code as the problem. And it _does_ fix several bugs. Reading some tickets suggest that it makes things worse, like from this one. http://developer.wz2100.net/ticket/1360, besides the reports on the forums. With some local testing, I have to agree that the sync was worse than before, when I last tested. Most of the time you can't tell there are other sync issues if you don't do LAN games to notice the issues, and only play net games. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On 4/7/10, Safety0ff wrote: For fire effects (not only oil well fires,) the _killEffect_ function retrieves the tile from the position (Vector3f,) and clears the fire bit of that tile. Effect times seem to use integers. If you don't believe me then look at the _killEffect_ function, it is very short. That clearing of the fire bit causes bug #1100 because there might be multiple fire effects whose position corresponds to a given tile. The first effect to die will clear the bit. Right, if fire is on a tile, and the timer is set, and if another projectile hits the same tile with fire, then it is set to that time period. Yes, it is a easy way to put out oil fires, or any other fire for that matter. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
C yp wrote: Think the main part is power, movement and experience. Think floating-point might be (mis)used a few other random places, but probably nowhere that isn't easy to fix. Think it's used all over the place in src/effects.c, but that file _shouldn't_ affect the game state (except that maybe it does, think Safety might have said something about oil well burning times depending on src/effects.c, not sure if I understood, since it's hard to believe there could be something hacky like that in a codebase like this). -Cyp For fire effects (not only oil well fires,) the _killEffect_ function retrieves the tile from the position (Vector3f,) and clears the fire bit of that tile. Effect times seem to use integers. If you don't believe me then look at the _killEffect_ function, it is very short. That clearing of the fire bit causes bug #1100 because there might be multiple fire effects whose position corresponds to a given tile. The first effect to die will clear the bit. -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 2:52 AM, Guangcong Luo za...@wz2100.net wrote:
Looks like the ML is back up.
On Sat, Apr 3, 2010 at 2:27 PM, buginator buginato...@gmail.com wrote:
...
...
The network code, AFAICT, we do not have any network related crashes anymore.
Yes, we got sync issues, but the 2.3 series will always have them.
Cyp's work with newnet should fix the sync issues, but, last I looked,
that version will __NOT__ work with 32bit systems at this time. This
is both on MSVC cross-compiled builds.
What about newnet requires 64-bit support? That seem so weird...
I think (97.13% sure) that it was working on a 32-bit Linux system
with sse2, and was working on at least one mac.
If I remember right, then the only issue is it not working on w32,
even if cross-compiled with gcc. I couldn't cross-compile it myself,
and haven't seen the assembler output of fptest1() in main.c, so I
can't determine if it's a wrong-code generation, or if it's windows
messing with the floating point registers somehow. (I once had an
issue with a version of Linux failing to restore the floating point
state correctly, so something like that wouldn't surprise me too
much.)
The assembler output must contain sse instructions, not x87 fpu
instructions. And no fused-madd instructions.
As far as I understand, -msse -mfpmath=sse -mno-fused-madd should fix
32-bit floats - fptest1(), and -msse2 -mfpmath=sse -mno-fused-madd
should fix 64-bit floats - fptest2(). Since there aren't many doubles
used, it probably doesn't matter if fptest2() fails.
So, as far as I know, the status is:
Linux x86_32: works
Linux x86_64: works
Linux ARM/MIPS/Alpha/PPC/sparc/ia64/...: unknown
Mac Intel: works
Mac PPC: unknown
Windows x86_32: fails
Windows x86_64: unknown
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
I think the bMultiMessages change I committed may have made the sync
worse, so I guess it should be reverted once again. This is really
frustrating, because it really does fix seven different bugs relating
to bMultiPlayer having an unexpected value.
(Background: Much of the code assumes bMultiPlayer is TRUE if in a
multiplayer/skirmish game, and FALSE in campaign. However,
bMultiPlayer can be FALSE in a multiplayer game because
turnOffMultiMsg messes with it. I thought my code was the most
reliable way to fix the problem, but apparently it was unsuccessful.)
For 2.3, I'm indifferent. Reverting that in trunk would probably cause
a few hundred merge conflicts with newnet.
No objections to Qt and newnet being merged as soon as possible.
I don't have any spare time at the moment. If squeezing a merge in, I
would at most be able to test if it compiles, not whether it runs.
(Should one expect 60fps via ssh X forwarding over a very unstable
network, or would it just be the usual 30fps as when running native?)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 9:17 AM, C yp cyp...@gmail.com wrote:
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
What parts of the game state still relies on floating point? I can
think of experience, power, movement (though I have an almost complete
patch for changing that, just need someone to up the precision), and
not much else? I do not think this option should be so hard.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 2:50 PM, Per Inge Mathisen
per.mathi...@gmail.com wrote:
On Mon, Apr 5, 2010 at 9:17 AM, C yp cyp...@gmail.com wrote:
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
What parts of the game state still relies on floating point? I can
think of experience, power, movement (though I have an almost complete
patch for changing that, just need someone to up the precision), and
not much else? I do not think this option should be so hard.
Option 1 should be the easiest (trivial), except that maybe it's
completely impossible instead of completely trivial.
I had to mention option 2, just for the sake of it.
That leaves option 3:
Think the main part is power, movement and experience. Think
floating-point might be (mis)used a few other random places, but
probably nowhere that isn't easy to fix. Think it's used all over the
place in src/effects.c, but that file _shouldn't_ affect the game
state (except that maybe it does, think Safety might have said
something about oil well burning times depending on src/effects.c, not
sure if I understood, since it's hard to believe there could be
something hacky like that in a codebase like this).
I think adding a // TODO Add more precision. line would probably be
sufficient for the movement patch to be committable (not that I've
tested it in any way, don't remember whether I read the patch or not).
If removing all floating point from the game state, then we can even
go the opposite way with the compile flags, and add -ffast-math...
-Cyp
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On 4/5/10, C yp wrote: On Mon, Apr 5, 2010 at 2:52 AM, Guangcong Luo wrote: Looks like the ML is back up. On Sat, Apr 3, 2010 at 2:27 PM, buginator wrote: ... ... The network code, AFAICT, we do not have any network related crashes anymore. Yes, we got sync issues, but the 2.3 series will always have them. Cyp's work with newnet should fix the sync issues, but, last I looked, that version will __NOT__ work with 32bit systems at this time. This is both on MSVC cross-compiled builds. What about newnet requires 64-bit support? That seem so weird... I think (97.13% sure) that it was working on a 32-bit Linux system with sse2, and was working on at least one mac. If I remember right, then the only issue is it not working on w32, even if cross-compiled with gcc. I couldn't cross-compile it myself, and haven't seen the assembler output of fptest1() in main.c, so I can't determine if it's a wrong-code generation, or if it's windows messing with the floating point registers somehow. (I once had an issue with a version of Linux failing to restore the floating point state correctly, so something like that wouldn't surprise me too much.) Oh, right. I forgot I got it working on linux 32bit OK. At least, I think it was OK. It has been too long. MSVC the CC version on windows are the big thorns. No objections to Qt and newnet being merged as soon as possible. I don't have any spare time at the moment. If squeezing a merge in, I would at most be able to test if it compiles, not whether it runs. (Should one expect 60fps via ssh X forwarding over a very unstable network, or would it just be the usual 30fps as when running native?) Maybe i-Nod can chime in if he got Qt or newnet working or not. For now, both branches are in a hold pattern for me, until we can push 2.3 out the door. We still have a fairly big crowd that uses MSVC, so I don't see us dropping that anytime soon, if ever. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Warzone's direction for 2.3 series
Before I left, I was told there was going to be some balance changes, and I haven't seen any for the beta 12 release, besides the penetration fix for the cannons. Is this still going to happen? The autoload of mods. This is still causing issues, as can be seen by trac tickets where people forget about mods that are in that directory. That was one of the main reasons why we disabled it in the first place. If we want a stable 2.3, then we should either disable that again, or someone needs to fix it. The network code, AFAICT, we do not have any network related crashes anymore. Yes, we got sync issues, but the 2.3 series will always have them. Cyp's work with newnet should fix the sync issues, but, last I looked, that version will __NOT__ work with 32bit systems at this time. This is both on MSVC cross-compiled builds. Other issues for 2.3, before a release is what exactly? I know about the campaign issues with the visibility routines, and I will revert the changes to the cleaning process as a temp fix for this. (What is going on is, on certain campaign missions, the pointers get swapped, and we end up freeing memory that shouldn't have been freed yet. (I have no clue why Pumpkin did the pointer swapping tricks, I guess to save some memory for the PSX or something like that). Is there anything else that needs to be looked at? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
Looks like the ML is back up. On Sat, Apr 3, 2010 at 2:27 PM, buginator buginato...@gmail.com wrote: Before I left, I was told there was going to be some balance changes, and I haven't seen any for the beta 12 release, besides the penetration fix for the cannons. Is this still going to happen? Haven't had time to commit the balance changes (or finish them, for that matter). The autoload of mods. This is still causing issues, as can be seen by trac tickets where people forget about mods that are in that directory. That was one of the main reasons why we disabled it in the first place. If we want a stable 2.3, then we should either disable that again, or someone needs to fix it. Man, we had a long IRC debate over this. My position is still: - Most commercial games do it the same way - autoload all mods in the mods folder, and do effectively no checking for compatibility when loading savegames. Warzone has done this since 1.00, too, until we removed it in 2.2 (a decision I still disagree with). - Since they do it that way, it is clear that there are a significant number of people who would rather have this mod system, however flawed, than no mod system at all. - The remaining people can simply _not use the system_. Remember the 2.1 days? When like 60-80% of the hosted games would have rebalance in their title? The mod thrived because the installation instructions were simple and clear: Drag to autoload folder. Despite the allegedly flawed mod system, it worked fine. 2.2 did not have any mod at that level of popularity, and I think part of that was due to the fact that requiring someone to install and learn a buggy mod loader, or mess with the command-line, is just too much of a barrier to entry. Sure, most of the forumites could do it if we provided detailed instructions. Or we could just provide the same one-step process that we used to from 1.00 to 2.1.3. When Buginator removed the autoload feature in the 2.2 betas, I was under the impression that he would fix it and restore it. Now, a year later, I've seen nothing from him to that end. Though I haven't completely fixed the mod system, I've improved it a bit, and I was under the impression that when I committed the autoload feature, everyone agreed it was solidly into the net benefit side of the benefit/harm spectrum. Now. I propose a simple solution: 1. Fix the mod loading system. Now, you can sit back and let me once again change the mod system to suit the wills of its detractors, or you can actively work towards making Warzone a worse game in the meantime. Is this really such a difficult decision? I've seen too much of removing features that have been with Warzone since the 1.10 days, especially features that the detractors could simply not use, and leave people who do use the feature alone. The network code, AFAICT, we do not have any network related crashes anymore. Yes, we got sync issues, but the 2.3 series will always have them. Cyp's work with newnet should fix the sync issues, but, last I looked, that version will __NOT__ work with 32bit systems at this time. This is both on MSVC cross-compiled builds. What about newnet requires 64-bit support? That seem so weird... I think the bMultiMessages change I committed may have made the sync worse, so I guess it should be reverted once again. This is really frustrating, because it really does fix seven different bugs relating to bMultiPlayer having an unexpected value. (Background: Much of the code assumes bMultiPlayer is TRUE if in a multiplayer/skirmish game, and FALSE in campaign. However, bMultiPlayer can be FALSE in a multiplayer game because turnOffMultiMsg messes with it. I thought my code was the most reliable way to fix the problem, but apparently it was unsuccessful.) -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On 4/4/10, Guangcong Luo za...@wz2100.net wrote: Looks like the ML is back up. Better late then never... Man, we had a long IRC debate over this. Yeah, this mail was before that conversation. When Buginator removed the autoload feature in the 2.2 betas, I was under the impression that he would fix it and restore it. Now, a year later, I've seen nothing from him to that end. Though I haven't completely fixed the mod system, I've improved it a bit, and I was under the impression that when I committed the autoload feature, everyone agreed it was solidly into the net benefit side of the benefit/harm spectrum. Other things got in the way...time is still the biggest enemy. Now. I propose a simple solution: 1. Fix the mod loading system. Now, you can sit back and let me once again change the mod system to suit the wills of its detractors, or you can actively work towards making Warzone a worse game in the meantime. Is this really such a difficult decision? The problem isn't fixing it per se, it is getting the time to fix it correctly. As it is now, it is broken, just like it was broken for 1.1.0, (but they did have a way for mods to detect other mods that the mods relied on), and like it was broken for the past releases we did. Is it better than it was? Yes. Does it fix the issues it had before? No, not all of them. The main issues left are, savegames made with mods fail if mods aren't loaded, when hosting mods, we don't transfer them, and when mods conflict (as in, they throw everything in autoload) then we get undefined results. To sum things up, I think 2.3.0 should have it disabled, and then have a working version in 2.3.1 or 2.4. The working version would need a new savegame format, and a way to transfer mods to other players. This is by no means trivial, and will require lots of time for someone to implement. I don't think holding up a release is in our best interest. We are *not* going to wait another 6-7 months before another release, that is just insane, and we should never do that again. I think the bMultiMessages change I committed may have made the sync worse, so I guess it should be reverted once again. This is really frustrating, because it really does fix seven different bugs relating to bMultiPlayer having an unexpected value. (Background: Much of the code assumes bMultiPlayer is TRUE if in a multiplayer/skirmish game, and FALSE in campaign. However, bMultiPlayer can be FALSE in a multiplayer game because turnOffMultiMsg messes with it. I thought my code was the most reliable way to fix the problem, but apparently it was unsuccessful.) Yes, last time I looked at (another one) of Pumpkin's hacks, it wasn't pretty... For what it is worth, this was also on my TODO list, but that list just got too big to manage. Time is the enemy. :( ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Sun, Apr 04, 2010 at 05:52:15PM -0700, Guangcong Luo wrote: The autoload of mods. This is still causing issues, as can be seen by trac tickets where people forget about mods that are in that directory. That was one of the main reasons why we disabled it in the first place. If we want a stable 2.3, then we should either disable that again, or someone needs to fix it. When Buginator removed the autoload feature in the 2.2 betas, I was under the impression that he would fix it and restore it. Now, a year later, I've seen nothing from him to that end. Though I haven't completely fixed the mod system, I've improved it a bit, and I was under the impression that when I committed the autoload feature, everyone agreed it was solidly into the net benefit side of the benefit/harm spectrum. It was removed because it was causing problems. I don't recall him ever declaring intent to rewrite the mod system. As for 'improving it a bit', what we have now just breaks in different and hard to find ways. Now. I propose a simple solution: 1. Fix the mod loading system. This is a great idea and a much better approach than trying to hack something together piecemeal. Since we are already wy too far into betas for 2.3, I suggest it be a goal for 2.3.1. A some requirements for a working mod loading system: Saved games need to know what mods they were running with so they can be loaded. An actual user interface to control what mods are being loaded - either an in-game interface to effectively take the place of the command line or perhaps a separate application to manage the autoload folder if we are retaining that. for multi-player, it would be ideal if the host could communicate what mods need to be loaded. At the very least, clients without the necessary mods would be rejected. In the meantime, the easiest fix is to turn off autoloading and end the problems it causes. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
