Tuesday, August 25, 2015

24 Tips for playing Fallout Shelter

All work and no play makes Jack a dull boy, so I need the occasional fun and games when I'm not working. Since they've just recently released the Android version of Fallout Shelter, I've taken to giving it a go.

As a typical gamer, I'd venture into the web to find strategies, tips and tricks for getting the most out of my gaming experience. I did come across several notable ones that provided a handful of good suggestions. But I realised that I can just as well document my findings regardless.

This is my list of observations:
Layout
  1. Assign all weapons to dwellers, keeping one powerful rifle in storage when possible; in case of random infestations in rooms with unarmed dwellers.
  2. Training rooms are sufficient in singles; it is possible thus to fit them in pairs on the right side of the map.
  3. Med Bays and Science Labs correlates to storage of Stimpaks and Radaways respectively; if you find yourself running out of space for storing these resources, build extra rooms for them without assigning dwellers to the rooms. These can be stacked with the training rooms.
  4. Rooms furthest away from Power Stations lose electricity first; build with the intention of sandwiching Power Stations between other resource rooms.
  5. Rooms touching dirt are where Mole rats strike first, according to this and also a tip from the loading screen; to prevent this, it is possible to build a second column of elevators since there isn't much space for anything else. Dwellers will use whichever elevator that is nearest.
Training
  1. Zoom in on a training room to see the countdown timer for dwellers to get an increment on the attribute they are training for.
  2. Training time is exponential across stat increments; unless you are prepared to wait extended hours to max the stat, it is ineffective to train a low-stat dweller.
  3. If training is interrupted, the timer resumes from where it left off instead of restarting.
Rushing
  1. A general guide for "safe" rushing would be for the Incident risk to be below 50%.
  2. Even if you've maxed out the storage for your resources, it is still possible to rush rooms in order to generate more caps; do this especially when the Incident risk is in the 20-30% range.
  3. Just before rushing a room, make sure the dwellers are sufficiently weaponised to prepare for infestations.
  4. If you notice the resource countdown timer reaching soon, wait for it to restart before activating a rush.
Reinforcements
  1. Assign more dwellers to help with larger fires to reduce the time taken in extinguishing the flames.
  2. Raiders attack starting from the vault door before proceeding downwards in a zigzag pattern. Assign dwellers to "receive" these unwelcome guests, starting from the first living quarters to preempt their next move.
  3. Support comes faster from dwellers working in adjacent rooms on the same floor.
  4. Even faster still, would be to reassign weapons from dwellers in other rooms to those that is encountering an incident.
Wasteland
  1. Send dwellers with high Endurance out into the wasteland; pack them off with 10 or more Stimpacks and Radaways and they will run the night while you sleep.
  2. It is possible to send a dweller who is totally unequipped into the wasteland. If they survive long enough, they will randomly encounter clothes and weapons along the way. If they are wearing the Vault Suit when they pick up their first piece of clothing, they will automatically wear the garment. If they leave the vault unarmed, they will likewise equip themselves with the first weapon they chance upon.
  3. The maximum Stimpacks and Radaways you can equip any one dweller is 25 of each. Do so only if you intend to let the dweller roam for extended hours. 
  4. They will automatically equip themselves with gear that they come across, which is better than what you'd sent them out with.
Babies
  1. Babies have their last names randomly picked from either parent; a convenient way of not pairing up families in future would be to name the boys after their mothers, and girls after their fathers.
  2. Throttle the baby-making to avoid a baby-boom; start with 2 to 3 pregnancies at any one time.
  3. Don't focus on reproducing couples with high Charisma; if you have a Nightwear, put it on a dweller working in the Radio Studio, and have every male dweller borrow it when needed. 
  4.  If you have training rooms already, it isn't as big a deal to pair couples with high attributes. All it takes is another few more hours/days of training to get the new kid up to speed with above-average stats.
Let's see if I can discover more anecdotes that I can add to the list!

Edit: I found this which led me to this amazing spreadsheet!

Sunday, June 14, 2015

HSM and the fellowship of cryptology

As luck would have it, I've been recently tasked to find a substitute for the Hardware Security Module that, for a handful of reasons, would no longer be able to serve us.

What is a HSM?
HSMs are server appliances, built on top of PKCS #11 in order to take advantage of the cryptographic functions, while maintaining a high level of security for the keys that it holds. The authentication, encryption, decryption, signing and all manner of connections to it are logged. They usually come with cryptographic security tokens that make sure you need to be physically present, to even perform any sensitive operation like reboots.

Sitting on the application server is an agent that would already have had a certificate exchange with the HSM appliance. The application need only to liaise with this agent, that will handle the communication with the HSM server.

The hunt
It would have been an easy job, had we only require asymmetric keys. Any old JKS, or PKCS #12 archive (for better compatibility outside of Java) stored within the application server would work. Except that our application require use of symmetric keys. The problem is, most keystores (a concept mostly within Java) only support private key and certificate pairs. They cannot handle storing secret keys.

Enter JCEKS. The Java Cryptographic Extension Key Store can carry private and secret keys alike. The next closest thing is from Bouncy Castle, with their BKS/UBER. A quick browse-through using KeyStore Explorer should suffice to show you their differences from JKS and PKCS #12. But I did take a little bit further to confirm that both Oracle and IBM variety of the JRE does indeed not support generating secret keys into PKCS #12 keystores, just because this claimed it possible. The runtime throws an exception because you'd have to pass in a null for the certificate, when PKCS #12 expects a certificate.

Any answers?
The valiant effort of OpenDNSSEC with providing a SoftHSM, proved too complicated beyond my comprehension. Whereas an Italian job - j4sign - requires an actual smart card as part of their recipe.

Somebody did suggest to encrypt the secret key with an asymmetric key kept in a keystore, and store it alongside in the filesystem. I see where he's coming from, but I'd feel naked and exposed not containing the key within the archive. It's plausible; just not ideal.

So what do?

I'm sticking with JCEKS for the time being. My counterparts working on C++ may need to put in some effort, while we sort this out. But to the best of my abilities, I've tried providing a wrapper JAR (that basically behaves like the HSM agent) for them to take advantage of the JCE keystore. It's still a work in progress, so if I can't convince them to make it work, we'll need to come up with an alternative, and fast.

The journey continues!

If you have any inkling of all these shenanigans, hit me up and let me know your thoughts.

Friday, April 10, 2015

jaxb.properties

A client was looking through the JRE console output with trace enabled. He saw the network communication going on while JAXB was trying to locate an implementation for the SAXParserFactory that I have included in my applet. It looked a bit like this:

network: Connecting https://my.url.com/my-project/com/project/result/jaxb.properties with proxy=DIRECT

In essence, the JRE tries searching for the file in-depth from the server repeatedly, causing what he amounted to increased latency across the board when accessing our application. I looked up the javadoc for SAXParserFactory on the sequence of events. This place spelled out the default implementation that's internal the Java. I simply placed into the annoying jaxb.properties file the following line:

javax.xml.bind.context.factory=com.sun.xml.internal.bind.v2.ContextFactory 

This jaxb.properties file was added into the several locations that I saw popping up in my Java console that has a relative path from my applet project. The runtime found what it's looking for, and no longer searches for the same file in multiple other locations. 

I'm aware that this file is leftover from the earlier versions of JAXB, but if Java is still churning out extra traffic while trying to hunt down a non-existent file, there will bound to be people that would much rather not have this extra step involved.

Edit: Apparently there's an even better way! This solution cuts through all the deprecated nonsense, by basically telling the applet to not do any lookups at all! 

The Java console log output for JRE 7 (not visible in JRE 8) indicated the search was still on, but for META-INF/services/javax.xml.parsers.SAXParserFactory this time. In order to avoid adding extraneous stuff entirely, just add this param into your HTML:
<applet>
  <param name="codebase_lookup" value="false">
</applet>

And it's even more convenient this way!