MayorBean

Since the ingame stoplights on road intersections are not very common to me I started to alter the relevant type 21 exemplars. Preview -- Road_IntersectionStr_Stoplight11 Some questions before going to all those 45 exemplars I've found: 1. Does something like this already exist? I haven't found anything on the STEX or in the forums. 2. Does anybody know about changes to the road intersection exemplars from SC4 to RH? I don't have RH installed yet. 3. I noticed that stoplights at diagonal intersection aren't animated (stoplights showing up green lights for every direction). Since the automata acts as if those stoplights are working, this is only a visual issue. Are there any fixes for this? Does it appear in RH, too? 4. I'd like to know about the look/position of stoplights in European countries. If I remember correctly, the position as shown in the above preview can be found in Austria, Belgium, Denmark, France, Germany, Italy, Netherlands,(...?...). Please correct me if I'm wrong. Thanks in advance ~bean~

Inspired by joerg's approach and since I really need something like this for my current region I revived my surface water project. I suspended the work on this MOD months ago, because I had no idea how to realize 'overland' bridges and ferry routes were not even on my mind (only plain SC4 when I started). Anyways, recently I found a Simtropolitan with BAT skills supporting this project by doing the essential BAT rendering. He's the one to be credited first - thank you Monteferro! Also thanks to gizmo28 for offering assistance for effect dir issues and J.O. and joerg for providing the basic idea. Well, here is a *very* first impression of what I'm working on: http://img164.exs.cx/img164/8831/surface490x903tm.jpg width=800 align=baseline> MB - SFM - img01 - first impression I'd like to give some rules for posting in this thread: 1st: Please don't post plain eek, totally bad... or wow, cool... - just write a PM in that case. 2nd: I really appreciate *any* kind of constructive criticismn. 3rd: Feel free to post your ideas. What do YOU need? Maybe it could be integrated... 4th: Avoid image quoting! There is no need to repost images. Just refer to it by naming the author and posting date/time. What I'm currently thinking about - 'pipeline': - water texture switches automatically to ingame water/custom water (provided by joerg or timotheus) - surface water provides some effects like sparkles - I have no quite good idea on how to realize wave effects, yet, maybe do something as time goes by... - this MOD is designed as 'advanced users only' MOD since there are some really tricky requirements regarding terraforming... ---------------------------------------------------------------- This 1st post will be updated if major changes are made to the MOD. ChangeLog V 0.0 alpha 0 [12/02/2005] ---------------------------------------------------------------- ~bean~

I'd suggest #2 for athletics and #5 as water sports arena. ~bean~

I second TPP - cycledoogs Columbus Terrain Mod. Awesome! ~bean~

Well, since I got aware of those tricky things on how to assign correct IIDs to custom vehicles, I tried to contact those recently known ST automata geeks to get a way of 'compromise'. (I never thought that a simple automaton may conflict with the NAM someday - but it might do...) So, here are my ideas on that stuff: 1: Let's use a (probably) secure IID range 0x63wxxxyz for all future automatons (and automata props) 2: Let's use a kind of group coding for different automata types. I'd like to suggest the following: w=0 -- reserved for shadows, light cones, flash lights and additional stuff w=1 -- cars & bikes w=2 -- trucks & semi-trailers w=3 -- public & pedestrians (e.g. taxis, ice cream vans, MayorBean walking around) w=4 -- civic land vehicles (police, ambulance, post, school busses) w=5 -- busses w=6 -- passenger heavy rail (engines & coaches) w=7 -- cargo heavy rail (engines & coaches) w=8 -- heavy rail checkers (engines/coaches) w=9 -- elevated rail (engines & coaches) w=A -- monorail (engines & coaches) w=B -- subway (engines & coaches) w=C -- GroundLightRail (engines & coaches) w=D -- aircrafts/airborne vehicles w=E -- water vehicles (ships, boats, surfers, submarines,...) w=F -- reserved (maybe SimMars vehicles and other stuff) 3: xxx for vehicle models - a 3 byte range per vehicle group (up to 4096 different models per group) 4: yz - defininig the number of skins per model including day/night difference. All even z are day models, all odd z are reserved for night models => up to 128 different skins per model. So, what do you think about this? I hope this will turn into a very contructive discussion... ~bean~

Here's a kind of template how the STVR Excel sheet may look like (see attachment). Also I did a 'common supplies' FSH that could be shared by most (land-) vehicles: 1st row - head/rear lights 2nd row - flashlight 3rd row - undercarriages 4th row - shadows ColourMap AlphaMap alpha blended thumbnail

Ardecila - thx! That is just what I want to establish - the same IID for each automata model - regardless of filetypes... I'm currently working out a possible database (based on excel due to ST constraints)... ~bean~

Well, to get more clear on what I'm thinking about: When I got my idea of a new bus/truck automata series (like SAC's) I had a look on the simcity dat files in order to find an IID range where those stuff could be organized (to avoid confusion with almost random IID stuff). I thought, the 0x55nnnnnn range would be good, since no ingame is located there - well, I failed somehow - the NAM makes widely use of the complete 0x5nnnnnnn range. I also noticed, the way how skins (materials) are assigned to s3d models may cause conflicts somehow - I once created a vehicle that was skinned with grassland, though there was a proper vehicle skin around - very odd... So I came up with the idea to create such centralized ST vehicle registry. Main goals: - One thread/table/database(excel) where you can browse several different vehicles and choose, which to use (something like a great dealership) - anyways, the files will be stored/rated/downloaded on the STEX. Just a kind of catalogue where you can look for creator, model description, pics, possible conflicts... - A place where automata creators can request specific IID ranges to develop there vehicles in (like geoffhaw's texture index) - A place where new models could be requested, without opening hundreds of threads for individual request. - A thread where tutorials/howtos are published. To make automata/automata props development more 'efficient' I suggested the type coding (read above). I also think, an automaton should consist of the following files: one automata exemplar, one prop exemplar, one daylight model, one nightlight model (optional), one daylight skin, one nightlight skin (optional) - all files share the same IID (day/night differ by the z-value). A shared FSH for shadows, undercarriage, lightcones could be supplied as base for all vehicles (red/green/blue flashlights, blueish/yellow front light cones etc). But before to start at this topic, I'd like to get some things clear: - is there *any* known reason, not to use the 0x63nnnnnn IID range? - is the vehicle type list complete? - is the capacity (4096 models per type, 128 different skins per model) sufficient? (well, I think that may do...) - should we enlist any older models (from Trolca, mikeseith, ardecila, oppie et al) without IID conversion? Well, post your opinions on this... ~bean~

@ardecila: hmm, willing to join, anyways?

Hey mike! I thought to discuss things first... (uhm) - I'd really like to sort things out before publishing anything is this range...

@Swamper: well, I'm already aware of that. It's just an suggestion - and I think, it should be in a separate range... @garfiedude: k, you're right. But I don't know any automata model in the 0x63xxxxxx range. Also Trolca and Ardecila have their very special way of numbering (and it might be nearly impossible to renumber older/existing models). It's an idea on how to proceed in future... ~bean~

*lol* - you may have to check the material settings and the texture itself. Also do you use a FSH larger than 256x256? ~bean~

Shadow: PMed you. I'm already working on a kind of tutorial.... Patience is your friend ~bean~

Maybe this is of interest, though it also might be a random problem: When I did my bus model, I started with a copy of a plane billboard which has only one group(first try was to add all vertices and dependand values in the reader by hand *uhm*). Well, soon I installed a demo version of 3dsmax for easier modelling and skinning. My bus model is build up of 7 'planes': top, bottom, left, right, front, back, shadow. When I first imported the 3ds file into the reader, the reader correctly added a new group per plane. But the values seemed to be messed up. Especially the group assignment table (reference to the vertex-, index-, prim- and mat-block) contained 65535 (max Integer) or negative values very often so I guess an overflow problem in the reader's import routine. After manually fixing that (the values, not the routine *lol*), I was able to add/move/delete vertices in 3dsmax and reimport the modified model without any problems. As far as I don't add/delete another plane. ~bean~ BTW, ardeclia: if you have a hint on a pivot point tutorial, please PM me. I seem to need such knowledge for articulated busses (yes, they work so far 'somehow'). Thanks in advance!

Date: 5/15/2005 6:50:22 PM Author: GoaSkin A request by me is a Y-stack for railroads (like the avenue-Y-stack but for railways). MayorBean wanted to try working on that but I think nobody from the SFBT has the experience to create complicated puzzle pieces like this. quote> Huh? Seems I've missed something?! I'm pretty sure I never mentioned to do something on rail Y-stacks. Since working on puzzle-pieces and all TE stuff is off my capabilities. There might have been a suggestion, though I already can't remember that. Anyways, great stuff with the ramblas. You may attach the textures, so I may have a look on it. Although, I'm somehow short on time ATM. ~bean~

Thx, boggy! *lol* Well, my first approach on that auto-switch was to assign the same group ID to the PROP's S3D-models as it is used by the terrain textures (0x891b0e1a). That already works for the water surface (water colour). Now I encountered a problem with the water floor. The ground for shallow water has the IIDs 0x00000014,0x00000114,0x00000214,0x00000314,0x00000414. For zoom level 1+2 there are some network textures sharing the same IID (114,214). Although they have a different GroupID, SC chooses them to use (which, of course, looks really odd). It seems, that SC grabs that texture with the lower GroupID first. So: does anybody know, if the comlete material TGI is stored somewhere in the S3D file? Browsing the hex code lead to no result so far. I only found the IID value in the code.... *darn* ~bean~