#0037: Tip for securing a cabled USB type-A plug and socket together
Preamble
This is a quick budget tip for securing a cabled USB type-A male and female plug and socket together. This technique could probably be extrapolated for use with other plug types. However I have yet to do so.
Tip for securing a USB type-A male and female plug and socket together
Now onto the tip. Simply put, I use an elastic band to hook the two plugs together. That’s it. Done. Thank you for reading…
Still here? Okay, now onto the part where we explore in excessive detail such a simple concept. One so simple you probably have immediately intuited the basic theory of operation. If not then here it is. Basically, the elastic band applies a pulling pressure that keeps the plug and socket engaged. This is especially useful when you have an otherwise loose connection, typically caused by issues such as weak retention springs within the female socket. Something that seems common to USB extension cables in my opinion. At least the ones I have encountered.
Method of application
I like to start by using a basic cow hitch to lasso one of the plugs. This is done by folding the band into a loop and simply inserting a plug into this loop. Then tightening it around the plug’s plastic shoulders. That’s a basic cow hitch.
Now, with the other side of the elastic band wind it around the plastic shoulders of the second plug a couple of times until the elastic is reasonably taught. Then insert the male into the female plug. And done. The band should now exert force that will keep pulling them together.
Elastic band application demonstration video
Best practices
For best results, I recommend using a reasonably strong elastic band. I also recommend only wrapping it around the plug’s plastic enclosure itself, and not involving their respective cables. This is so that no force is applied to the cables themselves. Force which may aid in the development of faults such as repetitive flex damage, or a kink in the cable. Additionally when the band is secured on the plug body it focuses and directionalises the force in a way that better pulls the cable ends together.
An attentive reader may notice that in one of my example images, the one with the beige elastic. The upper band loop is a little bit too high up, and sits on the plastic wire strain relief itself, rather than the plastic plug body. What can I say? Do as I say, not as I do. 😉 Its really not a huge deal either way. Securing the loop on the plug body is just what I consider best practice.
Why not use adhesive tape instead?
Alternatively to using elastic bands, you may think: why not use tape to adhere the two ends together? Briefly put, tape is messy – it leaves glue residue when removed, it’s too permanent or hard to remove, and probably most importantly: it doesn’t put pressure on the plugs to keep them together. So as time passes the plug could slowly but steadily slip out of it’s respective socket. Due to things like vibration, gravity, or general handling.
Closing thoughts and my use-case summary
In my particular use-case, I use elastic bands like these to keep the USB extension cables attached to my 4 Watt USB lights and their switches. The weak retention springs within the female USB sockets on the extension cables allow any plugs inserted into them to eventually slip out.
I used to use electrical tape to manage this but, as time went on the tape lost it’s adherence. Yet left a mess of melted glue residue. After this I switched to using duct tape, but it was too strong, and too difficult to easily remove when I wanted to. Hence the bands. Third time the charm it seems.
So far, just common garden variety elastic bands seem to work best for me in this application. Whatever you can find is fine. Funny thing is, I didn’t even buy them. I just collected the ones that my mail man keeps dropping around my door.
All in all. This is an example of a zero budget application of junk that has gained value via use. At least I found it to be so. Anyway, I hope this article is of use to you. At the very least I hope I can raise a little awareness of the genuine potential uses of random household miscellanea. And that it may assist you in exploring alternative DIY solutions to purchasing one’s way out of any given problem. I know I have been guilty of that.
As a bid to get myself into creating music – or at the very least something music adjacent: I decided to purchase a Stylophone. A simple and cheap electronic synthesiser. Something budget friendly and fun looking with which to test out the waters.
What is a Stylophone and how does it function?
If you are unfamiliar with what a Stylophone is, I will briefly explain. A Stylophone is a handheld electronic musical instrument. A synthesiser that creates audible waveforms from electricity.
The most notable feature of this instrument is it’s set of oversized PCB (Printed Circuit Board) pads, which operate as musical keys. These keys are accompanied by an electrically wired stylus, which functions as their activator. To play a note, one just has to touch the stylus to a keypad. This then closes an electrical circuit within the device, in essence mimicking a keyboard (button) press.
Broadly speaking, component-wise: at the heart of a typical Stylophone lies a voltage controlled oscillator. This component creates a waveform when fed a DC voltage. This waveform is then fed to the speaker to create an audible tone. Since this is a voltage controlled oscillator, it means that it’s output waveform is dependant on the input voltage supplied. Thus voltage is used to control the specific sounds produced.
To control the oscillator input voltage, each musical note key on a Stylophone has it’s own circuit with it’s own unique resistor values that are different from all the other note keys. These resistors are used with the intention of stepping down the 9 volts input into whatever each note-key’s desired oscillator supply voltage is.
Although there is undoubtedly more to discuss on Stylophones; such as how the pitch change, or vibrato functions operate: they are largely out-of-scope for this simple introduction. Although I will go into further detail if/when I do a full device analysis on this Stylophone. (Link below when/if that article is written.) However in general Stylophones like this one are really not too complicated devices.
Tools and equipment
Tools:
soldering iron
hot glue gun
toothbrush
tweezers
desoldering pump
Consumables:
hot glue
isopropyl alcohol
desoldering braid
(leaded) solder
solder flux
Components:
red 5mm⌀ through-hole LED
ethernet wire (multi-strand copper wire)
10kΩ potentiometer
toggle switch
Device Repair
Fortunately (or perhaps unfortunately for this article) the device needed very little fixing. It’s main faults were either cosmetic in nature or trivial to fix; and since the Stylophone was basically fully functional, other than the dirt and grime that had gotten into it over the years: there’ll consequently be little to say about it in this regard.
I will say that the sound it produced was a bit choppy (intermittent), probably due to dirty contacts on the keypad. This issue of dirty contacts applied to the two built in slide switches as well, as they where notably unresponsive. Flicking them produced unreliable results.
More specifically: flicking the power switch on didn’t always cause the device to power on. I had to toggle it a couple of times for it to operate as expected. Additionally I couldn’t even tell at the time that the “Vibrato” button wasn’t functioning. It was only until after it was cleaned and started working, that I realised what it actually did. It makes the sound of the notes “wobble”.
Since these slide switches were built into the PCB itself, rather than a discrete component than can be easily removed: I decided that the best course of action was to simply inject some isopropyl alcohol into them. Then work the switches on and off until they self cleaned. The combination of the alcohol breaking down the embedded grime chemically, and the friction from mechanical manipulation cleaned the electrical contacts.
Moving on. I cleaned the PCB keypad in a similar way. Dousing it in alcohol and scrubbing it with a toothbrush to remove any loosened debris. This simple cleaning fixed both the intermittent connection issues of the switches and keypad.
Another small but annoying issue I encountered was with the stylus’s wired cord. It was damaged. The cord had a deep nick on the inner side of a loop that it had to fold in on, in order for the stylus to fit into it’s receptacle. Because of the location of this damage, it meant that I couldn’t simply just put a layer of heat-shrink tubing over it and call it a day, as it would limit the cord’s flexibility. Which in turn would make it no longer able to fold up and fit into place.
Instead I decided to just replace the entire wire. This lead to the next issue. The stylus’s original wire is somewhat unique. It’s inner structure consists of loose bundles of stranded metal conductors (presumably aluminium) interlaced with plastic (nylon?) fibres. This made it significantly more flexible than any of my wire stock. This flexibility allowed the wire to fold in tight under the stylus when placed into it’s receptacle.
Since I didn’t have an appropriate substitute wire, I decide to just use the best that I had on hand. This consisted of a single line of pure copper multi-stranded wire that was salvaged from an ethernet cable. Since this wire was considerably less flexible than the original, it meant that I could not use the original cable hole to enter the stylophone, if I also wanted to use the stylus receptacle as well. This is because the new cable could not fold into the same tight space under the stylus the old one did. Prioritising the stylus’s use of it’s holder, I decided to just drill another hole for the wire towards the back of the stylophone’s plastic housing.
Now, with regards to the more cosmetic elements of this repair: firstly, I removed and straighten the bent metal grill top plate. I then scraped it and the plastic housing clean of all that yellow hard glue using a scalpel. Ultimately I replaced all the old yellow glue with hot glue after I cut up the grill to fit my additions.
Although as a whole, probably the most noticeable thing about this Stylophone: was the prominent yellowing of the plastic housing. This yellowing is caused by ultraviolet (UV) radiation in sun light. The more sunlight a plastic enclosure like this gets in it’s lifetime, the more yellowed (or even brown) it becomes. Ironically to restore these plastics to their original colouring, one has to use a UV light in conjunction with hydrogen peroxide.
I briefly considered whether or not I wanted to restore the plastics to their original white. And if this was a full restoration project I would have done just that. However this wasn’t the point of this project, since at the end of the day: I was planning to add some crappy home-brew mods to it.
Additionally, I actually rather like the yellowing of older machines. Computers especially. I find it nostalgic. It reminds me of a simpler time: of a young boy listening to the hum of a beige box as it powered on, and the clicking and chittering of the various drives as they promised quality escapism. Insert Sierra logo tune here.
Device Modifications
First things first: for anyone who might raise an eyebrow at my choice of components below, I wish you to know that I basically decided to modify this Stylophone with whatever junk I happen to have on hand at the time. I was unwilling (and somewhat unable) to purchase or salvage more appropriate components for the task.
Not a single part that I put into this machine works as well as they could if I did take the time to source (or install) things properly. However I think that for this particular use-case, such perfectionism is unnecessary. It was just a fun and experimental hack together; and ultimately a learning experience.
With that in mind, I made three simple mods. These were made with the aim to better facilitate my particular use case of this instrument. Something I will explain as I go on.
These mods are:
a power indicator
an internal speaker cut-off switch
and a volume dial for the internal speaker
1) Power indicator
The necessity of an indicator was made apparent to me: when I first picked up the Stylophone to find that I had left it on between sessions, and that the battery was now flat. Now that isn’t to say that the Stylophone definitively uses power when on but not actually playing. I’d need to test whether or not that is the case to say for sure. Either way really, a power status indicator is needed on this device to remind me to turn it off when putting it away. Simple as that.
To install a power indicator, I just used a basic 5mm⌀ red through-hole LED paired with a 330 ohm resistor. I tapped into the 9 volt positive side just after the power switch, and the negative side to the common device ground.
Unfortunately, this resulted in the LED being far too bright for my liking; with a light output that is more applicable for illumination, than as a device power status indicator. I really should have ran some basic ohm’s law calculations on this. Instead I simply used the same resistor value that I was accustomed to pairing with these types of LEDs on the 5 volt circuits that I am used to. Even then, they were rather bright. Now they are even brighter. I should have used a resistor with a much higher value. 1kΩ would likely do for a status indicator on a 9v circuit.
RED 5mm⌀ LED amperage and brightness comparisons
maximum continuous amperage: 30mA
recommended continuous amperage: 20mA
setup I am used to: 5v/330Ω=0.015A (or 15mA) –> reasonably bright
current setup: 9v/330Ω=0.027A (or 27mA) –> too bright
future amendment: 9v/1000Ω=0.009 (or 9mA) –> perfect for a status indicator
I should state that in my experience using ohm’s law like this is a good guide for component choice. However components are all variable. The vast majority of components all operate within certain tolerances of their stated values. Additionally they can also behave differently once within a circuit.
For example I tested a red LED with a 330Ω (actual value 329Ω) resistor in series on a breadboard and provided it with 9 volts. It’s current draw was 22mA. I don’t really know why. It should still be 27mA. I’m guessing that I am likely not adjusting for something, such as the inline resistance of the breadboard and it’s contacts. Either way, these simple calculations still allow a technician to set their general expectations with regards to component behaviour.
2) Internal speaker cut-off switch
In addition to the internal speaker the Stylophone also comes with an amplifier output socket (3.5mm audio jack socket). I intend to use this socket to sample the audio. Either directly, or via an intermediary signal amplifier of some sorts. This is an alternative to recording using a microphone as you would with an acoustic instrument for example. I think direct sampling like this would produce a cleaner signal, and ultimately better audio.
I added the speaker cut-off switch because I didn’t want the Stylophone itself emitting sound while I was sampling it using a computer. Additionally, since I am likely to be plugged in to PC audio using headphones during the process: the Stylophone playing to the room is unnecessary in this scenario. Hence it might as well be silenced in order to minimised noise pollution and/or disturbance to others.
To make this happen, I just added a switch to the line between the main PCB and the speaker. I decided to use a toggle switch because they are cool. Very simple stuff. That being said, I probably wouldn’t have bothered with a speaker cut off switch if I though of installing the volume dial first. This is because it effectively performs the same function. By lowering the speaker volume to virtually nothing, it does the same job of silencing the speaker.
This was however the first thing that I installed into the device, and I have to confess it was predominantly because I thought that toggle switches were rather neat. I like the tactile feedback of flicking a switch like this, and because of that, I then went looking for a reason to install it into something. I actually almost used two switches like this to replace the two built in slide switches; but decided against it when I saw how they where integrated into the actual PCB itself. Too much work for too little return.
As it is I did notice something interesting about this toggle switch. When flicked off, the signal outputted to the 3.5mm audio jack socket lowers in volume. I think this might have something to do with the cut-off switch taking the internal speaker out of the loop. Perhaps the lower impedance of the speaker coil draws a higher amperage. Which would provide a stronger signal which then would have access to the audio out socket: since it has been place in circuit parallel with the internal speaker.
It’s just a guess, I honestly don’t know why removing the internal speaker from the circuit would result in the signal volume on the audio output lowering. I’ll look into it further when it comes time for a full device overview of this Stylophone. Just for clarity, I should also mention that this does not happen when the internal speaker’s volume dial is set to lower the volume to zero. With it’s potentiometer adding ~10kΩ in series with the speaker in the process. It only happens when the switch cuts the speaker out of circuit entirely. Hmm. :/
pins bent to fit space
3) Volume dial
This is probably the only add-on of mine that is actually an absolute necessity in my opinion. Simply put: the Stylophone’s default volume is too loud. It’s tinny high pitched notes can easily come across as obnoxious and irritating at it’s default volume. Especially, when the player is using it to learn by playing the same little tune again and again, and fucking it up half the time.
To install a volume dial, I placed a potentiometer in series with the speaker. That’s it. In this case I used a 10kΩ pot as that’s what I had to hand. Once it came to testing however: it became apparent that I was using less than a quarter turn to effectively move the volume from 100% to 5% volume. With the other approximate two quarters moving the volume from 5% to 1%. Interestingly, the volume never does go down to zero. Even with the full 10kΩ of inline resistance: I can still hear the notes coming out of the speaker faintly. (For context: this pot only rotates to approximately 225 degrees; i.e. to a little under three quarter turns.)
I think this may be the reason why older devices’ volume dials ended with switches. For example with mono-sound CRT televisions: they’d work the volume level with a potentiometer, and then once the volume was below a certain threshold the dial switch would click on to either mute the volume entirely, or switch the device off all together. With that in mind, it makes the unnecessary speaker cut off switch sound almost useful. Eh?
If I were to redo this add-on: I would probably replace the potentiometer, with one with a smaller resistance value range. Maybe a pot that caps at 2500Ω. This is because only the first quarter of the current 10kΩ pot is in effective use, as it represents the most dramatic change in resultant volume.
The main reason why I may want to use a smaller value potentiometer is because it will increase the amount of incremental control the user has over the volume. This increase in precision is caused by adding a larger number of degrees that the dial needs to be rotated in order to increment the volume. Ideally this will result in a full turn of the pot corresponding to the volume scaling accordingly (100% to 5%). As opposed to the current setup of 0 to 90° rotation representing a 100% to 5% volume level, with the other 160° of rotation essentially going to waste.
Another way I could possibly achieve this is by using the same 10kΩ potentiometer and pairing it with a fixed value resistor in parallel in order to bring it’s effective max resistance value down to around the 2.5kΩ I desire. I am honestly not sure how that would work out, as I am only thinking of this while writing. I will experiment with putting resistors in parallel with the potentiometer when it comes time to revise this device.
volume differences on external output w/ using speaker cut-off switch
Music demo (internal speaker)
Music demo (external speaker)
Closing thoughts
Ya’know reading back on this: it really is funny how much I could say about so little. At the end of the day all I did was purchase an old Stylophone, clean it up, and then stick a bunch of bullshit in it.
Now, some people may be mad that I did this to such an old device. I noticed that it was made in the 1970’s; and honestly it’s age did give me pause. However I paid very little for this Stylophone, and bought it for the express purpose to tinker with. Additionally, it was literally the cheapest one I could find. Spares and repair condition, economy delivery, no returns accepted. You know the drill.
Also let’s be honest here: not everything old is an antique (e.g. your mum ;)). A mass produced low price point item like this Stylophone is not going to be worth much any time soon. However my innate preservationist did have to hold his breath while I butchered this wee lad. I’ll say that much.
I will be revisiting it, mostly to repair my repairs. To lower the power LED’s brightness, to decrease the volume potentiometer value, and to look into the utility of the speaker cut-off switch. I did have a few other mods in mind as well for it. Such as a 9 volt DC barrel jack socket and power source switch. That way I can run it off a wall charger in addition to battery.
That’s right you heard me. If I am going to butcher a beloved piece of British history, I am going to go all out.
Thank you for reading.
Term glossary
CRT – Cathode Ray Tube DC – Direct Current LED – Light Emitting Diode PCB – Printed Circuit Board UV – Ultra Violet
#0031: Creating a TF2 themed RimWorld scenario mod
Preamble
I recently decided that I’d like to try dipping my toes into creating mods for RimWorld. Incase you are unfamiliar with the game: RimWorld is a base builder; where the core objective is to try to create a functioning base or colony.
Building and maintaining this colony is achieved by issuing orders to various pawns. Examples of orders include: building the structures you designed, hunting animals, farming crops, fixing broken items, creating tradable goods, and cooking food to name a few. Additionally, it also includes arming up and engaging in combat.
RimWorld is a game that is in a similar vein to the venerable classic that is Dwarf Fortress. And like DF, once you have built a base that is halfway decent, you can then move on to secondary objectives such as: exploring the world, or actively trading and warring with other factions.
I decided to start modding RimWorld with something very small. Something that could be done in one or two sittings and with minimal research and planning. That way the mod doesn’t risk spiralling out of it’s initial small scope. Which can likely result in an eventual state of demotivation and ultimately project abandonment. Which is primarily caused by ongoing feature creep due to poor project management (scope discipline).
With that in mind: I decided on a simple custom scenario, coupled with a preset roster of pawns. For nostalgia’s sake: I decided to give this scenario a Team Fortress 2 theme. As a rule of thumb (and for obvious motivational purposes) I only really create things that I myself would like to play with. And to me at least: the idea of playing with the TF2 roster within the RimWorld settings sounds pretty fun. I hope you agree.
Creating a custom scenario
Scenario creator tool
Straight off the bat I should mention that the built-in scenario creator tool does not facilitate editing the individual starting pawns itself, just the world conditions and the equipment that they start with. In other words it does not allow for the modification of each individual pawn’s variables such as traits and skills. To specify pawn variables, one has to use an additional mod called “EdB Prepare Carefully”. Which I will discuss in more detail later.
With that said, let’s begin. Creating a custom scenario is a rather straight forward affair. All you need to do is navigate the menus within the RimWorld game, and follow their very simple instructions.
There are several game options available from the scenario editor. However for the most part editing a game scenario consists of choosing how many pawns the player is able to choose from, and then start with. Then choosing their starting load-out of equipment and resources: weapons, tools, food, animals, building materials, etcetera.
Additionally one could also add various world conditions such as periodic events (e.g. meteorite crash), permanent weather conditions (e.g. toxic fallout), a game time limit, as well as more wacky things such as every world pawn exploding upon death.
It seems like a rather fun thing to play with, however I only required an equipment list that vaguely resembled something that the real TF2 cast might have. I tried to give each pawn similar weapons and tools to the characters that I modelled them after. However, the group got little else in terms of general equipment and technology, outside a handful of exceptions for narrative reasons. Namely the ground scanner and a drill; since they are technically (narratively speaking) on this rim world in order to survey it for Australium.
I should also mention that I designed this equipment list with the mod “Simple Sidearms” in mind. In other worlds each character pawn was designed with the intention that they have the ability to carry more than one weapon. For example the Sniper was given either a sniper rifle or recurve bow to equip as a primary weapon, with the gladius (a functional surrogate for his kukri or bush knife) to be used as a secondary weapon (sidearm). Although the mod itself isn’t strictly necessary. If you choose not to use it, you’ll just be saddled with an abundance of surplus weaponry sitting in your stockpiles. That’s all.
Pawn equipment list
Sniper:
[x1] sniper rifle
[x1] recurve bow
[x1] plasteel gladius
Pyro:
[x1] incendiary launcher
[x1] molotov cocktail
[x9] incendiary shells
Scout:
[x1] shotgun
[x1] wooden Club
Soldier:
[x1] shotgun
[x1] plasteel breach axe
[x3] triple-shot rocket launcher
Engineer:
[x1] shotgun
[x1] autocannon turret
[x1] plasteel mini-turret
Medic:
[x1] revive serum
[x18] medicine (x18)
[x1] vitals monitor
Heavy:
[x1] minigun
Demoman:
[x1] frag grenade
[x1] plasteel longsword
[x60] beer (x60)
Spy:
[x1] revolver
[x1] knife
Miscellaneous:
[x1] ground penetrating scanner
[x1] deep drill
[x18] packaged survival meal
Alongside the equipment list, I also wrote some flavour text for the scenario. However, as far as what I wanted to achieve with this mod, this is as far as the scenario editor went. The next thing I needed to do was edit the nine random pawns the scenario provided into the TF2 mercenaries using the Prepare Carefully mod.
Creating custom pawns
In order to create my custom pawns I needed the mod “EdB Prepare carefully”. This mod allows the player to edit their pawns to a far deeper level than the standard RimWorld tool does. Which only really allows rolling a completely new character with randomised stats. Before this mod, I remember having to keep clicking the randomise button repeatedly until I eventually got something halfway decent. A process that honestly gets old rather quickly.
Using this mod I created a custom nine pawn preset. With each pawn having their own unique appearance, backstory, traits, health conditions, and skills. Once finished I saved this configuration locally, in a file named “TF2_crew.pcp”. It saved as a custom XML file that was suffixed with “.pcp”, which I assume stands for “Prepare Carefully Preset”.
And that’s it. That is all that there is to the process. Easily really. Although I must say that: it actually took me several hours to get all nine pawns’ various stats just so. This is because I can be a rather pedantic perfectionist when it comes to the little (read: insignificant) details. Things like which eye is the Demoman missing (left), and whether I should give him a peg (left) leg or not.
That’s not even to mention assigning each pawn’s skills, since they absolutely have to be (in my mind) representative of the character. This was then exacerbated by the fact that I also tried (and mostly failed) to balance the pawns in terms of usefulness and general colony value. That is, as well as retaining each character’s unique flavour; like Pyro’s oddness, or Demoman’s alcoholism. Needless to say it took some time to settle on such things.
This balance of priorities, often working against each other ended with a reasonable compromise in the final version. At least I think so. Still, I learned that Engineer and Medic are by far the most useful pawns in application, and that if you allow the other pawns to drink Demoman’s beer, causing you to completely run out by day four … well let’s just say that I nearly put a bullet in him myself, after his third low mood tantrum due to the alcohol withdrawal debuff coupled with his natural pessimism.
Scenario narrative and expected gameplay
Explaining the narrative premise
Yes, there is indeed a story here. There is reason for these guys to be on an extraterrestrial planet 3000 years in the future. The story is rather simple. 3000ish years ago, after exhausting the Earth’s supply of Australium: TF Industries decided to look for it on other planets.
So they built a fleet of Mann Co. brand low cost space rockets. A thousand of them. Each rocket containing 9 cryogenic life support pods designed to keep it’s occupant in a state of suspended animation. The occupants naturally being clones of the mercenaries. Cheap, useful, and expendable. These clones were then shot into space with the mission to survey any planets that they land on for Australium.
That is if they actually make it to one. And after three thousand years of drifting in space, and against all odds: one rocket managed to actually make it to a habitable planet. It also somehow manages to deposit it’s cargo of crypto-sick mercenaries and their gear; just in time to avoid catching them in the fires of it violently exploding in the planets atmosphere.
Now these mercenaries find themselves on a hostile planet with minimal supplies other than guns. And with no direction other than a 3000 year old order to survey the planet for a rare resource.
Just for the sake of clarity, I should mention that the resource Australium is not implemented within this mod. It is purely a narrative plot device. Funnily enough, implementing an extra resource like this is exactly the type of feature creep I mentioned earlier that end up killing my projects. Its a rabbit-hole that I don’t want to go down, nor need to go down as I simply want to bang out a small mod that consists of a custom scenario and character roster. That’s it.
I designed this setup for a combat heavy game. Since the player only starts with 18 meals (enough to feed a team of nine for about a day), no money for trade, no animals, and only a little medicine – it incentivises more aggressive actions in order to survive the early game. Especially at higher difficulties and challenging world conditions. Keyword: “incentivise”, not force.
The players are encouraged to strip the map of resources early. Steel, components, herbal medicine, berries, as well as deconstructing buildings for their materials, and attacking the ancient danger room much earlier than usual. This is because they don’t have the time to build up resources normally; by for example farming and stone cutting blocks. The nine pawns will just eat too much in the mean time.
Additionally the fact that every pawn also has the “psychopath” trait means that many of the drawbacks to bloody play-styles are removed. Such as emotional debuffs due to executing prisoners, butchering humans, or harvesting organs.
All of the above factors leaving early bloody aggression as a very viable and deeply incentivised play-style. Basically, I designed the TF mercenaries to play like the TF mercenaries. In other words: a hostile invasive violent paramilitary force, and not an agrarian farming community. Thank you very much.
Having said all of this good stuff, I should also parenthesis it with this final sentiment. Don’t feel like you have to to play these characters out in the way that I designed them. Feel absolutely free to tinker with them however which way you wish. Is Demoman’s alcoholism annoying you? Remove it. Don’t like how slow Heavy is? remove the Slowpoke trait from him. Pyro burning down your cornfield in the middle of the night for no reason? You get the message. Although I designed things in a way I personally find compelling; it’s your game at the end of the day. Play it your way™
Technical issues explained
RimWorld UI and editing XML files directly
Although creating a scenario using the in-game menus is simple enough, the cumbersome basic user interface for this can get rather frustrating rather quickly; because of this I quickly made an initial save of the scenario with all the basic fields and variables populated. This is in order for the RimWorld binary to create an XML file for the scenario. A file that I then chose to edit directly with a text editor.
I find that editing XML files in this way with a text editor to be a preferential experience, to fiddling with the game’s user interface. For example if I wanted to reorder a list of items, by taking the bottom item to the top of the list or vice versa: using a text editor it is as simple as cutting and pasting the textual data set into it’s desired place.
Whereas doing this within the game requires one to to click on either the up or down arrow button in order to make the list item move a singular place; by swapping positions with it’s respective neighbour. I should also mention that when the item swaps position with it’s neighbour, the list item itself moves on-screen and not the list items around it. This means that you can’t just keep smashing the arrow button to skip several places quickly; because the button moves from under your mouse once clicked. Imagine wanting to order a list alphabetically and then having to do something like that for every item on a 30 item list. Tedious. You’ll have to essentially manually bubble sort the entire list.
Using a text editor to bypass this went fine for the most part. I was able to reorder the populated list of equipment easily enough, as well as change item quantity and material (when applicable). I did however reach a sticking point here. After several edits I found that the RimWorld binary no longer recognised the scenario file. Something within the file was breaking the program’s ability to read data from it.
Naturally I thought that it was a syntax error. Maybe I forgot a character of syntactic punctuation somewhere, or forgot to enclose an XML data set properly with their data syntax. No. After much double checking for errors; followed by more back and forth: changing one thing at a time within the file, then rebooting the RimWorld game to test if it now recognises it. Well after that process, it turned out that adding comments to the data set broke the RimWorld binary’s ability to read the file. Just for clarity when I say comments I mean fully syntactically correct XML comments.
Example:
<!-- this is my comment -->
I can only conclude that the XML interpreter within the RimWorld binary for whatever reason does not have the functionality to understand comments and skip them. At least when specifically talking about reading data from either files that it originally generated or from scenario files in general (.RSC file format).
After a little additional testing: apparently I may put comments in and have it still load but only if it is not within the <parts>…</parts> section and in between list items <li>data</li>. In other words as long as the comments aren’t in the only useful place to have them, in order to meaningfully separate a run on list of items into recognisable categories.
I’m guessing that the RimWorld interpreter probably has a very rigidly structured read protocol; and why shouldn’t it, since it is only expecting to read files it itself created. Please note that I am not an expert on XML nor the interpreter RimWorld is using, I just can’t help speculating when I observe such behaviours.
Honestly it much doesn’t matter anyway, I only mention my experience here in the case that you choose to add comments to your code base, and then it suddenly stops working despite having no syntax errors. I hope to save you some time needlessly troubleshooting and head scratching.
Text-field character limits
The RimWorld Scenario editor has an upper limit to the number of characters each text-field box can contain. (As of version 1.3.3117). I first realised this when my initial draft of the scenario description did not fit into the intended text-field box when pasted into RimWorld. What followed was a tedious process of trimming my sentences (narrative) until it finally fit.
To save you having to do the same, I decided to get the character limits of each text box. The process that I used was by inputting the character ‘0’ into each text field until full. Then CTRL+A, CTRL+C, and CTRL+V into an empty text file. I then used Xed text editor’s built-in tool that counts words and characters to get these results.
Text-field character counts:
Title: 55 Summary: 300 Description: 1,000 Game start dialogue: 20,000+*
*doesn’t seem to have a fixed upper limit (possible dynamic text-field)
I spent quite a bit of time going back and forth between the scenario editor and the equipment section of the Prepare Carefully mod; as I wanted to make uniform both lists. Even though technically only the Prepare Carefully equipment list actually matters from a gameplay perspective since that is the one that overrules the scenario’s list and actually makes it’s way to the game. I still wanted both lists to be the same since the scenario list is the first one the player sees, and consequently informs them of what to expect.
I should mention that the reason why the two lists of equipment weren’t always identical is because as I edited the pawns, and looked through the (quite frankly better) Prepare mod’s equipment chooser: I got motivated to give and take equipment. For example I added the Auto-cannon to the list rather late, as only once seeing it’s graphic in the mod’s loadout section: did I get inspired to use it as a surrogate for the Engineer’s big turret.
In order to avoid this tedious back and forth editing, I would recommend that you plan ahead and write down the complete equipment list before initially creating a custom scenario. Alternatively, don’t worry about the scenario editors equipment list at all while making the custom pawn presets. Instead circle back to it at the end and essentially paste in the equipment list from Prepare Carefully.
Instructions for running this scenario (GNU Linux)
1) firstly make sure you have the mod “EdB Prepare Carefully” installed 2) download the file archive here: “rimworld_tf2_scenario.ZIP” 3) unzip the file archive 4) move/copy the file “TF Industries Australium survey force.rsc” to “~/.config/unity3d/Ludeon Studios/RimWorld by Ludeon Studios/Scenarios” 5) move/copy the file “TF2_crew.pcp” to “~/.config/unity3d/Ludeon Studios/RimWorld by Ludeon Studios/PrepareCarefully” 6) boot the game, it should show up as a custom scenario 7) choose it, then click on the “prepare carefully” menu button 8) click the “Load Preset” button and choose “TF2_crew” 9) edit the pawns to taste 10) start game
Note: Windows and Mac instructions are basically the same but with some variation around the location of the RimWorld data directory.
Closing thoughts
Simple one this time round. Like I said I wanted to complete something small in a timely manner, just to dip my toe into the waters of modding RimWorld. I hope you enjoy playing with this mod as much as I did. Hmm, is this thing even technically a mod? Does it matter? I guess not.
Funny. It actually took me longer to do this write up, then it did to create the actual thing that it is about. I guess that’s not that odd, considering the fact that explaining things properly can take it’s time. Especially with my signature caveats and addendums … and waffling.
I hope this article motivates you to at least try out getting into modding games, if you aren’t doing it already. Never be afraid to start something new. But start small. Start with something that can be completed within a timely fashion and with your current skillset. Then iteratively add complexity with each later thing that you complete.
I know this is rich coming from me, but remember that “perfect is the enemy of done”; and that there’s nothing more motivational than finishing something that you set out to do. It’s better to complete 100% of something small, than 66.6% of something big. One can be released out there for people to enjoy, whilst the latter is rotting in your “ongoing_projects” folder. Or maybe that’s just me.
#0027: Dominions 4: Thrones of Ascension map creation guide
Preamble
This is a quick bullet point style guide to how I create maps for IllWinter’s game: “Dominions 4: Thrones of Ascension”. Note: I will henceforth refer to the Dominions 4 game binary as “dom4”.
Map creation steps
Step 1: acquire or create a base image to use as the map.
I created an image using the GIMP image editor, and saved the multilayer project file (.xcf).
Step 2: use an image editor program to alter/create an image to conform to a standard that the dom4 executable can recognise.
Image specifics:
image must be in the Truevision TGA (.tga) or Silicon Graphics Image (.rgb) image format
minimum image size: 256×256 pixels
recommended image size: 1600×1200 pixels
image must be in 24 bit or 32 bit colour depth
image must be either uncompressed or using run-length encoded (RLE) compression
image must use a white single pixel as a province marker
white = HEX:#ffffff, RGB:(255,255,255)
Step 3: using the image editor, export a correctly formatted image.
I exported a TGA image file to specification, with a size of 256×256.
Example image file name: “tutorial_map_256x256.tga”.
Step 4: copy that image file to the dom4 working directory.
Working folder directory:
Linux: ~/.dominions4/
Mac: ~/.dominions4/
Windows: %APPDATA%\dominions4\
Step 5: boot up the dom4 game, and navigate to the game’s internal map editor.
Menu navigation: Game Tools > Map Editor > New map > (enter image file name)
This will automatically create a map. By populating it with provinces (one at each white pixel), then guess at the links between the different provinces.
Step 6: use the in game map editor to edit the map data.
This includes: mapping links between provinces, formatting link types (mountain, river, ground); terrain types (forest, farm, sea); throne sites, special sites, and so fourth. Its important at this stage to generate random names for each province, this is in order to populate within the .map file relevant code for the province names.
Example: #landname 1 “Deepmount”
example with no province markers
clean map
name edit
saving map name
example with imported image
Step 7: save the map. This will generate a .map file in your dom4 working folder.
Step 9: test play the map, and troubleshoot errors.
If the dom4 program crashes as soon as you load up the map. Then it is indicative of a hard fault. For example, the tutorial map here crashes if you try to add more than 4 nations to it. Other crashes like this can be caused by the dom4 binary being unable to find a resource. E.g. the user renamed/edited resource files, then tried to load into a game that uses them.
This method is probably the simplest way to actually create decent playable maps. By using the built in map creator tool, a user can bypass a lot of the tedium involved in coding. Such as learning the meanings of various symbols used for variables and game function, or learning the specific syntax used to generate a viable .map file. This is because the in-game visual editor automatically populates the .map file with viable code. All the user has to do is use the visual editor to assign all the functionality that they require for each province by checking menu boxes. Save the map. Then circle back to the .map file to fill in a couple of titles (in game text fields) after that.
Ultimately, I think that this quick guide provides a good framework. One that an aspirant map creator can build on further by reading IllWinter’s map making manual. Which in turn will allow them to gain further insight into the mechanics of map making; including the ability for more advanced functionality. In the mean time, just these simple steps will enable users to create perfectly playable maps. Ones that should satisfy most.
USB “OTG” stands for USB “On The Go”. USB On-The-Go is a specification of the USB protocol that allows traditionally slave devices such as smart phones, to act as master devices or host systems (e.g. personal computers) when connected to either other slave devices such as digital cameras and printers; or peripherals such: USB storage disks or human interface devices (e.g. keyboard and mouse).
USB plug classifications.
There are a myriad different types and generations of USB cables available on the market today. However most obey the convention of having two different plug-socket configuration in each class specification. A type-A plug and socket for connecting with the host system (a.k.a. “A” device), and a type-B plug and socket for connecting with the slave (or “B”) device. A standard USB cable will have one male type-A plug and one male type-B plug. A USB OTG cable differs from a standard USB cable in only one significant way. The standard USB type-A plug is replaced with either a USB Mini type-A or USB Micro type-A variant. That’s it.
For example to connect a generic modern printer to a smart phone with a USB Micro type-AB socket. One would need a male USB Micro type-A to male USB type-B cable. The replacement of the USB type-A with a USB Micro type-A is what makes it an “On The Go” configuration. This means you don’t need a traditional PC to use the printer. You can connect directly with and use the mobile device to send the files to the printer in it’s stead.
image taken from wikipedia.org
Limitations of the USB OTG specification.
A device with OTG enabled capabilities unfortunately can not act as a general purposes host system with the same peripheral compatibilities as a personal computer. Instead they are given a Targeted Peripheral List (TPL) from their manufacturers. This is a rather limited list of general peripherals designed to work with the particular device for it’s expected use cases. This is because these devices will have limitations on them such as power output or limited supported protocols.
Unfortunately, as I see it; with the innumerable amounts of devices (smart phones, tablets, etcetera) and peripherals (with various protocols and power draws) on the market today: the best way to find out whether or not a peripheral is compatible with your particular device – is to just plug it in and see. This is also true for finding out whether or not your device supports the USB OTG functionality in general. Some might not.
I tested a couple of smart phones I had on hand, and of the four I had, only one actually supported OTG functionality. The other three simply didn’t register the peripherals (including a basic USB thumb stick) plugged into them. These were: (2011) Samsung GT-I5500, (2012) HTC Chacha, (2015) Huawei GRA-L09, and (2018) Blackview A30. Of them only the Huawei GRA-L09 worked with my OTG cable. It performed perfectly with the wireless USB keyboard-mouse combo, and the thumb drive I tested with. The Huawei even allowed connections to the other smartphones (using a Micro type-A to Micro type-B cable). It could charge the other devices, register on their end as connected to a host, but not allow access to their filesystem like a PC would allow. This last thing could be a software limitation, that will require some further tinkering to work; or possibly using some kind of third-party file browser or peripheral manager. Long story short, when it comes to compatibility: your mileage may vary.
Creating a USB Micro OTG cable.
The USB OTG specification was originally created for use with mobile devices that utilised the USB Mini standard, and later updated to include the USB Micro standard. We will create an OTG cable by modifying a Micro type-B plug to a Micro type-A plug. Then using it to create a male USB Micro type-A to USB (full size) type-A socket. This is to connect basic low power USB peripherals such as storage drives or a wireless mouse and keyboard combo. Which is my particular use case. However it should be stated that the same modifications can be made to a USB Mini type-B plug to turn it into an OTG enabled Mini type-A plug.
To create a basic USB Micro OTG cable is actually rather simple. All you essentially need to do is short the ID pin (pin 4) on the USB Micro type-B plug to ground (pin 5). This procedure effectively (i.e. electrically) turns the Micro type-B plug into a Micro type-A plug.
Unfortunately in my case, my kit USB Micro plugs only came with 4 soldering pads (for the power and data lines). It was missing a solder pad for the ID pin. This meant I couldn’t just run a small jumper from the ID pad to the ground pad. I instead had to access the ID pin directly. On one hand this makes creating the OTG cables that require some resistance value between the ID and the ground pin significantly harder. Due to no room for the resistor. However if you intend to just create a basic cable, then this method of just bridging the ID and ground pin can be useful for salvaged USB Micro plugs who in all likelihood won’t have an ID solder pad.
With this in mind, I disassembled a kit USB Micro type-B plug. Next I scraped the covering plastic on pin 4 and 5, then soldered a bridge across them. I removed the plastic to create space and headroom for the solder bridge. Otherwise, I may be unable to slide the plug head (with it’s plastic inner lining) back on. Space constraints need to be paid attention to. Reassembled the plug. Then tested for continuity using a multimeter and a USB Micro type-B socket breakout board. Id est making sure that pin 4 is grounded, and that the solder bridge wasn’t coming off.
Please note, there are other methods for creating OTG cables that involve running a specific resistor across the ID and ground pins for certain devices to work, or to enable the host and/or peripheral device to draw power from an external power source. However I am omitting them, for brevity. This is a quick guide to build a basic DIY OTG cable.
I decided to make the pictured OTG cable modular using breadboard jumper cables. The reason for this is because I intend to mix and match various plug and socket ends to create different types of cables. However, I would recommend making a more fixed and permanent cable for actual real-world use.
Modular OTG cable example
Tooling and material example
Disassembly and modification of a USB Micro type-B plug
Modular male Micro type-A to female USB type-A OTG cable in use
Modular male Micro type-A to male Micro type-B OTG cable in use
