Messages

1

XPiratez / Re: [MAIN] XPiratez - 0.99 - 7 Jun - First Impressions

« on: June 11, 2016, 12:49:37 pm »

A possible implementation of the ruleset idea without actually doing any implementation would be to provide a custom shortcut to the executable with lots of "-<option name> <option value>" pairs. This appears to update the current cfg with the values specified.

I'd think a config based solution might provide a lower barrier of entry to customizing each setting though. An alternative might be that a mod could supply their own (partial or full) default_options.cfg which would be used during the construction of the user options.cfg or for adding missing values to the same file upon version change. This way users wouldn't have to dig into the ruleset to change certain values, and if the game wasn't supplied with a user config a new (and correctly configured) one would be automatically created to suit the active mod.

2

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: June 10, 2016, 10:06:12 pm »

Found and corrected the inconsistent inventory spacing bug as reported by Arthanor and Meridian. It was caused by a read outside of the assigned cache, hence the random nature of the error. This could also cause a CTD on opening of the inventory, so if anyone was experiencing that, it should be fixed too.

https://github.com/stiansel/OpenXcom/commit/6c6b4f17acb121ca4869121858ff538c49851d50

3

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: June 06, 2016, 09:38:18 pm »

Does the issue also occur if you change the search term function to use arrangeGround(false)? (I don't have access to a compiler right now and probably can't take a much closer look for a couple of days.)

Edit: The extra spaces may be caused by incorrect values in the start index cache. Try disabling the startCache stuff by simply setting x=0. With the other changes done the performance loss is fairly small. If this turns out to be the culprit I'll fix it when I get back to a more useful computer.

4

XPiratez / Re: Getting higher-level ships

« on: May 31, 2016, 09:05:17 pm »

Would a Tetris-like approach be possible? That game uses a bag like randomization approach where pieces are randomized by picking from any of the pieces which haven't yet occured. Then once all pieces have been used a new bag is filled with all pieces and the process repeats. If transfered to xcom this allows for an even distribution of factions while retaining the possiblity of getting the same twice in a row (last of one bag, first of the next bag).

5

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 31, 2016, 08:52:14 pm »

I updated the FOV repository with a new bug fix. While investigating why Yankes hadn't noticed a difference with 3D distance set for the position based FOV updates I found a few cases where I had been inconsistent in my use of 2D and 3D distance. After this fix visibility near max range should be consistent with the base game behaviour again.

6

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 31, 2016, 02:28:28 pm »

I updated the repository for the item stacker. I changed it a bit to better facilitate filtering by category. Namely I've changed it to stack each item in advance in its stackable subtypes, rather than bunch all items of the same type, then later figure out the stackable subtypes. This makes filtering out a specific subtype easier later on. (actual filtering not included as it's probably better to add that to a different branch?)

Also noticed a getItem function which (worst case) scanned the entire item inventory for each tested location of the stacker. With the other changes I've done to the stacker it tries to find room for stacks rather than individual items. So with the stacker no longer needing to know which item is present, just that something is there, I changed it to a small occupancy lookup table instead. The new version is about 10 times faster on the previous test save you gave me (and scales better).

7

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 31, 2016, 11:31:06 am »

Yeah, those changes look good to me. Though there's one thing that needs to be checked first. The FOV calculation needs the supplied radius to be large enough to fully cover the event, so it may need a +1 to the radius.

Edit: I wouldn't add the 3D distance fix as it will produce different results depending on whether a position based update or a unit based update takes place. That addition fix in the same commit is very much recommended though.

8

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 22, 2016, 02:12:28 pm »

Yeah, space is really at a premium on that screen. I thought of placing it to the side, but some items have really long names and may overlap. I considered it as a seperate button, but a pop-up would require more clicks and may not allow the user to manipulate the inventory while searching. That search component idea with a wrapping box and an x to clear sounds pretty good though, so I may have to rethink the whole placement.

The current implementation shares the location with the item/button tooltip. If the user hovers over the tooltip it changes to a "click to search" string. If clicked it disables the item/button tooltips while input is active. The filter updates live as in the animation, but if the user presses enter the filter is saved and tooltip functionality is returned. I'm thinking of adding a filter active prompt to the tooltip whenever the tooltip is empty to reduce confusion ("didn't I have more items than this!?").

Technical implementationwise it's not a component (yet atleast), I'm simply using the TextEdit box with it slightly changed to allow exiting with zero-length strings. Should be room for something similar in the upper left of the workshop screen, right?

9

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 22, 2016, 01:25:03 pm »

Here's an animation of my latest inventory experiment (may have to click the image to animate). A search field for those really big inventory lists.

It currently allows searching by the (localized) name of items. There's still some work to do, like allowing damage types to be searched for, and hiding artifacts, as well as some useability improvements. Shouldn't take all too long though.

10

XPiratez / Re: Suggestions on how to improve the mod

« on: May 20, 2016, 05:45:54 pm »

ˇ

I'd love to see õäöü.
If we'd get there I'd do Estonian translation.

Better get started then.

11

OpenXcom Extended / Re: Meridian's resources and mods for X-PirateZ

« on: May 19, 2016, 08:41:34 pm »

Code: [Select]

  - type: STR_MUTANT_POGROM_DISTRESS_NO_PENALTY
    points: 0
    objective: 3
    spawnZone: 0
It appears to be caused by the spawnZone and objective combination. (the region with that spawnZone has only mission zones for objective 0). Changing spawnZone to 3 appears to remove the crash, but as I don't know the intent nor have that big a familiarity with the modding system, that might change other things as well. Just saw the difference with the other pogrom mission.

12

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 05, 2016, 04:27:31 pm »

Thanks for the notification Meridian. Uploaded the fix.

13

OpenXcom Extended / Re: Meridian's resources and mods for X-PirateZ

« on: May 05, 2016, 04:26:53 pm »

Ok, fix uploaded on the inventory stacker github. Sorry about that!

On a slightly unrelated note: piratez takes a looooong time to boot in debug mode.

14

OpenXcom Extended / Re: Meridian's resources and mods for X-PirateZ

« on: May 05, 2016, 04:03:29 pm »

I'll take a look at that crash shortly. Thanks for the report.

15

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 03, 2016, 03:01:19 pm »

I uploaded the source on Github and as a pull request to oxce2.9-plus-proto. I retained the item order. Without the debug info it ended up with stacking Meridian's test save inventory in 5.2ms. Hopefully that should give enough room, even when we account for larger item collections.

This is why I'd also love to have that "Sort Items" in inventory ability.  A dropdown from the top, where you could choose "Grenades"  "Pistols" "Rifles" "Infiltration" etc.

Already on my todo list.

I changed it so that it should be easier to filter items of interest. If you remove any items you do not wish to display from the "itemListOrder" vector on about line 1066 it shouldn't show up on the display. Hope that helps.