Messages

16

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.

17

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.

18

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 08, 2023, 12:02:17 am »

If that patch (or something equivalent) is implemented, I'll be pretty content. For me that's the big improvement that the system needs; and this current argument about what should happen when there isn't enough equipment is, although contentious, less important.

I disagree about it being inconsistent with the original requirements about soldiers bringing their equipment with them. (I started typing some explanation for why not, but decided it was just going to be a long boring rant that is tangential to what people actually care about. So I'll skip that.)

If the existing equip-from-craft patch is implemented, then more people will use that and get a feel for what is good about it and what is not. At that point, I think the conversation about follow-up details will be more meaningful. At the moment I'm literally the only person in the world who has used the version of the system that I'm asking to change!

So yeah, I'm pleased that Dioxine approves of the equip-from-craft changes. Hopefully Solarius and Meridian will also approve of that. Then that's good enough for me - even though it isn't yet my ideal end-point.

19

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 07, 2023, 01:47:10 pm »

In the current system as it is, I can accidentally mess up my craft equipment simply by adding a soldier and then immediately removing it. I think this is an unnecessary pitfall. Adding a soldier and then removing it should result in the same equipment setup as if you'd clicked nothing at all; and that's one of the things my suggested change aims for.

In terms of the GUI, I imagined is that would look identical to how it does currently. It's slightly tricky, because there are effectively *three* important numbers: held items, extra items, and actual total items; and we're effectively trying to represent those three with just two numbers; but I think the cases where total ≠ held + extra aren't important enough to put in a third number. The left arrows and right arrows would do just what they do now: i.e. attempt to take an item off the craft, or attempt to add an item to the craft. This is effectively done by increasing the 'extra' items. In cases where we attempt to add an item when there is not enough available, the extras does not increase; but in cases where we attempt to take away an item that is reserved by a soldier, the extras *does* (silently) decrease. When the craft has no soldiers, whatever items are in the craft should match the 'extras' list exactly. (I hope this would be clear and intuitive enough without the need for any extra buttons or numbers on the screen.)

I'll say a bit more about why I'd want this. I agree with you that when a soldier is removed from the craft, items have to either go to the craft or the soldier. You've said that they should go with the soldier. That's interesting to me, and obviously I disagree (otherwise I wouldn't be suggesting all this). From my point of view, whenever a craft leaves the base to go a mission, we're splitting our soldiers and equipment into two disjoint sets: those who are staying in the base, and those who are going to the mission. And I think the ones going on the missions need to be given priority. I want those ones to have exactly the right soldiers and exactly the right equipment. The ones staying behind can have whatever is left over.

I'd say that it is totally normal to not have enough equipment for every soldier to have their desired gear at all times. For example I might have 5 soldiers who are longbow specialists, but I only have 2 longbows. If I don't put more than two of those soldiers on a mission at the same time, they get their loadout. But if all three are on at once, then someone misses out and has to equip something else.  That kind of thing happens a lot. I assume it happens to everyone for different types of equipment at different times. It's most obvious when there is a base defence mission. When every soldier is on the mission all at the same time, the player often finds that there are some gaps in what they'd like to equip.

In any case, like I said, I think it's normal for there to not be enough equipment to fully outfit every soldier in the base all at once. And I think the soldiers on the craft on their way to a mission should be the ones gives priority. If I'm putting gear explicitly on the craft, then it's because I think I might want it on a mission. I want that equipment to stay on the craft rather than stay with some soldier who is just resting in the base. The soldier can have the equipment when the craft gets back.

Note: in this suggested system, although the soldier may not bring the reserved extra items with them off the craft, the items are still on the soldier's loadout. They certainly aren't forgetting that they want that those items, and they will still equip them automatically at the start of any mission when the items are available.

20

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 07, 2023, 10:36:13 am »

I've been playing with the craft screen inventory changes that I made, and I'm pretty happy with how it works. For me, this is the change that pushes the new equipment system from being an ok alternative, to being a superior system. For how I use the equipment screens, this is a necessary upgrade.  However, there is still one minor annoyance that I'd like to fix up. Unfortunately, it might take a bit of rewriting to resolve. It's about what happens when there is not enough equipment for the 'extra' craft gear (i.e. items that are on the craft, but not assigned to any soldier on the craft).

When there is plenty of equipment, moving a soldier onto the craft will move their equipment with them, and moving them off the craft moves their equipment off too - leaving exactly the same 'extra' equipment on the craft as when you first started. That's good. But if there is not enough items in the base for both the soldier's equipment and the extra equipment, it's different. The soldier claims ownership of the equipment so that they can complete their loadout; and so when they leave the craft they take the equipment with them.

For example, suppose you have 2 laser rifles available in your base and you want to bring them on every mission, so you assign them as 'extra' equipment on the craft. If you then equip the laser rifles in your soldiers' loadouts, those laser rifles will be taken off the craft when the soldiers are swapped out. This probably isn't what you want.

---
What I'd like is for the craft to remember the extra equipment assigned, so that when soldiers leave the craft, that amount of extra equipment remains unchanged - even if it was used in some soldiers loadout. As for how to implement it... my immediate idea involves heaps of changes - which I'd probably just go ahead and do if it was my project; but I suspect you'd be relucted to accept the changes. You might prefer it to be done in a different way.

Here's an outline of what I have in mind: the craft's `_tempSoldierItems` list that is currently used for soldier equipment should be replaced with `_extraCraftItems` to store the extras list instead of the in-use list. I figure that the total soldiers' equipment can be calculated at any time, and so we don't really need to store it. Whereas the extra items is not always inferrable; it must be recorded if we want to remember it. `calculateTotalSoldierEquipment` would remain, because it is useful - but instead of storing the results in a member variable, it would simply return the entire vector. The calling function can store that vector for however long it needs it. (Returning a vector in C++ was once a bad thing to do, for efficiency reasons. But that's no longer an issue, thanks to the magic of `std::move`.)

Anyway, that would be a significant amount of stuffing around with the API of the new code, but the logic is pretty much unchanged. Currently (without these API changes) we have total equipment on the craft, and a calculated list of what the soldiers are using; and we use `extras = total - used` to work out the leftovers. The problem is that the leftovers may only be a subset of what we want to reserve to stay on the craft. By storing the actual list of items that we want to keep on the craft we avoid that problem. Incidentally, I think it's a bit weird that `_items` and `_tempSoldierItems` are dynamically allocated rather than just being on the stack. I guess maybe there is some legacy reason for `_items`, and the new one is done that way for consistency? I guess it isn't important enough to change that now.


In any case, that's my current thinking of how it should work. I'm just not sure whether or not everyone is on the same page about the desired behaviour, or the implementation.

21

OXCE Suggestions DONE / Re: [DONE][SUGGESTION] Alternate loadout system

« on: January 05, 2023, 12:54:28 pm »

I tried this, but it breaks the reporting of missing items.
Any good/easy idea how to fix that?

EDIT: ok, I think I have a solution

Hmm. You're right. It was still reporting missing items when there isn't enough for the template on its own; so I hadn't noticed that it doesn't report the extra missing items.

I think I know what to do to fix it - but it sounds like you already did it.

22

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 05, 2023, 06:42:36 am »

Ok. I've made the changes I was talking about. I've only barely tested that it is working correctly, but I'm expecting this to be a major improvement to the new system.
Here is the patch: https://github.com/karadoc/OpenXcom/commit/b64c4fd23ef1eb59a57acfd3aa4441a06c79effd

The behaviour is what I described earlier (also described in the commit message on github).
The gist of it is that if go into the inventory screen from a particular craft, you'll see *all* of your base items. And if you change any soldier's equipment from that screen, those changes will be reflected in the items that are loaded onto the craft.

The way this is implemented is by temporarily moving all base equipment on the craft, and then moving it off again after the changes have been made.

There are a couple of things that still need to be improved:

• The code currently assumes no items limit on the craft. If there is an item limit, then it may not be able to fit all of the base's items - and so... that will be kind of annoying. I thought about temporarily repressing the item limit; but I'm not sure how best to re-impose the limit afterwards. So I'm just leaving it on the 'todo' list for now.
• Changing soldiers' equipment from the craft inventory screen changes the items on that craft. Which is good... but unfortunately there is now an inconsistency. Because if the soldiers' items are changed from the base inventory screen instead, then it *doesn't* change the items on the craft that those soldiers are assigned to. Ultimately I think it should... but I haven't looked at that part of the code, so I haven't implemented it. (and also, I don't care that much - other than it being potentially confusing for other people.)

One last thing:  while making these changes, I noticed and fixed a minor bug in the existing code:  When loading an equipment list for a craft, if a warning box was triggered due to missing items then the item list would not be correctly updated to show which items are equipped by the crew. (The bug was that the warning box caused the list update to be suppressed.)

23

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 04, 2023, 07:41:18 am »

I don't think it's this easy, it will likely require more, maybe even a lot more.

You're right. I just started browsing the code to see what would be required. It's a mess. To achieve what I was asking for would either require a lot of untangling to separate the inventory stuff from the normal battle creation stuff; or alternatively, an increasingly high tower of kludges - where we do some weird crap to get the desired result. Earlier I was suggesting moving the crew out of the craft; but now I'm thinking maybe temporarily moving all of the base equipment into the craft might work better. I'm not quite ready to launch into it, but if I was in a big hurry to get this done today, I'd try this:

 * Get the list of all items currently on the craft.
 * Subtract items that are equipped by the soldiers on board the craft.
 * Temporarily save that list for later.
 * Move all items from the base into the craft.
 * Create and run the inventory fake-battlescape thing in the usual way.
 * Merge the temporarily saved item list with whatever items the soldiers have equipped at the end of the inventory screen.
 * Remove everything from the craft except the things on that newly merged item list.

That's it.

That's my current plan, but I don't intend to try it right now. I'll read a bit more of the code and think about it a bit more first. Maybe there is a better way.

24

OXCE Suggestions DONE / Re: [SUGGESTION] Alternate loadout system #2

« on: January 03, 2023, 09:57:50 am »

I'm not suggesting that you remove the equip from base functionality. I think that's good. My suggestion refers only to when you enter the inventory screen from the craft equipment screen.

To clarify, suppose you are on the main base screen. If you click soldiers, then select 'inventory' from the drop-down menu, then you get the full base equipment screen - exactly as it is now in the current version. But if you if you click the craft screen->select a craft->equipment->inventory, then it should bring up an inventory screen only for the soldiers currently on that particular craft. Which is also what it currently does, but I'm suggesting that it should show the equipment from the base's storage on the ground rather than the spare equipment from the craft on the ground - probably implemented by silently automatically taking the soldiers off the craft before the inventory screen, then putting them back on again when it is closed.

25

OXCE Suggestions DONE / [DONE][Suggestion] Alternate loadout system #2

« on: January 03, 2023, 01:53:11 am »

The new system is working pretty well. It requires some changes of playing habits, but it is an improvement overall.

I think the only significant inconvenience is this business of disembarking all the crew so that you can equip them in the base, then putting them back on the craft again. It's a lot of easy messing around, and remembering / finding the crew you want. For me personally, I think the ideal case would be if the 'inventory' button from the craft equipment screen did a bit of magic to make it easier... I'd like it to show only the soldiers on the craft, but with all base equipment - including equipment that might be held by other crew who aren't on the craft.  And when this inventory screen is closed, changes to soldier equipment are reflected in the craft equipment.  I think most of this would be achieved by what you (Meridian) talked about in another thread. i.e. if you automatically take the crew off the ship for the inventory screen, then put them back on the ship when the screen is closed. I think that would achieve almost exactly what I'm asking for - except that I always want the inventory screen to not show any soldiers who aren't on the ship.

By the way, on a semi-related note, on my own personal OXCE version I've implemented a way to load craft equipment without removing current equipment. Here. I'm not sure if this is interesting to anyone else. The main use-case is when you have a template saved for general additional craft gear that you want to add after you've already put your soldier on-board. (I went for the easiest implementation I could think of. Holding ctrl when clicking the template makes it add rather than replace the equipment; but maybe a 'nicer' implementation would have a toggle button on the load window.)

Maybe later I'll try implementing the stuff about soldiers in craft that I described above. But that's a lot harder, and my vision might not agree with everyone else's needs anyway, so I'm a bit worried that would be wasted effort.

26

XPiratez / Re: Discord BS

« on: February 09, 2022, 09:49:15 am »

I also got that exact rejection email, saying that the account would not be reinstated.

It's pretty insulting really. Discord claims that I posted content that was "dehumanizing or discriminatory content or incited violence"; and then has the gall to follow up with a claim that they have 'reviewed and confirmed' the violation. It's absolute rubbish. I am certain that I have not posted any content of that sort - ever, for any reason, in any context. So obviously they are lying about having confirmed it. For me, that's worse than the ban itself.

27

Programming / Fixed bug in TileEngine::voxelCheck related to stairs / slopes.

« on: February 17, 2018, 12:22:42 pm »

Melee attacks against units standing on slopes would often fail to do any damage. This was a long standing and well known bug. Today I tracked it down. It turns out to be a mistake in TileEngine::voxelCheck.


The gist of the problem is that the voxel check wasn't finding the unit to deal the damage because it wasn't including the terrain height of the unit. It wasn't including the terrain height of the unit because it was instead including the terrain height of the tile above the unit... which was unhelpful.

The fix is easy, and I've posted it here (along with a description of the problem).

I suspect a side effect of this will be that units on slopes will be hit more often in general; because voxelCheck is used for many things, and this problem would affect all of them. Nevertheless it is a bug fix.

28

XPiratez / Re: Disruptive transmission mission

« on: July 29, 2017, 03:09:38 am »

I don't think you'll be able to beat it until you have space suits. The enemies there are too dangerous to defeat with the escape pods. You'll want to use proper laser weapons, or perhaps melee.

29

OpenXcom Extended / Re: [OXCE] OpenXcom Extended

« on: July 12, 2017, 01:51:01 am »

Here is my patch for improving the order of items on the ground.

https://github.com/karadoc/OpenXcom/commit/c446001e3f13f1be0352fd9bf3e6b307a71ee0d4

Note that most of the changes in the patch are just cosmetic things, changing the interator loops to be range-based for loops. I just made those changes for my own benefit, to make the code easier to read so that I could see what I was doing.

There's only really three lines that make any difference: the sorting of the list, the starting x position when placing an item, and the 'break' rather than 'continue' for quick search (which is just for efficiency).

---
By the way, I like the fix for the psi bug. It looks like you've fixed the caused of the crash, fixed the faulty AI, and improved the robustness of the functions involved.

30

OXCE Suggestions DONE / [DONE] [Suggestion] Pilot auto assigning ideas

« on: July 11, 2017, 12:10:33 pm »

I still think it's pretty awkward to get thrown out of an intercept action due to lack of pilots. It's not as bad now that there is a button to take you to the ship screen to assign a pilot, that was a big improvement, but it's still a bit cumbersome to have to go through a few menus for something that usually doesn't matter.

I don't think the 'auto assign' option in the options menu is as useful or as intuitive as it could be. Currently the auto assign option forces all ships to use whoever is last on the list as their pilots. This is ok for most situations, but sometimes it just isn't what I want to do - and I certainly don't want to have to go in and out of the options screen whenever I want to change tactics. In general, I care about who pilots my interceptors, but I don't care who pilots the troop transport ships. The tricky part is that some troop transport ships are also interceptors. I think it would be better if auto assign only tried to assign pilots when there aren't enough already.

Here are a few other approaches which I think would work well. (Any one of them would be good. Not all three!)

• Whenever the player puts any unit in a craft, the game checks if the craft has enough pilots; if it doesn't yet have enough pilots, the unit being added to the craft becomes a pilot. I think this would be good default behaviour, and it would remove the need to even have an option to 'auto assign' pilots.
• Alternatively, when an intercept is told to launch, if there the ship doesn't have enough pilots, it could then (and only then) automatically assign whoever was available as a pilot. This would be the functionality of the 'auto assign' option. If 'auto assign' was turned off, or if the craft still doesn't have enough pilots even after auto-assigning, the game would do exactly what it does currently. ie. tell the player that there isn't enough pilots and offer to go to the ship screen.
• There could be an additional button on the 'not enough pilots' screen which effectively says "auto-assign and go!" The button would try to automatically assign pilots, and continue the intercept command without the player having to reissue it.

As I said, I reckon the current system is still a bit awkward. I also think it's potentially confusing for newer players who are less comfortable with the UI. I think it would be much better if one of the suggestions I've offered was implemented. I like the first option best.