aliens

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

Pages: [1] 2 3 ... 16
1
When selecting a soldier from the transformation screen, a large part of the soldier selection panel is unresponsive.

In the attached screenshot, clicking at that current position (or anywhere left there) has no effect - even though the highlighted name suggestions that it should work.

(I only noticed this because I was trying to select a soldier with a very short name. Clicking the name did nothing - because the entire name was in the dead-zone.)

2
When multiple dogfights are in progress, sometimes one dogfight ending removes the minimised windows of the others, so that you can no longer continue those dogfights.

In particular, if I have a minimised interception window; and a different craft is caught by an enemy hunter-killer; disengaging from the hunter killer removes the minimised interception window. I have to manually tell my interceptor to stop, so that the enemy can get away a little bit, then attack again to bring up the interception window.

I'm attaching an XPZ save which shows this happening. My jetbike is just about to catch up with an enemy, but the snake is just about to be intercepted by a hunter killer. If I minimise the jetbike interception window, then disengage with the snake shortly after, that leaves me unable to continue intercepting with the jetbike even though it is still following the enemy ship.


3
OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2
« on: April 12, 2023, 02:28:16 am »
I've read the code, and I can't see any problems with it. I agree that the `ignoreInBaseDefense` thing is  good idea; and the restructuring looks good. I left a couple of very minor comments on github.

I haven't test it yet though. I'll let you know if I notice any weirdness.

4
Fair enough. There was a bit of code shuffling to get it right, and it isn't all pretty either. So its understandable that you aren't comfortable with it.

I'm really enjoying the benefits though, so its unfortunate that the code is a bit messy. You probably saw my description on github as to why the messiness is required; so if there are any compromises that you'd be willing to make, I'll leave that to you. For example, it could be changed so that items arrive immediately but the popup screen announcing the arrival was delayed. Compared to the version in the pull request, that would obviously be worse in terms of game experience - but it would allow for neater and less invasive code. (And it would solve the issue of being unable to sell unwanted items.)

In any case, I guess I'll just keep the patch as a feature I maintain on my own version until some other solution is decided on. Now that I have it, I don't want to go back to the way it was!

5
OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2
« on: April 11, 2023, 03:13:12 pm »

The moving of all base items into the craft only works when the "Everything" filter is selected (and no quick filter is used).
(otherwise not displayed items are not moved)

Is that intended?

If not, should I hide the "Inventory" button when the combobox filter or the quick filter are used?
It's a bit quirky, but it is intended.

The main use-case is when preparing for special equipment restricted missions. For example, the player might want to filter for 'underwater' so that they don't have to remember / double-check which equipment will be available underwater while they are looking at the inventory screen. The filter is not applied items that are currently equipped though, so could potentially be confusing. (I still think it's best to not filter out the currently equipped items, because otherwise the player might mess up all their equipment by accidentally opening the inventory with a search / filter active.)

6
I've made the changes so that the items arrive instantly. I'll guess I'll post it as a pull-request in a few days after I've done a bit more testing to make sure there's no glitches. (My first attempt looked like it was working, but actually had the items not arrive at all! So I also made a couple of tweaks reduce the risk of coding errors like that in the future.)

While I'm looking at it though, is there any special reason why soldiers, scientists, and engineers are all given a 24 hour arrival time from events (whereas everything else was 1 hour)? I don't really care much about the 24 hour arrival time for people. It's not relevant to the thing I'm trying to fix; but it just seems a bit odd to me, so I wondered if there was a reason for it.

--
(@TBeholder - the difference is that if the items don't arrive straight away, then you can't get rid of them when you run out of space.)

7
Ok. Lets put aside the idea of delaying the storage check - because that kind of just shifts the problem somewhere else (which may look better to me, but look like a bug to someone else).

But I still think it is ... awkward and 'ungood' that the new items arrive one-hour later - mostly because of the storage issue. If I get an event like "someone just dumped 100 units of rubbish in your base", I shouldn't have to clear out 100 units of my high quality valuable gear to make room for that rubbish to arrive. The idea of a option to sell the stuff from the event screen itself would work; but the items aren't currently listed on the event screen anyway. I still think the best solution is if the items arrive immediately after the event screen; and *then* do the storage check. That way players could sell any combination of new and old stuff they like to make it work.

I've been bothered by this event storage thing for awhile now - and I have glanced at the relevant bits of the code in the past and concluded this isn't going to easy to fix...    so I'm not surprised that there was some kind of problem in a previous implementation. I still think it's worth another look though. Or am I basically the only one who cares about this? If there was a patch that changed it to arrive instantly, is that something we'd want in the main OXCE?  (I don't intend to work on it right now - but if it's something people actually want, then I might do it sometime in the future.)

8
OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2
« on: January 21, 2023, 01:20:45 am »
Thanks for checking it out, Scamps.

And R1dO,
All of that UI work looks quite good to me. I like that the < and > buttons effectively have normal vanilla functionally, but with a clear and intuitive 'interpretation' in terms of soldier equipment & craft equipment. That similar to what I had in mind earlier, but perhaps better. I also like that the inventory button had a visual indicator for when it going to screw up my soldiers' inventories. The "!!!" doesn't look super attractive - but at least it is a clear warning, and I don't have a better idea. On the combo box, I don't know how 'claimed by soldiers' is different from 'equipped' (but I don't tend to use the 'equipped' thing, so maybe I'm wrong about what it does).

In any case, I'd pleased to see all of those challenges implemented alongside the alternative inventory system. I like it. But for the original equipment system (i.e. normal / 'option 1' / 'ignore soldier equipment'), I don't think there is a concept of soldiers claiming equipment - so I'd only want the additional visual information and warnings about claimed equipment to be activated when using the alternative system.

9
OXCE Support / Re: HK soft lock
« on: January 20, 2023, 03:56:13 pm »
My mistake. I misremembered the withdrawal thing as a time counter when it is actually a shot counter. And I certainly wasn't trying to correct you about anything. I was just trying to contribute a snippet of info that I thought was interesting and relevant. Apparently I'd got the info wrong, and misinterpreted the mood of the thread too. Sorry.

10
OXCE Support / Re: HK soft lock
« on: January 20, 2023, 02:37:07 pm »
Although UFOs have unlimited ammo... I believe there is already code which tells hunter-killer AI to withdraw from combat after a certain time - which makes it look like they've run out of ammo. In fact, the entire reason that timed-withdraw exists in the code is to avoid this kind of softlock!  So... if you are being attacked by a hunter-killer with no weapons, you can just wait it out. (And it sounds like a mod-rules bug to have a hunter killer with no weapons.)

11
When a random event creates items, those items are currently set to transfer to the base arriving at the next hour.

I think this is a bit confusing, and sometimes annoying and frustrating. It's confusing because many things could happen in between the event and when the item arrive on the next hour - which might make it harder for the player to connect the two ideas. Immediately after the event, the player might wonder where the items are. And when they arrive, the player might be confused about what the items are for or where they came from. It can also be annoying / frustrating if the items take up a lot of storage space - triggering the base-overfull forced sell screen. This is bad because the forced-sell screen is set to appear immediately after the event. The space requirements of the new items are counted, but those items haven't arrived yet - and so they cannot be sold / transferred on the force-sell screen.


In my opinion it would be much better if the new items arrived immediately after the event, rather than at the usual 1-hour for items transferred. A secondary less-good option would be to just remove the immediate storage space check on the event screen - leaving only the normal 1-hour storage after the items actually arrive.

12
OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2
« on: January 16, 2023, 07:02:40 am »
What I want to say is, original requirement and your requirement are not compatible.
What you are proposing is not an improvement of an existing system, it is a different system.
To be honest, when I first read this post I was a bit unsure what you thought the original requirements were. Since the original request was marked as 'complete', I thought the feature was already working as intended, and that we were just trying to refine it a bit.

But after talking to UchuuKaizoku, I realise that that you weren't just going for a system loosely inspired by apoc. It was literally meant to have soldier equipment strictly reserved so that items were effectively stored on the soldier rather than in the base or the craft. I didn't realise that was the aim, because I don't think the current implementation achieves it - and I prefer the current implementation compared to that strict goal anyway!

So Meridian, you were right. I probably was proposing a different system. A system that is very similar to what is currently implemented, but not the same as the 'apoc' idea that was originally intended. I think this whole discussion is a bit foggy, with different people having different understandings of how things currently work, and different ideas of how things should ideally work.

I've taken a bit of time to write some notes about what I think the three different systems are. Option 1 being standard xcom, option 2 being something close to what we have currently, and option 3 being the strictly reserved soldier equipment system. I'll paste those details in a moment. But let me just say I thought option 2 was more-or-less what everyone was aiming for here and I was enjoying using that system. I'm reasonably happy with what we have currently implemented. But I have no interest in using option 3 whatsoever, and I think it could be a bit of a nightmare to implement and maintain. So although the original idea might have been something closer to option 3, I'd urge people to think carefully about what they actually want. It would be a shame to spend a lot of effort 'fixing' discrepancies in the current system only to end up with something less useful.


Here's are the details that I've written down for the three options:
(`*` means implemented already. `#` means currently unimplemented. `?` means the current implementation is ok, but I have a suggested change.)


Option 1: standard
aka: ignore soldier equipment
-------------------------------------------------------------
* (Standard original OXCE behaviour)
* Soldiers' remember what items they last used, but do not bring any items with them or reserve items for any reason.
? Inventory changes from the base screen, the craft screen, or pre-battle are saved - updating the soldier's remembered items list. (Although, perhaps it would be better to not save pre-battle changes - just for consistency with the other options.)

* Items can be sold, transferred, or used in any way - as normal - with no special restrictions.

* Moving soldiers does not trigger any movement of items.
* Craft item template save/load affects all items on the craft, including any items equipped by the soldiers.
* Craft inventory screen shows only the items that are currently in the craft.




Option 2: the currently implemented 'alternative system'. (This is my preference.)
aka: request soldier equipment

-------------------------------------------------------------
* Soldiers' remember what items they last used. This is their 'preferred equipment' list.
* Inventory changes from the base screen or the craft screen are saved as the soldiers' current 'preferred' equipment. Changes made in pre-battle, or during battle, are not saved.

* Items can be sold, transferred, or used in any way - as normal - with no special restrictions.

* Moving soldiers on / off a craft will also move their preferred equipment list with them (if the items are available in the base).
* Equipment of the soldiers on the craft cannot be separately moved off the craft. (They must be either unequipped first, or the soldier must be moved off the craft.)
* Items in the base's storage can be added to the craft, regardless of whether they are equipped by other soldiers in the base.
# Craft item templates save/load affects only the unequipped items on the craft. (i.e. templates refer to the craft's extra items, not including the preferred inventory of soldiers currently on the craft.) (Edit: I've got other thoughts about this now, so it might be worth ignoring this one, or discussing further).
* Craft inventory screen shows all items available in the base - including items by soldiers not on the craft. (Items can therefore be 'shared' by multiple soldiers. i.e.  Two or more soldiers can have the same unique item in their preferred equipment list.)
* Changes made to soldiers' equipment from the base screen or the craft inventory screen will result in equivalent changes to craft items.
? When a soldier is moved onto a craft, if there were not enough items in the base to add the full equipment list to the craft, the missing items should not be removed from the craft when the soldier is removed. i.e. Adding a soldier to the craft then immediately removing the soldier should not have any net effect on the craft's equipment list.




Option 3: strict apoc
aka: reserve soldier equipment

-------------------------------------------------------------
* Soldiers' remember what items they last used; and they are treated as literally 'holding' these items at all times. The items are strictly reserved, preventing for all other uses.
* Inventory changes from the base screen or the craft screen are saved as the soldiers' current 'reserved' equipment. Changes made in pre-battle, or during battle, are not saved.

# Equipment held by soldiers cannot be sold, transferred, researched, or used in manufacturing. Items held by soldiers should not appear in the base storage screen, with the exception of the 'force sell' screen when storage is overfull.
# Transferring a soldier to another base also transfers their held items.
# When a soldier is injured, they drop all items. (This is a technical issue only. The inventory screen is unavailable for injured soldiers.)

* Moving soldiers on / off a craft will also move their equipment with them.
* Equipment of the soldiers on the craft cannot be separately moved off the craft. (They must be either unequipped first, or the soldier must be moved off the craft.)
# Equipment of the soldiers not of the craft cannot be added to the craft. (The items are reserved by the soldiers still in the base, and therefore should be unavailable for the craft. We cannot share or steal the equipment of other soldiers.)
# Craft item templates save/load affects only the unequipped items on the craft. (i.e. templates refer to the craft's extra items, not including the preferred inventory of soldiers currently on the craft.)
# Craft inventory screen shows all items available in the base - excluding any items held by soldiers not on the craft. (Items can not be shared by multiple soldiers. If a soldier has a unique item in their equipment list, then no other soldier can equip that item.)
* Changes made to soldiers' equipment from the base screen or the craft inventory screen will result in equivalent changes to craft items.


----

Implementation notes:

* The current version of the game stores an inventory list for every soldier, but these items are not actually stored by the soldier. The soldier's items are always stored by the craft or base. Therefore, the 'strict apoc' setting must explicitly check the items list of each soldiers to manually reserve those items from other usages. This makes implementing the strict setting (option 3) a bit tricky, and potentially creates a code maintance issue - since every type of item usage / transfer must always check these item lists.

* Regarding the last dot-point in option 2, about moving soldier on and off craft. This is what we were discussing earlier in this thread. For me, it is important that moving a soldier onto a craft and then off the craft again should not result in any net change. And to ensure this, we might need to store the craft's "extra" items as a separate list, so that they can be remembered even when some of those items are currently being used for a soldier's inventory. We could simply ignore this, and the result would be a bit of minor inconvenience in the craft inventory changing sometimes due to not enough spare items; but I think it would be nice to fix it. The issue doesn't happen in option 1, because soldier's don't bring their equipment; and it doesn't happen in option 3 because the items on the craft would not be allowed to include missing items from the soldier's inventory in the first place.



And finally, let me just clarify that I'm not really requesting that we have a three-option system implemented in the game. We could do that and it might be good, but I don't really mind what happens. I'm just trying to clear up some confusion about what I was aiming for and what other people might be aiming for. If the goal is just to have the standard system and 'reserved soldier equipment' as an alternative system, then that's fine - but I'll just stay out of it. I'm only really interested in using option 1 or 2.

13
OXCE Suggestions DONE / Re: [DONE][SUGGESTION] Alternate loadout system
« on: January 09, 2023, 01:45:57 pm »
Sorry, I missed that. I had never (manually) loaded equipment on interceptors before so I hadn't even realized it's possible. I suppose some mod might use it for something, AFAIK it would not have a purpose in vanilla.
You can transfer items from one base to another by loading the items on the interceptor, and then flying the interceptor to the other base. It's cheaper and faster than the normal transfer method. (But it's only possible for items that can be loaded onto the craft.)

14
OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2
« on: January 09, 2023, 12:36:14 am »
is this effectively the same as this: https://openxcom.org/forum/index.php/topic,10984.0.html

if yes, I have already implemented that, please have a look: https://github.com/MeridianOXC/OpenXcom/commit/cd932f6885fb86ae9ef4763ca75f15399472713d

Yes. That's what I was thinking about; and at a glance, the implementation looks good. (I don't like the variable name `_backup` though. I'd go with `_soldierCraftMap` or something like that.)

So I guess everyone will be very happy. :)

15
OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2
« on: January 08, 2023, 12:41:20 pm »
In terms of the craft inventory screen, the only additional change I'd want to make is that the pre-existing (extra) craft equipment should stay on the craft when soldiers are added or removed - but I don't think we've reached an agreement on that yet. So I guess I'll leave that part alone for now. For what we've agreed on, I think the feature is probably ready to go as is. I've been playing with it over the last few days and I haven't noticed any bugs. And I think it is high value enough that I'd like to get it out to other people sooner rather than later.

There are two other things I think are worth mentioning though:
  • There is an additional 'feature' that turns out to be a side effect of my implementation...  it's actually something that I'd thought about adding deliberately - so it's pretty funny to me that I'd done it accidentally. Here's how it works:  as you know, when you go into the inventory screen from a craft, my code temporarily moves all base equipment into the craft so that you can equip your soldiers from anything that's in the base. That's normal. But the accidental 'feature' is that if you have a filter applied on the craft equipment screen (such as 'underwater items') and then you click the inventory button, then it only moves items matching the filter. Items that were already on the craft will still be there; but only items matching the filter will be available from the rest of the base's items. In my view, this is something I like - because I think its sometimes helpful to show only the items that match certain conditions; and showing the items that are already on the craft is good too, so that it doesn't mess up the soldiers' saved equipment by removing what they are holding. It's an accidental feature, but I like it. It happens for the same reason why saving an equipment template while a filter is on only saves the items matching the filter. We could easily fix it by clearing the filter automatically - but I'd prefer to leave it as is!
  • The other thing is only indirectly related to my changes. It's about the base inventory screen rather than the craft inventory screen. In my changes to the craft inventory screen, equipping items will add those items to the craft. So I think it would be good if the base inventory screen did the same thing. i.e. if you add items to the equipment of a soldier from the base inventory screen, then those items should be added to whichever craft the soldier is currently on (if they are on any craft at all). I have a vague sense that Meridian was going to implement this himself; but maybe I imagined that. In any case, I think it would be an improvement consistent with the changes that I already made.


So I'd suggest just merging the craft inventory patch as is; and then follow up with the base inventory change afterward if we're in agreement about that. As for my suggested craft-extras changes... we can just shelve that idea for now. Maybe when people have played a bit with the new patch they'll see why I wanted it - or maybe not. It's a minor tweak in terms of functionality, but it could be quite a bit of work to implement. So I don't really want to do that if it just going to get rejected.

Pages: [1] 2 3 ... 16