2 versions of alogg
by Hans de Goede
Hi all,
Quoting myself from:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188625
---
Before I forget the ugly name is because there are 2 alogg libraries out
there, one which is called just alogg and one which is called AllegroOGG
but still use alogg as soname. I hope we never need the other alogg
otherwise I see a problem, but with this name atleast its clear which
alogg this is:
http://lyrian.obnix.com/alogg/
http://nekros.freeshell.org/delirium/alogg.html
---
Thanks for the review! I've not imported this sofar, because the fact
that debian has the other alogg packaged worries me, this means that the
other one is used by some free software too, so sooner or later we will
need to package it too. I think I'll just start packaging the other one
right away so that I can find any conflicts now and come up with a
resolution, before a bunch of packages depends on one or the other.
---
So there we are 2 different ogg support for use with allegro support
libraries both installing:
/usr/lib/libalogg.so
One of them installs:
alogg.h
And the other:
alogg/alogg.h
Which also seems like an accident waiting to happen. I'm thinking of
solving this by:
-give AllegroOGG a new soname: libAllegroOGG.so, or should I give them
both a new name, and in that case what should I use for alogg?
-putting all the header files of both in seperate dirs under include:
/usr/include/allog/(alogg/alogg.h)
/usr/include/AllegroOGG/(allogg.h)
-modifying allog-config todo the right thing for alogg
-use pkgconfig for AllegroOgg
-patch AllegroOGG using programs to use pkgconfig. Currently only raidem
can use AllegroOGG (I have a new version ready which adds ogg support
as a replacement for the stripped out mp3 support, giving raidem its
background music back).
So does this sound like a plan if not, what do you suggest?
Regards,
Hans
18 years
last prboom update
by Nicu Buculei
Last prboom update is awful. The lack of functionality (not possible to
change the screen resolution or go full screen) can be forgiven, the
datalos is much worse: the old configuration (like keyboard mapping) is
lost and savegames from the old version does not work ("incompatible
savegame" error message).
I guess this was caused by the changes made upstream, not by packaging,
but this is a kind of situation one would be expecting whenm updating
from Rawhide, not from the stable branch.
--
nicu
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro
18 years
user-writable content in games
by Michael Thomas
I've come across two games so far that allow user-contributed content,
but am unsure of how to proceed with the file permissions.
The first game, njam, has an in-game editor for users to create new
levels. The directory where user-levels are saved is
/usr/share/njam/levels.
The second game, hack (part of bsd-games), creates 'bones' files when a
character dies. These bones files are later loaded and removed when
other players start a game to create ghosts and treasure piles.
In both cases this user-contributed content needs to be placed in a
directory that is writable by the game binary. This is similar to the
shared scoreboard file, except that in both of these cases the name of
the file is not known in advance, so we can't open a setgid filehandle
when the game starts up and then drop setgid.
hack works around this by not dropping setgid so that the app is free to
create new files in the content directory, which isn't the safest thing
to do.
Does anyone have any ideas on how we can allow this user-contributed
content without sacrificing too much security in the games?
--Mike
18 years
prboom update
by Michael Thomas
FYI: I've updated prboom on FC4, FC5, and devel to the latest upstream
2.4.1 release. In addition, I enabled opengl support in the binary.
>From the testing that I've done, the opengl support is at least as
stable as without.
If anyone wants to see the non-opengl version return then I'll try to
include both, but for now I'm inclined to ignore it.
Happy Dooming!
--Wart
18 years
Save games
by Michael Thomas
Many of the current single-player games (ularn, rogue) let the user save
the game state so that they can come back to it later. These save files
are stored in the user's home directory. Clever users could use a
binary editor to modify the save files to cheat at the game (increasing
money, player stats, etc.) to increase their position in the shared
scoreboard files. non-clever users could simply backup the save files
to restore the game after they die.
What strategies could be used to prevent this sort of cheating? Should
save files be moved into a shared directory, owned by root.games, so
that user's can't edit them?
Or is the impact of this cheating so minor that it's not worth worrying
about?
--Wart
18 years
Re: non-desktop art?
by Michael Thomas
Cross-posting to f-g-l due to relevance:
Nicu Buculei wrote:
> Máirín Duffy wrote:
>
>> Michael Thomas wrote:
>>
>>>
>>> Is there any interest from the Fedora art community in helping out with
>>> artwork for some of the Fedora games? Or is that outside the charter of
>>> this group?
>>
>>
>> Do you mean the gnome games? What games are you talking about
>> specifically?
>
>
> Yesterday when i learned about the games SIG i was hit about an idea: is
> some interest on personalizing the look of Gnome games? I realize this
> is somewhat contrary to the desire of staying as close as possible to
> upstream.
>
> I just started to feel the taste of modifying graphics on those games
> with Gnome 2.14 which have my graphics as default in gnobots and my
> playing cards on gnome-games-extras.
>
> Ideas for such personalization:
> - a set of stones in Same Gnome featuring the infinity symbol from the
> logo;
> - the back of the playing cards being in Fedora's blue.
I think this is a fine idea. From what I can tell, installing a new
same-gnome theme is just a matter of dropping a new .png file into
/usr/share/gnome-games/same-gnome/themes. Other gnome games are
probably just as easy to re-theme.
I can see two ways to add the additional themes. The preferred method
would be to submit them upstream and get them included in the original
upstream package. This would simplify the packaging and installation
process greatly.
If, for whatever reason, upstream is not receptive to adding new themes,
then we can make a new 'gnome-games-themes' package that contains the
new themes. The advantage of using a separate package is that new
themes could be added without having to coordinate with upstream
gnome-games releases.
I would welcome new themes for these games and would be willing to help
coordinate with upstream or package them separately as needed.
--Wart
18 years
[Fwd: Re: Comps, or, Making it Easier for Users to Find Software]
by Michael Thomas
Forwarding this from f-e-l. Apologies if you have already read it.
Jeremy has asked if anyone wants to help with a cvs submit filter for
verifying the integrity of the comps-fe5.xml file. This should be
simple enough with the 'xmlwf'.
He's also asked if anyone wants to submit patches for yum so that we can
install optional group packages more easily (most games fall under this
category).
Any takers?
--Wart
-------- Original Message --------
Subject: Re: Comps, or, Making it Easier for Users to Find Software
Date: Mon, 17 Apr 2006 15:04:58 -0400
From: Jeremy Katz <katzj(a)redhat.com>
Reply-To: Discussion related to Fedora Extras
<fedora-extras-list(a)redhat.com>
To: Discussion related to Fedora Extras <fedora-extras-list(a)redhat.com>
References: <1142054562.2915.4.camel(a)aglarond.local>
<4442946A.40507(a)kobold.org>
<1145296661.26993.72.camel(a)orodruin.boston.redhat.com>
<4443DC84.60706(a)kobold.org>
On Mon, 2006-04-17 at 11:20 -0700, Michael Thomas wrote:
> Jeremy Katz wrote:
> > On Sun, 2006-04-16 at 12:00 -0700, Wart wrote:
> > One thing that would help is a script to be run as a pre-commit check to
> > ensure the file is well-formed.
>
> I'll ask the SIG to see if we can come up with something. What are the
> rules for pre-commit scripts in terms of languages, locations,
> dependencies, etc.? Or is it enough to run xmlwf on the file?
The XML file just needs to be well-formed. Eventually, translations
will be getting merged in, but that's the "easy" part. And dependencies
also don't need to be specified as those get resolved at runtime
> >>Additionaly, it seems that the FE games are listed as 'optional'
> >>packages in yum, which means that users can't use 'yum groupinstall
> >>games' as a shortcut to get all of them. What determines if a package
> >>is 'optional' or 'required'? Would it be possible to change it so that
> >>users can get all of the games via 'yum groupinstall', either by
> >>reclassifying the FE5 games as 'required', or by creating a new category
> >>for these games?
> >
> >
> > If a package is required, then the group isn't considered installed
> > without the package being installed. You almost certainly don't want
> > that behavior with all of the games :-) And I don't even think a
> > separate category is really what's wanted. What problem are you trying
> > to solve by installing all of the games?[1]
>
> The ultimate problem is that I'm trying to avoid doing any real work.
> :) I'd like to be able to install all of the games with one command
> after an initial system install, and later use one command to pull in
> any new games that have since been added to the repo.
Heh ;)
> > Jeremy
> >
> > [1] Note, that it would be pretty easy to write the little tool using
> > the yum interfaces that just installed all of the optional packages in a
> > group.
>
> That's what I did for now, which is when I discovered that 'yum
> groupinfo' didn't list them all. Perhaps there could be an option to
> 'yum groupinstall' to install optional packages, such as
> "yum --includeoptional groupinstall games".
Yeah, I'm thinking that something like this is probably the best
approach to the problem. It shouldn't be that hard to add support for
both
* yum groupinstall --alloptional foo
and
* yum groupinstall --requiredonly foo
to yum. Anyone want to volunteer to write the patch? :-)
Jeremy
--
fedora-extras-list mailing list
fedora-extras-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-list
18 years
bsd-games volunteers?
by Michael Thomas
I've been working on packaging bsd-games, a collection of rather dated
text-based games. Due to the large number of games in the package, it's
taken a while to clean this one up. Specifically, the games 'sail' and
'phantasia' need to be audited to try to reduce the amount of code that
gets run setgid.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187964
I'll continue to work on this package, but any help with 'sail' and/or
'phantasia' will speed up the process.
Thanks,
--Wart
18 years
Re: Fedora's Games
by Victor Skovorodnikov
Hi,
I am currently developing a 2D shooter game called "Maximum Destruction". I am in the process of obtaining a license from an original developer of images from Star Control 2 game. Once I get the license and polish up my game, it will be ready for packaging in Fedora's "extras". The game can be reviewed/downloaded at:
www.victorsk.webhop.org
I welcome any feedback on how to improve/extend it's playability.
Thank you,
Victor.
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
18 years
Games Not Showing Up in Pirut
by Christopher Stone
I have noticed that when browsing software with pirut, selecting
Applications/Games & Entertainment only lists a handful of all the
games that are available.
Are we doing something wrong, or is pirut at fault? For example, abe
is listed under Games & Entertainment while worminator is not. Both
packages belong to the same group so I do not understand why pirut is
being selective about which games it lists.
If you use the List view in pirut, I think all the available games are
listed there.
18 years
