Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread Zarel
On Fri, Oct 9, 2009 at 11:23 PM, bugs buggy buginato...@gmail.com wrote:
 What will that solve?  It will save people 3 characters... not exactly
 worth it IMO.

It's not so much about saving people 3 characters, as about not having
to guess when to use .wz and when not to.

Meh, why are we even arguing this? I'm applying part of my patch, it
doesn't hurt anything, and I doubt you'd be so malicious as to revert
it.

 Nope!
 A) the maps code sucks, and has many issues by itself.
 B) the checks that I have reimplemented are done *in game*, not the lobby.
 C) it can't be done in the lobby yet, that is for the future, we still
 have to come up with a way to read in the mod,  know where it came
 from, and then make a hash out of that, then transmit this info to
 everyone, which is why the lobby code has all those extra fields that
 we can use--I am not sure the best way to handle this.  Having a poor
 GUI doesn't help either.

:(

 ... 2.3.0 will be re-branched from branch/2.2 ? I did have reasons for
 wanting to stick with 2.2.4, namely, that the netcode will be broken
 again, and so the next version after 2.3.0 will be 2.4.0 and if
 something changes, we can go up to 2.9.x?

 [...] I rather stick with 2.2.4 and so on, [...]

Here's some more stuff on why we shouldn't release 2.2.4:

[14:20]  Zarel Can you point to any rationale on that? One of my
developers is trying to break MP compatibility for Warzone 2.2.4, and
I need backup as to why that's a bad idea. :/
[14:23]  mordante the simple rationale is, it's called stable for a reason ;-)
[14:23]  mordante but that's a bit simple
[14:24]  mordante IMO an MP protocol is an API and in general when
you start to modify an API you should bump the minor or major version
number
[14:25]  mordante in general when updating to a new minor or major
version number a user expects problems, when updating to a new patch
they don't expect problems only bug fixes
[14:26]  mordante (at least for OOS projects I expect that,
commercial software often uses version numbers as marketing tool so no
predictions there ;-) )
[14:26]  mordante but why does your developer think it's a good idea?
[14:31]  Zarel https://mail.gna.org/public/warzone-dev/2009-10/msg00021.html
[14:34]  Zarel :( The other developers don't even see that much of a
problem with it.
[14:35]  mordante :-(
[14:35]  mordante it's not only net compatibility but compatibility
in general
[14:36]  mordante stable is bugfix only
[14:36]  mordante as it should be (tm)
[14:37]  mordante or you need to state your policy that every patch
release is incompatible, how often do you release patch versions
[14:37]  Zarel Not that often. Once every few weeks?
[14:37]  Zarel This is the first time we've had an incompatible
patch release in ages.
[14:38]  Zarel Heck, I thought it was policy.
[14:41]  mordante Zarel, maybe make it a policy and go for version
2.3.0 (or 2.4.0 if you want to use the odd/stable numbers)
[14:41]  Zarel That's what I've been trying for.
ns lol, and lol means heh
[14:48]  mordante Zarel, still don't understand why your fellow
developers think it's a good idea to release incompatible patches but
good luck getting 2.3.0 out

:[

We should revert your commit to 2.2, if you don't want to release 2.3.0 yet.

-Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread Per Inge Mathisen
I think the network incompatible story is a red herring. People
should NEVER play with different versions of the game, period. This is
asking for trouble, unless all the changes between the two versions
are purely cosmetic or crash fixes. Since the game is based on peer to
peer algorithms, playing with different versions/features will lead to
off-sync. Most releases IIRC add some things are not pure crash fixes,
yet we do not bump the minor version number. What we should do is make
all releases network incompatible, like almost all other RTS games do
it. The minor version number should be reserved for savegame
incompatibility. The major version number should be reserved for
mod/map incompatibility.

This means, 2.2.4 should go forward, and trunk should become 2.3. IMHO.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread bugs buggy
On 10/10/09, Per Inge Mathisen perxxx...@ wrote:
 I think the network incompatible story is a red herring. People
  should NEVER play with different versions of the game, period. This is
  asking for trouble, unless all the changes between the two versions
  are purely cosmetic or crash fixes. Since the game is based on peer to
  peer algorithms, playing with different versions/features will lead to
  off-sync. Most releases IIRC add some things are not pure crash fixes,
  yet we do not bump the minor version number. What we should do is make
  all releases network incompatible, like almost all other RTS games do
  it. The minor version number should be reserved for savegame
  incompatibility. The major version number should be reserved for
  mod/map incompatibility.

  This means, 2.2.4 should go forward, and trunk should become 2.3. IMHO.


I couldn't have said it better.

I still plan to release 2.2.4 this weekend, unless someone can come up
with a very good reason not to.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread bugs buggy
On 10/10/09, Zarel zarelxxx...@xxx wrote:
 On Fri, Oct 9, 2009 at 11:23 PM, bugs buggy bugxxx...@x wrote:
 It's not so much about saving people 3 characters, as about not having
  to guess when to use .wz and when not to.

  Meh, why are we even arguing this? I'm applying part of my patch, it
  doesn't hurt anything, and I doubt you'd be so malicious as to revert
  it.

I never said I would revert it, I just don't see a need for it.

  [...] I rather stick with 2.2.4 and so on, [...]

  Here's some more stuff on why we shouldn't release 2.2.4:
while I don't really know who mordante is, let me just say this...

  [14:36]  mordante stable is bugfix only
  [14:36]  mordante as it should be (tm)
  [14:37]  mordante or you need to state your policy that every patch
  release is incompatible, how often do you release patch versions

The whole point of the DI routines *was* to make it _more_ stable.
Right now, people would crash or have other weird behavior because we
couldn't check the data before.
In this sense, it IS a bugfix.  It just happens to require everyone to
upgrade, which is not unreasonable or bad practice IMO.


  We should revert your commit to 2.2, if you don't want to release 2.3.0 yet.

Not.  See above for the why.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread Zarel
On Sat, Oct 10, 2009 at 4:08 AM, Per Inge Mathisen
per.mathi...@gmail.com wrote:
 I think the network incompatible story is a red herring. People
 should NEVER play with different versions of the game, period. This is
 asking for trouble, unless all the changes between the two versions
 are purely cosmetic or crash fixes. Since the game is based on peer to
 peer algorithms, playing with different versions/features will lead to
 off-sync. Most releases IIRC add some things are not pure crash fixes,
 yet we do not bump the minor version number.

Erm, other than your change to VTOL pads, I can't think of any changes
to a minor version that aren't purely cosmetic or crash fixes, or at
least don't affect netcode compatibility...

 What we should do is make
 all releases network incompatible, like almost all other RTS games do
 it. The minor version number should be reserved for savegame
 incompatibility. The major version number should be reserved for
 mod/map incompatibility.

I guess that it's not _that_ big of a deal to make minor versions
netcode incompatible (biggest consideration is probably that people
using the version from Ubuntu repositories won't be able to play with
people on other platforms, since Ubuntu never updates stable
repositories, but then again, that's usually true either way...).

But then we would need one copy of the lobby for each minor version,
which would get kind of extreme... Also, updating requires downloading
at _least_ a 50 MB file, which is a disincentive for many people to
update.

On Sat, Oct 10, 2009 at 10:58 AM, bugs buggy buginato...@gmail.com wrote:
 I still plan to release 2.2.4 this weekend, unless someone can come up
 with a very good reason not to.

D:

I have balance changes I need to commit! Give me time!

On Sat, Oct 10, 2009 at 11:36 AM, bugs buggy buginato...@gmail.com wrote:
 The whole point of the DI routines *was* to make it _more_ stable.
 Right now, people would crash or have other weird behavior because we
 couldn't check the data before.
 In this sense, it IS a bugfix.  It just happens to require everyone to
 upgrade, which is not unreasonable or bad practice IMO.

As long as we make it _very_ clear to everyone that it's netcode-incompatible.

-Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread bugs buggy
On 10/10/09, Zarel zarelxxx...@xx wrote:
 I guess that it's not _that_ big of a deal to make minor versions
  netcode incompatible (biggest consideration is probably that people
  using the version from Ubuntu repositories won't be able to play with
  people on other platforms, since Ubuntu never updates stable
  repositories, but then again, that's usually true either way...).

  But then we would need one copy of the lobby for each minor version,
  which would get kind of extreme... Also, updating requires downloading
  at _least_ a 50 MB file, which is a disincentive for many people to
  update.

Eh? How does the lobby play a role in this?  It would still use the
same lobby, and in fact, it does.  That code has *not* changed.
The only change is a new message packet, and old clients wouldn't know
what to do with it, so it would ignore it.  The host will wait X
amount of time (while in game) for the packet, and if nothing is
received, then it will auto-kick them.
50MB isn't that big, most driver packages are pretty close to that.


  On Sat, Oct 10, 2009 at 10:58 AM, bugs  wrote
   I still plan to release 2.2.4 this weekend, unless someone can come up
   with a very good reason not to.

  I have balance changes I need to commit! Give me time!

I hope it is quick, since otherwise, I most likely will not be around
until the end of the month.  Which is why I have been saying get all
the patches in ASAP since before I left last week.


 As long as we make it _very_ clear to everyone that it's netcode-incompatible.

You make it sound like this is a big deal, but 99% of our user base
upgrades when a new release is out...

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-10 Thread Zarel
On Sat, Oct 10, 2009 at 6:22 PM, bugs buggy buginato...@gmail.com wrote:
 Eh? How does the lobby play a role in this?  It would still use the
 same lobby, and in fact, it does.  That code has *not* changed.
 The only change is a new message packet, and old clients wouldn't know
 what to do with it, so it would ignore it.  The host will wait X
 amount of time (while in game) for the packet, and if nothing is
 received, then it will auto-kick them.

Well, I mean, we have to show 2.2.0 - 2.2.3 games to their respective
players, and 2.2.4 games to their respective players...

 50MB isn't that big, most driver packages are pretty close to that.

Most driver packages aren't updated by redownloading the entire thing
every month. In fact, they're rarely updated, unless they're updated
automatically. I wouldn't mind requiring latest version if Warzone had
differential updates and automatic background updating.

 I hope it is quick, since otherwise, I most likely will not be around
 until the end of the month.  Which is why I have been saying get all
 the patches in ASAP since before I left last week.

Meh, I'll try to do it in the next 12 hours.

 You make it sound like this is a big deal, but 99% of our user base
 upgrades when a new release is out...

Okay, I admit to making up numbers as well, but 99% is a bit
ridiculous. I'd estimate it at more like 60%. Maybe less. You know
around 50% of the problem reports on the forums are due to players
running old versions of Warzone. And many of the people who post
problems will probably download the latest version first, further
skewing the numbers that way.

-Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-09 Thread bugs buggy
On 10/5/09, Zarel zarelxxx...@xxcom wrote:
 On Sun, Oct 4, 2009 at 9:57 PM, bugs buggy buginx...@.com wrote:

see below about 2.2.4 / 2.3.0

   In case everyone is confused on how this works, if host starts a game
   with ntw mod, they would do --mod_mp ntw (if from source) or --mod_mp
   ntw.wz then that loads the ntw mod.  Now when they host, all players
   *must* also have --mod_mp ntw  or --mod_mp ntw.wz (depending if they
   are running from source or not) and then, once in game, it checks the
   data, and kicks everyone who doesn't have matching data.

 Can we just implement the part of my mod loading patch that lets you
  leave off the .wz? So we don't need to guess when we need the .wz
  and when we don't?

What will that solve?  It will save people 3 characters... not exactly
worth it IMO.
It isn't confusing, since 99% of our userbase uses .wz,  the ones that
run from source, pretty much know that they don't need '.wz' ending.
Re-read my ticket, I said this is only the *start* of fixing the mods,
there remains a heck of allot of work to be done, and I can pretty
much guarantee that we will break netcode compatibility again when it
is all done.

   If host just starts a normal game with no mods, and a player is using
   a mod, the data check will see this, and kick the player(s).
 Can't we send them like maps? And enable/disable them like maps?

Nope!
A) the maps code sucks, and has many issues by itself.
B) the checks that I have reimplemented are done *in game*, not the lobby.
C) it can't be done in the lobby yet, that is for the future, we still
have to come up with a way to read in the mod,  know where it came
from, and then make a hash out of that, then transmit this info to
everyone, which is why the lobby code has all those extra fields that
we can use--I am not sure the best way to handle this.  Having a poor
GUI doesn't help either.


  Especially if we're going to be breaking netcode compatibility. We
  should probably work out a scheme for sending them like maps before we
  release a new version. I'm fine with releasing 2.3 beta 1 next week,
  but definitely not a final.

Didn't we have a argument like this for 2.2.0?
Anyway, as I said, we are going to break netcode compatibility
again, there are no ways around it.   I was thinking the map + mod
stuff will end up using the same routines and they will handle any
type of file. (the current DPID BS blows in 2.x!!)

I still think a 2.x.x* release should be done this weekend.   I see no
real reason to label it 'beta', and no reason not to do a final
release.

... 2.3.0 will be re-branched from branch/2.2 ? I did have reasons for
wanting to stick with 2.2.4, namely, that the netcode will be broken
again, and so the next version after 2.3.0 will be 2.4.0 and if
something changes, we can go up to 2.9.x?
I rather stick with 2.2.4 and so on, until we finally get the netcode
under control, and THEN we can do a 2.3.0 or by that time, 3.0
(current trunk) will be in good shape, and I can say DIE 2.x DIE!
Heck, I very close to saying screw 2.x, and put all my efforts into
3.0-- I see little reason it maintaining 2.x longer than we absolutely
have to.
Unless we get a sudden influx of devs to help I do not see a good
solution, as they say, talk is cheap.  The netcode in trunk is very
different than 2.x, and just not easy to maintain both versions.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-05 Thread Zarel
On Sun, Oct 4, 2009 at 9:57 PM, bugs buggy buginato...@gmail.com wrote:
 Why?   Look at the code, it isn't that complex in what it does, and
 now that it is in both trunk  branch/2.2, we can have plenty of
 testing  before the release of the next version next week...  Hear
 that testers?  We need your help :)

It's not about complexity, it's about compatibility. I don't care if
it's a one-line change, if people running 2.2.3 can't play games with
people running 2.2.4, then it shouldn't be called 2.2.4. The most
analogous game is Wesnoth, and they have a policy not to break netcode
compatibility on bugfix releases of stable games. In fact, we probably
do too, not that anyone really knows what our official policies are at
this point.

 In case everyone is confused on how this works, if host starts a game
 with ntw mod, they would do --mod_mp ntw (if from source) or --mod_mp
 ntw.wz then that loads the ntw mod.  Now when they host, all players
 *must* also have --mod_mp ntw  or --mod_mp ntw.wz (depending if they
 are running from source or not) and then, once in game, it checks the
 data, and kicks everyone who doesn't have matching data.

Can we just implement the part of my mod loading patch that lets you
leave off the .wz? So we don't need to guess when we need the .wz
and when we don't?

 If host just starts a normal game with no mods, and a player is using
 a mod, the data check will see this, and kick the player(s).

Can't we send them like maps? And enable/disable them like maps?

Especially if we're going to be breaking netcode compatibility. We
should probably work out a scheme for sending them like maps before we
release a new version. I'm fine with releasing 2.3 beta 1 next week,
but definitely not a final.

-Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-04 Thread Zarel
On Sun, Oct 4, 2009 at 5:44 PM, bugs buggy buginato...@gmail.com wrote:
 Hey all, the current plan is to release 2.2.4 (or 2.3.0--which ever
 version # wins) next weekend, most likely Saturday night/ Sunday
 morning.

 If you have fixes/changes, then please get them in now, or wait for
 the next release.

D: D: D:

BLOCK

We are not rushing out a netcode-imcompatible release that soon, no no no!

-Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-04 Thread bugs buggy
On 10/4/09, Zarel zarexx...@gmail.com wrote:
 On Sun, Oct 4, 2009 at 5:44 PM, bugs buggy buginato...@gmail.com wrote:
   Hey all, the current plan is to release 2.2.4 (or 2.3.0--which ever
   version # wins) next weekend, most likely Saturday night/ Sunday
   morning.
  
   If you have fixes/changes, then please get them in now, or wait for
   the next release.


 D: D: D:

  BLOCK

  We are not rushing out a netcode-imcompatible release that soon, no no no!

Why?   Look at the code, it isn't that complex in what it does, and
now that it is in both trunk  branch/2.2, we can have plenty of
testing  before the release of the next version next week...  Hear
that testers?  We need your help :)

In case everyone is confused on how this works, if host starts a game
with ntw mod, they would do --mod_mp ntw (if from source) or --mod_mp
ntw.wz then that loads the ntw mod.  Now when they host, all players
*must* also have --mod_mp ntw  or --mod_mp ntw.wz (depending if they
are running from source or not) and then, once in game, it checks the
data, and kicks everyone who doesn't have matching data.

If host just starts a normal game with no mods, and a player is using
a mod, the data check will see this, and kick the player(s).

Like I said, this isn't really that complicated, and it was in
Pumpkin's original codebase + a few changes so it runs on all
platforms.

Anyway, I will be back next week.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [warzone2100-dev] 2.2.4 (or 2.3.0) is planned to be released next weekend

2009-10-04 Thread bugs buggy
On 10/4/09, bugs buggy buginxxx...@gmail.com wrote:
...
  now that it is in both trunk  branch/2.2, we can have plenty of
  testing  before the release of the next version next week...  Hear
  that testers?  We need your help :)


I uploaded both 2.2  trunk versions (.exe ONLY) as of this e-mail to
the forums here:
http://forums.wz2100.net/viewtopic.php?f=6t=3895start=0

Feel free to tell people to test it.


  Anyway, I will be back next week.


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev