Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jon_dArc

Pages: [1] 2 3 ... 9
Mac / Re: HEAD (2.5) build failure on OSX 10.8/Clang and fix
« on: June 05, 2013, 11:40:40 pm »
You missed the second occurrence (not hard, the code block hides it and gives no indication there's anything to scroll to).

Code: [Select]
diff --git a/src/shared/images.cpp b/src/shared/images.cpp
index 4ed93d3..b8f9868 100644
--- a/src/shared/images.cpp
+++ b/src/shared/images.cpp
@@ -397,7 +397,7 @@ static SDL_Surface* Img_LoadJPG(char const* const name)
                jpeg_mem_src(&cinfo, buf, len);
-               jpeg_read_header(&cinfo, true);
+               jpeg_read_header(&cinfo, TRUE);
                cinfo.out_color_space = JCS_RGB;


Mac / HEAD (2.5) build failure on OSX 10.8/Clang and fix
« on: June 05, 2013, 06:20:15 pm »
Building complains about two function calls in src/shared/images.cpp on account of no matching functions in jpeglib.h and no known conversion from bool to boolean; the offending argument is "true", and nearby similar functions use "TRUE" in the same position. Changing the two offending calls to "TRUE" satisfies the compiler; it looks like this might have been a typo (or brain-o) that might be concealed by an implicit conversion in other build environments. The relevant patch is included below:

Code: [Select]
diff --git a/src/shared/images.cpp b/src/shared/images.cpp
index d11e250..b8f9868 100644
--- a/src/shared/images.cpp
+++ b/src/shared/images.cpp
@@ -247,7 +247,7 @@ void R_WriteJPG (qFILE *f, byte *buffer, int width, int heig
        jpeg_set_quality(&cinfo, quality, TRUE);
-       jpeg_start_compress(&cinfo, true);      /* start compression */
+       jpeg_start_compress(&cinfo, TRUE);      /* start compression */
        jpeg_write_marker(&cinfo, JPEG_COM, (const byte *) "UFOAI", (uint32_t) 5
        /* Feed scanline data */
@@ -397,7 +397,7 @@ static SDL_Surface* Img_LoadJPG(char const* const name)
                jpeg_mem_src(&cinfo, buf, len);
-               jpeg_read_header(&cinfo, true);
+               jpeg_read_header(&cinfo, TRUE);
                cinfo.out_color_space = JCS_RGB;


Mac / Re: Current Dev version
« on: October 10, 2012, 05:34:50 pm »
Yes, why?


So from HEAD (and as far back as I can remember offhand) has a nice, convenient little section where it checks to see if /opt/local or /sw exist and, if so, add the first one to exist to CFLAGS/LDFLAGS. This caused some troubles for me back in the day because instead of having my extra libs/headers in either of those locations, I had them in /usr/local (shocking, I know).

Once I figured out what was going on it was a quick fix. Over time, though, UFO:AI has picked up a few more dependencies, some of which have installed themselves in other places—the most recent being, in fact, in /opt/local.

Is there in fact a realistic fear of people getting stale libraries/headers from the wrong source if, instead of selecting precisely one source for headers/libs, instead tested for existence of common places to stick such things and then simply added each one it found (plus /usr/local and /Library/Frameworks) to CFLAGS/LDFLAGS appropriately? It would require a few more tests to tease out exactly where SDL_* is living, but not much more, and it seems like it would dramatically reduce the likelihood that someone will need to edit (or, I guess, probably pass the right options to configure) to have a successful build.


Discussion / Re: Alien Activity
« on: August 26, 2012, 12:33:07 am »
For the purposes of your current game, debug_showinterest and debug_interestset are the console commands that would be useful. I regularly use debug_interestset to accelerate things when the aliens are taking their sweet time.


Discussion / Re: Weapons and damage in 2.5 (HEAD)
« on: August 20, 2012, 06:25:14 pm »
Having realized that the problem I'd been having before was basically just that I'd been trying to make an ad-hoc implementation of the relational calculus on my UFO data structures, I shifted gears and started sticking parse results into a proper relational database. The bad news from all this is that, predictably, I decided to use this as an opportunity to refamiliarize myself with a bunch of tangentially related stuff like database design and normalization, so the whole business is horribly overengineered and slow going. Also, Real Life™ got busy. Still, database population is almost done, which means that the DB schema is firming up; I'm going to toss it (and the rest of my code) up in a proper public repository once DB population is finalized, but for the moment here's the SQL for DB setup. Note that I use some quantity of Postgres-specific features which may or may not be easily removed for more general RDB compatibility.

Code: [Select]
CREATE TYPE team AS ENUM ('phalanx', 'alien', 'civilian');
CREATE TYPE range AS (min int, max int);
CREATE TYPE randval AS (center int, swing int);
CREATE TYPE usestyle AS ENUM ('holdtwohand','firetwohand','onehand');

item_id text PRIMARY KEY,
item_name text NOT NULL,
type text NOT NULL,
price int NOT NULL,
size int CHECK (size >= 0) NOT NULL

CREATE TABLE "armour" (
useable team NOT NULL,
weight int CHECK (weight >= 0) NOT NULL

DROP TABLE IF EXISTS "protection";
CREATE TABLE "protection" (
damageweight text,
resistvalue int NOT NULL,
PRIMARY KEY (item_id,damageweight)

CREATE TABLE "template" (
template_id text PRIMARY KEY,
strength range NOT NULL,
speed range NOT NULL,
accuracy range NOT NULL,
mind range NOT NULL,
close range NOT NULL,
heavy range NOT NULL,
assault range NOT NULL,
sniper range NOT NULL,
explosive range NOT NULL,
piloting range NOT NULL,
targeting range NOT NULL,
evading range NOT NULL,
health range CHECK (health > 0) NOT NULL

unit_id text PRIMARY KEY,
unit_name text NOT NULL,
side team NOT NULL,
wearsarmour bool NOT NULL DEFAULT TRUE,
carriesweapons bool NOT NULL DEFAULT TRUE,

DROP TABLE IF EXISTS "unit_templates";
CREATE TABLE "unit_templates" (
template_id text NOT NULL REFERENCES template ON DELETE CASCADE,
PRIMARY KEY (unit_id,template_id)

DROP TABLE IF EXISTS "resistance";
CREATE TABLE "resistance" (
damageweight text NOT NULL,
resistvalue int NOT NULL,
PRIMARY KEY (unit_id,damageweight)

CREATE TABLE "weapon" (
use usestyle NOT NULL,
ammocap int CHECK (ammocap > 0) NOT NULL,
reload int CHECK (reload > 0) NOT NULL

CREATE TABLE "firedef" (
ammo_id text NOT NULL REFERENCES item (item_id) ON DELETE CASCADE,
weapon_id text NOT NULL REFERENCES weapon (item_id) ON DELETE CASCADE,
name text NOT NULL,
skill text NOT NULL,
vspread real CHECK (vspread >= 0) NOT NULL,
hspread real CHECK (hspread >= 0) NOT NULL,
crouch real CHECK (crouch >= 0) NOT NULL,
range numeric(10,1) CHECK (range >= 0) NOT NULL,
shots int CHECK (shots >= 0) NOT NULL,
ammoconsump int NOT NULL,
tus int NOT NULL,
damage randval NOT NULL,
damageweight text NOT NULL,
reaction bool NOT NULL DEFAULT TRUE,
PRIMARY KEY (ammo_id,weapon_id,name)

My biggest qualm with this design is that it requires me to interpret melee weapons as having 1 ammo and all of their attacks as consuming 0 ammo (except for throwing attacks, which consume 1), and with a 0 reload time, which all seems semantically unsound to me, but I think I'm confident enough in not actually getting into trouble as a result to just go with it.

~J, going all architecture astronaut

Discussion / Re: UFO:AI and Kickstarter
« on: August 16, 2012, 01:54:44 pm »
Why not?
Again, how are you going to turn the cash into progress? Hiring someone who doesn't already work on the game would be thorny in many ways, and I don't think there's any serious prospect of raising enough for one of the current devs to quit their job and work on UFO:AI full time (even if you manage to pay their salary for a year, unless they're already unhappy with their job or there's a real prospect of managing to do it again next year that's just not enough—you'd need at least several years up-front to make the risk acceptable).

Mozilla Corporation, in contrast, is large enough to in fact turn donations into full-time employees.

Now, it's possible that there are resources that could be purchased to help develop the game, maybe a dedicated build/test server or something, but there's another can of worms there: I'm pretty sure there's no UFO:AI Corporation, so anything like that would be owned and physically possessed by one of the devs. How do you ensure ongoing availability of that resource? How do you make sure it gets used to develop UFO:AI and not for the personal affairs of the possessor? This can be a problem even without actual wrongdoing—perception can be just as important.

There's really no point in discussing the matter further until we fill in the "???" in "1) Collect donations, 2) Use the money to ???, 3) UFO:AI is better!".


Discussion / Re: Playing 2-5 dev
« on: August 04, 2012, 05:13:13 pm »
This can be advantage rather than disadvantage for some of us, because it makes battle a bit more "fuzzy".
Ignoring the question of whether "fuzzy" is a good thing or not, in the absence of poking around the UFO files battle could already be mistaken for Bigfoot.


Discussion / Re: Playing 2-5 dev
« on: August 02, 2012, 01:36:05 pm »
-bolter is now some kind of handcannon? 28 TU for aimed shot? Isn’t it a bit too much? And only 2 rounds?
Some kind of cannon, more like. IIRC the fluff always had it as a high-tech successor to the Sniper Rifle; it's just that now the stats bear that out. That said, 28 TU may be a tad steep.

-heavy laser seems to me inferior compared to plasma rifle. In every way. Less damage, same spread, high range is not really so useful, requires a lot of research
Laser weapons in general got excessively nerfed. There's a plan going on to make them a later-game anti-alien-armor weapon, and I'm also working on a weapon analysis and comparison tool to help balancing.

-plasma blaster seems now to be useless. Only 35 damage? It’s good for unarmored targets only.
30±5 damage, actually. It's really all about the Ball firemode at the moment.

-grenade launcher without multiply shots is not worth using. I think that handgrenades are better.
You're ignoring the major increase in range and the increased damage which, though it doesn't look very large, pushes GL grenades at nearly point-blank range solidly into one-hit-kill territory. Three-shot mode was critical in 2.4 mostly because it would almost certainly take at least two grenades to actually kill your target.

As for hand grenades, they've got better radius, TU use, and minimum inventory investment but substantially worse range, decently worse damage, and take up more space per shot ammo-wise; I don't think they really compete.


Discussion / Re: Reaserch
« on: August 01, 2012, 04:17:46 pm »
On a tangent, it would also be nice to have a reason to split your efforts in a single base other than the occasional edge case where two mutually-nonrequisite techs are both required to be useful (the only case I can think of is DF Cartridge and any of the three personal laser weapons).


Discussion / Re: New wound and healing system on 2.5-dev
« on: July 26, 2012, 06:00:04 pm »
It is a possibility, but what do you do when a wounded gets healed up to 90%, is shot again, gets healed and shot again and so on and then dies with -1000 health at mission end? Maybe that's even realistic (to be patched up and, drugged so one is combat ready for one more minute or so before dying), but as a player I want to know after the battle that every soldier alive now is alive when the dropship returns to base and then stays alive at the hospital.
There are three obvious ways to handle that. One is, as you note, allowing soldiers to die at the end of a mission, which IMO is a bad way to handle it (for your reason, among others). Another is to raise all 0 or negative health values for surviving soldiers to 1 at the close of a mission. The third would be to redefine death—a soldier would die when taking damage that leaves that soldier at 0 health or less, and so the temporary healing could allow a soldier's real health to become negative, extending recovery time. This seems messy and error-prone, so I guess the more reasonable version would be to tack on a recovery-time penalty whenever a soldier is raised to 1 real health at the end of a mission. I'm not going to dig into the pros and cons of these approaches unless it looks like temporary healing is actually being considered, though.


Feature Requests / Re: Suggestion - Player Guided Soldier Level Ups
« on: July 25, 2012, 07:14:34 pm »
Perhaps a little of both...player chooses but can only level up skills that have been used since the last level. That would be just a quick flag on skills/attributes.

Ex if you keep using heavy weapons, your heavy weapons skill, will be available for levelling up but your pistols will not be.
Or have some relatively small fraction of XP earned be discretionary, assigning the rest via use.


Tactics / Re: What's your favorite weapon?
« on: July 13, 2012, 02:23:20 pm »
In 2.4 it seemed to me like the bolter had a strange glitched interaction with throughwall—if a shot hit a wall it would stop rather than continue through, but an additional shot would be fired on the same trajectory that would pass through that wall, repeat up to the throughwall limit. I was all excited about three-round aimed shots until I realized that only one projectile could actually hit a target.


Tactics / Re: What's your favorite weapon?
« on: July 12, 2012, 02:45:06 pm »
Sure, but civilians are so incredibly squishy that almost any weapon will kill them in one hit, so that's not really a downside for the sniper rifle so much as it is for any non-melee weapon.


Discussion / Re: Weapons and damage in 2.5 (HEAD)
« on: July 11, 2012, 05:38:59 pm »
As a status report, I'm currently working on a script to pull weapon, alien, and armor data out of the UFO files and perform various analyses automatically. It's taking substantially longer than anticipated because I decided for some reason that I needed to write a full-on parser for it; I'm going to give it a few more man-hours before throwing up my hands and hacking it together with regexes.


Pages: [1] 2 3 ... 9