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.

Topics - Stoddard

Pages: [1] 2
OpenXcom Extended / The ziploader
« on: February 22, 2019, 08:55:29 pm »
The ziploader loads game resources and mods from zip archives in addition to plain old directories.

Game resources are the common directory and the UFO and TFTD directories. These can be put into, and respectively, in a datadir. The archives must contain the top level or respective directory - that is is wrong, the code expects,, etc.


A subdirectory is considered a mod if it has a metadata.yml file at its top level.

A zip archive can either contain a single mod, when the metadata.yml file is at the top level, or multiple mods in top level subdirectories. Ones without metadata.yml are ignored.

An example is the It has multiple mods - all the bundled ones in fact.

Mods are identified by their id from metadata.yml. Zip archive and subdirectory names are irrelevant.

It there is a metadata.yml file but it lacks the id attribute, the mod id is taken to be the subdirectory's name. (This should be deprecated and removed).

The ziploader supports overriding mod resources and rulesets from the zip archive with ones from a plain directory.

Both the zip and the directory must have the same mod id in their metadata.yml and at most a single zip and a single directory are supported for a given mod id.

First, all rulesets from the zip archive are parsed, then from the directory. Resource files are loaded from the directory and if that does not exist then from the zip.

Mod loading order.
The VFS and ruleset/language/other parsing/lookup rules.
User and Data directory locations and search order.

Offtopic / Galaxy Squad
« on: December 31, 2018, 04:05:36 am »
Here's something I found recently:

No idea if it would ever be any good or even finished, but still a curious attempt.

Offtopic / Irrelevant cat videos
« on: November 09, 2018, 10:14:28 pm »
Now that the questions of meritocracy, net neutrality and the future of humakind have been settled, I propose to at last use the internets for its innate, stated, implied and otherwise relevant to its design goal purpose.

Please post photos/videos of black cats.


OpenXcom Extended / [Suggestion] Single-handed unload
« on: July 22, 2018, 04:21:28 pm »
- Added option for one-handed-unloading of weapons (by karadoc)

Was this discussed somewhere? It's just I think it should be per-weapon, not a global option.

OpenXcom Extended / [Offtopic] Throwing someone into a pond
« on: June 18, 2018, 06:34:34 pm »
I wonder what the correct outcome should be if I stun someone, pick the body up and throw it into a pond.

I guess they should drown and show up as killed/no corpse, plus all the items in their inventory lost?

Should a kill be ascribed to one who did the throwing?

And what about guys in space suits, or I dunno, Gillmen?

Much food for thought..

OpenXcom Extended / [Info] Linux build farm
« on: June 08, 2018, 10:49:05 pm »
My buildfarm currently builds Debian jessie64, Ubuntu trusty32, trusty64 and xenial64 (that's 2014 and 2016 LTS releases).

It's time to blow up this farm and build a new one.

Any opinions on which distros/releases it should build for?

Xenial, which is 16.04 x64 stays, as does jessie64. Ubuntu bionic (18.04) x64 will join them in any case, and trusty gets dropped unless someone relies on it.

Anything else?

Two EPs that kind of reminded me of the old times playing UFO:EU on an Amiga
for some unknown reason

Work In Progress / Embedded PyPy driving OpenXcom's GUI.
« on: June 15, 2017, 01:35:19 pm »

Embedded PyPy driving the GUI.

Now that was hairy, and still has some kinks to straighten out.

Driving most anything else in the game is much simpler.

XPiratez / Vodka
« on: May 25, 2017, 10:54:50 pm »
In light of, I think the fact that alcohol does not restore at least a bit of morale should be considered a bug.

OpenXcom Extended / [Feedback] Let's design craft equipment templates
« on: April 30, 2017, 09:54:48 pm »
This wish was I believe expressed lots of times. I think the problem is that no one actually designed the feature to the point it was clear how to implement it. Let's fix that.

The problem to be solved: that the player has to manually swap almost entire inventory of a craft and two to three sets of inventories of the crew if the next mission differs much from the previous.

Possible solution:

  • Drop craft inventory entirely. No equipment is associated with a craft. (Craft weapons stay as they are, obviously)
  • Drop permanent armor assignment. Armor becomes part of an equipment template. Base assaults - use the existing and proposed UI to assign armors and equipment.
  • Craft transfer doesn't pull crew or equipment (possibly apart from craft weapons) with it.
  • Possibly allow designating stuff for transfer by the sets - one of the kinds of the sets would be the eq+armor set
  • Permanent, named crew inventory templates, with the armor included.
  • Clear, simple UI to design, save, apply a crew member template.
  • Possibly include capability to design equipment templates in the absense of actual items.
  • I don't know how autoequip works currently. Since I think it was designed just as a kludge to alleviate the inventory problem, drop it entirely.
  • Keep backwards compatability - save actually used equipment sets automatically and reapply them to the same crew members. This will emulate how it currently works enough for the early game.

This is a significant departure from the original game, but I think it's worth it. Please comment.

XPiratez / Flak tank firing sound
« on: April 30, 2017, 05:36:37 am »
Built a flak tank at last and was disappointed by the firing sound. It lacks authority.

Replaced with the attached one (cut from some random video from Youtube)

Then actually looked at the tank sprite and noticed it's not 4-barrel (as implied in ufopaedia), but a rotary instead. Well..

Btw, the hell the forum takes exception to the file name suffixes??

XPiratez / Meridian 3.5 vs 3.3 lostness
« on: January 06, 2017, 06:29:29 am »

Before the holidays, I decided to not move much thinking it's better to focus on a single codebase, expecting 3.5 to emerge as such shortly.

But it's 5th or 6th Jan already, depending on hemisphere, and as far as I get 3.3 is still the definitive version to play X-Piratez, and so, by extension, to test the new stuff on too.

I'm kind of lost here. I don't want to work on 3.3 because that'd mean painful forward-ports, and I can't work on 3.5 since I playtest on X-Piratez, and that isn't vetted to work on 3.5. So I'm stuck.

I do not intend any pressure anybody, I'm just curious on what the current situation and plans are. Or maybe I misunderstood something.
Please enlighten me.

Programming / Time to go SDL2?
« on: December 11, 2016, 04:23:35 pm »
SDL2 is pretty much stable at this point. SDL1.2 is on the other hand pretty much obsolete. Staying on it hampers stuff like more mouse bindings, and I think the android port will have a bit more opportunity to gain traction if SDL1.2 stuff goes out of the way.

Problem is, this has to go bottom-up from upstream. I volunteer to present an as clean as humanly possible OXC SDL2 port, so that the changes can then be most painleslly merged downstream.

What do you think?

Fan-Stuff / wooden xcom that wasn't
« on: October 18, 2016, 09:06:35 pm »
 that wasn't envisioned as anything to do with X-Com

but someone mentioned the likeness

4mm plywood, 5x50mm planks, dw349, glue, a ton of paint, much angst and grinding (courtesy dw443/bsl220)

Pages: [1] 2