Messages

1

OXCE Suggestions DONE / Re: [Suggestion] Bases Preview

« on: February 25, 2020, 01:58:08 am »

You could use this as a mock battle to test out your equipment, at your own risk of course. It would kind of work like as using the base as a firing range. Be careless with shooting and explosives at your own peril.

Otherwise work as a normal battle, ammunition is lost and wounded soldiers have to heal and dead soldiers lost. No experience is gained, as no enemies were hit or killed.

Aborting the mission would produce the normal post-battle-briefing titled e.g. "Live-fire exercise over".

2

OXCE Suggestions DONE / Re: [improvement] Inventory priorities

« on: February 24, 2020, 10:22:12 pm »

If the motion scanner happens to appear in the right hand most often in the saved loadouts then the right hand should be the first slot tried when ctrl left clicking the scanner.

Good idea, tally up slots the item is placed in from existing loadouts. Prioritize slot selection based on that frequency. Giving highest priority to loadouts of units with same armor as the one currently being equipped.

This may even be partially adapted for auto-equip. At least it gives your preferences for where what kind of items should be equipped. Haven't looked into how auto-equip logic works, or even used it more than once, so I may be completely in the wrong.

3

OXCE Suggestions DONE / Re: [improvement] Inventory priorities

« on: February 24, 2020, 08:35:35 pm »

I don't think a fixed priority order approach will work well.  I for one in x-piratez, tend to pick my primary weapon as one of the last items equipped.

Only solution I can think of is that the first equipped weapon is primary, as there always won't be a secondary. Do note that right hand is only ever prioritized for quick-equip of a weapon. Other items are not placed there.

Instead of trying a one size fits all approach, what about a more adaptive method that looks at how the player has previously equipped soldiers and the saved templates (s)he created.

Building an intelligent quick-equip / autoequip would be a larger huge task.
- It would try to learn based on your corrections, saved templates, previous loadouts, available equipment, armor and soldier attributes. That is a lot of variables.
- It would require some kind of AI/neural network.
- AIs always need very large data-sets and learn very slowly. Especially when there are lots of variables. Your play-style will probably evolve faster than any possible AI can learn, resulting in a feature even more useless than the current auto-equip.

I had an idea based on this, though.
- From previous loadouts, use the best matching for auto-equip. This "best match" cost function being somehow weighted with all relevant variables and limitations.
Problems with even this:
- Would be pretty hit-and-miss, even if your playstyle has clearly defined soldier roles.
- Preserving all previous at-combat-start-loadouts would be quite a bit of a size increase to the savefile.
- Defining a useful cost function would be very hard.

Auto-equip is hard. I think the only solution would be to hard code better logic than the current one. But as that wouldn't be vanilla and very subjective, it might not be something that Meridian would be prepared to merge.

As I said, everyone has different expectations, and I don't see why I would add a feature to cover specifically your expectation, no offense intended.

None taken. Vanilla quick-equip works according to your expectations?

I'm using this in my own custom build, but won't start releasing builds. I'm sharing changes here for the potential benefit to others.

4

OXCE Suggestions DONE / Re: [improvement] Inventory priorities

« on: February 24, 2020, 06:06:03 pm »

Not always, there are passive items, which you just need to have in the inventory to work.

Default such items to backpack / slowest to access slot. But maybe such a corner case it won't be a problem? Also see next assumption.

Yes, but you use more than just one item... which one gets priority for the "best" slot?

Assume player start equipping with items intended for best slots.

As many opinions on this as there are people on Earth.
I just saw Quickmind complaining about it (twice) on yesterday's stream.

Any improvement suggestions that could be added as well?

Nope, it's vanilla.

How about binding to ALT-click, leaving the vanilla CTRL-click as is?

5

OXCE Suggestions DONE / Re: [improvement] Inventory priorities

« on: February 23, 2020, 12:00:22 pm »

Others have expressed some interest and I have a working proof-of-concept, so let's see if this is salvageable?

I've outlined some problems with current placement priorities in the first post. What I'm looking for is a smoother playing experience for most play-styles (including yours). Yes, "optimal placement" is impossible, so let's just call it better placement.

For trying to come up with a cohesive requirement for can I assume:
- Items are equipped to be used?
- Lower TU cost to using an item is better?
- Current heuristic for when to place the item in a hand slot is good?

Quick-equip is not a vanilla feature, right? So changes shouldn't be a problem from a purist point of view?

6

OXCE Suggestions DONE / Re: [improvement] Inventory priorities

« on: February 22, 2020, 11:25:37 pm »

Things I still may want to do before submitting for merging:
- Test using also other mods than Final mod pack.
- Handle optimal item placement better when there are modded custom slots.
- Optimize ammo placement reload, other items for grabbing to other hand

I guess the absence of a "No" post from Meridian is a good sign

7

OXCE Suggestions DONE / [DONE][Suggestion] Inventory auto-placement priorities/rules

« on: February 10, 2020, 12:37:43 am »

Problems with current mechanics of quick equip (CTRL-clicking items in inventory):
- when belt is full, items are placed in backpack
- pistols are placed in backpack even if they would fit to the belt
- high explosives rapidly block pistol slots from belt
- items are not prioritized to the slot where in-combat use (moving it to hand) is fastest.

Thus here is a change for:

    priority order:
    * place item into hand slot using previous rules
    * shoulder slots (3 TimeUnits)
    * leg slots if 2 wide item (e.g. high explive) (4TU)
    * belt (4TU)
    * leg slots (4TU)
    * backpack (8TU)
    * where-ever it fits (custom mods may have other slots, so just iterate all of them)

Some mods may cause this to be suboptimal, though.

Edit 2020-02-12: attached patches updated.
Edit 2020-02-22: small tweaks, patches updated
Edit 2020-02-24: clarified that this patch doesn't change how quick-equip works if current code placed item into a hand slot

8

XPiratez / Re: How strong of a system do you need to run pirates?

« on: July 13, 2018, 11:20:37 am »

My only gripe (as a coder) is how "bandit cave" and base defence missions are much slower than usual maps only due to the spawn point/most of the combat being up on the 3rd/4th level. I guess the engine draws the lower layers regardless of 99% of them being completely covered by completely opaque tiles on the layers above.

But I guess there is no information about a tile, or even its floor, being completely opaque, and thus the graphics drawing engine can't skip drawing tiles that are fully hidden by a upper level.

9

XPiratez / Re: How strong of a system do you need to run pirates?

« on: July 13, 2018, 02:33:48 am »

Running mostly ok using almost all 2GB of ram on my low-power Atom laptop with a 1024x600 screen. Must close my browser and any other memory intensive applications before starting xcom.

Linux gentoo 4.11.3 #10 SMP PREEMPT Mon Jun 5 00:24:27 EEST 2017 x86_64 Intel(R) Atom(TM) CPU N450 @ 1.66GHz GenuineIntel GNU/Linux

During base defence and some large maps I need to change video to show only 1/2 or 1/3 in order for moving soldiers not to be too slow.

Compiling oxce+ took about 2hours, and starting the game takes a few minutes 2min 15 sec of loading on the black "MS/DOS" screen before presented with the first main menu.

10

XPiratez / Re: HOW-TO: Install OpenXcom X-Piratez on Arch Linux

« on: July 13, 2018, 01:02:17 am »

How to adapt this for Gentoo (sorry not sorry, not arch linux but close enough  ):
* adapt openxcom ebuild from official portage tree to pull correct version of MeridianOXC/OpenXcom from github (my modified ebuild attached, for reference or lazy trusting people just remove the .txt extension).
* Tried emerging, but compilation failed for me on yaml-cpp linking. Fixed this by removing line 91 of
 cmake/modules/FindYaml_cpp.cmake (i.e. the line: SET(YAMLCPP_INCLUDE_DIR "${YAMLCPP_INCLUDE_DIR};${YAMLCPP_INCLUDE_DIR}/.."))). To fix this on the run, we use the ebuild command (as emerge does to install a package):
** run first "sudo ebuild meridianoxc-3.5.0_p9999.ebuild fetch unpack".
** then remove the line (on my system unpack placed the source files into /var/tmp/portage/games-engines/meridianoxc-3.5.0_p9999/work/meridianoxc-3.5.0_p9999)
** Finnish installing with "sudo ebuild meridianoxc-3.5.0_p9999.ebuild compile install qmerge"
* Unzip piratez mod distribution (e.g. in your home dir) and run from inside the created Dioxine_XPiratez-folder using: "openxcom -data ." (this way all the nay/yarr options seem to be preset and locked to correct values, and no copying files anywhere is needed, again satisfying my laziness)

Yes, you can do it Gentoo

ps. for extra fun, place your starting base at an out-of-the way location.
pps. and if you're more knowledgeable about gentoo, feel free to create an overlay with the ebuild with the proper patch. This be my 3cents.