Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New Map Hex Images
#1
New 1 lane and 2 lanes road system for sharing. All images and tileset sample in the zip file. And the reason for all the "N/A hexes", personnel preference for keeping track of my work, just delete it if you don't require it.









Attached Files Thumbnail(s)
   

.7z   Road.7z (Size: 339.87 KB / Downloads: 6)
Reply
#2
Just noticed that the resolution used doesn't align the road properly.
Reply
#3
Just wondering, is there a specific reason why you used GIF instead of PNG?
Reply
#4
Er... I think it's because the original road was GIF. Also I'm using some animated GIFs.
Reply
#5
I like it, will MM auto use these when generating a town/urban area?
Reply
#6
Afraid not, unless you replace the existing road with eithe the single or double lane. Otherwise you will have to build the map yourself.
Reply
#7
Ground road system complete, now with 3 lanes road.. now to the their bridges... PM me with your email address if you want the images.



Attached Files Thumbnail(s)
   
Reply
#8
(03-14-2016, 09:18 AM)BLOODWOLF link Wrote: I like it, will MM auto use these when generating a town/urban area?

That's an interesting and far-reaching topic, actually.

We have two kinds of generic "roads" (normal and with trees around them), SirMegaV adds three more variants to them, and that's just for the "paved road" type. They all need to link together. They all need to link to bridges and pavement. They all should link to gravel and dirt roads (which aren't implemented yet). We also have rails as another feature which should auto-link, but only with itself, in two variants (steel and maglev), which shouldn't link to themselves, and walls as a to-be-implemented feature which should break linkage.

And the data structure is quite a mess.

Let me sleep on it ...
Reply
#9
You will get my vote for dev of the year this year if you can pull it off Big Grin
Reply
#10
After getting some sleep:

* A terrain type has an optional link type (examples: ROAD, RAIL, MAGLEV, STREAM, HIGH_VOLTAGE_CABLE)
** Link types are free-form strings, in a configuration file
** Link types have a priority, default 0
** Link types have a maximum elevation change, default INFINITY (well, actually about 2 billion, but who's counting?)
* A terrain type has an optional blocker type
** Blocker types are configured the same way as link types
** Blocker types also have a priority
* A terrain type has an optional elevation determination value
** Default: Same as underlying elevation
** Option: First value is elevation above (or below if negative) the underlying elevation - see bridges
** Option: First value is absolute elevation (high voltage cables, for example)
* Terrain types are defined:
** by name, like "road", "wall", "pavement" or "cliff"
** by name + value, example "rail:1"
** by multiple such, like "raid,fluff:15" for the ones SirMegaV is making
** For multiple name terrains types, only the first one's second value is changed by the autolinker
* Terrains with the same link type automatically link to each other if the second value is not set.
** The values set by the autolinker are in the range 0-63, distributed as before
* Terrains with a blocker type prevent automatic linking in directions specified by the second value's lowest 6 bits (so if it's 65, the lowest 6 bits are 1, or just "prevent linking north", while the graphic might differ)
* Map rotation and flips detect link and blocker types and modify the lowest six bits of their second values if they are specified
* You're free to use the other 25 bits of the second value for variants, but setting any of them means the autolinker won't touch that terrain

Reply
#11
There's high voltage terrain type? What's the code in editor to call it out?

There's wall terrain type? How come I've never seen any maps with walls? Do you use it like wall:1:00?

I'm quite lost at your explanation, don't understand half of it. Smile

Can you give an example of blocker?

Autolinker range from 0-63? Why are there 68 building images?

I'm free to use the other 25 bits of the second value for variants? Can you give examples on how to use it? And if I use it for a NS road (9), and the autolinker wouldn't touch it, does that mean that MM will not be able to determine that my road should 'connect' to the road above and below even when it does visually?

Reply
#12
(03-22-2016, 02:07 PM)SirMegaV link Wrote: There's high voltage terrain type? What's the code in editor to call it out?

There isn't - it's just something I used since it illustrates the need for both "constant elevation" terrain and the "priority" for terrain types (walls which block roads shouldn't block high voltage lines).

(03-22-2016, 02:07 PM)SirMegaV link Wrote: There's wall terrain type? How come I've never seen any maps with walls? Do you use it like wall:1:00?

There isn't yet, but we need to support it to be compatible with the full TW/TO/SO rule set. Same goes for cliffs.

(03-22-2016, 02:07 PM)SirMegaV link Wrote: I'm quite lost at your explanation, don't understand half of it. Smile

Can you give an example of blocker?

Something like a wall should block auto-linking between roads, as should do cliffs. The map creator would need to explicitly link those to override the blocker.

On the other hand, a cliff shouldn't block a stream (no, we don't have streams yet, nobody made graphics for them), it'd just create a waterfall.

If we'd have a "raised highway" road type, walls and cliffs shouldn't auto-block them.

(03-22-2016, 02:07 PM)SirMegaV link Wrote: Autolinker range from 0-63? Why are there 68 building images?

For variety. The map editor won't use them directly, but you can if you want add them manually.

(03-22-2016, 02:07 PM)SirMegaV link Wrote: I'm free to use the other 25 bits of the second value for variants? Can you give examples on how to use it? And if I use it for a NS road (9), and the autolinker wouldn't touch it, does that mean that MM will not be able to determine that my road should 'connect' to the road above and below even when it does visually?

This is only important for rotating and flipping maps.

What that means is that a north-south connection (9, bitmask: 00001001), if rotated clockwise once, will turn into a northeast-southwest connection (18, bitmask: 00010010), but so will a road with the value of 73 (bitmask 01001001 -> 82, bitmask 01010010), 137 (bitmask 10001001 -> 146, bitmask 10010010), 201 (bitmask 11001001 -> 210, bitmask 11010010) or 2147483593 (bitmask 1111111111111111111111111001001 -> 2147483602, bitmask 1111111111111111111111111010010). You're free to use those values between 64 and 2147483647 (inclusive) for values the autoconnection won't touch, but which will be rotated and flipped properly if used in a map.
Reply
#13
(03-22-2016, 02:30 PM)Akjosch link Wrote: Something like a wall should block auto-linking between roads, as should do cliffs. The map creator would need to explicitly link those to override the blocker.

On the other hand, a cliff shouldn't block a stream (no, we don't have streams yet, nobody made graphics for them), it'd just create a waterfall.

If we'd have a "raised highway" road type, walls and cliffs shouldn't auto-block them.

Is auto blocking working in MM now? If yes, how would the code look like using the *.tileset format?

(03-22-2016, 02:30 PM)Akjosch link Wrote: [quote author=SirMegaV link=topic=2338.msg15689#msg15689 date=1458670027]
Autolinker range from 0-63? Why are there 68 building images?

For variety. The map editor won't use them directly, but you can if you want add them manually.
[/quote]

Sorry.. it's 69 images. Are you saying that the autolinker is working only for building:X:00 to building:X:63, and building:X:64 (NW,N,NE) onwards is just for fluff?

Let me get something right, is autolinker = e.g. the 'thing' that tell MM that both building is connected, therefore when shooting, it's considered shooting from inside a building to inside a building?

(03-22-2016, 02:30 PM)Akjosch link Wrote: [quote author=SirMegaV link=topic=2338.msg15689#msg15689 date=1458670027]
I'm free to use the other 25 bits of the second value for variants? Can you give examples on how to use it? And if I use it for a NS road (9), and the autolinker wouldn't touch it, does that mean that MM will not be able to determine that my road should 'connect' to the road above and below even when it does visually?

This is only important for rotating and flipping maps.

What that means is that a north-south connection (9, bitmask: 00001001), if rotated clockwise once, will turn into a northeast-southwest connection (18, bitmask: 00010010), but so will a road with the value of 73 (bitmask 01001001 -> 82, bitmask 01010010), 137 (bitmask 10001001 -> 146, bitmask 10010010), 201 (bitmask 11001001 -> 210, bitmask 11010010) or 2147483593 (bitmask 1111111111111111111111111001001 -> 2147483602, bitmask 1111111111111111111111111010010). You're free to use those values between 64 and 2147483647 (inclusive) for values the autoconnection won't touch, but which will be rotated and flipped properly if used in a map.
[/quote]

OK.. I kind of understand (45%).  :Smile Anyway, lets say that I have a beautiful NS road and I use it as road:1:73, and since autoconnect doesn't touch anything beyond 63, so MM won't know that it's a road connected to N and S, therefore breaking the BT road rules. Am I correct?

Sorry... layman here...  ;D
Reply
#14
(03-22-2016, 10:32 PM)SirMegaV link Wrote: Is auto blocking working in MM now? If yes, how would the code look like using the *.tileset format?

It's not working, and I have no idea yet. Right now, I'm just musing about the required feature set.

We need to have walls and cliffs at some point in time anyway.

(03-22-2016, 10:32 PM)SirMegaV link Wrote: Sorry.. it's 69 images. Are you saying that the autolinker is working only for building:X:00 to building:X:63, and building:X:64 (NW,N,NE) onwards is just for fluff?

Let me get something right, is autolinker = e.g. the 'thing' that tell MM that both building is connected, therefore when shooting, it's considered shooting from inside a building to inside a building?

The autolinker is the (hardcoded right now) "thing" which links roads and buildings together, using the ...:00 to ...:63 tiles. Conceptually, it has very little to do with deciding which building counts as one, but right now it's rolled together, yes.

(03-22-2016, 10:32 PM)SirMegaV link Wrote: OK.. I kind of understand (45%).  :Smile Anyway, lets say that I have a beautiful NS road and I use it as road:1:73, and since autoconnect doesn't touch anything beyond 63, so MM won't know that it's a road connected to N and S, therefore breaking the BT road rules. Am I correct?

Sorry... layman here...  ;D

Similar as for rotations, road:1:73 will be treated by the game mechanics the same as road:1:9, so it will properly connect, just potentially look differently.

At least, that's the plan.
Reply
#15
(03-23-2016, 12:50 AM)Akjosch link Wrote: [quote author=SirMegaV link=topic=2338.msg15709#msg15709 date=1458700328]
Sorry.. it's 69 images. Are you saying that the autolinker is working only for building:X:00 to building:X:63, and building:X:64 (NW,N,NE) onwards is just for fluff?

Let me get something right, is autolinker = e.g. the 'thing' that tell MM that both building is connected, therefore when shooting, it's considered shooting from inside a building to inside a building?

The autolinker is the (hardcoded right now) "thing" which links roads and buildings together, using the ...:00 to ...:63 tiles. Conceptually, it has very little to do with deciding which building counts as one, but right now it's rolled together, yes.
[/quote]

Meaning that if I use building:4:64 (hardened_roof64) linking north with building:4:63 (hardened_roof63), MM won't know that I should be able to walk within the building from 64 to 63?

(03-23-2016, 12:50 AM)Akjosch link Wrote: [quote author=SirMegaV link=topic=2338.msg15709#msg15709 date=1458700328]
OK.. I kind of understand (45%).  :Smile Anyway, lets say that I have a beautiful NS road and I use it as road:1:73, and since autoconnect doesn't touch anything beyond 63, so MM won't know that it's a road connected to N and S, therefore breaking the BT road rules. Am I correct?

Sorry... layman here...  ;D

Similar as for rotations, road:1:73 will be treated by the game mechanics the same as road:1:9, so it will properly connect, just potentially look differently.

At least, that's the plan.
[/quote]

In order for me to use beyond the 00-63 tiles, I must first know what numbers represent which directions. I think that is quite difficult for me unlike the current system where I can just click my exit in the editor. Not forgetting about the little number display after selecting the exits is kind of small to display more than 1 digit.

Need your suggestion. I have 3 sets of heavy buildings. What is be the best way to keep the current design and add 3 new heavy building sets without using 'fluff:XX' (I'm using it for other things) and 'theme' (I need the existing themes). I kind of have a solution, but its not perfect.
Reply
#16
(03-23-2016, 02:29 AM)SirMegaV link Wrote: Meaning that if I use building:4:64 (hardened_roof64) linking north with building:4:63 (hardened_roof63), MM won't know that I should be able to walk within the building from 64 to 63?

It's ... complicated. Way more complicated. Essentially, MegaMek scans the whole map on loading and tries to group building terrain into buildings according to its own, internal, error-prone, hard-coded rules and later on uses this assembled data to decide what constitutes a single building and what doesn't. It might work, it might not work, just playtest your map if you're not sure.

Explaining it all in detail would take literally hours of my time just to pour through the code to make sure I got everything right and has nothing to do with autoconnecting roads, so I'll just leave it at that.

(03-23-2016, 02:29 AM)SirMegaV link Wrote: In order for me to use beyond the 00-63 tiles, I must first know what numbers represent which directions. I think that is quite difficult for me unlike the current system where I can just click my exit in the editor. Not forgetting about the little number display after selecting the exits is kind of small to display more than 1 digit.

So don't use those numbers. They are there if you want to use them (but not directly accessible from the GUI), and they don't matter if you don't want to use them.

(03-23-2016, 02:29 AM)SirMegaV link Wrote: Need your suggestion. I have 3 sets of heavy buildings. What is be the best way to keep the current design and add 3 new heavy building sets without using 'fluff:XX' (I'm using it for other things) and 'theme' (I need the existing themes). I kind of have a solution, but its not perfect.

Use "fluff:XX".

That's what it is there for: Graphical variations without gameplay changes.

Take note: The current "road:2" is an error and will be changed to something like "road:1,fluff:20" at some point in the near future.
Reply
#17
(03-23-2016, 03:27 AM)Akjosch link Wrote: [quote author=SirMegaV link=topic=2338.msg15717#msg15717 date=1458714566]
Need your suggestion. I have 3 sets of heavy buildings. What is be the best way to keep the current design and add 3 new heavy building sets without using 'fluff:XX' (I'm using it for other things) and 'theme' (I need the existing themes). I kind of have a solution, but its not perfect.

Use "fluff:XX".

That's what it is there for: Graphical variations without gameplay changes.

Take note: The current "road:2" is an error and will be changed to something like "road:1,fluff:20" at some point in the near future.
[/quote]

Thanks. Will keep that in mind.
Reply
#18
One potential issue with fluff that SirMegaV has pointed out to me via email is that fluff doesn't easily support multiple types per hex.  You could imagine creating a tileset of "building modifiers" and you may want to combine several of these fluff building modifiers in one hex.  To do this, you would need to create a unique fluff level for each combination.

A more concrete example based on some images SirMegaV had sent me... Lets say you've got a heavy building as the base image, then you want to superimpose a "faction symbol" on top of that building, using fluff.  Then maybe you've got another fluff image for a building-top tennis court, or a some HVAC equipment.  If you wanted to combine 2 or more of these fluff images together, your tileset would need to have a unique fluff entry for each combination.

There are some limitations to the current system, that I don't think were ever really considered in the riginal design.
Reply
#19
(03-23-2016, 11:56 AM)Arlith link Wrote: One potential issue with fluff that SirMegaV has pointed out to me via email is that fluff doesn't easily support multiple types per hex.  You could imagine creating a tileset of "building modifiers" and you may want to combine several of these fluff building modifiers in one hex.  To do this, you would need to create a unique fluff level for each combination.

A more concrete example based on some images SirMegaV had sent me... Lets say you've got a heavy building as the base image, then you want to superimpose a "faction symbol" on top of that building, using fluff.  Then maybe you've got another fluff image for a building-top tennis court, or a some HVAC equipment.  If you wanted to combine 2 or more of these fluff images together, your tileset would need to have a unique fluff entry for each combination.

There are some limitations to the current system, that I don't think were ever really considered in the riginal design.

You don't need to dig particularly far to find severe limitations with the current building system. Just try to recreate the building graphics in page 125 of TO.

Sadly, I have no clever ideas in regards to building graphics (or multiple bridges crossing each other either, for that matter). None which wouldn't demand that the current map format be scrapped, at least.

Roads and walls are easy in comparison ...
Reply
#20
(03-14-2016, 10:27 AM)SirMegaV link Wrote: Afraid not, unless you replace the existing road with eithe the single or double lane. Otherwise you will have to build the map yourself.

I would replace the existing roads with yours.  I at least would replace the:

super * "road:1:62" "" "boring/road62.gif"
super * "road:1:63" "" "boring/road63.gif"

super * "road:2:00" "" "fluff/road_trees_00.gif"
super * "road:2:01" "" "fluff/road_trees_01.gif"

"road:2:01" "" ...... set with your double lane roads since I dont like the roads with trees stuff.  Even if yours aren't built the same as in the data/hexes/fluff folder i can just resave them to what image they would match for the original tileset.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)