• Moose

_Michael

Moderator
  • Content Count

    1,473
  • Joined

  • Last Visited

  • Most Liked  

    3

Reputation Activity

  1. _Michael liked an article by nos.17, AutoHotkey as a Modding Tool   
    For those who are not familiar with it, Autohotkey is a fantastic open source program designed to replicate repetitive keyboard or mouse actions. As with any sort of coding, the possibilities are technically limitless, but so far I have used small script (about 20 lines) to save and open new exemplars in LeProp, and add/remove properties dozens of props in the Reader. What would have taken probably 20-30 minutes, one is able to achieve in under 5 seconds!
    As I said above, the possibilities are limitless, so I will make this tutorial as general as possible while showing examples of scripts I have created.
    This tutorial will be continuously updated as suggestions for inclusions are offered.
     
     
     Introduction 
    This tutorial is aimed towards any custom content creator who regularly, or semi-regularly has to perform repetitive tasks in the Reader or any other application. Simple text scripts can be used to quickly and easily automate such tasks. Skills learned can also be applied to any program or procedure outside of Sc4 also.
    This tutorial is worded simply so those with zero programming experience can complete their first script. This tutorial only covers a few of the basics. There are hundreds of more advanced functions for more experienced users. The AutoHotkey Help file is a great resource for this.
     
     
     Getting Started 
    Download AutoHotkey here. You will notice that there is no interface to start up and code into. This is because everything is done through simple text files.
    The first step is to identify a procedure you would like to automate, for example, adding Prop Family properties for a collection of 80 props. You will need to know exactly what you are doing for the task at hand. As you go through the process manually for the first few times, make careful notes of when and where you click, what you type in, etc. It may be helpful to write a procedure down on paper as you go.
    The second step is to create a new *.txt file that will be used for the script. It is not important at all what it is named or where it is placed. As long as its file extension is changed to *.ahk at some point, it will become associated with Autohotkey and everything will work fine.
     
     
     Sending Key Presses 
    The most basic command is the Send command. Typing
    Send asdf will, upon execution of the script, will type out asdf automatically. Not very useful you say? Yes, you’re right.
    Some special keys can be activated by enclosing their name in braces { }. Be careful here. Typing
    Send Enter will literally type out Enter as text: that is, the letter “E” followed by “n,” “t,” “e,” “r.” This does NOT have the same effect as pressing the enter button (obviously, typing “Enter” into Word will not put the cursor on a new line – the same concept applies to scripts). To simulate pressing the Enter button,
    Send {Enter} should be used instead. Other examples include {Shift}, {Delete}, {Tab}, etc.; for the arrow keys, {Up}, {Down}, {Left}, {Right} are the appropriate commands. Any of the other special keys are called using special characters instead:
    !  .......... Alt
    #.......... Windows
    +.......... Shift
    & ......... Used to combine two keys to a single new one (eg. f&g = hold “f” and press “g”)
    ^ ......... Ctrl
    < , > .... If there are a pair of keys, <! Signifies Left Alt and >! Signifies Right Alt; ! would trigger when any Alt is pressed, for example.
    From this, we can refine our script a little more:
    !u:: Send asdf Will type “asdf” when Alt and the 'u' key is pressed. A little more useful, don’t you think? Note the double colon after the statement. This demarks the start of the code that will be executed when those buttons are pressed. Adding a
    return demarks the end of the code for that hotkey. For simple scripts, it is not strictly needed, but for good practice, we will amend the code to include it anyways:
    !u:: Send asdf return  
     
     Sending Mouse Clicks 
    Every page can technically be operated without a mouse, but using 50 Tabs or Shift-Tabs to advance focus to the button you are looking for is inefficient, time-consuming, and dumb. There are numerous ways to do this; by far the simplest method is to use mouse clicks. The syntax
    Click xx, yy or, for a right click,
    Click right xx, yy simulates a left or right click at xx and yy, where xx and yy are the x and y coordinates of the button on the window you are using. Figuring out these coordinates will probably be the most time-consuming part. Fortunately, there is a tool which comes packaged with AHK that makes this process simple. Navigate to the AHK installation folder and run au3_spy.exe (or type it in the start menu).
    Among other things, the program will give you a live readout of the x and y coordinates of your mouse pointer for the current window and your overall screen. USE THE COORDINATES FOR THE CURRENT WINDOW. The “On Screen” coordinates are marked “less often used,” which is apt. You want to use the mouse position in the active window for numerous reasons, the largest being that if you drag the window around your screen, the Active Window coordinates will remain constant while the Screen coordinates will change.

     
    This is where careful notes come in handy. Going through the process manually with au3_spy open in the background, recording somewhere the x and y coordinates of any buttons needed in your task. For example, we could write a script that (in notepad) will paste something from the clipboard with minimal effort:
    !u:: Click right Send {Down}{Down}{Down}{Down}{Enter} return NOTE: In the example above, it is possible to use a mouse click to press the paste button instead of pressing Down 4x and enter, however, this method will be dependent on coordinates of the initial right click. Thus, many times it may be easier to chain arrow key commands instead of locating mouse positions.
     
    To transition to the next topic, suppose we have the following code:
    #s:: Click right Send {Down}{Down}{Down}{Enter}{Enter} return Which, when run on my internet browser (Chrome) will right click where the cursor is, open the save dialog box, and hit “Enter” to finalize the save. Run it, and you will notice that it does not entirely do what we want it to do. It will open the save dialog box, but the second enter (to finalize the save) does not seem to execute.
    This is a simple error in timing. When the script executes, all of the commands are sent instantaneously. This is the ideal condition; in real life, however, it takes some amount of time to do everything. Even a time of fractions of a millisecond is enough to throw your code off. If you manually right click and hit save, there will indeed be a small delay until the dialog box appears. Syncing everything may seem like a difficult fix, but the code required is quite simple.
     
     
     Opening New Windows 
    AHK sends its commands very quickly (as it is supposed to do). If click on any buttons that activate new windows or dialog boxes, you may run into problems. As mentioned above, the script will execute correctly, but not as intended; rather, it will send some (or all) of the commands in the time it takes for the message box to appear and become active. The solution is to wait until the new window is active and ready for input. Simply use the command
    Winwait, xxxxxx where xxxxxx is the full or partial title of the window. It is important to note that this string can either be the full exact title or just the first few characters. For example, if I am editing a file called nos.17_VehiculosFamilias_1c90deg.dat, I could type
    Winwait, nos.17 Using just “nos.17” is enough for the script to recognize which window it is waiting on.
    If the title is not explicitly stated in the window like it is below,

    Windows Task Manager can give you the appropriate name.

    Remember, only the first part of a window name is required. If the name is long or complex, the first few letters should suffice.
     
     
     
     Loops 
    To repeat tasks multiple times, one could either copy and paste the commands the necessary number of times, or use loops. Loops, if you are not familiar with them, will simply repeat the tasks within the braces { } a specified number of times for example,
    Loop, 4 { Send ^v Send {Enter} } would paste whatever is in the clipboard five times on a new line (another description). For obvious reasons, this method is preferred for larger numbers but is also easier to read and debug for small numbers (like 4) too. NOTE: The number in the loop control starts at 0. So if you want something to happen 4 times you will need to enter 3 (0 1 2 3), and so on. The general equation for the number of times you want to loop: n-1. If you’re interested why, (1) and (2); if not, just try and remember that.
     
     
     
     Comments 
    Comments are used for your convenience. Comments are bodies of text that the computer skips over and will not execute - their purpose is to either explain what should happen when some code executes or anything else the programmer wants to say. As such, they are never required but always recommended. In AutoHotkey, everything after a semicolon (;) on the same line will not parse (they will be completely ignored by the computer). An example:
    Click 380,590 ; Click Apply Everything after the semicolon ( Click Apply) will be ignored by the computer. It is only for my benefit to remember what each line is supposed to do. Comments in no way are required on every line. I've merely included them for sake of clarity so others can read my code.
     
     
     
     Saving and Running the Script 
    Whenever you are finished. Simply save your notepad document. If you haven’t already, change the extension from *.txt to *.ahk. Windows might give you a warning telling you that changing the extension may make the file unstable – this is generally a good warning but not applicable here and can be ignored. Changing *.txt to *.ahk will in no way change anything in the file – it will simply associate that file as an AutoHotkey script instead of a lowly text file.
    Once the file is renamed, right click on it and you should see some additional options in the menu.

    “Run Script” will make the script become active. Hit whatever hotkey(s) you assigned, and your script will execute every time you press the key(s). You will see an icon appear in your system tray. Right clicking there will allow you to do a few different things, including closing the script so it will no longer run (Exit). “Compile Script” will automatically convert the script to a *.exe file. It can be exited in the same fashion from the system tray. “Edit Script” opens the notepad file and allows the script to be edited. Note that just double clicking like normal to open the file actually has the same effect of “Run Script.” This is one of the other results of changing the file extension to *.ahk.      
    “Open” “Help” opens the AutoHotkey help documents which can be a great help in finding the correct syntax. “Window Spy” launches au3_spy.exe. See the "Sending Mouse Clicks" subsection for an explanation of its purpose. “Reload This Script” recompiles the script. If any changes were made, they will now be active. “Edit This Script” opens the notepad file and allows the script to be edited in whichever editor you assigned as default for the *.ahk extension. “Suspend Hotkeys” will keep the script active but disable any hotkeys mapped within the script. Useful if the key combination you assigned is actually used in some other program. The H tray icon will be replaced with a similar looking icon, but with an S. “Pause Script” prevents any part of the script from running until it is manually resumed. The tray icon will be replaced with a red one. “Compile Script” will automatically convert the script to a *.exe file. It can be exited in the same fashion from the system tray. “Exit” completely closes and ends the AutoHotkey process.  
     
     Examples 
    There is simply an immense amount of things one can do with AutoHotkey scripts. However, the things outlined above should be enough to complete most of your scripts for SC4 modding (they’re all I’ve used so far).
    To make your own, identify something repetitive that you do that can be easily scripted. The two examples below detail my method of solving these problems. As with coding, a multitude of approaches exist, and the only incorrect one is the one that does not work (or perhaps takes an inordinate amount of time).
     
    LeProp_SaveClose.ahk
    For those that do not know, LeProp has a peculiar bug where it can only save one action at a time. As such, one needs to close and reopen to edit multiple things on a lot. It can be quite tedious having to save, close, navigate to, and run the LeProp executable. This script is designed to fix that.
    !x:: Click 380,590 ; Click Apply Click 550,120  ; Click Save WinWaitActive, LEProp ; Wait for “Save Successful!” dialogue box Send {Enter} ; Closes “Save Successful!” dialogue box WinWaitActive, iLive ; Waits for main window to be active (“Save Successful!” dialogue box is fully closed) Send {Esc} ; Close LeProp run, C:\Program Files (x86)\iLives\LEProp.exe ; Opens LeProp WinWaitActive, Ilive ; Waits for main window to be active Send {Enter} ; Opens the “Open File” window
     
    Reader_Add_BuildingPropFamily.ahk
    #a::     ; Hit Windows-a to activate Click right 1200, 600        ; Right click in the right pane Send {Down} {Down} {Down} {Down} {Enter}  ; Select “Add Property” WinWaitActive, Property :             ; Wait for Property editor to appear Click 425, 50      ; Click to expand the Name menu Send buil ; Type to scroll list to Building/prop Family Click 250, 105     ; Select Building/prop Family Click 450, 255     ; Select Add Click 40, 635      ; Click in the Values as text field Click 40, 635      ; Not sure why I have this twice Send 0x5f85e126    ; Your prop family IID goes here Click 435, 635     ; Hit first Apply Click 190, 700     ; Hit Second Apply WinWaitActive, Reader  ; Change to Reader main window name; partial name is acceptable Click 1200, 235   ; Click on Building/prop family property Send ^c ; Copies that property to the clipboard Click 870, 1000   ; Click to place focus in the left pane Send {Down}       ; Move down to select next exemplar   Loop, 257     ; Change to number of exemplars starting count at 0: e.g. if last num is 65, use 66 { Click 1200, 600   ; Click to place focus in the right pane Send ^v            ; Paste the property Click 870, 1000   ; Click to place focus in the left pane Send {Down}       ; Move down to select next exemplar }                  ; Repeat
     
     
     Conclusion 
      If anyone has questions or needs help on their scripts, I will be happy to help. If I don't start a thread, just shoot me a PM and we can work out your problems together. Happy modding! ...
  2. _Michael liked an article by rsc204, Modding Automata into Props   
    Have you ever wanted to use one of the in-game automata as a prop in lotting? Well it's actually really simple, all you need to do is create a prop exemplar that links to the installed automata model. You can even duplicate the model and make rotated versions. Unlike normal SC4Models, automata are special because fully 3D models are used in game.
     
    However to aid you in making automata as props, I've included here a template for the Bus Automata. I will use this as an example, and walk through the modifications required to make whatever bus automata you are using. But the principles explained here can be adapted to props for any S3D 3D model that you want as a prop. Note all models are S3D, but not all S3D models are the 3D ones.
     

     
    In the example above you can see the Basic Prop Exemplar for the default Bus Automata. The IID* of this model is 0x10620000. This is the same ID used in the Resource Key Type 0 field of the prop exemplar.
     
    *IID = Instance ID, as in Type, Group and Instance. For all 3D models the same Type and Group ID is normally used, hence we only need to worry about the Instance ID when dealing with these models.
     
    Any models which over-ride the Maxis defaults, must have the same ID as the originals. Therefore it's usually easy to know which IDs we are looking for. Vester has compiled a handy list of most Maxis Automata here.
     
    The example shown above references the default Bus Model. Without further modification, you can now use this prop to place your Bus Automata on lots. But in the included template DAT, there are a further 3 Prop Exemplars, linked to 3 S3D model files. These S3D files need to be replaced by duplicates of the actual Bus Automata you want to make into props. Since those included are merely templates.
     
    Copying your custom Bus Automata.
     
    These additional prop exemplars need to link to rotated models. At FAR-L, FAR-R and Diagonal positions. If you want to use these, you need to find the DAT containing your Bus Automata. Open that file, whilst keeping the included file opened as well.
     
    Copy the S3D of the Bus Model. Be careful to get the whole bus, not the model with the lights. Paste this below an existing S3D model in my file.  Right click the template S3D model and select "Copy Entry ID".  Right click the replacement S3D model and select "Paste Entry ID".  Right click the template S3D model, select "Remove File". We don't need this anymore.  
    So that's one S3D model replaced with your custom one. If you do it this way, all the prop exemplars and textures from the existing model are now automatically linked together, saving a lot of work.
     
    Repeat the process for the remaining two S3D templates. Save your modified file. You can optionally rename the Prop Exemplars to better suit your model.
     
    Rotating unique model instances with Model Tweaker.
     
    Now we need to rotate the models, because right now our copies are still straight. For this, you need Coego's Excellent Model Tweaker. Open the modified DAT file using Model Tweaker.
     
    Highlight the following S3D models in turn and use the Rotate Models option with the following settings for each:
     
    S3D IID 0x20620000 FAR-L        -    Counter-Clockwise / Free = 18.5 S3D IID 0x30620000 FAR-R        -    Clockwise / Free = 18.5 S3D IID 0x40620000 Diag             -    Clockwise / Free = 45  
    Now save the file. Your props will now appear in the Lot Editor for use. Bear in mind that such props may not show correctly in the Lot Editor. But they will appear in game, all four props link back to the original model's textures. So to use them, you must keep the file with the automata installed.
    BusAutomata_as_Props.zip
  3. _Michael liked an article by rsc204, Slope Mods: A Brief Guide   
    I was asked about slope mods by Dreadnought today. Halfway through replying to a PM, I realised this would be better posted here for all to see. If anyone can think of something I've missed, I'd be happy to consider it's inclusion at some point. For now though, this will just cover some of the basics.

    What is a Slope Mod?
    A slope mod just adjusts the allowable slopes, at an individual network level. What does that mean?...
    Without any additional mods, if you have a big hill and draw a network, the game has a default setting for the maximum slope of each network. Maxis deliberately made this pretty unrestrictive, for ease of play. If you want to create more realistic looking cities, especially with hilly terrain, you will probably want to install a mod that adjusts the default slopes, making them more restrictive. This will help to avoid the bumpy uneven roads, that are very common when playing without such a mod.
    Each network in the game has it's own settings, that dictate how steep the slopes can be when dragging that network. These networks are:
    Street Road OWR (One Way Road) Avenue Maxis Highway Rail Elevated Rail Monorail Dirt Road (RealHighway [RHW]). It should be noted that override networks do not have separate settings. So for example, if you are using the Network Widening Mod (NWM) or Street Addon Mod (SAM), which are overrides of the Road and Street networks respectively, they will use the same settings as the base network.
    Dirt Road is so called, because it was an additional unused network left in the game's code. Whilst it has been repurposed by the NAM team to be used for the RHW mod, technically it's the Dirt Road network. From here on in, I will refer to dirt road as RHW, for the sake of clarity.
     
    A Slope Mod sounds just up my street...
     
    Hopefully if you've made it here, you'll be thinking right now about installing a slope mod. As always with mods for SC4, there are far too many options out there to go into every one in excruciating detail. They all do pretty much the same thing, but there are two important factors you should consider when selecting one.
     
    What networks does the mod support/change. How restrictive is the slope.  
    For example, you may decide you only want to have restricted slopes for some of the supported networks. So if a mod bundles everything together in one DAT, unless you know how to remove those you do not want, (really not very hard, even though it does require the Reader), you should be mindful of this.
     
    A very restrictive slope mod will totally transform how you build and terraform in game. Whereas a very unrestrictive mod, could end up looking like the vanilla experience. If you are new to slope mods, then it's probably best to try a few out and get a feel for how they affect things. Especially before you start using one in a cherished region. For example, a really restrictive slope can mean a 15m height difference, would take something in the region of a whole large tile for the slope. Obviously that's an extreme example, most of them are much more balanced for general play.
     
    For the purposes of this tutorial, I'm going to show the three mods I'm using:
     
    BRF's Tunnel and Slope Mod RHW Slope Mod BTM Slope Mod  

     
    And here is a comparison shot, to give you an example of how these changes affect your slopes. Each of the networks in this picture are transitioning from a 15m high hill. Even with the slope mod by BRF, the street network takes only three tiles or 48m to descend by 15m. For math aficionados, that's a slope of around 1:3. This is pretty steep, but probably not completely unrealistic in some places. The road takes 4 tiles or 60m by comparison, which is 1:4. As you can see, I've cunningly laid these out from bottom to top, in the order of the slopes gradients. From steepest, to the shallowest slope. If you are still wondering why you need a slope mod, this picture should hopefully show you how much nicer your slopes can be.
     
    Note: I've used Rail stubs to indicate the first three tiles that are at ground level for each network. I've also used PedMalls to help see the slopes better. As you can see, rail has the most restrictive slope of all, so much so, even with my fairly reasonable grades, it doesn't fit in the screenshot.
     
    Using your slope mods more flexibly
     
    Whilst you could have multiple slope mods for a number of different situations, that's quite a complex setup and requires you to close SC4 and move files about. Let's say I want a road to have a slope similar to that of the El-Rail network shown above. Rather than switch to a slope mod permanently with those settings, there is an easier way. Just use the El-Rail tool to draw the slope first, delete it and drag the road down your nice new slope. Using the above picture as reference, you can do this for any network which appears lower down the screenshot, than the slope you require. To put that another way, if you made a slope using the Avenue tool, but then wanted to use it for the Rail network, this would not work. Since the rail network is more restrictive. Using this setup though, you can have quite a bit of flexibility for a number of networks. Note how the Rail networks, including Monorail and Elevated Rail, have the most restrictive slopes of all. That makes a lot of sense when you think about it, since in real life, the gradients they are able to support are much less than cars and other traffic are able to deal with.
     
    Some final hints and tips
    Sim City 4 can be unforgiving at times, it's all too easy when making other changes, for your hard work creating slopes to become unravelled. Just as I have shown above, using PedMalls next to the slope, will lock-in the slope, making it impossible for development and other networks to alter them further.
    Of course, if you wanted a junction halfway down the slope, that now be impossible too. Here's where some planning really comes in handy. Using the four steps shown on the right, you can easily form intersections as part of your slopes.
    Drag the initial slope, here I am using the El-Rail tool for the slope. I have placed pedmalls and used a rail stub to completely flatten the tile where the junction will be. Now you can continue to drag your slope, in this case in two directions, from the stub. I've placed the pedmalls here before I built the road. As you can see, the slopes are working very well. Lastly, I've dragged the street tool, anything with a less restrictive slope would do, parallel to the new road. This makes the surrounding tiles match the slope used for the road. This is useful if you want to zone next to the road, or sometimes for blending into the terrain better. Note: I have not dragged next to the road junction, a gap of one tile must be left here. Because I've used pedmall to lock-in the slope, there would be no danger of messing up our hard work. But if the pedmalls were not present, dragging either of the parallel streets closer to each other, might mean you'd have to start over.
    Another useful thing to know, when zoning next to slopes, the game can actually alter the slope of the transit network. Either when zoning or when buildings develop. Often this is quite undesirable, but there is a way to avoid it. By holding the CTRL key when zoning, the game knows not to change the slopes in either scenario. It does require some thinking about how you zone each area, but is a very handy way to stop the game messing up all our hard work, to keep slopes looking good.
    If you make a partial slope, you can then level off areas using "stubs" as required. Stubs are made by clicking only once with the network tools, such as the Street, Road or Rail, in each tile. As opposed to connecting or drawing them in a line. I prefer to use rail stubs myself, because they do not feature auto-connect. This can catch you out on occasion, causing problems, especially when using the RHW or Streets tool.
    Leave these stubs in place whilst you are building your slopes, to incorporate many different things, that might otherwise look undesirable on uneven terrain. This can be especially useful for incorporating WRC's, TE connections and many other possibilities into your slopes.