Post news RSS DevLog 44: Lighting System, Continued Serialization & Polishing...

We’re on the brink of November and development blog 44 is, as you can, not delayed! We’ve had another productive week despite having to deal with classic autumn sickness and a lot of other life distractions and looking ahead it seems as if life seems a bit less congested compared to the previous week, always feels great to be able to prioritize development.

Posted by on


Lighting System

We started the week by doing some very much needed changes to the lighting algorithms, replacing an unnecessarily complex looping algorithm with an animation curve that gave us a lot greater control over the lights. Each lamp in Airport CEO is a single object (yes, every runway and taxiway lamp as well) and almost all structures will most likely be fitted with some kind of light source (excluding the terminal). This called for a better lighting system and what we ended up with is that now can we not only simulate cool lighting delay effects depending on if the light is, for example a big spot light that takes some time to spin up, or if its a runway LED lamp that lights up instantly, but CEOs can now also decide themselves when the lights turn on and off .

The lighting system also affects the sun, and we can now simulate different sun rises and sun setting times depending on the season of the year (or region if we want to really push the details…) so that those cold winter mornings really are extra long, depressing and dark (basically December in Sweden).

We tweeted out a .gif of the improvements which was very well received and so we’ll post it here for everyone to see. For effect comparison, the first .gif has lights on at sundown and the second .gif shows lights on at midnight.



Of course, if an aircraft was going in for landing and the lights being turned off you’d likely have an incident on your hands. Making sure that lighting requirements are adequate for your flight planning is initially the responsibility of you, the CEO and perhaps later the COO.

So what’s the purpose of being able to control when the lights go on? Well, lights require power and so we are thinking of adding another resource in to the game: Electricity contracts and power consumption. Most objects already have an hourly operation cost whereas a sofa’s operational cost is $0 and a basic fuel deposit has a substantially larger sum (not yet decided). In order not to make it too complex the electricity cost could make up like 30% (-ish) which would ultimately mean that when you’re running all the lights at night you’ll experience an increase in power consumption whilst the concept of electricity consumption still is graspable. What do you think? Too much micromanagement? Or another nice tradeoff simulation?

Continuing the Serialization Quest…

The ongoing quest of serialization continues! Testing of passenger and employee serialization has reached the point of where we have test case scenarios requiring us to implement serialization of other stuff. For this reason we have moved on to prepping for serialization of vehicles and bags. This includes cleaning up model classes and at the same time preparing the for modding support (similar to what we did the aircraft model classes) and during this week effort we will implement the same system we use for saving and loading passengers. In short, we’re simply continuing the work of converting and adapting existing models into functioning serialization practices: Progress this week on vehicles and bags should be swift.

We’ve also spent a few hours fixing additional errors related to saving and loading of franchise contracts as well as clearing up som UI stuff related to that while also adding some more variables that were forgotten during a save.

Polishing

As focus right now is on quality and making sure that stuff don’t break, we’ve done some overall polishing and fixing…

  • Rooms have been fitted with a new selection image
  • Rooms had an issue where the canvas text was out of bounds – resolved
  • Stupid and redundant code for getting items within a room has been removed
  • Static as well as dynamic queues are now visible by toggling U (and they also become visible when building)
  • Multiple issues resolved with passenger activity methods
  • The staff room panel lacked a “remove room” button, which has been added.
  • A lot more…

That’s it folks. And oh right, we also put some time into correcting a small login issue with the forum even before anyone reported it …and also fixed an issue with the devlog posts breaking the page and blocking the footer. Interesting, huh? That’s it for this week. See you later and have a good one!

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.