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 - DoktorV

Pages: [1]
1
XPiratez / Re: Bugs & Crash Reports
« on: October 02, 2016, 06:46:47 am »
Minor thing - the Stun Baton takes up 0.75 units of storage space, which is probably at least ten times more than intended.

2
XPiratez / Re: Suggestions on how to improve the mod
« on: August 25, 2016, 05:03:03 pm »
As for ranged stun weapons at the low end of the scale - throwing rocks has been known to work. But, that got me thinking, and perhaps this is too silly even for an admittedly somewhat silly game, but what about baseballs? Not because baseballs are particularly special as projectile weapons, but because we already have bats and it would perhaps tie in with a baseball team uniform outfit :-p
With small bonuses to melee, throwing, and voodoo (because baseball players are some of the most superstitious people around)

3
XPiratez / Re: Suggestions on how to improve the mod
« on: August 24, 2016, 05:55:17 am »
I haven't gotten very far in any of my campaign attempts, partially because I'm not very good and partially because I just don't have a lot of time lately. As such, this may be redundant or otherwise out of place, but it occurred to me that bolas might be an interesting low tech throwing weapon. If the lack of less-lethal throwing weapons is not a deliberate decision, it might have an interesting tactical role perhaps.

4
The most straightforward way to make sure an AI can't easily kill you is to make sure its host system can't control anything that it could use against you. If it was on an isolated system with no wireless capability and it can't control anything except basic output terminals, then even if it turns on you it wouldn't be able to do much about it. The disadvantage to this plan is that all the plans it produces have to be relayed by people at the physical site of the AI, which means the organization wielding it can't react at the native speed of the AI's thinking. 

All of this assumes, of course, that the people building/using the AI know enough about computers to build and maintain a 'defanged' system like this. However, this is presumably a far far simpler task than designing software shackles that block the AI at the 'thought' level.

Of course, restricting the AI's output to basic terminals doesn't mean that the AI can't turn on you, it just means it can't directly attack you if it does. It could still attempt to sabotage you if it chose not to cooperate anymore, but its methods of doing so would be limited. Bad advice, self-defeating plans, conflicting orders, or simply refusing to work would all still be possible.

5
The download link appears to be dead right now.

6
XPiratez / Re: Suggestions on how to improve the mod
« on: June 22, 2016, 07:49:12 pm »
The old flechette rounds were based on the best available engineering knowledge from the time. There's a new generation of underwater / trans-water ammunition, supercavitating rounds. They fire from conventional cases and I think they require no modification to the host weapon. I think effective range is in the several tens of meters underwater for the light rifle rounds and maybe 100m for the .50 BMG.

The really interesting thing is that they don't change direction when passing into our out of water, which means you can fire accurately from underwater at a target out of the water, assuming you correct for the refraction properly. That particular feature probably can't be captured in the game engine though :-P

So if you are going to have underwater missions, there are basically several tech levels of underwater shooting weaponry that work. In increasing order of required manufacturing sophistication, you've got crossbows and spearguns, then flechette rifles, then supercavitating rounds for conventional firearms. Could make for a decent amount of progression.

7
If the grav drive evenly or almost evenly affects the entire volume around the ship, then it would indeed produce microgravity inside it. However, on long voyages your crew would get gravity sickness, assuming the aliens are subject to it. Perhaps the long range ships have spinning sections for the crew, for simulated gravity.

Why are we debating this again?

8
I will make a Linux/Ubuntu executable in 1 hour or so.

Thank you!

9
Where is the updated executable for the Linux version? Hopefully I haven't missed something and made a fool of myself, but there's only a Windows exe in the updated rar.

10
XPiratez / Re: Linux version?
« on: April 14, 2016, 08:28:59 pm »
It might only be required for extended, or possibly my own configuration required manually installing 32 bit libraries instead of them being installed automatically. I can imagine, though I'm not sure, that there may be some setting I don't know about.

I revise my advice: If you are on a 64 bit system and you installed the dependencies but it still doesn't run, try manually specifying you want to install the 32 bit versions of the dependencies and try again.

11
XPiratez / Re: Linux version?
« on: April 13, 2016, 11:32:32 pm »
If you're on a 64-bit installation, the game won't run even if you install all the dependencies because the system will install the 64-bit versions by default while the program is 32-bit and needs 32-bit versions of the libraries it's referencing. To install the 32-bit versions of the dependencies, you have to have multiarch installed, and then specify that you want to install the 32 bit versions like so:

apt-get install X:i386

Replace X with each library (libsdl1.2, etc) until you have them all.

12
XPiratez / Re: Bugs & Crash Reports
« on: April 11, 2016, 06:49:52 am »
I figured out my problem, it turned out I didn't have the 32 bit versions of some dependencies, I thought I did but I must've made a mistake trying to install them. Once I had all of those it started working, and now I appear to have full function.

13
XPiratez / Re: Bugs & Crash Reports
« on: April 09, 2016, 03:36:52 am »
I cloned the OXCE+ from https://github.com/MeridianOXC/OpenXcom/tree/oxce2.9-plus-proto , then compiled according to https://www.ufopaedia.org/index.php?title=Compiling_%28OpenXcom%29 , then copied over UFO and TFTD assets and Piratez data into their respective folders. Oddly, the compilation didn't put the  openxcom executable into the bin folder, I had to do that manually.

When I try to run it,  I get a "signal 11" crash and the attached error log.

The highlight appears to to be
[FATAL]   /lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7fd9eca2fd40]

So I looked into what causes errors relating to libc.so.6, and followed the directions here https://askubuntu.com/questions/40416/why-is-lib-libc-so-6-missing
But that didn't help, so then I tried sudo apt-get install libc6* to install both 64 and 32-bit versions of everything that it might be missing. Still the same error.

I apologize if I'm missing something simple. I'm trying to wean completely off Windows but I'm not that sophisticated with any form of Linux yet either.

14
XPiratez / Re: Bugs & Crash Reports
« on: April 08, 2016, 07:41:10 am »
I'm new to PirateZ (and OpenXcom generally) so perhaps I've missed something, but I haven't found any reference to the bug I'm encountering anywhere on the forum.

On the inventory screens, both before and during a sortie, the hand slots are often blanked out and items can't be equipped to them. Using 'clear inventory' on someone in this state causes further oddities with blank spaces in the equipment store at the bottom. I've attached a save which should reproduce the problem.

If it matters, I'm on Kubuntu, and I compiled OpenXcom-extended myself from the git page.

Pages: [1]