[OLD] Old OXCE+ discussion thread

[karadoc]

As for the boom fruits, their lighting adds to the atmosphere while increasing chaos. I can't see what's wrong with them. If you're unsure if you're illuminated or not, accomodate your tactics accordingly. Darkness usually favorizes you, so what's the problem?

From my point of view, the problem is that tiles which (to me) appear to be in total darkness can be treated as fully illuminated.

I don't mind much if the system is binary, or if I'm sometimes a bit unsure about which tiles are dark enough. But I think this particular case is extreme. I wasn't unsure - but I was wrong. The screenshot is basically just black. I don't see any light anywhere; but yet apparently the game treats one of the soldiers as illuminated. It's just bizarre. (Maybe it would have been more clear from playing rather than just from a screenshot. I don't know.)

I'm not going to be upset if it isn't changed, but I do think it's something that could be improved.

[legionof1]

Boom fruits providing light is fine and i do like them being apart of steel tileset. The issue is as Karadoc notes that tiles being treated as full day when the player cant make out anything is actually there under most user setups. This is the sort of problem modern games handle with a gamma slider but we dont have that luxury.

[Absalom]

Not sure where else to ask this so forgive me if off topic.

Let's say I wanted a feature wherein prisoner's are robbed/enslaved etc as soon as they are available to prevent going into the manufacturing screen after every mission.  Where would I start implementing this?

I have tried googling all available documentation but they generally point to manufacturing rulesets or product.dat, not the actual manufacturing code itself.  Is it located inside the executable?  Now, as infinite manufacturing and auto sell were added to the base game, I suspect auto-prisoner processing would be possible, I'm just not sure where to start looking.

[karadoc]

Auto processing would certainly be possible - but it's a lot more complex than auto-sell, or infinite manufacture; because unlike those other things, there are are several micromanagement decisions which need to be made by the player in order to process the prisoners. For example, how many runts to assign, which current process to remove those runts from; start immediately, or wait until current projects are complete, etc.

Because of this, I don't expect auto-processing of prisoners will become a feature any time in the near future. It would be a significant amount of work to implement, and it would be potentially difficult to integrate into the UI in a useful form. So unless there are other major automation features added to the manufacturing system, I don't think auto-processing of prisoners will happen.

[Meridian]

Let's say I wanted a feature wherein prisoner's are robbed/enslaved etc as soon as they are available to prevent going into the manufacturing screen after every mission.  Where would I start implementing this?

It would be a change in the code (executable).

You would need to create the manufacturing projects in/during the mission debriefing (class src/Battlescape/DebriefingState.cpp).
Make sure to make it optional.

PS: most manufacturing code is located in classes: src/Basescape/*Manufacture*State.cpp
PS2: if you expect somebody else to do it for you, see post above (from karadoc) first

[just_dont]

Question: do we have a hotkey to remove all equipment from a craft?
I found out that I'm spending way too much time managing craft's inventories (especially in times when you mass-upgrade your equipment).

[Meridian]

Question: do we have a hotkey to remove all equipment from a craft?

Yes, press X.
(or anything you have bound to "clear inventory")

[Meridian]

There's something else I wanted to ask, I often find myself hitting ESC when I enabled the quick search field and decide against quicksearching after all, but this does nothing. It would improve usability (at least for me) by quite a bit if ESC canceled the quicksearch immediately.

1/ ESC on normal text edit components will:
- remove all text
- move caret to beginning
- keep the focus in the component

Tip: you can use this to quickly delete a soldier's name when you want to rename him/her

2/ ESC on quick search component will:
- remove all text
- move caret to beginning
- remove focus from quick search
- perform quick search with empty string (i.e. show everything)

Note: ESC on quick search won't toggle it off... ESC does what you can do manually by holding backspace to remove all text and then pressing enter to lose focus and perform search

[Absalom]

Auto processing would certainly be possible - but it's a lot more complex than auto-sell, or infinite manufacture; because unlike those other things, there are are several micromanagement decisions which need to be made by the player in order to process the prisoners. For example, how many runts to assign, which current process to remove those runts from; start immediately, or wait until current projects are complete, etc.

Because of this, I don't expect auto-processing of prisoners will become a feature any time in the near future. It would be a significant amount of work to implement, and it would be potentially difficult to integrate into the UI in a useful form. So unless there are other major automation features added to the manufacturing system, I don't think auto-processing of prisoners will happen.

Yes I anticipate a long difficult road.  Will report any progress in a new thread.

It would be a change in the code (executable).

You would need to create the manufacturing projects in/during the mission debriefing (class src/Battlescape/DebriefingState.cpp).
Make sure to make it optional.

PS: most manufacturing code is located in classes: src/Basescape/*Manufacture*State.cpp
PS2: if you expect somebody else to do it for you, see post above (from karadoc) first

Alright thanks I will start there.  Though I think I will start from the idea of having the relevant manufacturing projects already started, just "paused" due to lack of materials, and instead making a check at every debrief if relevant materials have arrived, and if so, to transfer a previously specified number of runts to the project, and then cycling them back to any other project in the list.

I will have to wait until I see the code itself until I decide which option is more feasible.

[Meridian]

The current hit indicator (CTRL+H) is useless half of the time, some improvement would indeed be good.
Main issue: reaction fire overwrites your fire.
I think there are some edge cases as well.

After Yankes introduced reaction scripting (not sure when exactly that happened) the hit log was logging reactions (a LOT) even if there were none.
I have fixed it today.

[Absalom]

After Yankes introduced reaction scripting (not sure when exactly that happened) the hit log was logging reactions (a LOT) even if there were none.
I have fixed it today.

Ja it was a bit of a cheat.  Your gals would suddenly stop and you'd check the log and sure enough, reaction fire check for someone you didn't see.

[Meridian]

Ja it was a bit of a cheat.  Your gals would suddenly stop and you'd check the log and sure enough, reaction fire check for someone you didn't see.

That's a different issue (with reactions) Fixed already some time ago...

Today I fixed an issue with hit log itself. When you did a melee attack, the hit log showed almost always "reaction fire..." even if there was none, instead of the damage you dealt.

[Yankes]

That's a different issue (with reactions) Fixed already some time ago...

Today I fixed an issue with hit log itself. When you did a melee attack, the hit log showed almost always "reaction fire..." even if there was none, instead of the damage you dealt.

This is because now melee can cause reactions, all machinery run until in last moment when script say "stop!" and unit obey default behavior.

[Meridian]

This is because now melee can cause reactions, all machinery run until in last moment when script say "stop!" and unit obey default behavior.

Yup, I just didn't notice it... and git merged it incorrectly without merge errors. Happens sometimes.

[Meridian]

New version is up.

2017-01-06
 - 10 new damage/resistance types: https://openxcom.org/forum/index.php/topic,4830.msg77276.html#msg77276
 - facilities required for research added to tech tree viewer
 - fixed hit log bug (falsely showing reaction fire after melee attack)
 - info message now says which craft are allowed (for a given mission), see screenshot
 - ability to override default action on facility R-click
 - various item sounds support random selection from a list
   (fireSound, hitSound, hitMissSound, meleeSound, meleeMissSound, psiSound, psiMissSound, meleeHitSound, explosionHitSound)
 - ESC cancels quick search (or quickly removes text in other TextEdit components): https://openxcom.org/forum/index.php/topic,4187.msg77145.html#msg77145
 - ESC to close alien inventory
 - M-click in alien inventory (on paperdoll/armor)
 - ability to enable/disable mind shield in base view (R-click)

Code: [Select]

STR_STARTING_CONDITION_CRAFT: "The ship is no good for a mission like that, Cap'n!{NEWLINE}{NEWLINE}Allowed ships: {0}"


Code: [Select]

facilities:
  - type: STR_TOILET
    rightClickActionType: 1
# 0=default, 1 = prison, 2 = manufacture, 3 = research, 4 = training, 5 = psi training, 6 = soldiers, 7 = sell, 8+ = go to geoscape


Code: [Select]

items:
  - type: STR_JUKEBOX
    fireSound: [100,101,102,103,104,105,106]
    ...
    ...
#supported: fireSound, hitSound, hitMissSound, meleeSound, meleeMissSound, psiSound, psiMissSound, meleeHitSound, explosionHitSound

Download: https://drive.google.com/open?id=0B8itkFQbhj-YRko4SmV5VHNSOFk