Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11671] trunk/lib/ivis_common/tex.h
On Wed, Sep 15, 2010 at 9:08 PM, muggen...@users.sourceforge.net wrote: Log Message: --- Replace #ifdef(APPLE) #include $path/gl.h sections with SDL_opengl.h which handles this already Please do not mess around too much with SDL related stuff, if you do not strictly need to, since it breaks Qt branch. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11671] trunk/lib/ivis_common/tex.h
On Thu, Sep 16, 2010 at 09:51:38AM +0200, Per Inge Mathisen wrote: On Wed, Sep 15, 2010 at 9:08 PM, muggen...@users.sourceforge.net wrote: Log Message: --- Replace #ifdef(APPLE) #include $path/gl.h sections with SDL_opengl.h which handles this already Please do not mess around too much with SDL related stuff, if you do not strictly need to, since it breaks Qt branch. Right, understood. The reason for that ^^ change was to get rid of the #ifdef APPLE-stuff when including gl.h and glu.h. This is already dealt with by SDL_opengl.h, thus my reason for using that header. Considering that most places we use SDL_opengl.h we only use it to properly include gl.h and glu.h we could probably take that part from SDL_opengl.h (which is independent of SDL) and move that into a wrapper header in lib/framework/ or lib/ivis_opengl/. That would additionally make porting to GLESv2 (OpenGL ES 2.0) slightly easier by requiring the addition of preprocessor conditionals to only that header. How would you feel about that approach? I'm reasonably sure it will even reduce the Qt branch's breakability with respect to the GL/SDL combination. -- Giel -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: Digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 (final) release plan
On Wed, Sep 15, 2010 at 9:06 PM, buginator buginato...@gmail.com wrote: First off, we need everyone to vote which icons to use for Cyp's changes. (no VTOL, no Cyborgs, and no tanks, and the kick icon) http://forums.wz2100.net/viewtopic.php?f=33t=6439 Does this need a vote? o_O We use the borg icon already in the game (the one n2large0shirt posted), and we use the latest VTOL icon (CinC's). I'll be fixing them up to look nicer when I have the time, but for now, those suffice. I also think we should include the intel vids from sequences.wz along with novideo.ogg file (which has been in all the release candidates.) The files are pretty small anyway, and they won't add that much more to the final build. Yeah, what Giel said. You gotta be less vague about this stuff. :P For the balance changes, I assume since nobody has really said anything that I can tell in the balance feedback thread, or the 2.3.5_rc4 thread, that it is OK now ? Balance isn't perfect, but it isn't worse than before. I have a few things left to do, but I can leave them for 2.3.6. Is there anything else before we tag ? Nothing from me, except maybe some changelog changes. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #2174: OIL! OIL! WE FOUND OIL!!!!! (bug: exponential oil drum growth)
#2174: OIL! OIL! WE FOUND OIL! (bug: exponential oil drum growth)
-+--
Reporter: CorvusCorax | Type: bug
Status: new | Priority: major
Milestone: unspecified |Component: Engine: Networking
Version: svn/2.3 | Keywords: oil drum spree
Operating System: All/Non-Specific | Blocked By:
Blocking:|
-+--
In a multiplayer game, once the game is created, multiGameInit() will call
campInit(), where the host will place PLAYER_COUNT *2 oil drums randomly
on the map:
{{{
multiopt.c: #568:
if (NetPlay.isHost) // add oil drums
{
addOilDrum(NetPlay.playercount * 2);
}
}}}
if such a drum (or in fact any oil drum on the map) gets picked up, a new
oil drum will be randomly placed on the map
{{{
move.c: #2912
static void checkLocalFeatures(DROID *psDroid)
{
SDWORD i;
BASE_OBJECT *psObj;
// only do for players droids.
if(psDroid-player != selectedPlayer)
{
return;
}
droidGetNaybors(psDroid);// update naybor list.
// scan the neighbours
for(i=0; i(SDWORD)numNaybors; i++)
{
#define DROIDDIST (((TILE_UNITS*5)/2) * ((TILE_UNITS*5)/2))
psObj = asDroidNaybors[i].psObj;
if ( psObj-type != OBJ_FEATURE
|| ((FEATURE *)psObj)-psStats-subType !=
FEAT_OIL_DRUM
|| asDroidNaybors[i].distSqr = DROIDDIST )
{
// object too far away to worry about
continue;
}
if(bMultiPlayer (psObj-player == ANYPLAYER))
{
giftPower(ANYPLAYER,selectedPlayer,true);
// give power
CONPRINTF(ConsoleString,(ConsoleString,_(You
found %u power in an oil drum.),OILDRUM_POWER));
addOilDrum(1);
}
else
{
addPower(selectedPlayer,OILDRUM_POWER);
CONPRINTF(ConsoleString,(ConsoleString,_(You
found %u power in an oil drum),OILDRUM_POWER));
}
removeFeature((FEATURE*)psObj);
// remove artifact+ send multiplay info.
}
}
}}}
checkLocalFeatures() gets called any time a droid moved, so if any droid
moves near an oil drum it gets picked up, a destroy message is sent on the
network, but before that addOilDrum(1) is called which will place one new
oildrum on the map, too. And inform all other players about it.
Now imagine the beforementioned cramped map. Theres almost no free space
on the map, except in the middle, where 8 players armies are battling it
out.
Right in the middle of a battlefield is a bad place for an oil drum to
magically appear though!
Why?
Because the next cycle after it appeared, multiple players might have
droids near it.
(it doesn't matter if they are on the same team or not)
Each of them will claim it the next cycle after they received that
notification, since the droids are moving. Then subsequently send an obj
removal notification to all the others, as well as place one new oil drum
on the map.
So For each nearby player, one new oildrum is placed on the map.
But remember, we said the map was cramped, so at least one of these oil
drums ends up in the midst of a pulk of units again!
And gets magically duplicated...
This is almost like sharing movies on PirateBay. I can have it, and you
can have it too, and then we give copies to others!
It didn't take long with 8 players on the attached map, and we couldn't
build a single building anymore because everything was full of oil drums.
And that was at the time when we barely had reached ripples. Oil drums
spawned faster than we could pick them up and I got these errors galore:
{{{
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(15,14)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(7,39)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(9,11)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(6,12)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(16,23)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(8,12)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(15,24)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(16,22)!
error |08:07:43: [recvMultiPlayerRandomArtifacts] Already something at
(16,25)!
error
[warzone2100-dev] What other changes should happen in 2.4 ?
Since I have implemented map support for X players, (where X = 2 through 8), this will require a slight change in how maps are made. The thread for this is located here: http://forums.wz2100.net/viewtopic.php?f=5t=5309start=165#p69854 I feel it would be best to do a major version bump from the current 2.3.5 to 2.4. And, since we will have a 2.4, is there any other change that people want to be put in this? So far, I think CorvusCorax's patch http://developer.wz2100.net/ticket/2151, the map patch mentioned above, the transport patch mentioned in this thread: http://forums.wz2100.net/viewtopic.php?f=5t=6237start=30#p69718 and then some more net code changes (and GAMESTRUCT--which also means master server changes). Anyone working on anything else ? Also, to make it clear, would we make a new 2.X branch form the current 2.3, or abuse 2.3 to also be 2.4 ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
