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.

Topics - Rubber Cannonball

Pages: [1]
XPiratez / Thoughts on hideout planning
« on: March 13, 2020, 05:10:18 am »
In my first game of Piratez I started out with all my hideouts being fairly similar which worked well until mid game.  In my next game in version K2 or later I want to start out with a plan for specializing my hideouts.  Right now, I'm leaning towards having my first hideout probably in China transitioning to full research and light production.  My second hideout in South America (for early global coverage capability) will transition probably to a full training and recovery hideout plus light research and manufacturing.  My Arctic and Antarctic strike hideouts will be heavily hangered and be the main mission and intercept hideouts.  I plan on having a second training & recovery base very similar to the South America one.  The other 3 hideouts will be majorly production focused on either the printer or factory with at least one of them focused on generating cash.  These 3 will be single empty hanger hideouts for producing craft or tanks.  I probably will have 2 factory hideouts and 1 printer hideout.  The red tower will go in one training hideout and the biotech lab in the other.  Along with the old earth lab, these 3 facilities are irreplaceable and are the only true labs.  I don't want to risk having them all in one research hideout and then lose them on a failed base defense.  I'm planning on keeping 2 hangers each on the research and training hideouts if I can and may go as high as 6 on the strike hideouts.  Any significantly injured gals or those with that "not so fresh feeling" will be sent to the training & recovery hideouts for quadruple-R, Recuperation, Rest, Relaxation, and Retraining.

This plan is based mostly on my knowledge from version J8.  I'm sure it will have to be tweaked for the latest version, and I'm interested in people's opinions on it.

OXCE Support / [Answered] inconsistent behavior with throwing objects
« on: February 17, 2020, 08:35:03 am »
Attached is a save made with 6.3.4 (v2020-01-11) and x-piratez v.k2

Case 1:
If Ruthless Snow aims a gas grenade 1 tile past either the ratman in front of her or 1 tile past the ratman 3 tiles to her left, that ratman will start flashing as if it was blocking terrain.  The "Unable to throw here" message is not displayed and the throw occurs.  The ratman will continue to flash indefinitely until left-clicking on any tile.

Case 2:
If Ruthless Snow aims the grenade at the ratman 2 tiles in front of her, the fence in the ratman's tile will flash temporarily as blocking terrain and the "Unable to throw here" message is displayed.  The throw doesn't occur. Seems normal.  However, repeated attempts to make the throw will eventually result in the throw occurring.  It is hard to repeat and may take 30 tries or so before the throw occurs.  I had confirm fire on so it wasn't a misclick.  I couldn't find any spot in the tile where the throw would always occur but moving the tip of the cursor arrowhead around the ratman's right hand area seemed to make the throw occur in fewer tries.

Case 3:
Ruthless Snow moves back one tile so that she is 3 tiles away from the ratman on the other side of the fence.  She again aims the grenade at the same ratman on the other side of the fence which is now 3 tiles away.  This time the fence does not flash, nor does anything else, but the "Unable to throw here" message is displayed and no throw occurs.  Repeated attempts will eventually allow the throw to occur.

Moving Ruthless Snow farther back allows the throw to occur in fewer tries.  Moving her 8 squares away from the ratman so that she is in the same tile as the white door behind her and the throw has a roughly 50% chance to occur.

When the throw eventually occurs through the fence, the fence does not flash and no message is displayed as expected.  The F10 snapshot shows the chain link fence modeled as a rail fence with 5 rails.  Does the game calculate a random trajectory instead of an ideal trajectory for each throw attempt?  And if no obstacle is detected then allow the throw which follows that same trajectory?  If so and if the ideal trajectory hits a rail, that might explain why the chance for the throw to occur increases the farther away Ruthless Snow is from the fence since the random trajectories spread apart with distance.  But this seems like an exploit.  If the player has a 1 in 20 chance of throwing an object through a hole in a wall, he merely has to attempt the throw 20 times, on average, and when the throw occurs the object sails through the hole nearly every time?   Except for the few times throw lands short of the wall.

Open Feedback / Forum issues today?
« on: February 15, 2020, 11:47:13 pm »
Is something going on with the forum today?  Late last night I got logged out early. This morning Firefox doesn't want to connect on the first try and whines about "detecting redirect will never complete" or some such message.  And then when I did get in the page header where the login boxes are in the upper left corner was slightly different for awhile; its normal now.  Firefox connects if I try a sub board in the address bar (using Firefox autocomplete pick list or whatever it is called when typing in the address)  Then when I clicked on OpenXcom Forum I see this in the address bar:

Or does this mean I have a problem at my end?

OXCE Suggestions Expired / [Suggestion] Score penalty for sacking personnel
« on: February 09, 2020, 11:24:59 pm »
Is it possible to penalize the player's score for sacking soldiers or even sacking scientists and engineers?  Would anyone be interested in a mechanic like this?

Story Rationale: XCOM is a secret organization.  Every fired employee is a high security risk.

Game Rationale:  At some point money is no longer a limiting factor and the player can hire thousands of every soldier type and weed out the low stat ones.  A small score penalty would discourage this.  A big penalty would significantly limit sacking.  A huge penalty spread over multiple months would stop it, until the player hacks his save file of course.  At any rate the idea is to get the player to play the cards he is dealt instead of stacking the deck.  Min stat values would have more meaning than just a sack signal.

The penalty amount would be set by the modder in the ruleset and the player could be warned by a ufopedia entry.

Also for soldiers the player can still get rid of them the regular Klingon way:
By glorious death in battle!
The scientist engineer thing may not be worth the effort unless a modder had reasons for limiting player flexibility with their numbers.   And I suppose a player could still sacrifice a base to get rid of excess scientists and engineers, but would anyone really do this?

PS If something like this exists, it just means I suck at searching for things in this forum.

I've noticed some mods have special items like x-piratez's menacing hull and tiny drill that can accidently get sold by the player.  I realize selling isn't the only way a player could lose these items for instance losing a base defense.  But instead of the mod relying on readme files, FAQs, or forum strategy hints to suggest to the player not to sell these special items, why not give the modder a more elegant way to prevent the selling of them.  A story arc item could have a NoSell string attribute defined in the ruleset whose value would be a reason string such as
"That ",STR_ITEM_XYZ_NAME," looks dangerous.  We don't want that junk." that would be displayed if the item was being selected to sell.  The message display would be similar to the not enough storage message when trying to buy items.

Items without a NoSell attribute would be sold like normal.  The reason string value would allow the modder to customize the message for why the player can't sell a particular item.  Basically flavor fluff, but better than a generic canned message used for every unsellable item.

I merely suggest the idea because I think it wouldn't be too hard to implement, but of course a modder would really want to have it first.  And if something like this already exists, then google let me down or I suck at search and I apologize.

The game seems to reserve at minimum only one empty column of "ground space" for dropping items on the equipment pile.  This usually isn't a problem except when trying to drop an item like the mind probe which is a 2x2 item.  Usually, there is plenty of space on the last "page" (using the scroll right on-screen button) but on rare occasions only 1 column is left empty and the game won't allow the mind probe to be dropped into a single column.  Pressing scroll right button again will just go to the start of the equipment pile instead of a blank ground screen.

I experience this issue when equipping my squad on the craft prior to leaving the base sometimes.

There are several ways to make available ground space show up, such as pressing Q and entering a filter string which might only be available in OXCE, but it seems to be an unnecessary extra effort just to be able to drop something.

One idea for improvement would be to reserve a minimum of two columns empty space.

Or if it is simpler to code, make the empty ground "page" always show up before jumping back to the start of equipment pile list.  Although I suppose this might annoy some people.

Or a hot key to just drop whatever has been picked up by the mouse pointer.  I've noticed right clicking on empty space anywhere just puts the item back into the inventory slot it was picked from.  Left clicking on empty space (not ground space) anywhere seems to do nothing.

Or allow the item to dropped on the word "GROUND" or on top of another item that doesn't take ammo so as not to conflict with the ammo swap out capability.

I apologize if this doesn't apply to OXC (I am making an assumption from observed OXCE behavior) or if this doesn't apply with the latest versions.  If this only applies to OXCE feel free to move it to that subforum.

Suggestions / Question about the FAQ
« on: January 18, 2020, 04:43:42 am »
From the FAQ on the about page it reads as follows:

Q: Are original savegames supported?
A: OpenXcom uses its own savegame format, to make it easier to maintain and not suffer from the original limitations. A converter for the original savegame format might be added later, depending on how much is transferable.

But this thread,4286.0.html says original game geoscape saves are supported.

Is this no longer the case or should the FAQ be updated to indicate the current capabilities with respect to original game saves?

From time to time I see messages from new players in these forums wondering why they got a negative score for the month or why nothing is going on for weeks at a time in the game.  Usually this is early in the game before they have built radars everywhere.  Generally it boils down to the player not utilizing the graphs or not realizing they update at least every 30 minutes game time.

My suggestion is to highlight the country name or region name on the buttons on the left side of the ufo activity graph screens in some fashion such as underline, bold, or color change if the score for that country or region has changed in the last 30 minutes of geoscape time.   The purpose of this is to indicate to the player that the aliens are doing something over there right now, maybe the player should send a craft over to investigate.

This doesn't provide any new information that the game didn't provide before.  It just makes it easier for the player to recognize and use the information already provided.

Currently, it is entirely possible for the player to do this by hand by manually recording the the graph values for the current month and continually checking the graphs every 30 minutes to see if any changed.  But actually doing this is quite tedious and detracts from the fun of the game.

I've seen similar requests from years ago in the suggestions thread for highlights to the geoscape globe, news ticker feeds, pop ups, etc for indicating alien activity, but evidently they were rejected or at least never implemented.

I'm proposing a less drastic change that keeps truer to the original game.  If the player chooses not to use the graphs at all, he won't see any effect of this proposed change.

PS  I know that zoom keys have been added to the graph screens at least in the extended version which makes it easier to see the actual score.  But generally the player doesn't need the exact numbers; they can already see which regions have high activity from the graph.  What is hard to see and is more useful is which graphs are currently changing.

Pages: [1]