Menu
▾
▴
sc2-devel — For developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(90) |
Sep
(74) |
Oct
(56) |
Nov
(13) |
Dec
(139) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(22) |
Feb
(6) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(7) |
Dec
(4) |
| 2004 |
Jan
(2) |
Feb
(3) |
Mar
(5) |
Apr
(1) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2006 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
(2) |
Dec
(6) |
| 2007 |
Jan
(4) |
Feb
(8) |
Mar
|
Apr
|
May
(4) |
Jun
(6) |
Jul
(8) |
Aug
(26) |
Sep
(18) |
Oct
(6) |
Nov
(6) |
Dec
(4) |
| 2008 |
Jan
(6) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(12) |
Oct
(11) |
Nov
(43) |
Dec
(64) |
| 2009 |
Jan
(59) |
Feb
(18) |
Mar
(41) |
Apr
(38) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Serge v. d. B. <sv...@st...> - 2006-02-20 22:23:05
|
On Sun, 12 Feb 2006, Scott A. Colcord wrote: > An article at <http://www.thestreet.com/tech/gamesandgadgets/10267684.html> > suggests that Atari is nearing bankruptcy. Should that occur, there might > be an opportunity for someone to buy the SC2 trademark from the bankruptcy > auction. > > ----Scott > > The preceding has been a public service announcement of FNN, the Frungy News > Network. If a bankruptcy were to occur, I doubt anyone would have the chance to buy a single trademark. I'd expect the company to be sold off in large chunks. But perhaps whichever company ends up with the Star Control trademark would be willing to set it free, for a bit of good PR. Serge |
|
From: sacspam <sa...@pr...> - 2006-02-20 21:59:16
|
sav...@ho... wrote: > Hi all, > After reading the Atari article I did some checking up. I am from the > Pong era and have been a Atari fan for a long time. This may seem like > I'm going off on a tangent but there is a point. Atari is for lack of > a better term "old school and old money" in the sodtware industry. The > problem with "old" is that they tend to try to stick to old practices > and methods. This hinders a younger software generation from > programmers to gamers. I beleive the loss of CEO will bring down the > company and the fact that HSBC is a terrible financial agency. They > loose the human factor of business and often set unrealistic criteria > for loans. However for the SC2 groups out there this may be a shining > light. I believe that Atari should be contacted and be offered a bid > for the rights to SC2. I beleive it should be a community effort not > one based on a individual or a company. This was made for the people > and should be owned by the people. I believe we should setup a paypal > or other type of way o > f making donations to put up for bid on the title. Being in Iraq I > have a little extra put aside that I would more than wish to donate > for the cause. SC2 encopassed alot of time when I was a young soldier > and I'm so enjoying it again since it was ported. There is a good fan > base and I think we should keep it that way. I'm sure that Atari would > see it that way as well. Thanks I think it'd be great if the SC2 trademark was released to the community. However, before we get ahead of ourselves, we'd need to have some idea (at least an order-of-magnitude guess) of how much money would be required. Also, note that it could be a bad move to take up a collection in any publicly viewable way, since if it goes to a bankruptcy auction, it's important to keep the potential amount of your bid secret. ----Scott |
|
From: <sav...@ho...> - 2006-02-20 21:35:27
|
Hi all, After reading the Atari article I did some checking up. I am from the Pong era and have been a Atari fan for a long time. This may seem like I'm going off on a tangent but there is a point. Atari is for lack of a better term "old school and old money" in the sodtware industry. The problem with "old" is that they tend to try to stick to old practices and methods. This hinders a younger software generation from programmers to gamers. I beleive the loss of CEO will bring down the company and the fact that HSBC is a terrible financial agency. They loose the human factor of business and often set unrealistic criteria for loans. However for the SC2 groups out there this may be a shining light. I believe that Atari should be contacted and be offered a bid for the rights to SC2. I beleive it should be a community effort not one based on a individual or a company. This was made for the people and should be owned by the people. I believe we should setup a paypal or other type of way o f making donations to put up for bid on the title. Being in Iraq I have a little extra put aside that I would more than wish to donate for the cause. SC2 encopassed alot of time when I was a young soldier and I'm so enjoying it again since it was ported. There is a good fan base and I think we should keep it that way. I'm sure that Atari would see it that way as well. Thanks SavageMind |
|
From: Alex V. <av...@us...> - 2006-02-13 05:15:57
|
Many thanks for the info, Scott. Really! I think I speak for all of us at UQM team saying that most likely none of us can afford to buy the trademark. I am wondering, however, if TFB would be willing to attempt it. I would not want to see it fall into the hands of some evil publishing giant (cue doom music here). -Alex. -----Original Message----- From: sc2...@li... [mailto:sc2...@li...] On Behalf Of Scott A. Colcord Sent: Sunday, February 12, 2006 10:18 PM To: sc2...@li... Subject: [Sc2-devel] Atari bankruptcy and the Star Control trademark An article at <http://www.thestreet.com/tech/gamesandgadgets/10267684.html> suggests that Atari is nearing bankruptcy. Should that occur, there might be an opportunity for someone to buy the SC2 trademark from the bankruptcy auction. ----Scott The preceding has been a public service announcement of FNN, the Frungy News Network. |
|
From: Scott A. C. <sac...@pr...> - 2006-02-13 03:41:39
|
An article at <http://www.thestreet.com/tech/gamesandgadgets/10267684.html> suggests that Atari is nearing bankruptcy. Should that occur, there might be an opportunity for someone to buy the SC2 trademark from the bankruptcy auction. ----Scott The preceding has been a public service announcement of FNN, the Frungy News Network. |
|
From: Serge v. d. B. <sv...@st...> - 2005-10-25 15:33:10
|
On Mon, 24 Oct 2005, P S wrote: > strupr not found > stricmp not found These messages are harmless. These symbols are usually only present on Windows. If they're not found, strcasecmp() will be used instead of stricmp() and an included implementation of strupr() will be used. > I installed all of the software listed in the INSTALL > file that came with v.0.4. I suspect these symbols > are used by the keycode file, because the copy I > compiled from > > Debian Sarge > > The 'iswgraph' symbol is provided by libopenal under > Debian. It may be the same way with other dists. iswgraph() being provided by libopenal sounds very strange. However, a missing iswgraph() is not a problem either. If build.sh bails out before a menu is displayed, it is the last message shown which gives you the reason. Serge |
|
From: P S <vis...@sb...> - 2005-10-24 21:02:25
|
strupr not found stricmp not found I installed all of the software listed in the INSTALL file that came with v.0.4. I suspect these symbols are used by the keycode file, because the copy I compiled from Debian Sarge The 'iswgraph' symbol is provided by libopenal under Debian. It may be the same way with other dists. |
|
From: Leo B. <cxk...@ya...> - 2004-12-27 02:43:26
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head><body bgcolor="#FFFFF1" text="#6C3B7F"><p><a href="http://qijsc.cmlacjkb.info/?P5RbRXQhnTqDA7jspxdugvbdkd"><IMG SRC="cid:part1.08010306.02090101@kwb...@ho..." border="0" ALT=""></a></p><p><font color="#FFFFFF">Let's talk it over Firestone Tires in 1876 in 1863</font></p><p><font color="#FFFFF3">in 1918 in 1823</font></p></body></html> |
|
From: Jason B. <jb...@tu...> - 2004-12-16 07:16:18
|
On Debian Woody, the package to install for the Ogg Vorbis stuff is at least "libvorbis-dev". I know I had it installed for run-time use prior to trying to compile UQM, so I don't know if there's another package that's needed, but that one in particular needs to be, um, apt-got. I assume the Sid package has that as a dependency. Jason B. -- When a garbage can gets old, how do you throw it away? |
|
From: Serge v. d. B. <sv...@st...> - 2004-06-18 15:10:47
|
On Wed, 16 Jun 2004, Scott A. Colcord wrote: > I've noticed that all the unicode wchar functions have been #defined back to > their ASCII parallels. It seems like this would break any attempt to make > unicode work properly. Is there any reason for it? > > src/sc2code/globdata.h: > #define wsprintf sprintf > #define wstrlen strlen > #define wstrcpy strcpy > #define wstrcat strcat > #define wstrupr strupr > #define wstrncpy strncpy > #define wstricmp stricmp > #define wstrtoul strtoul > #define wstrcspn strcspn At some point at the start of the project, Chris had made a start of converting the existing code to use unicode, but it appearantly was not finished yet, and these defines were made to get back to the original behaviour (globdata.h is not really the place for this though). When the new resource system gets introduced, that will also take care of unicode strings. We may end up using UTF8 encoding though instead of UTF16. Serge |
|
From: Serge v. d. B. <sv...@st...> - 2004-06-18 14:57:35
|
On Wed, 16 Jun 2004, Scott A. Colcord wrote:
> I've noticed that there are two different booleans used in the code:
>
> src/sc2code/libs/compiler.h:
> typedef enum
> {
> FALSE = 0,
> TRUE
> } BOOLEAN;
>
> src/types.h:
> typedef enum
> {
> false = 0,
> true
> } bool;
>
> Is this by design, or is it something that should change? My intuition says
> to use 'bool', since that's the way the C99 standard did it.
compiler.h was part of the original code. types.h is something we created.
We should at some point get rid of not only BOOLEAN, but also types like
BYTE, UWORD, WORD, UWORD, and DWORD. It hasn't been a priority though.
For now, just try to match the type that is used in the code you modify.
Serge
|
|
From: Scott A. C. <sac...@pr...> - 2004-06-16 18:35:20
|
I've noticed that all the unicode wchar functions have been #defined back to their ASCII parallels. It seems like this would break any attempt to make unicode work properly. Is there any reason for it? src/sc2code/globdata.h: #define wsprintf sprintf #define wstrlen strlen #define wstrcpy strcpy #define wstrcat strcat #define wstrupr strupr #define wstrncpy strncpy #define wstricmp stricmp #define wstrtoul strtoul #define wstrcspn strcspn ----Scott |
|
From: Scott A. C. <sac...@pr...> - 2004-06-16 18:35:04
|
I've noticed that there are two different booleans used in the code:
src/sc2code/libs/compiler.h:
typedef enum
{
FALSE = 0,
TRUE
} BOOLEAN;
src/types.h:
typedef enum
{
false = 0,
true
} bool;
Is this by design, or is it something that should change? My intuition says
to use 'bool', since that's the way the C99 standard did it.
----Scott
|
|
From: <ami...@be...> - 2004-03-10 03:38:12
|
Your message was bounced by the recipient's mail server The Recipient account on this server is canceled. |
|
From: Niemi M. <mar...@yt...> - 2004-03-03 11:08:04
|
Olen j=E4=E4nyt virkavapaalle 1.9.03 alkaen vuodeksi. Koska sijaiseni = valinta on kesken, on tarvittaessa parasta k=E4=E4nty=E4 johtajaylil=E4=E4k=E4rin = sihteerin puoleen. H=E4n on Heidi J=E4rvinen, s=E4hk=F6postiosoite: = Heidi:J=E4r...@YT... |
|
From: Postmaster <pos...@im...> - 2004-02-11 07:14:51
|
No message body: cat...@pa... Original message follows. |
|
From: Michael C. M. <mcm...@st...> - 2003-12-08 14:54:44
|
On Mon, 8 Dec 2003, Serge van den Boom wrote: > Alternative approaches: make the dialog scrollable, or put a number over > the image, indicating the amount of ships of that type. I'd lean towards scrollable dialogs. We can't really use OpenGL to do scaling directly since everything's pixel-based in the engine (we'd use our own mipmap-based rotozoomer for that), and even then, if the number of ships gets large enough, it will fall into unrecognizability. --Michael |
|
From: Serge v. d. B. <sv...@st...> - 2003-12-08 13:41:49
|
On Sun, 30 Nov 2003, Jason Dorje Short wrote: > With opengl we could scale the images. But my approach has been > simpler: just make the boxes they're stored in smaller, and let the > drawing library fit them as well as possible. It's quite playable, > although as I said it's incomplete. Alternative approaches: make the dialog scrollable, or put a number over the image, indicating the amount of ships of that type. (only when necessary, to be 'compatible' with the original game). The latter probably won't be as good as later people could add lots of types of custom ships. Serge |
|
From: Jason D. S. <js...@an...> - 2003-12-01 03:27:05
|
sanjay madhav wrote: > Well, the problem is that the actual drawable area for the teams is dependant on the sizes of a few of the content files (content/melee/melee.0.png, content/melee/melee.1.png, content/melee/melebkgd.0.png, and content/melee/melebkgd.28.png). When I changed the teams to have 14 like the PC version, instead of 12, I had to resize those images. > > Now it's probably not that much of an issue for, say, the main melee screen, because the size of those boxes can definitely be reworked to be calculated (and can be made smaller). But the save/load and select ship in combat screens have pretty small icons already, and the ship selection part would definitely need to be reworked how that is drawn. > > Ideally (and I speak for myself, not the team) it would be nice down the road to be able to just change some number in an xml file and change the sizes of the teams. But, that would definitely require some reworking. With opengl we could scale the images. But my approach has been simpler: just make the boxes they're stored in smaller, and let the drawing library fit them as well as possible. It's quite playable, although as I said it's incomplete. But the races.h change is something quite different: without this the queue code will segfault in a difficult-to-trace way. If it's possible to change the #defines, it would also be easy enough to make them variables loaded from a config file. But I don't know if that's a goal for the near future. jason |
|
From: sanjay m. <ma...@us...> - 2003-12-01 01:29:12
|
Well, the problem is that the actual drawable area for the teams is dependant on the sizes of a few of the content files (content/melee/melee.0.png, content/melee/melee.1.png, content/melee/melebkgd.0.png, and content/melee/melebkgd.28.png). When I changed the teams to have 14 like the PC version, instead of 12, I had to resize those images. Now it's probably not that much of an issue for, say, the main melee screen, because the size of those boxes can definitely be reworked to be calculated (and can be made smaller). But the save/load and select ship in combat screens have pretty small icons already, and the ship selection part would definitely need to be reworked how that is drawn. Ideally (and I speak for myself, not the team) it would be nice down the road to be able to just change some number in an xml file and change the sizes of the teams. But, that would definitely require some reworking. Sanjay ----- Original Message ----- From: Jason Dorje Short <js...@an...> Date: Sunday, November 30, 2003 3:19 pm Subject: [Sc2-devel] changing NUM_MELEE_ROWS/NUM_MELEE_COLUMNS > One thing I've always wanted to do is allow more ships in melee. I want > to be able to use all 25. > > So I tried increasing NUM_MELEE_ROWS and NUM_MELEE_COLUMNS. Naturally > this didn't work too well. So I worked through the problems. The > gzipped attached patch is my result here. It is incomplete but allows > reasonably good gameplay. > > Of course, I'm sure these values aren't going to be changed in CVS. But > it would be nice if someone could change them and have things work > without needing lots of other changes. The attached plaintext patch is > a small step in this direction (but took the most work to find). > > jason > |
|
From: Jason D. S. <js...@an...> - 2003-11-30 23:20:44
|
One thing I've always wanted to do is allow more ships in melee. I want to be able to use all 25. So I tried increasing NUM_MELEE_ROWS and NUM_MELEE_COLUMNS. Naturally this didn't work too well. So I worked through the problems. The gzipped attached patch is my result here. It is incomplete but allows reasonably good gameplay. Of course, I'm sure these values aren't going to be changed in CVS. But it would be nice if someone could change them and have things work without needing lots of other changes. The attached plaintext patch is a small step in this direction (but took the most work to find). jason |
|
From: Ville <vil...@ik...> - 2003-11-20 16:50:36
|
On Thu, 2003-11-20 at 18:36, Mika Kolehmainen wrote: > On Thu, 20 Nov 2003, Alex Volkov wrote: > > > Thanks, Ville. I was hoping one of the core members would answer sooner, but > > they all seem busy. > > Really just acknowledging receipt for now ;-). > > Yeah we all have been quite busy for some time now. Anyway, a link to > Fedora is now added to our download page. Thanks, and no problem, it took us over a month to get the trivial update (in packaging terms) from 0.2 to 0.3 in the repository in the first place :) |
|
From: Mika K. <mim...@cc...> - 2003-11-20 16:37:12
|
On Thu, 20 Nov 2003, Alex Volkov wrote: > Thanks, Ville. I was hoping one of the core members would answer sooner, but > they all seem busy. > Really just acknowledging receipt for now ;-). Yeah we all have been quite busy for some time now. Anyway, a link to Fedora is now added to our download page. -- Mika Kolehmainen <mim...@cc...> |
|
From: Alex V. <av...@bp...> - 2003-11-20 09:42:58
|
Thanks, Ville. I was hoping one of the core members would answer sooner, but they all seem busy. Really just acknowledging receipt for now ;-). Alex Volkov. ----- Original Message ----- From: "Ville Skyttä" <vil...@ik...> To: <sc2...@li...> Sent: Wednesday, November 19, 2003 1:56 PM Subject: [Sc2-devel] Red Hat/ Fedora Core RPMs -- fedora.us > FYI: Red Hat 9 and Fedora Core 1 RPMs of UQM 0.3 and the content pack > are available from www.fedora.us, the "testing" repository. Feel free > to add a link to sc2.sf.net if you like. > > (And let me know if this is not the correct place for announcements like > this...) > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Sc2-devel mailing list > Sc2...@li... > https://lists.sourceforge.net/lists/listinfo/sc2-devel |
|
From: Alex V. <av...@bp...> - 2003-11-19 23:45:33
|
Interesting ideas, Jason. I have a couple comments: 1) I doubt very much that any of this will be implemented before UQM hits v1.0. The ultimate 1.0 goal is to make a straight port, whereas after 1.0 I suspect there will be branching of versions. 2) I think this *could* be implemented using the emerging Code DataPlate system, but not in the immediate future. Unfortunately, none of the core team has any spare time, and the rest of us just help out the best we can. 3) If you would like a discussion on the subject of AI improvements and if you are also willing to filter through some questionably constructive comments (to put it lightly), I think you will be better off at the General Discussion UQM forum -- http://uqm.stack.nl/cgi-bin/yabb/YaBB.pl . Many more people read and respond to the forum articles. Regards, Alex Volkov. ----- Original Message ----- From: "Jason Dorje Short" <js...@an...> To: <sc2...@li...> Sent: Wednesday, November 19, 2003 5:18 AM Subject: [Sc2-devel] a better AI: strategy and tactics > I assume improving the AI is not currently a priority, but as an > experienced Melee player it is something I am interested in. > > > The easiest and most boring way to improve the cyborg AI would be by > introducing non-combat strategy: specifically non-random ship selection. > Each ship generally has around 5 ships that it is particularly strong > against and 5 ships that it is particularly weak against. As an > example, the Druuge is a good ship to pick against the Chmmr, while the > Spathi generally is not. Simply adding a few ship 'preferences' here > could make the cyborg vastly more competitive. More complicated > strategy might take into account the damage level of the ship you are > facing off against, or how a particular choice matches up against other > ships remaining in the opponents' fleet. > > But making this type of change reduces the variety of battles that you > encounter, so it will also make the Cyborg more boring. Not good. > > > Improving the tactics of the cyborg should be a bigger priority. The > cyborg is already a spectacular pilot and gunner - facing a cyborg Pkunk > or Druuge can be an excercise in frustration because of this (again, not > something that is fun). But in tactics the cyborg is very weak. It > should use more correct tactics against its opponents, and also use more > varied tactics. Both will add both to the competitiveness and the > entertainment value of the AI. > > I was discussing this with a friend the other day, and tried to codify > the different tactics that I use regularly. I came up with 6 of them. > In order of increasing sophistication, they are: stand, charge, flee, > circle, get planet-whip, get planetary orbit. > > Looking at the current cyborg code, I see four different tactics: pursue > (charge?), avoid (flee?), entice (circle?), and wait (stand?). As I > recall the AI is fairly incapable of using the planet: it occasionally > gets planet-whip but never keeps it for long, and never orbits the planet. > > To design the AI as an expert system, I would teach the AI to use the > above six tactics, teach it to recognize the opponent's tactics, and > then add code to select the current tactic. > > A simple way to do this is to choose our tactic based on the opponent's; > something like > stand => circle/charge > charge => flee/get planet whip > flee => circle/charge/get planet whip > circle => circle/charge > planet whip => charge/stand > orbit planet => charge/circle > but this is probably similar to the current algorithm, and will fail in > many cases. > > Something more extensive, but still logically simplistic would take into > account the current ship and the opponent's ship as well as the > opponent's tactics. In the most brain-dead case this could take the > form of a 25x25x6 matrix of tactical choices; however this would have a > lot of redundancy and still wouldn't be as good as a human tactical > agent. It would, however, be easy to put in the ship-description > data-files rather than directly in the code, thus being more modular and > modifiable. > > It is also desirable to change tactics from time to time and/or choose a > somewhat random element in picking a tactic. In most situations there > are two or three reasonable tactics, and if one doesn't work you should > try another. This is probably the area where the current cyborg is most > deficient. > > A 25x25x6x3 matrix may sound daunting and unmaintainable, but in the > grand scheme of things I think it should be manageable. However, such a > scheme would still leave many things out, and at that point adding more > complexity is too much. > > > Ideally the cyborg could deduce the correct strategy from the basic laws > of the system and its knowledge of each ship's abilities. For instance > it should be able to deduce that a ship that is faster and has longer > range than its opponent should maintain an ideal distance and then open > fire. Coming up with a full list of such rules will take a real expert > (even this rule is overly simplistic and only works against the 'stand' > tactic). There may be a few additional values that the cyborg would > like to know that could be measured by human experts and then put into > the ship description files. > > > For me, the Supox-versus-Yehat battle is an example of how increased > tactical sophistication can make the game more interesting. When I > first started playing (against human opponents), the Yehat would > generally win. Soon the flee and circle tactics were developed, and > things swung over to the Supox's side. When we discovered the tactic of > getting planet-whip, things were balanced out again. However, with a > combination of intercept-and-flee tactics, the Supox can defeat this. > With the introduction of the most sophisticated tactic I know, planetary > orbit, the Yehat was able to again recover an even number of victories. > > But could we have known all that just by looking at the ships' > statistics? The supox can fire backwards and sideways to its vector of > acceleration, so it is a good candidate for flee and circle tactics. > The Yehat has good acceleration and low top speed, so it is a good > candidate for planetary tactics. > > Maybe. > > -jason short > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Sc2-devel mailing list > Sc2...@li... > https://lists.sourceforge.net/lists/listinfo/sc2-devel |
333 messages has been excluded from this view by a project administrator.
