• Moose

Cyclone Boom

Administrator
  • Content Count

    4,065
  • Joined

  • Last Visited

  • Most Liked  

    14

Cyclone Boom last won the day on
July 11

Cyclone Boom had the most liked content!
View Past Leaders

About Cyclone Boom

  • Rank
    Simtropolis Geek

Profile Information

  • Gender
    Male
  • Location
    United Kingdom
  • Interests
    City-builders, simulation games, golf, cricket, tennis.

    Technology, websites, problem solving, multimedia & photography.
  • City-building game(s)
    SimCity 4
    Cities: Skylines
    SimCity 3000

Recent Profile Visitors

13,281 Profile Views
  1. OK, guess what? 326 days later, that point is finally now... So starting out with this: Cloud Map 1 The initial test render came out a bit plain. So I decided to add a stream that ended up widening into a river cutting through a canyon. I found the reason for this was since it was a high elevation, and anything coloured pure black will render as water at the lowest possible height. After some trial & error, and a generous helping of Gaussian Blur I quite liked the end result of the jagged cliff edges. I then lowered the Gamma Input Level, added a small lake, and gave the terrain a bit more definition in parts (using the Burn tool, with selected blurring in focussed areas). The greyscale: Region preview: Cloud Map 2 Next I thought to use the same cloud formation and try a more basic approach. All I did this time was use around 15.0 of Gaussian Blur, and reduced the Gamma Level to around 0.60, lowering the land. Other than that, keeping the source image untouched: To my surprise, this came out rather well (of course, after experimenting to find the appropriate amount of blur and Level adjustment). As can be seen below, this created a nice waterfront with a bay area. The narrow strip of land connecting the mainland happens to be just wide enough for an avenue. Or equally it'd be tempting to terraform this and allow watercraft into the inlet: Another cloud pic: Cloud Map 3 After the usual procedure, for this I also did some extra editing: The waterway I painted with the Burn tool to deepen the level (using a soft brush to try and replicate an artificial harbour area). Since it fits in better over there, I also moved the mound over to the middle right (cut, paste, smudge and blur). Then also raised it up somewhat and created a cliff face so it looks more interesting / realistic than a flat hill. In the upper right, I made the water with a gradient effect to simulate increased depth. There's also a basin type area which would be a prime location for housing with a view of both the south and north: One more snapshot of the British summer: Cloud Map 4 For this I kept it straightforward and followed the pattern of the blue sky to paint the water. First using the textbook method of using the Acrylic brush. Then the Burn tool to make the more gradual elevation change for the river banks: Simple yet effective, and I think the end result ain't too shabby. Especially the cliff face from cutting through the hillside: Cloud Map 5 For this I used the same source image, but thought to mix things up a bit. So I flipped it vertically and rotated clockwise by 90 degrees. Then wondered what would happen by inverting the colours. Sure enough as expected, the lowlands and the highlands exchanged roles: A few nice natural lakes were formed, and it's just asking for a bridge through the middle there: Note: All in game renders show the Appalachian Terrain Mod, with the 'Silt' variation of SHK Brigantine 2.0. If they're useful to anyone, here are the source bitmap greyscales: CB Cloud Map Greyscales-1.zip (573KB) (Each is 769x769 to create a 3x3 large tile region. The included config.bmp works with all of them.) One thing I've tried to bear in mind is making the landscape features fit in each tile. This required some minor editing in GIMP using the Smudge Tool with varied levels of Strength/Opacity. Adjusting the Levels really is a very powerful tool, as each increment can completely transform the landscape. I didn't delve into any of the other myriad of tools, but I suspect there are other ways of similarly manipulating the heights. Should I release these properly, I'll need to deepen some of the water levels. Without painting water manually, a limitation I've found is the depth may not be great enough to allow ports or other land/water structures to be built. Editing by hand it's tricky to get this right while still preserving the integral shape of the terrain. As lots of experimenting was required for the finer editing, I found SC4Terraformer very useful to get an instant preview. This allows each BMP to be imported and viewed in the expected rendered form. You can zoom around and view different elevations, and really get a feel for how everything fits together in the individual tiles. It's also quite accurate I've found when compared to the actual render. But keeping in the spirit of the CORIMAPS method, I only used GIMP for editing, as much as Terraformer would've made the task of refining much, much easier. I must say this was a whole lot of fun. With the entire concept, what I find most fascinating is how in terms of patterns and form, nature in the sky somewhat correlates to nature on the ground. You can take a picture of something miles above, yet through some simple editing it can unmistakeably represent terra firma in a world of pixels on a computer screen. So if you're reading this and you haven't already, I'd encourage everyone to give it a try. @CorinaMarie Speaking of maps, I noticed you've uploaded some splendid new ones with mention to a 'planet generator' method (e.g. Mons Lacus & the Jr edition). Given the innovation of CORIMAPS, I'm really interested what heights your newly discovered technique can reach. So, how exactly did you go about that?
  2. Excellent, and thanks also for updating all of your uploads with screenshots.
  3. Thanks for sharing, and when you get a moment to upload some images that would be great. STEX files allow screenshots to be added and shown as snapshots at the top. This has the advantage of also appearing on the category listings (for example). With each file, this can be done by opening the menu and clicking Upload a New Version. As Corina said, you don't actually have to upload the city (*.sc3) files again, but this page allows screenshots to be uploaded and assigned to the file once saved. One image per file is sufficient, and they don't have to be anything fancy or high resolution. Just to give people an idea of what the cities are before downloading. All in your own time, and let us know if you'd like any assistance with this. You're very welcome here, and I hope you enjoy the site.
  4. Given many of the early lots primarily used Maxis props, that would be my best guess. Just extract each DAT file and place anywhere in your Plugins folder. For a lot which references a Maxis building as a prop, they will be missing without necessarily showing a brown box (I just tested this to confirm). Alternatively to the bldgprop files, another option is to use: Which as an added bonus, also fixes a minor annoyance on custom lots. With the exception of Origin, I believe all other known digital versions (including Steam) come fully patched. At least in the past, an indication was to check the game's exe, which reported version 1.1.641.0 when hovered over. If the checksum is different than what the patches expect, the updater will fail. Then throw in the DRM that also changes the structure of the executable, that's a reason why the Origin edition is completely unpatchable. EDIT: @rex3456 Glad to hear it worked.
  5. Some additional thoughts on a few of the topics raised... Automated System As I see it, the concept for APT type system (following @matias93's post here) would be the ultimate universal solution for distributing content. Bridging the gap between both accessibility and ease of use. Greatly simplifying the process of batch installation -- that's what this is all about. Therefore as such, it should leave no stone left unturned. If this is the way to go, it needs to cover all the main aspects of plugin management. The whole incentive aims to reduce the steps needed to add BATs, lots & mods in bulk. We want to make it easier for everyone involved. Whether a newcomer to SC4 or a veteran player. People want to have the option of adding custom content, without going through the arduous and headache-ridden task involving dependencies and testing for conflicts, binary searches etc. The mise en place would be done beforehand, and then the system takes care of the rest. After all, that is the main appeal of fast food restaurants... I imagine a key benefit is it'd be relatively simple to modify the master list for each pack. Effectively being a central reference and set of instructions. Adding new files accordingly, and the same if needing to point away from obsoletes. By sourcing the original files, something worth considering is if authors decided to release updates. The STEX (at least) uses versioning, where any previous revisions are saved and are by default still available for separate download. We'd need to ensure should any given file be updated, the system retrieves only the version it expects. This would be the one incorporated inside the MODPACC, already checked for compatibility with the others included. Any changes would need manually approving for inclusion. Then the instruction commands could be altered, pointing to the new version and any additional dependencies. The authors supply content, and those tasked with arranging the packs determine how it gets compiled. Otherwise the more extra variables, the greater chance of all sorts of potential conflicts and chaos. Without cohesion, it'd defeat the purpose. For the user, the process of updating ought to be as simple as re-running the tool, to synchronize with the pack's contents. Removing obsolete files (in the modus of Cleanitol), and replacing them with the newly released ones. For the sake of bandwidth and convenience, it'd be grossly inefficient to re-download the entire content set more than once per installation. Above else, all this needs to revolve around simplicity. Streamlining at both ends of the spectrum. Going down this route, I'm very much in favour of it being implemented cross-site to the fullest extent possible. Personally, I must admit the finer mechanics of all this is beyond my current technical expertise. I know the IPS suite does provide a standard REST API which may help provide the platform for integration. However, this would absolutely require a team not only willing to work on this, but obviously have the knowhow to understand how all the procedures work to bring this to fruition. So essentially looking ahead in this direction, we'd need at least 3 core groups of people: Developer(s): Creating the base framework, integrating it accordingly with site software, and creating the commands for processing. Organisers: Determining the contents of each MODPACC, considering compatibility between items. Testers: Basically quality assurance for functionality, and checking each MODPACC works correctly in SC4 (and ideally when combined with other packs). This would need to be in a standardised environment as determined by the package manager. Content & Community Cycle While I like the idea behind automation and packaging content in general, I feel @Fantozzi's earlier concerns are very valid. Following on... How would the batch distribution of plugins (automated or otherwise) affect the motivation of active or aspiring content creators? Knowing a MODPACC bundle is far more appealing, there's a chance of individual entries on the STEX or LEX being overlooked, especially if included. With a package containing multiple items, individual creations are less likely to be recognised and cherished in their own right. I suspect at least for some, this plays a big part with motivation -- knowing what you create is valued by those who decide to pursue it. For any aspiring creator, the task of earning appreciation may then become steeper. If all the plugin packs attain most of the the limelight, and you receive no feedback, why would you bother to continue sharing your own works? It'd be very hard to compete on such a scale. I imagine this is one reason why there's been so very few transport mods other than the NAM and RTMT, or based around them with compatibility in mind. The reason being, a MEGA mod is designed to be an encompassing solution for a specific need. Tried and tested, and proven to achieve just that. Anything much more than a collection of fixes, I think we need to proceed with a degree of caution to ensure authors are respected for creating individual uploads. I very much agree with @rsc204's summation, including the points about informing people about custom content as a whole. At the same time, I think we also still need to encourage newcomers to ask questions. A starter pack should be strictly limited to just that -- an introductory taster. The thing is, there's a cycle where people enter the scene, slowly learning their trade. First starting small, posting on the forums, or seeking advice. Sharing progress, while progressively becoming familiar with how the game and custom content functions. Maybe delving into BATting, lotting, modding or map making of your own. All the time expanding on your knowledge and gaining vital experience. Finally completing the loop by passing it onto other newcomers who come along. While the so called 'golden era' for new creations may be over, what we're seeing nowadays is quality over quantity. We therefore still need to be careful not to break the cycle, otherwise closing the door and potentially discouraging those interested in taking up creating BATs, lots, mods or maps for the first time. That cycle is what keeps any learning community alive and well. This isn't and rightly shouldn't simply be a museum. Bandwidth Considerations Anything involving mass online data distribution brings this into the picture. Here at Simtropolis, the STEX is unsurprisingly the biggest overhead in this regard. Putting it in perspective, the past 30 days has seen 630GB of bandwidth used from all files downloaded. I can confirm within the IPS suite, there are standard usergroup settings to cap bandwidth quota, download speeds and also quantity. So there are options to limit the flow, should that be required. Using an external host such as ModDB is a possibility. At least on the STEX from files, it's possible to link the download location set via a URL. That way the user would either by redirected to the page (as the NAM does currently), or perhaps a direct link to start the download. I did notice ModDB's terms state the following: As @CorinaMarie previously mentioned, I suppose a way around this is by re-designating all content as property of the community. If we can help it though, I think it's best to keep everything hosted here. Nothing on the internet is certain. But the recent Photobucket debacle proves yet again how relying on external sites puts full trust in their policies and services. Integrating any system is also much harder without direct access. Indeed, through a system allowing MODPACCs to be batch downloaded on site, or even compiled and offered as individual entries, it can only result in a sharp rise in the amount used. As @Tarkus said above, it's difficult to predict the scale or trends of such an increase, and we'd need Dirk to clarify whether this may overflow the upper limit costs of the site. Depending on the scale, the question is: Do costs need to be covered? Then if so, where possible, finding the best method(s) to recoup this without restricting the packs to an isolated group of users. I've mixed views about packs being withheld and not openly available. On one hand it'd prevent bandwidth mounting, but on the other would be contrary to making them accessible to all SC4 players. Similarly with putting each on a DVD or in an exclusive section say for site donors (min $X amount). The deciding factor here is whether or not it's sustainable to cover the costs of any extra bandwidth. It's tricky to have it both ways. But if we can avoid it, I'd be in favour of keeping them available to the masses. If we're looking at lowering barriers for newcomers, this I feel is necessary. Overall the entirety of this project would undoubtedly be a mammoth task. But when there's a will, there's a way... right? Like most things: start small, gain momentum, get off the ground, with the ambition to expand.
  6. We did remove the status bar which was really causing a significant extra load on server resources. As per my post here: This means the Chat is still available using the tab navbar link, which was the same arrangement as previously with IPS Chat. As to if there's since been reduced activity, I'm really not sure what that could be attributed to. My best guess is people expect to see the number of online users shown on the tab. And seeing as this isn't any longer, people think no one is actually using it and then don't enter. Also just to say we haven't given up on improving chat to the best of our ability. Just it's been a very busy last few months behind the scenes.
  7. Yeah, the $400 per year refers to the farcical Photobucket pricing policy. Absolutely spot on. There's a known stat which says ~80% of businesses capitulate within the first year. But with Photobucket we're talking about a company which has been established for 14 years. Providing a free service for people to host and share images on 3rd party sites. This had been the status quo. It proves that sufficient revenue must've been generated from other sources (e.g advertising, account upgrades), while still allowing them to offer the core free service most people signed up for. Their fundamental policy has stood strong until now, and such provisions in their terms only make them legally entitled to make changes. It doesn't make it the ethical or right thing to do. But they can do it, and they've done it. Especially where web services are concerned, it's understandable the costs of hosting and bandwidth increase over time. Where there's demand, anything involving mass data storage will always grow naturally without intervention. Also not to forget the hardware which must be upgraded and maintained, catering to the ever changing developments in technology. Therefore, revenue must scale with increasing costs. Clearly they'd reached the tipping point where action was necessary. But if costs were growing, and profit margins narrowing, what do you do? Surely they could've seen the danger signs early enough, planned ahead, and given everyone sufficient warning. There's no excuses. Yes, I'm sure there are other more progressive methods which could've been explored. Why not ask what people would be willing to pay? Give ample opportunity for images to be transitioned. But no, they've lured people in, then turned the primary motive for using the services into a ransom. The reason for the extortionate fee is simply because they know all too well the ultimate dilemma they've created. The task of rehosting is far greater than paying. So in reality, they're charging based on the supposed time it'll take people to find and migrate to an alternative solution. The rip-off price alone does not represent the upgraded service being offered. They also know that to cover their costs, only a very small fraction of the userbase must fall for the trap. Most likely businesses who've relied on them to function. I still cannot get over the fact a service can go from $0 to $400. An all or nothing approach taking a drastic U-turn, and is bad enough in its own right. But alongside no prior form of communication or justification whatsoever, it's beyond a joke. To rub it in, they've even since defended their pricing as being "competitive" with other 3rd party hosts. Unbelievable. Anyway, I'll be having talks with Dirk on the feasibility of ST offering a sustainable storage model for the membership, at a perfectly reasonable fee.
  8. If you'd like, I can move your posts about SmugMug over to a new topic. But otherwise you're quite right -- it is still related to image hosts, and I'm sure @CorinaMarie won't mind. EDIT: As confirmed above. That's very possible. I've heard some image hosts do compress images to conserve bandwidth by reducing file sizes. This is likely to be more noticeable on JPGs, since it's a lossy format. The higher the compression, the more blurry or degraded the overall quality becomes. Usually I'd advise against sharing PNGs, since they're prone to be larger in size. Most notably for images with lots of detail (e.g. landscapes), where the difference can be in megabytes. The reason being, PNG images use lossless compression, which means the file size is reduced without losing quality. But this comes at a cost, since it's harder to compress images without discarding data. A useful purpose of them is for smaller web images, where visuals must be crisp & clear, without the file size getting out of hand. It might be worth checking your account settings at SmugMug, as they may allow the level of compression to be adjusted. Otherwise it wouldn't hurt to test a PNG upload and try a comparison in terms of quality vs. file size. If the advantages are great enough, that might be the best solution. At least for images you'd like to stand out or feel would most benefit from the increased clarity. I believe that shows on attachments uploaded here to ST, or automatically if an image overflows the boundaries of a page. For images posted from external sites, this won't show if the image fits without being scaled (resized).
  9. It's nothing special (was actually a test city I created a while back), but the overall population is just under 255k. Glad to hear it! Let us know if we can be of further assistance.
  10. Welcome to Simtropolis! When aiming to build urban areas, I've always found it helps to think ahead to where larger transport networks could be built. Since as population density increases, finding land to construct these later on becomes an increased challenge. Perhaps for some inspiration, an idea is to look at transport maps of real world cities, and try to replicate the layouts. Quite often cities have a central loop of main highways, which branch off and intend to equally distribute traffic throughout the region area. Even with the benefits of NAM, the traffic simulation in SC4 isn't directly comparable to reality, but the basic principles still do apply in parts. Like most things in the game, it does require a lot of trial and error. So perhaps it's worth making regular copies of your region and exploring different methods. That way it's easy to revert back if something doesn't work out. Also it can help to check the Traffic Data Views, and toggle between the two options. The "Congestion" view is the default and shows the overall quantity for all types of transport, where red is the worst extent of congestion. Then there's the "Volume" view which allows filtering between road traffic, and the 9 other modes of transport. The dots reveal the flow of the traffic in the direction travelled. There's also separate toggles between morning / evening commutes, for when Sims travel to and from work. For example: Also using the Route Query tool (Alt + /) can help to show the path taken from specific buildings or networks in a city.
  11. From reading through, before I add a few additional thoughts... Just to say it's very reassuring to see as a community we can come together here, discussing such topics so intelligibly. That alone is clear proof there's a strong desire to enact change in the best way possible. Moving away from a 'one for all' approach, I also think the idea is heading in the right direction. Rules and policies are usually the biggest stumbling blocks. Especially those which have been established around the core fundamentals of a culture or mindset. The longer they're set in concrete, the harder the initial step of breaking them down. However, providing there are valid reasons to amend policy, and providing there are people around with the motivation to do so, that is precisely what should be done. Not by words alone, but by taking focussed action to establish new foundations. And I absolutely agree such measures are required to help keep custom content relevant, accessible and moving forward. With due care and attention, by continuing to work together, I'm confident this objective can be achieved.
  12. @mike_154 Just to reassure that no one is forcing you to follow the advice given about dependencies. They have often been a widely and often deeply debated subject. So it's completely your choice, and you're free to use as little or as many as you choose, regardless of their form or function. T Wrecks' post wasn't meant to offend or undermine your creative rights as a content creator in any way. It was made to try and help provide some direction, perhaps on some areas which could be improved. With the aim to make the task easier for people to enjoy your creation. This has always been a learning community, open to both newcomers and experienced players alike. By sharing files, that alone is a big first step and not everyone gets that far. There have been 2,816 authors in the history of Simtropolis, and you're a more than welcome addition. After all, variety in custom content is what keeps SC4 going strong after all these years. If you'd prefer to do things your own way, that's completely fine. Again, there are no obligations to follow any such advice. Or equally if you'd ever like some guidance along the way, remember we're here to help.
  13. File Issues Fixed! I'm pleased to confirm that following my post here, the various issues affecting the STEX have now been successfully resolved. This includes broken layouts, formatting errors & unparsed BBCode, which caused files to be malformed or not displayed as the author intended. Also more recently, the missing URLs broken as a result of the initial attempt to fix the above -- these have also been restored and merged into the formatted descriptions. As they were rebuilt via a batch process, it's possible there may be a few descriptions which could still be formatted better. Such as excessive spacing or tables missing data. For these or anything else, please let us know either in this thread, or using the dedicated 'Report' function on files and we'll correct them manually. Still, the overwhelming good news is such files should now finally be in a much, much better state than they were previously, without any major defects.
  14. Yes, good point. Even though BBCode is technically deprecated on the site, the basic functions should still be converted to HTML once posted. E.g. [b]Bold[/b] [i]Italic[/i] [u]Underline[/u] [color=blue]Blue Text[/color] [center]Center[/center] [img=http://community.simtropolis.com/library/misc/bzt.gif] [url=http://community.simtropolis.com]URL[/url] Is automatically rendered as expected: You're welcome!
  15. In the ST post editor, double clicking the image should allow any set URLs to be edited or removed.