[OLD] Old OXCE discussion thread

[Meridian]

I'm not sure where to go with this suggestion, so I'm putting it here, since it has little meaning for the vanilla.

UFO:Extraterrestrials was a pretty good game. Well, in reality it was sort of bad without a big mod called UNIMOD, but it had some really need UI solutions. I would like to ask if one of them can be implemented.

In UFO:Extraterrestrials there were three "classes" of shooting weapons:

• 1-handed weapons: they work exactly like 1-handed weapons in X-Com - they can be fired with one hand with no penalties and leave the other hand open.
• 1.5-handed weapons: they work exactly like 2-handed weapons in X-Com - they can be used with one hand, leaving the other hand free, but then they receive a penalty.
• 2-handed weapons: no equivalent in X-Com, which is what would be nice to have. Such a weapon, when in hand, blocks both hands - it displays the weapon in hand slot as normal, and a semi-transparent image of the weapon in the other hand slot, to represent this is currently taken.

Why do I want it? Mostly because every time I see a LP with someone firing a Rocket Launcher or a Heavy Flamer with one hand, I feel some of my brain cells die horribly (and probably some kitten somewhere, too). So I would like an option to enforce two-handed weapons to be two-handed, for sanity reasons. Mind you, it's not like I want to do it for rifles and such, only for the really unwieldy weapons.

The way I imagine it is to add a new flag, like blockBothHands: true or whatever. If used, it displays a semi-transparent bigob in the other hand slot and prevents it from being used. If the other hand is already in use, you can't take a blockBothHands weapon and a warning flashes (like with wrong ammo type).

Alternatively, if you think blocking the other hand is too specific or restricting for the X-Com GUI, we can simply disallow firing a blockBothHands weapon when the other hand is occupied, but it could be a little confusing for the player which weapon can be fired and which cannot, without trying it.

Done.
Usage in ruleset "blockBothHands: true"

Mechanics:
As soon as you click on any action other than Throw... and you have something in the other hand too, a warning (STR_MUST_USE_BOTH_HANDS) will flash.

PS: This restriction applies only to friendly units and mind-controlled enemies/neutrals... doesn't apply to mind-controlled friends, enemies and neutrals. I decided to do this, because AI would probably not be smart enough to drop the item in the other hand.

PS2: the two-handed weapon indicator is not affected by this attribute!

[Dioxine]

PS: This restriction applies only to friendly units and mind-controlled enemies/neutrals... doesn't apply to mind-controlled friends, enemies and neutrals. I decided to do this, because AI would probably not be smart enough to drop the item in the other hand.

Very smart decision, else it'd an apocalypse if suddenly hundreds of AI deployments were broken

[Yankes]

I would prefer teaching AI to handle that situation (drop live grenade to shoot something, getting it back is for noobs ). But in long run result will be same, only different TU cost.

Btw Meridian when you publish it on github? Because I finished scripting and now I have time to do other things like pulling some of your commits to my branch or helping you with stand alone exe.

[Meridian]

Btw Meridian when you publish it on github? Because I finished scripting and now I have time to do other things like pulling some of your commits to my branch or helping you with stand alone exe.

I publish immediately (once a day). Everything is on github.

Helping with EXE would be very nice... I don't need it myself, but each time before a new version of PirateZ is released, you could build a latest one for Dioxine.

As for pulling my stuff, I would wait with that, if it's OK with you.
I have only a few more things on my todo list... and then I would make a video with the explanation/presentation of new stuff and would like to talk to you, SupSuper and Warboy about what could go into OXC, what to OXCE and what should stay in OXCE+.
If you want something even before that, I could prepare a pull request with "proper implementation", because currently many features are just prototypes: they are missing support for translation, for TFTD, they are scattered across multiple commits and in general they are sometimes just really dirty.

[Meridian]

I would prefer teaching AI to handle that situation (drop live grenade to shoot something, getting it back is for noobs ). But in long run result will be same, only different TU cost.

Thanks for the report on github.
- the blockBothHands flag is now also checked before reaction fire
- but not before berserking (you should still be able to blow yourself to pieces )
Currently testing... will upload today or tomorrow.

[Yankes]

New version 2.9 is ready:
Scripting support in unit graphic (more info in game log with debug on).
`bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version.
New property `refNode` used to shared values between items/solders/armors etc.
Option for setting numbers of melee hits done by AI.
Control space usage of soldiers with 2x2 armors in crafts.
Bug fix and small bump of nightly.

[ps]
I fixed broken download link in mod portal, now you should be able to download it.

[Yankes]

First tutorial:
How made animation and change torso to something else?

Solution:

Code: [Select]

armors:
  - type: STR_NONE_UC
    spriteSheet: TEST.PCK
    spriteScript: |
      #remember about proper indent! Because of symbol `|` all things that are currently 6 spaces indented will be treated as text
      if eq blit_part BODYPART_TORSO; #do we currently draw torso?
        set r0 anim_frame; #we set to register0 value of current frame (its start from 0 to infinity or more accurate MAX_INT)
        unit.getId r1; #get id of current unit to register1, used to difference animation offset
        add r0 r1; #we add id to animation frame
        div r0 4; #reduce animation speed by dividing
        mod r0 2; #warp it to have only {0, 1} values
        offset r0 8 272; #272 is position of new torsos, this operation change possible values {0, 1} to {272, 280}
        add r0 i1; #we add rotation of body from input1 arg
        ret r0; #we return offset that will be used for `spriteSheet`
      end;
      add i0 i1; #default behavior
      ret i0;
extraSprites:
  - type: TEST.PCK
    subX: 32
    subY: 40
    width: 512
    height: 720
    files:
      0: test3.png
Result is now animated A and B over head of solder.
Required file in attachment.

[Meridian]

@Yankes: on 2.9, I am getting a CTD when "playIntro" is set to true... can you check, if you're getting it too?

[Yankes]

Look fine for me. I try exe that I posted in my working directory and it run intro without any problems.

[ps]
can you test my version of exe: https://www.mediafire.com/?zbzytnl6s8r69tz if it work or crash?

[Meridian]

Look fine for me. I try exe that I posted in my working directory and it run intro without any problems.

[ps]
can you test my version of exe: https://www.mediafire.com/?zbzytnl6s8r69tz if it work or crash?

Your version doesn't crash. Strange.

[Yankes]

Best way is simply compile with debug info and see where crash. And its not strange, I compile using completely different compiler and libraries versions.
Sometimes small difference can easy crash something.

[debuser]

Hi Yankes

I am having some trouble getting a properly working binary with xpirates 97D under Debian Linux.

So far I have compiled the 'oxce2.5b-plus-prototypes' branch from  https://github.com/MeridianOXC/OpenXcom.git
When it runs I cannot see  the latest two handed firearm changes or filtering in the craft crew menu. Other odd thing is I am unable to save and then load. It creates a save game but will not show any save game created by this binary in game for me. I am able to see and load save games in game that was made by other binaries.

I'll attempt to attach my binary if you could see if it works for you or if you could share your known working binary that would be great thanks!

[Yankes]

Hi Yankes

I am having some trouble getting a properly working binary with xpirates 97D under Debian Linux.

So far I have compiled the 'oxce2.5b-plus-prototypes' branch from  https://github.com/MeridianOXC/OpenXcom.git
When it runs I cannot see  the latest two handed firearm changes or filtering in the craft crew menu. Other odd thing is I am unable to save and then load. It creates a save game but will not show any save game created by this binary in game for me. I am able to see and load save games in game that was made by other binaries.

I'll attempt to attach my binary if you could see if it works for you or if you could share your known working binary that would be great thanks!

First of all most of this, with you have problems is from Meridian branch. It will be hard to debug someone else code.
Do you used binary based on my branch too https://github.com/Yankes/OpenXcom.git ? (but look out, current version 2.9 is incompatible with xpirates).
Could you prove commit id your binary is build on? Maybe when I will have more free time in this week I will look on your problem.

[debuser]

Thank you for the reply Yankes. I have tried compiling your repo https://github.com/Yankes/OpenXcom.git but as you said it does not work with x-pirates.
This is really a problem with Merdian's repo, I was under the impression you are already familiar with x-pirates and hoping you already had a working binary. I'll post in the x-pirate thread https://openxcom.org/forum/index.php/topic,4187.msg58671.html#msg58671

[Yankes]

I have working (at least I think I have) version at https://www.openxcom.com/mod/openxcom-extended for ubuntu (2.5b is current xpirates).
If it not work in debian then you can grab commit id from readme and compile it yourself. It will lack features from Meridian build but should work (save & load).
If it still not work then its my fault and I probably need fix it fast