pak48.bitlit

[Nazalassa]

Hi Simutrans community,

I've been working on a pakset for a few days weeks, so I thought I could share it on the forums.
I got somewhat inspired by the simplicity of pak48.Excentrique, and so I thought, "can I make something even simpler?", and then came the idea of the computer-themed pak48.bitlit.

 
Note: previews may not be up-to-date.

Description

Pak48.bitlit is a simple 48px pak set in the realm of Electrons, Bytes, Memory and CPUs. Passengers are Electrons, mail is Generic Data, and there's neither roads nor tracks, but uni- and bi-flows. There are no double- or half-slopes, since "it's too complicated", even if the slope size is 6px -> so half-height.

Download

Until version 1.0b, releases of pak48.bitlit were attached to this post, or any other in this thread. Pak48.bitlit has then moved to a git repository, hosted at Codeberg.

Links (tar.gz): Compiled pak (0.1c) | Source (0.1c)
Links (zip): Compiled pak (0.1c) | Source (0.1c)

Codeberg repository: https://codeberg.org/Nazalassa/pak48.bitlit

Old links:

Compiled pak (0.0c)
Compiled pak (0.0d)
Compiled pak (0.0e)
Compiled pak (0.0f)
Compiled pak (0.1a)
Compiled pak (0.1b)
Source (0.0c)
Source (0.0e)
Source (0.0f)
Source (0.1a)
Source (0.1b)

Features

• Uniflow. Versions included have speed limits of 300 km/h and 450 km/h. It needs care like train tracks, but it can overlap with biflow (like tram track).
• Biflow. Versions included are limited to 160 km/h and 240 km/h, so it's significantly slower than uniflow. However, like roads, it allows for two-ways circulation, and does not need signals if running several convois like uniflow.
• Bridges for uni- and bi-flow, and uniflow tunnels.
• Stops for uniflow, biflow, and both.
• Depots for biflow and uniflow.
• Half of a proper English translation.
• Two engines for uniflow, and their biflow counterpart: "yellow", less powerful, and "green", more powerful.
• Electron and Byte carriages, for both way types, and both speed classes. To transport freight.
• Wireless communication: header and payload sections.
• Also in wireless communication: aerial wireless as an addon (for now).
• A townhall, and buildings of the three kinds (residential, commercial, industrial).
• Monuments.
• Program chain: the Byte Generator generates bytes, which are consumed by the Instruction Converter, which produces Instructions, which are turned into Programs by the assembler, which are consumed by the Control Unit. Production will be fine-tuned a bit in the future.
• Wireless chain: the Wireless Transmitter transmits data to the Wireless Receiver. There also is a Remote Server
• Power: the Power Supply Unit may supply power to any other factory, via powerlines.
• Powerlines, with assorted bridges and tunnels.
• Inter-computer space! (beware of imperial destroyers there)
• Plenty of icons and cursors drawn for the pak's toolbars - and more!
• Plenty of icons and cursors not drawn, with some placeholder text instead!
• Purple-ish sunset and sunrise (it's a feature, trust me)
• A nice-looking toolbar (at least from my point of view)
• v124.1 icons!

Todo

• Add some attractions  some monuments in 0.1a
• Some more vehicles, especially headers, also mail transport in 0.1a
• Find more names for cities and stops

For later / suggestions:

• More industries?
    '-> More goods
• More ways/building/vehicles in 0.1a
• Maybe some stuff to go on the coolant (water) ? Like "boats" 'n stuff  in 0.1a

Known issues and caveats

• Minor artifacts if building a bridge over a building; may hide factory animation.  unimportant
• Transporting stuff is waaaaaay too profitable, the pak is currently not balanced. pak balanced in 0.1a, although there may still be issues
• Biflow is limited to 50 km/h in cities. It is because Simutrans sets it to some hard-coded constant, so I can not do much against it, at least not until there is an option to change it.
• If you generate too much cities, some of them will be named "simcity", because there isn't enough city names.
• There is a hidden uniflow way, because apparently bridges can not use streetcar-type ways at their ends. If it were not here, there would be segfaults. However, the "t" shortcut selects it because it can not, either, select streetcar-type ways. Apart from the fact that one cannot cross biflow, there are virtually no differences. actually, it doesn't matter
• City names may not work well, for uncertain reasons. Investigations in progress. Issue closed for lack of replication. Probably a locale issue.
• Industries often generate weirdly, without enough production for the consumption spawned. Will try to fix. fixed in 0.0f

If you have any comments, or suggestions, or questions, feel free to post them here.

Disclaimer: pak48.bitlit is in no way affiliated with bit.ly, or anything bearing a similar name.

[Roboron]

This is cool! I like experimental paksets like this 

Some observations:

- The first tab in depot says "Electrons and Mail" -> I think Mail should be Data?
- The city names I am getting are just the base game combinations of CITY_SYLL (Pollingstead, Hillfield, etc), not sure why :-/
- It would be cool to make use of night lights. Specially for "vehicles"!

Biflow is limited to 50 km/h in cities. It is because Simutrans sets it to some hard-coded constant, so I can not do much against it, at least not until there is an option to change it.

Indeed, I can see in the code this limit is hard-coded when the way has sidewalk (assuming hat_gehweg() means that xP)



Maybe this value should be configurable by paksets. Not only for special cases like yours, but also because the limit of 50km/h is not true for every country!


May I showcase this in the upcoming Simutrans Extra?

[Nazalassa]

May I showcase this in the upcoming Simutrans Extra?

Of course!

Some observations:

- The first tab in depot says "Electrons and Mail" -> I think Mail should be Data?
- The city names I am getting are just the base game combinations of CITY_SYLL (Pollingstead, Hillfield, etc), not sure why :-/
- It would be cool to make use of night lights. Specially for "vehicles"!

• Corrected. Download Attachment has been updated.
• Weird, I will investigate. What language exactly are you using? My guess is that the pak lacks a citylist_en_*.txt, or something similar.
• Noted. Now the question is, "where?" On the front, or the whole vehicle perhaps - I'll give it a try.
  -- Upd. --
  I think I'll put #E3E3FF (usual window color) on the full byte carriages. They'll glow yellow-ish at night. I think it's the headers, rather  than the carriages, that should glow.
  The following colors don't go more yellow at night:
  
  • ███  #FFFF53  ->  Yellow
  • ███  #FF211D  ->  Red
  • ███  #01DD01  ->  Green
  • ███  #FF017F  ->  Magenta
  • ███  #0101FF  ->  Blue
  -- Upd. 2 --
  I made the headers glow, and it actually looks quite good!
  
  

-- Upd. 3 --
New capacitor arrays:

[Isaac Eiland-Hall]

Wow, this is spectacular! I especially love that it uses Simutrans to basically make a new game. Certainly a new paradigm. I won't be able to poke at it for a bit, but I most definitely will. This is awesome!

Maybe this value should be configurable by paksets.

Something I've long wished for.

[Yona-TYT]

Something I've long wished for.

My dear friend Isaac, you are always very attentive to new Paksets.

[Leartin]

The following colors don't go more yellow at night:

• ███  #FFFF53  ->  Yellow
• ███  #FF211D  ->  Red
• ███  #01DD01  ->  Green
• ███  #FF017F  ->  Magenta
• ███  #0101FF  ->  Blue

I'm quite certain that the special night colors can be redefined in the simuconf tab. Might make sense to check that out early - you wouldn't want to change them anymore once you got a bunch of graphics ready.

Cool trick with them by the way: For buildings, you can overlay a special color in the backimage with something semitransparent in the frontimage. This allows you to somewhat extend your possibilities. Feels like the theme of this pakset might benefit from such tricks.

[Nazalassa]

I'm quite certain that the special night colors can be redefined in the simuconf tab. Might make sense to check that out early - you wouldn't want to change them anymore once you got a bunch of graphics ready.

Cool trick with them by the way: For buildings, you can overlay a special color in the backimage with something semitransparent in the frontimage. This allows you to somewhat extend your possibilities. Feels like the theme of this pakset might benefit from such tricks.

Good to know. I'll look for special night colors in simuconf.tab as soon as possible - which means now.

In other news: capacitors are done and depots have been redone, plus I added season symbols and corrected the biflow bridge. 0.0e will be out within a few days (I hope).

-- Upd. --
Unlike menu grey, night colors are not defined in simcolor.h, nor are they part of the "standard" 256-color-set.

-- Upd. 2 --
Uh-oh... Found this in simutrans/display/simgraph16.cc:

Code Select Expand

/*
 * special colors during daytime
 */
uint8 display_day_lights[LIGHT_COUNT*3] = {
0x57, 0x65, 0x6F, // Dark windows, lit yellowish at night
0x7F, 0x9B, 0xF1, // Lighter windows, lit blueish at night
0xFF, 0xFF, 0x53, // Yellow light
0xFF, 0x21, 0x1D, // Red light
0x01, 0xDD, 0x01, // Green light
0x6B, 0x6B, 0x6B, // Non-darkening grey 1 (menus)
0x9B, 0x9B, 0x9B, // Non-darkening grey 2 (menus)
0xB3, 0xB3, 0xB3, // non-darkening grey 3 (menus)
0xC9, 0xC9, 0xC9, // Non-darkening grey 4 (menus)
0xDF, 0xDF, 0xDF, // Non-darkening grey 5 (menus)
0xE3, 0xE3, 0xFF, // Nearly white light at day, yellowish light at night
0xC1, 0xB1, 0xD1, // Windows, lit yellow
0x4D, 0x4D, 0x4D, // Windows, lit yellow
0xE1, 0x00, 0xE1, // purple light for signals
0x01, 0x01, 0xFF, // blue light
};


/*
 * special colors during nighttime
 */
uint8 display_night_lights[LIGHT_COUNT*3] = {
0xD3, 0xC3, 0x80, // Dark windows, lit yellowish at night
0x80, 0xC3, 0xD3, // Lighter windows, lit blueish at night
0xFF, 0xFF, 0x53, // Yellow light
0xFF, 0x21, 0x1D, // Red light
0x01, 0xDD, 0x01, // Green light
0x6B, 0x6B, 0x6B, // Non-darkening grey 1 (menus)
0x9B, 0x9B, 0x9B, // Non-darkening grey 2 (menus)
0xB3, 0xB3, 0xB3, // non-darkening grey 3 (menus)
0xC9, 0xC9, 0xC9, // Non-darkening grey 4 (menus)
0xDF, 0xDF, 0xDF, // Non-darkening grey 5 (menus)
0xFF, 0xFF, 0xE3, // Nearly white light at day, yellowish light at night
0xD3, 0xC3, 0x80, // Windows, lit yellow
0xD3, 0xC3, 0x80, // Windows, lit yellow
0xE1, 0x00, 0xE1, // purple light for signals
0x01, 0x01, 0xFF, // blue light
};
Looks like it's not possible to modify night colors from a pak.

[Leartin]

What you found in simgraph16.cc are the default colors.

Try to add this in your simuconf.tab (using different colors, obviously)

Code Select Expand

# special pak set colors for day and night
special_color[0]=0x57, 0x65, 0x6F, 0xD3, 0xC3, 0x80 // Dark windows, lit yellowish at night
special_color[1]=0x7F, 0x9B, 0xF1, 0x80, 0xC3, 0xD3 // Lighter windows, lit blueish at night
special_color[2]=0xFF, 0xFF, 0x53, 0xFF, 0xFF, 0x53 // Yellow light
special_color[3]=0xFF, 0x21, 0x1D, 0xFF, 0x21, 0x1D // Red light
special_color[4]=0x01, 0xDD, 0x01, 0x01, 0xDD, 0x01 // Green light
special_color[5]=0x6B, 0x6B, 0x6B, 0x6B, 0x6B, 0x6B // Non-darkening grey 1 (menus)
special_color[6]=0x9B, 0x9B, 0x9B, 0x9B, 0x9B, 0x9B // Non-darkening grey 2 (menus)
special_color[7]=0xB3, 0xB3, 0xB3, 0xB3, 0xB3, 0xB3 // non-darkening grey 3 (menus)
special_color[8]=0xC9, 0xC9, 0xC9, 0xC9, 0xC9, 0xC9 // Non-darkening grey 4 (menus)
special_color[9]=0xDF, 0xDF, 0xDF, 0xDF, 0xDF, 0xDF // Non-darkening grey 5 (menus)
special_color[10]=0xE3, 0xE3, 0xFF, 0xFF, 0xFF, 0xE3 // Nearly white light at day, yellowish light at night
special_color[11]=0xC1, 0xB1, 0xD1, 0xD3, 0xC3, 0x80 // Windows, lit yellow
special_color[12]=0x4D, 0x4D, 0x4D, 0xD3, 0xC3, 0x80 // Windows, lit yellow
special_color[13]=0xE1, 0x00, 0xE1, 0xE1, 0x00, 0xE1 // purple light for signals
special_color[14]=0x01, 0x01, 0xFF, 0x01, 0x01, 0xFF // blue light
I did a quick check changing the windows in pak192comic:


So it exists and does what it should. And the screen displays beautifully why no pakset with established colors should touch it


EDIT: The Code responsible for reading those special colors, in settings.cc

Code Select Expand

void settings_t::parse_simuconf( tabfile_t& simuconf, sint16& disp_width, sint16& disp_height, sint16 &fullscreen, std::string& objfilename )
{
    tabfileobj_t contents;

    simuconf.read( contents );

#if COLOUR_DEPTH != 0
    // special day/night colors
    for( int i = 0; i < LIGHT_COUNT; i++ ) {
        char str[ 256 ];
        sprintf( str, "special_color[%i]", i );
        const vector_tpl<int> c = contents.get_ints( str );

        if( c.get_count() >= 6 ) {
            // now update RGB values
            for( int j = 0; j < 3; j++ ) {
                display_day_lights[ i * 3 + j ] = c[ j ];
            }
            for( int j = 0; j < 3; j++ ) {
                display_night_lights[ i * 3 + j ] = c[ j + 3 ];
            }
        }
    }
#endif

Edit2: Works slightly differently then I thought. The colors in the PNG that read as special colors can't be changed, but you can change how they are displayed. So if you want to use "special_color[0]", you can make it black in the day and white in the night, but it's just #D3C380 in your source graphic that becomes black and white.
No change in the possibilities for you, just makes it a bit more complicated to handle.

[Nazalassa]

What you found in simgraph16.cc are the default colors.

Try to add this in your simuconf.tab (using different colors, obviously)
(code)

I did a quick check changing the windows in pak192comic:
lightcolors.png

So it exists and does what it should. And the screen displays beautifully why no pakset with established colors should touch it

EDIT: The Code responsible for reading those special colors, in settings.cc
(code)

Edit2: Works slightly differently then I thought. The colors in the PNG that read as special colors can't be changed, but you can change how they are displayed. So if you want to use "special_color

• ", you can make it black in the day and white in the night, but it's just #D3C380 in your source graphic that becomes black and white.

No change in the possibilities for you, just makes it a bit more complicated to handle.

Oh, right... Thanks Leartin! I didn't look at the settings code. Guess I still have a lot to learn about source-code-browsing

I added orange and light blue light, and updated the Byte Generator so that it glows at night. Looks even better now.

Also: Industrial arrays are finished: transistors, resistors and capacitors, in 3 sizes.

-- Upd. --
I made graphics for the instruction converter and the assembler, but I'm having some trouble findings ideas for the control unit. 0.0e will be ready either this evening, or tomorrow morning.

[Nazalassa]

Version 0.0e is out!

Changelog:

Changelog for version 0.0e
""""""""""""""""""""""""""
  [ADD] Graphics for capacitor and missing transistor arrays.
  [ADD] Graphics for Instruction Converters, Assemblers, and Control Units.
  [ADD] Symbols for seasons and timeline.
  [ADD] More icons... Build city, Grow/Shrink city, Change player, Hide/Show
        station labels/coverage...
  [ADD] Show/Hide stuff in special tools.
  [CHG] Changed the first two night colors in simuconf.tab - thanks Leartin!
  [CHG] The Byte Generator's bytes now GLOWS! Hehehe
  [CHG] Made headers GLOW during night - so pretty...
  [CHG] Overhauled depots.
  [CHG] Corrected offset in Biflow bridge 160, separating it in two.

[Yona-TYT]

Excellent! This is turning simutrans into an electrical circuit simulator... 

[Nazalassa]

Version 0.0f is out! It is (if nothing goes wrong) the last version for 0.0.

Download: Compiled pak (0.0f) | Source (0.0f)

Changelog for version 0.0f
""""""""""""""""""""""""""
  [ADD] Commercial buildings.
  [CHG] Tweaks for industries, proportions and # of suppliers should be correct
        now.
  [CHG] Mail is now Data, and can be carried by byte transporters (CATEGORY_01)
        (Data tab in depots).

[Leartin]

I made a mockup to show you some things I think could be changed / interesting for you.



- Drastic Color Change. Nothing wrong with your sterile gray aesthetic so far, but I think it could be fun to have it look like an actual circuit board. You could use climates to get different colors of boards, besides green you could have blue, brown or even red. For the ways, I'd use semi-transparent white - thus, it would always be a lighter version of the ground underneath. (And if you use a semi-transparent white light, your data streams slightly glow in night mode, while the data itself glows to the full extent.)

- Black water. So you could have several islands as different circuit boards. Ships could represent wireless transmission. Industries based in the 'ocean' as tiny handheld devices. Also, make sure your shores are straight.

- I really don't like the bases all your elements are placed on. They make no sense to me. I suppose if they are almost the same color as the ground, it doesn't matter much.

- Make sure to use multi-tile city-buildings, center top in the mockup. They shouldn't be much harder to create, but those size differences could look fantastic in the end result. On that note, you could fiddle with the city street logic to generate larger blocks. Simutrans usually has huge ways to better show off vehicles, but you don't really have those. So, I vote for more sprawling.

- I think it makes sense visually if all ways end in holes, and I mocked the city name label as well to try and capture the aesthetic. Also, perhaps details like holes for screws or white labels make for good ground objects, as "non functioning" parts.

- Something I did not show: You could get rid of slopes in general - visually. Instead of slopes, visuals could show the edge of the top board and some vertical space to the next layer underneath. visual slopes should be part of sloped ways though.


That's it - just some ideas

[Nazalassa]

I made a mockup to show you some things I think could be changed / interesting for you.



- Drastic Color Change. Nothing wrong with your sterile gray aesthetic so far, but I think it could be fun to have it look like an actual circuit board. You could use climates to get different colors of boards, besides green you could have blue, brown or even red. For the ways, I'd use semi-transparent white - thus, it would always be a lighter version of the ground underneath. (And if you use a semi-transparent white light, your data streams slightly glow in night mode, while the data itself glows to the full extent.)

Hmmm... I don't know for this one. I initially thought of the pakset as a network of computers (each city being one),  or as a single computer, so I don't really think making the whole map a single circuit board (save the color differences) would keep the pak in its theme. Or rather, it would, but that would be a particular "subtheme".

That being said! Maybe I can reskin city buildings and sidewalks, so that their backgrounds are green-ish. In that way only cities would be circuit boards (albeit with holes in them, unless I mess enough with cityrules.tab).

- Black water. So you could have several islands as different circuit boards. Ships could represent wireless transmission. Industries based in the 'ocean' as tiny handheld devices. Also, make sure your shores are straight.

That idea is excellent! I will try to implement it soon.
Right now water is "coolant", and I have thought of wireless communication devices at the beginning, but I placed them (in my mind) near the edges of the map.
However, I don't know how to make shores "straight" - the map generator doesn't know about this word

-- Upd. --
I may have to disable lakes.

- I really don't like the bases all your elements are placed on. They make no sense to me. I suppose if they are almost the same color as the ground, it doesn't matter much.

Good catch - turns out I don't really like them, either. I think I'll recolor the ground to be uniform, and then the buildings are just on the ground.

-- Upd. --
Done, except for the memory blocks in factories, but these shouldn't take too long. I still kept a thin, darker border around stuff that has pins, else said pins blend with the ground and can hardly be seen.

- Make sure to use multi-tile city-buildings, center top in the mockup. They shouldn't be much harder to create, but those size differences could look fantastic in the end result.

They're on my todo list for 0.1.

On that note, you could fiddle with the city street logic to generate larger blocks. Simutrans usually has huge ways to better show off vehicles, but you don't really have those. So, I vote for more sprawling.

I had some ideas about the cityrules.tab, but I didn't experiment with it yet - been busy with powerlines and power supply units.

- I think it makes sense visually if all ways end in holes, and I mocked the city name label as well to try and capture the aesthetic. Also, perhaps details like holes for screws or white labels make for good ground objects, as "non functioning" parts.

The ground objects are a nice idea, but I don't think I will make ways end in holes - they go well with the "circuit board" theme, but probably not really with the current one.

- Something I did not show: You could get rid of slopes in general - visually. Instead of slopes, visuals could show the edge of the top board and some vertical space to the next layer underneath. visual slopes should be part of sloped ways though.

I initially thought of that, but I couldn't decide where to put the separation between levels. On the top edge, and ramps going into the um, "sea", would have looked weird, and I'm not sure I can change that in cityrules.tab. In the middle or at the bottom edge, and sloped ways would have to dig through the ground. Bah, I can still redo the lightmap - not like I have thousands of ways to modify


In a nutshell:

• Will do: black water, no bases for buildings, multiple-tile city buildings, ground objects
• Will probably not do (for now): drastic color change, changing the slopes (at least not until I would have experimented a little)

[Nazalassa]

Good thing: I managed to fix all the issues I had with the industry!

I made the beam bridge "continuous" and glow-in-the-dark:


I have also spotted a "minor" problem: Electron and Data convoys (not freight ones, though) just can't handle the demand without being extra-long, and taking like half the length of an average city (4 or 5 station tiles).

Possible solutions:

• [ -- ] Reducing passenger and mail levels Not fun!
• [ + ] Adding more advanced, higher-capacity vehicles, but with a lower income (to avoid generating insane amounts of money)
• [ + ] Adding higher-speed ways

And, lastly:
I want to experiment with factories that consume passengers or mail: do they get it from city buildings? Or do they get them from another factory, like any other good? What about factories that produce these "goods"?
Results: Apparently they are handled like any other good. Looks like I can't have a factory that changes data into "wireless payload".

Possible solution: a factory with a production of 1, and a boost of 6,000%, so that if enough data is delivered it will produce 60 units per month. I am testing this and, well, it works! (kind of.) Well it stopped working >:( too unpredictible.

I think I will implement wireless transmission like this:

┌────SHORE────┐ Wireless ┌────SHORE────┐
│ Wireless Tx │─────────⇾│ Wireless Rx │
└─────────────┘          └─────────────┘

and we'll suppose that the data collector wireless transmitter does the job of collecting the data from surrounding cities.

-- Upd. --
Currently testing the full chain of 4 factories (with two more ends in cities. I have removed them since.) Observations as I write this:

• If there is no "water" nearby, the data distributor will not be connected to anything. Similarly, if there is no "water" nearby, the data collector will just sit there and wait.
  
  • Maybe add a second "subchain" between data collectors and distributors? Like one that goes though wireless and another through ethernet or something.
  • Or: just remove the data collector/distributor and make wireless receiver the end of the chain?
• It is possible that the wireless transmitter and receiver are not in the same body of "water" - they are separated by land.
  
  • Maybe add a water tunnel? like "special channel" (pun intended) or something Done.

Oh, also one more thing, about Leartin's night color changing: it looks like day-time colors don't apply until the first night if you load a game during day. But it fixes itself after one night, so it's not much of a problem.

[Nazalassa]

Sneak peek into next release: (I know, I like long posts, it's the third in a row)

• Power Supply Unit, powerlines (they even have a tunnel!)
  
• Removed the bases of buildings (and also terrain recolor, etc.)
  
• Wireless! For communicating across intercomputer space.
  
• And, in case there's land blocking wireless: a private wireless channel
  I reused it for uniflow tunnels.
  
  (I know, this one isn't particularly efficient, but still.)
• Wireless transmitter (left) and receiver (right)
   

[Nazalassa]

On multitile buildings:
Multititle buildings are only usable since Simutrans 121. In older versions, the city generator only builds the northwesternmost (is that even a word?) tile. I managed to make multitile building graphics in such a way that they would still look somewhat good in 120.4.1 and below.

Left: Simutrans 120.4.1 (red arrow points to "multitile" building)     |  Right: Simutrans 123.1
 

[Nazalassa]

I have tried airplanes instead of boats for wireless transmission, but:

• In a convoy, only the first vehicle lifts off the ground: the others stay on the ground. Not very good.
• While the head of a convoy lands, the rest of it does weird things and circle all around. They unite back (let's rather say "teleport") to the head when it lifts off the runway ("antenna").
• Some more problems, mainly with routing and the like.

I will keep the boats. It's safer than airplanes. Airplanes will probably drive me mad.

[Isaac Eiland-Hall]

LOL. Airplanes. Well, not many airplane convois in real life, I think. So I don't know if this might be considered a bug. Or if a developer might be interested in fixing it if so.

But it might be worth asking/checking, because it would make sense to have aircraft represent wireless comms, I'd think.

I'll create a topic and link here to prompt discussion on whether or not that might be considered a bug.

edit: Forgot the link! https://forum.simutrans.com/index.php/topic,22559.msg205123/topicseen.html#new

[Nazalassa]

Another sneakpeek, featuring all currently displayed icons (including new ones), the new "Display toolbar", 7 new monuments, and a Uniflow tunnel.
Next step: balancing (I have quite interesting ideas for this) and new, faster, higher-capacity ways and vehicles
Nexter step: "pedestrians" (electrons actually) and groundobjs
Nexter-er step: nessing aroud with city rules and building proportion

Indeed, I can see in the code this limit is hard-coded when the way has sidewalk (assuming hat_gehweg() means that xP)



Maybe this value should be configurable by paksets. Not only for special cases like yours, but also because the limit of 50km/h is not true for every country!

I have taken a look at the code and it appears that the hard-coded speed limit is present in 3 different files:

1. obj/way/strasse.cc (lines 78/79)

Code Select Expand

if(desc->get_topspeed()>50  &&  hat_gehweg()) {
    set_max_speed(50);
2. obj/way/weg.cc (lines 118/119)

Code Select Expand

if(  hat_gehweg() &&  desc->get_wtyp() == road_wt  &&  desc->get_topspeed() > 50  ) {
    max_speed = 50;
3. obj/wayobj.cc (line 92)

Code Select Expand

sint32 max_speed = weg->hat_gehweg() ? 50 : weg->get_desc()->get_topspeed();
So I guess making the city road speed limit configurable would just require to replace the 50s in these 3 files with  env_t::cityroad_speed  or something (I don't really know what the difference is between  env_t  and  settings_t).

[Yona-TYT]

LOL. Airplanes. Well, not many airplane convois in real life, I think. So I don't know if this might be considered a bug. Or if a developer might be interested in fixing it if so.

But it might be worth asking/checking, because it would make sense to have aircraft represent wireless comms, I'd think.

I'll create a topic and link here to prompt discussion on whether or not that might be considered a bug.

Good news, our dear leader is fine with resolving this. 

[Nazalassa]

Here are the new, greener, 450 km/h faster vehicles, next to the old, 300km/h ones:  (both are header, electrons x2, bytes x2)

I currently have two designs for faster uniflow: with a lighter band in the middle, and without. That's why there are two different fast uniflow variants. I can't really decide which one to actually use.

Things I'll have to sort out:

• Whether 30 km/h and 450 km/h vehicles can be used together (probably yes)
• 450 km/h uniflow has a 150% increase in capacity. That means uni450 (for short) will be shorter, and faster, than uni300. I was thinking of making uni450 less profitable than uni300, so that people still use uni300, mainly at the beginning.

-- Upd. --
I think I'll keep the design without a lighter band in the middle.

[Isaac Eiland-Hall]

Good news, our dear leader is fine with resolving this. 

lol — I can't do anything to resolve this, but I just wanted to make sure it was seen by those who could, to maximise the chance that it might be.

[Nazalassa]

Version 1.0a is out! Includes:

Changelog for version 0.1a
""""""""""""""""""""""""""
  [ADD] Symbols for Electrons, Data, Power.
  [ADD] Cursor for remove tool, as well as for 'build'.
  [ADD] Remove way tools in Uniflow and Biflow toolbars.
  [ADD] Wireless! (aka ships.)
  [ADD] Wireless generator and Wireless terminal.
  [ADD] Special wireless channel: for when the land blocks wireless.
  [ADD] Powerlines! With assorted tunnel and bridge.
  [ADD] Factory: Power Supply Unit, it produces power.
  [ADD] Factory: Wireless Transmitter.
  [ADD] Factory: Wireless Receiver.
  [ADD] Transformers.
  [ADD] Uniflow, 450 km/h version, with track, bridge, tunnel.
  [ADD] Uniflow vehicles, top speed: 450 km/h.
  [ADD] Uniflow tunnels!
  [ADD] Biflow, 240 km/h version, with track and bridge.
  [ADD] Biflow vehicles, top speed 240 km/h.
  [ADD] New Display Tools toolbar, where there are tools to hide/unhide stuff, as
        well as underground view, etc.
  [ADD] New icons: view tools, Special Construction and Display toolbars...
  [ADD] Monuments:
         * To old computers
         * To "United Gates Air Force" (originally to logic gates)
         * To G. Boole <0.1>
         * To the Unix shell
         * To Alan Turing (a turing machine with as animated tape)
         * To the EMERAC (lots of lights which at night show a smiley)
         * To wireless (animated)
  [CHG] Removed bases for buildings, except for entropy pools.
  [CHG] Coolant is now "inter-computer space" and is dark blue-ish.
  [CHG] Changed ground color, it is now uniform #B0B0B0.
  [CHG] The outside is the same color as intercomputer void.
  [CHG] Finally figured out how to fix the issues I had with factories:
        crossconnect_factories = 0 in simuconf.tab.
  [CHG] Changed the locality factor to 5,083 (=1000πφ, rounded down)
  [CHG] New maps no longer have lakes by default.
  [CHG] Uniflow beam bridge is now continuous, and glow-in-the-dark.
  [CHG] Balanced the pakset; let me know if stuff is too easy or too hard.

Screenshots of yet-not-shown stuff:

Powerline bridges


"Make way public" cursor


Links: Compiled pak (0.1a) | Source (0.1a)


Planned for 0.1b: pedestrians, groundobjs, better cityrules (that one may as well be for 0.1c lol)

[Nazalassa]

Pedestrians!



Also, citycars. (that may have been a little too much)




(.pak files attached)

[Nazalassa]

Messing around with cityrules, day 1.

Messing around with cityrules has started!

It definitely shouldn't look like that.

* Nazalassa : tweak tweak

I guess that's what's called "private circles".




Messing around with cityrules, day 2.

Even better. Now city only get roads when they have monuments.

* Nazalassa : tweak tweak

Whaaaaat is that??

* Nazalassa : more tweaking

Allright, changed road rule 8, let's see- problem fixed.



But there still is the problem of double roads and weird pseudo-roundabouts.
Also, looks like we need more roads...

I have added a house rule that makes dead-ends disappears: if a road has buildings on 3 or more of its sides (not counting diagonals), then it may be replaced by a building. I don't know if I will keep it.

(tbc)


In other news: here are the uncut graphics for a "Remote Server" factory:


Here it can be seen in its natural environment:


Note: I will update this post every now and then, as I cut my way through the deep forest of Cityrules. I hope I will not loose my sanity in the process.

[prissi]

Thank you for the update. The city rules have also a random factor. Building becomes more likely, the more rules fit a situation.
You can use larger 5x5 rules if you want more buildings and less roads.

[prissi]

Airplane convois are now somewhat working (from r11009). No really checked through stops with airplanes yet, but the crashes are gone at least.

[Yona-TYT]

I have tried airplanes instead of boats for wireless transmission, but:

• In a convoy, only the first vehicle lifts off the ground: the others stay on the ground. Not very good.
• While the head of a convoy lands, the rest of it does weird things and circle all around. They unite back (let's rather say "teleport") to the head when it lifts off the runway ("antenna").
• Some more problems, mainly with routing and the like.

I will keep the boats. It's safer than airplanes. Airplanes will probably drive me mad.

You can now continue your experiments with airplanes, let's hope that bug is completely fixed.

Many thanks to @prissi

[Nazalassa]

I've thought a bit about what to use for wireless (boats or planes) so:

Using boats:
  Pros: It really represents communication between computers.
                -> It gives a meaning to intercomputer space
            It ensures wireless occurs on the edge of "continents" (or computers)
            Unlike planes, boats can stop at mid-sea factories
                -> they can access remote servers, handheld devices, and so on
            They also won't need the latest update to work properly
  Cons: It looks less cool than planes, and a bit less realistic, too.
            It prevents factories located, for example, in cities, from accessing the network.
Using planes:
  Pros: Access to wireless for every factory
            Looks wayy cooler than boats
            More infrastructure for the player to build (especially runways/antennas)
  Cons: Planes will need the latest update or they will look ugly and possibly not work.
                -> Would be great if there were alternatives for Simutrans <= 123.1 (more boats?)
                -> Or: for Simutrans <= 123.1, no plane convoys, but longer vehicles as an addon
            irl there is little to no wireless transmissions inside the same computer
                -> Inter-computer void loses some of its meaning... :(


Idea: each "continent", instead of being a computer, is a LAN or something like that. Inter-computer void then becomes "Internet void" or something like that. So on "continents" there may be wireless devices such as network cards, internal servers, gateways, etc., between which aerial wireless (planes) is used. This aerial wireless goes faster than maritime wireless (or slower? will see). On shores and in the sea are web and network devices such as a remote server, Wikipedia, the Simutrans forums, etc. (Simutrans install chain coming...) which can only be reached by maritime wireless, which may just represent data travelling on the Internet or the like.

So: aerial for local communications, maritime for further communications (we'll pretend it's optical fiber or something).
I may add, for example, network cards in cities, then link them to wireless transmitter (renamed gateways or something), so it makes a more complex chain.
Or social media factory, which consumes user data and produces addictive content, which is sent back to receivers, or phones, etc.

One thing though: is there a way to specify a different crossconnect factor and factory spacing for some factories? The Program chain has to be somewhat compact, but wireless (at leat maritime) would be better if its factories were more distant and interconnected.


Oh and, by the way, I just realized I forgot to add the .pak for the remote server; corrected.

[Nazalassa]

After successively enduring COVID and flu, I am back to business!

Tested airplane convois in r11009. Results:

(the vehicles are offset by 3 pixels upwards, that's normal)

I think I will include "all-in-one" air vehicles, that is, single cars? coaches? idk, that can be used instead of a convoi (i.e same capacity, price, etc.) while convois are still erroneous.

[Roboron]

Interesting, you may be the first to create non-airplanes air vehicles.

[Isaac Eiland-Hall]

And arguably, they *should* be known as, well.... a connection providing data connectivity is a "bus", and this one is in the "air" wirelessly, so it's arguably an Airbus.

[prissi]

I am preparing for a release and I think this is certainly an interesting pakset to include with the installer. As this is the next binary, it would support aeroplane convois to some degree. Is there now a github page or should I just take the link form the forum?

I could also offer you Sourceforge access for the sources and binaries ...

[Nazalassa]

I am preparing for a release and I think this is certainly an interesting pakset to include with the installer. As this is the next binary, it would support aeroplane convois to some degree. Is there now a github page or should I just take the link form the forum?

I could also offer you Sourceforge access for the sources and binaries ...

That reminds me to get pak48.bitlit on top of my todo list and finish all the wireless things. I'll work on it.

I don't have a github page for the mod atm but I guess I can make a git repository for it as soon as I learn how to use git (should be done within a decade or two, if nothing goes wrong). The link from the forums may be the best option until I have done so.