On 10/5/09, Zarel <zarelxxx...@xxxxxxcom> wrote:
> On Sun, Oct 4, 2009 at 9:57 PM, bugs buggy <buginx...@xxxx.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
