Afaik the original plan was to have a working converter script so third party scripts can just be converted. Hand-adjusting the currently converted Lua code would go against that, since all other scripts would have to be hand-tuned as well.Crymson wrote:Status on lua? viewtopic.php?f=35&t=4733
The font rendering problems have been worked around by reinstating the GLC font rendering. The problem is that QT doesn't support resolution switching, and there haven't been any solutions yet. I have tried a workaround, switching to a lower resolution with xrandr, but on my system, that results in a window that is larger than the screen... And it would have to be implemented for all systems separately, which goes against portability...Status on QT : viewtopic.php?f=6&t=5446
I don't think we have one plan of what 3.0 is even supposed to be...Status on 3.0? Why is there no testing builds of this?
Well, it needs someone to work on. Also, the original approach of fiddling with compiler options to get float operations to work the same on all systems is much too dependent on the compilers, we should probably use ints for relevant game state instead.Status on newnet? I don't see any action on this at all.
Yeah. Unfortunately this stupid power under/overflow issue is still not solved completely...Status on 2.3.1? I guess there is some action on this that I see from svn logs.
Yeah, it would be nice if someone wrote something like that.Emdek wrote:Well, it would be nice if for example someone would create blog or something like this (for example something like commit digest was in KDE in the past)
Correct me if I am wrong, but there isn't any other 3rd party script from 1.10 that would currently work with warzone is there?cybersphinx wrote:Afaik the original plan was to have a working converter script so third party scripts can just be converted. Hand-adjusting the currently converted Lua code would go against that, since all other scripts would have to be hand-tuned as well.Crymson wrote:Status on lua? viewtopic.php?f=35&t=4733
I was playing around with it again, and the reintroduction of quesoglc sucks, we can't make static builds with that library using the microsoft compiler.cybersphinx wrote:The font rendering problems have been worked around by reinstating the GLC font rendering. The problem is that QT doesn't support resolution switching, and there haven't been any solutions yet. I have tried a workaround, switching to a lower resolution with xrandr, but on my system, that results in a window that is larger than the screen... And it would have to be implemented for all systems separately, which goes against portability...Status on QT : viewtopic.php?f=6&t=5446
cybersphinx wrote:I don't think we have one plan of what 3.0 is even supposed to be...Status on 3.0? Why is there no testing builds of this?
it is on your roadmap ?cybersphinx wrote:Well, it needs someone to work on. Also, the original approach of fiddling with compiler options to get float operations to work the same on all systems is much too dependent on the compilers, we should probably use ints for relevant game state instead.Status on newnet? I don't see any action on this at all.
What was the reason for using floats in the first place? I also thought that all floats are the same on all platforms, since all compilers support IEEE 754 ?I ran into that on the latest svn/2.3. It was odd, 4 player game, and I transferred over some power, since he had 0, then he had 100K.cybersphinx wrote:Yeah. Unfortunately this stupid power under/overflow issue is still not solved completely...Status on 2.3.1? I guess there is some action on this that I see from svn logs.
There are; they're the latest trunk builds.Crymson wrote:Status on 3.0? Why is there no testing builds of this?
Intel famously had floating point arithmetic precision issues on one processor family back in the 90s. Modern computers generally don't have noticeable issues, but afaik they don't implement floating point arithmetic exactly according to spec.Crymson wrote:
CNR, unfortunately. That's probably an unrelated power bug. I have a feeling it wouldn't be too hard to fix with signed power.Crymson wrote:I ran into that on the latest svn/2.3. It was odd, 4 player game, and I transferred over some power, since he had 0, then he had 100K.
We had power underflow bugs before the fixing, too - remember the "I have 29719823 power" bug reports? I implemented the 100,000 limit before I started fixing the power system.Crymson wrote:Why not go back to the original code instead of delaying the next release? I don't recall ever having issues with power before all these fixes started to fix things, only to make it worse.
It's not only scripts from 1.10, but those people might be working on at the moment. It'll also be harder to write scripts for both current and lua when there is no working converter. EDIT: viewtopic.php?f=1&t=3757&p=36870#p36870 is where a converter was promised.Crymson wrote:Correct me if I am wrong, but there isn't any other 3rd party script from 1.10 that would currently work with warzone is there?Getting it close with the converter, then tuning it by hand with patches would seem like it would help this branch pick up speed.
What's more important, cross-compilation also doesn't work yet, so making releases with qt isn't possible atm. I didn't notice any change in rendering speed though.I was playing around with it again, and the reintroduction of quesoglc sucks, we can't make static builds with that library using the microsoft compiler.
Note the singular. And no,cybersphinx wrote:I don't think we have one plan of what 3.0 is even supposed to be...
is not a plan for a release.Zarel wrote:We have a pretty good idea of what 3.0 will be, it's just "everything currently in trunk, plus whatever minor patches hit between now and release, plus possibly Qt and/or newnet if they're stable enough by 3.0-branch feature freeze."
Well, the game used fixed point numbers (the Playstation doesn't have a FPU), which were replaced by floats to make things easier. Read http://lwn.net/Articles/387122/, section "Standard conforming excess precision" for an insight into the clusterfuck that floats are, especially on x86 hardware (remember, we don't care about precision, just that all systems get exactly the same result when doing the same calculation). The mentioned solution in the comments, to use SSE2 would a) require everyone to use SSE2-capable CPUs (Pentium 4+, Athlon 64+) and b) depends on the correct compiler switches (and compiler support).
CNR ?Zarel wrote:CNR, unfortunately. That's probably an unrelated power bug. I have a feeling it wouldn't be too hard to fix with signed power.Crymson wrote:I ran into that on the latest svn/2.3. It was odd, 4 player game, and I transferred over some power, since he had 0, then he had 100K.
Twelve times?We had power underflow bugs before the fixing, too - remember the "I have 29719823 power" bug reports? I implemented the 100,000 limit before I started fixing the power system.Crymson wrote:Why not go back to the original code instead of delaying the next release? I don't recall ever having issues with power before all these fixes started to fix things, only to make it worse.
And remember how there were some power upgrades that didn't actually upgrade your power production rate? That's also one of the things the new power code fixes.
By the way, this may be like the twelfth time you've used the phrase "only to make it worse" in your time with Warzone 2100. While we appreciate your intention to help, phrases like that are unnecessarily insulting to whoever wrote the fix, especially if you are not familiar with the fixes in question and do not know what they fixed.
To be fair, I've used variations of the phrase myself, but only in situations where I actually knew what the fix was intended to do, and how it does it (and I've been meaning to stop, anyway).
I don't recall that many, but that is beside the point. Could Not Reproduce [the bug in question].Crymson wrote:CNR ?
It was exaggeration, but that's beside the point.Crymson wrote:Twelve times?
The point is, if a fix makes things worse, as can be clearly seen in http://developer.wz2100.net/ticket/1581 then the options are to revert or fix the fix of the fix. I don't mean any insults by that comment, that is just how most SDP handle this, sorry if it offended you.