very simple to combine the two into a universal build.
lipo -create sim-i386 sim-ppc -output sim
will merge the two (or more) specified binaries into a single universal one.
I wrote a 'deploy' script and modified the configuration files to support a few extra variables so a single script could build both binaries in a two p**** compile process, then merge them.
the above lipo command works on the mac, no idea if its present on anything else
can blender output to .pov files? or is there a converter?
thinking since pov has a variable that can be set on the command line, and since its input is pure text files its reasonably simple to use 'sed' to adapt files prior to rendering
anyone know a way of opening a blender file, and changing paths of loaded textures, form say "G:/path/file" to something like "/users/leopard/documents/blender/project/file"
got some old blender files from my PC days that won't load right now, and a simple search & replace in the file doesn't work
cable... 18 month contract also, ****uming the house is wired already. if its not forget it, chances are minimal.
not to mention I've had dealings with the f**kwits before, and won't touch them again with anything other than a club with a nail in it. the only company ever to make BT look competent, even worse than British Gas...
not exactly a huge move, a few miles at the most, just going rented, and not willing to sign up to an 18 month contract with BT with a 6 month house rental contract.
can play on the forum with an iPhone but won't be able to post stuff with it, or sadly download anything
sadly I won;t be on line much longer, a house move will knock me off line in any serious way for a year or so probably, I hope to get a 3G dongle whatsit but won't be right away. I will be grabbing a snapshot before I vanish though, to play with.
I have a grounding in basic C, and am slowly getting better with objective-C (I run an apple mac c++ doesn't get much use here)
having said that I have written a reasonably powerful (and modular) script language in vb.net, and am about halfway through porting it to obj-c.
what I don't have is enough of an understanding of the way the game is structured to make this work.
it did occur to me that another way to handle this would be a special stop cl****, which 'captures' anything that visits it until a preset time before letting it go. thus allowing the idea of stabling sidings or a parking lot to be implemented without anything complex.
I'm still considering this one, Having added a hook or two into the core code I've got a few ideas as to how such events could be managed (essentially its just a case of expanding the code for loading/unloading, which should trigger at a stop) to call another function and p**** it a string (the script).
in thoery not too hard to do, in practice well you know. it depends if you need logic of a simple linear script (i.e. do you need 'if' statements)
its a case of tagging a text field into an object that the user can place a 'script' into, and having something that can process these scripts within the object cl****.
having written a script language for another project its not that hard, though its not fast (so you'd want to limit it to a few units where its needed, i think requiring the user to enter them will manage that)
then its a case of adding the 'triggers' somewhere, thats the harder bit.
still thinking about this, the potential is amazing, in some circumstances, but only in some.
the hard bit is allowing the script to 'see' the game envirnonment not strictly required but useful, the simple time based events would help hugely though and would be theoretically easier. have increments of say 1 hour, every 'hour' the vehicle object gets a prod to run the script, and is given the hour as a parameter, if the script is set to work on that hour its fired.
as a simple way of saying "go to sleep until the time is 'x'" this is very useful, even in the standard schedule system, e.g. a destination waypioint/station instead of getting a minimum load paramter (or in addition to it) could have an hour added, so the train pulls into a station, and will not leave until the hour is equal to a preset value (or values) forcing a delay and allowing some basic schedulling to be handled
that would probably be easier than a full blow event scripting system and provides many of the benefits.
thinking specifically for low density routes, as a way of forcing a train to wait a while at the end points, but after a set time to move, regardless of the load. allowing a more optimal usage of the investment
oh the point about city chaos was simple, I though road cars were generated by p****engers who were unable to travel by public transport. hence a naff transport grid = clogged roads, not a deliberate feature just a result.
the hard bit would be making these p****engers fickle, so they don't wait too long, otherwise you just geta buildup you can handle over time, which isn;t the point.
the goal being to emulate the way people move trying to get to and from work, the road traffic is a result, not the point
pakritain is where the basic idea came from, was thinking about this a while back when I did my original somewhat cartoon like voyager. needed to do five vehicles, specifically so you could have a four or five car. but no more.
later thought more about it as a way of requiring brake vehicles for some types of stock. the 'logic' of a braking system could be vastly more complex, but while adding reality wouldn't add much to the game play (i.e. adding a brake force calculation).
but its a good way of ensuring something with three link only connects to three link, instanter to instantor, screw to screw, knuckle to knuckle etc.
e.g. you could define many types and colours of MkIII coach, all basically defined as a MkIIIb HST stock vehcile, a Cl43 powercar can connect to any of them, and they connect to each other, without the huge constraints file, and needing to update it whenever a new graphic goes in. but these vehicles are then locked out from anything else
likewsie MkIV stock only ends up behind a Cl91
some goods stock only behind a Cl66, and the Cl66 itself only able to haul certain types of wagon etc.
plus it makes it a little harder to put a Cl66 in front of a m****ive rake of older (cheaper) freight stock where in practice it would probably pull the first vehicle apart.
thinking the easiest way would proabbly be to add wildcards to the constrain system, e.g. you require the next vehcile to match a pattern: MKIIIb* or TL* (three link)
this may be easier than changing the code in a more detailed fashion, essentially add the '?' and '*' wildcards. specifically since this shouldn't effect the current pak files at all, but offers options for newer ones
oh its def not sim city, this is worth the space on the hard drive *ducks*
jut thinking for a simulation, well the commuter rush is a key part of moving people, the challenge being to make money doing it, and not to stuff up moving goods round.
would suggest a 'flag' to turn something like this on/off
constraint 'cl****es' so you can specify exact vehicles as at present.
or could specify a 'cl****' e.g. "p****enger-brake", "goods-brake", "fitted-goods", "unfitted-goods", "fitted p****enger" etc
essentially defining the type of physical coupler present, as well as providing a way to state that freight vehicles need a brake van at the end (for early vehicles) but not bothering about the type.
thus a freight vehicle can be set to require either any other freight vehicle or a brake van, without having to specify every possible combination as at present.
speaking as someone with a moderate collection of kits for freight vehicles, with a definite LNER bias I can say I await this with interest. managed a few blender type building a while back but never got a vehicle to work properly.
considering having a go though.
the brake van idea is a good one, the way to handle it properly however requires some semi detailed physics to be considered (i.e. a change to the engine) e.g. defining a default 'brake force' equal to a vehicles weight, this providing the default braking. a lower total brake force providing a slower deceleration, hence slowing down earlier. hard to do properly.
constraints get annoying however, its easy for block trains to say a vehicle is followed by another one of the same or a brake vehicle. but this makes mixed trains difficult
I would suggest the easy way to add brake vehicles, is to give them a low cost, and a low maintenance cost, essentially they just take up space, but cost little, i.e. "eye candy" but not much more.
thinking of having a go with blender again, I currently have a partly ****embled kit of a brake van like that on the bench, but thinking an actual van may be more useful.
bauxite coloured body = express freight, meat etc white coloured body = chilled goods grey coloured body = non express goods, crates etc
ideally will need several versions of each though, but with minimal graphical changes, maybe slightly different roof colours or a stripe of colour (not prototypical, but on the prototype you could read the writing on the side :-) ) to identify the basic goods type.
thus allowing a grey (unfitted version, cheaper but lower top speed) and a fitted (more expensive but faster) version of the basic types.
busy this weekend, but away from home next weekend, so will have some time to play.
only issue is remembering to take my external mouse, blender on a macbook (one button) is a pain. may just play in GIMP
but in blender thinking two ch****is lengths a basic box and a roof is about all it needs, cattle wagon just has a slightly different body type. otherwise the model is basically the same.
suggest adding a system of trigger events and actions.
e.g. a vehicle gets an event trigger when it enters a stop, and when it leaves. the event being notified what the stop is
e.g. a time based event similar to 'cron' which could be used to enforce a schedule of sorts in some areas.
something that could be added to any vehicle or stop, but as an option. essentially adding a very limited player controlled script language.
purpose: allowing some vehicles to act with a degree of intelligence, e.g. a train enters a station, unloads and is then routed to a waypoint, where it will stop (a stabling siding, maybe a seperate station that never loads anything) here it waits until a time trigger routes it back to the station (maybe by removing a minimum load criteria holding it somewhere it can't load) thus allowing p****engers to build up, without hogging a platform.
e.g. a bus operating a schedule where by as it enters a certain stop, it will wait until an event trigger releases it
this allows better use of a limited number of vehicles, and allows a 'commuter' type service, with some units operating part time, and spending the rest of the time stabled out of the way.
envisaged as a pure option, that would only be used on some units in special circumstances, but allows a vastly more flexible operation scheme to be devised
this bit may well be my fault, I think I added that bit, well at least I added the two audio files. should be possible though for someone to sort that bit out with a command parameter, when I compile here (on a mac) I use a seperate batchfile to call the make script (since the single file has 'issues' building for both PPC & Intel, i.e. building two binaries)
suggested solution, split the BACKEND=cocoa option in the config file to two seperate sections
BACKEND=cocoaqt BACKEND=cocoasdl
or just add an option thus MACAUDIO=quicktime MACAUDIO=sdl
?
and the relevent options in the makefile to use these parameters?
there is theoretically no reason why not to a version of the experimental build. there are two ways to do it, one is the way i currently manage this, which is essentially manually patching a few files and adding a couple of new ones, then running a build script. since the build process has to be run twice (once for intel, once for PPC) then combined. this uses a slightly adjusted makefile, but could in theory be applied to the distro one. with a seperate build script to call it twice (and set a few variables)
the second would be to adapt this build process to the 'standard' simutrans build, which should work very well, but wouldn't have the extra bits I've added. its probably worth me sorting that out, since then in theory anyone with a mac can build it.
note OSX does not generally cross compile on other platforms very well, apple don't support mac development on anything other than a mac (understandable, but still daft)
I my be going off the net for a few months middle of the year so don't want to get too deep into the development process just yet (since i'd have to drop out) but I can post what i've managed so far, along with some of the logic behind it to try and make the OS X version a very simple compile for anyone else
Now working correctly, few issues to do with getting objective-c to talk to c++, and vice-versa
now have a cocoa window, with a slider. adjusting that slider sets the zoom in the game window, that bit was reasonably simple. it doesn't do it by simulating keypresses though, it calls set_zoom_factor(); directly with a suitable value. this bit was reasonably simple.
the fun bit was getting simutrans to call an objective-c routine, so that when you use the '<' and '>' keys to zoom in & out the GUI slider moves to show the current zoom level.
if any one is interested this will be posted, along with source code, next time I put this up. but there are one or two other bits I want to polish up first. the mothod is actually very simple.
create a basic "c" file, not c++ or objective-c, in this put a few simple functions. simutrans calls these, which then call the objective-c. this works both ways, hence simutrans thinks its calling a "c" function and doesn't know about the objective-c or cocoa bits.
I don't have the resources to do it, but this would allow for example a similar interface to the windows GUI to be implemented. it would also allow code in other languages to be used, e.g. maybe visual basic?
anyway this is what it currently looks like, the comp**** (which needs a new graphic) provides eight way scrolling via mouse clicks
part one working, i.e. a GUI with a slider that can set the zoom level in a nice friendly way (not that I have anything against a keyboard interface, but I'm using a laptop)
oh the joys of getting objective-c to talk to c++, they get on like a house on fire, people screaming, running for cover etc.
essentially I'm calling "set_zoom_factor(int z)" directly from the sliders event handler, it works, maybe not the best way to handle it but it works
thanks, i'll have a look, calculating the zoom isn't an issue, I hope. just thinking of a GUI slider to adjust it, which would need to know if anything else alters it, so it can update.
simply calling a method to poke the slider to find out what it needs to show whenever the system changes is more than enough. I shall have a fiddle.
****ume, for the sake of argument, that some nitwit wanted to be notified whenever the screen zoom changed.
nothing fancy, just where is the relevant keyboard event handled?
thinking the main event loop, which I've not yet found, that handles the keypress, so if I, sorry a nitwit, wanted to put a notification hook to a custom function when the screen zoom level changed they could work out where to put it.
also is the current zoom level, or scaling factor held anywhere in an object, or simple variable (in the case of an object so the setter could gain the notification 'event')?
asking since I'd like to replace the 'zoom in' & 'zoom out' buttons on my navigation window with a slider, wouldn't be too hard to make that work to set the zoom level, its just altering it when the game changes it, i.e. the feedback.
as an aside where is the main event loop than handles keypresses? since other feedback events could be inserted.
I've had a scan through the code but not found anything obvious, sadly I speak German with the skill of the average English nitwit (i.e. not at all), and despite a recent trip to Holland indicating just how many Europeans speak multiple languages my lingustic skills are still limited to growling...
Love the coronation rake, been thinking of adding the real model of that to my loft lot, bit it works out about ten foot long :-o
Not sure if there was a triple in it, thought it was four twins and the obs car. Not that it matters, there was a triple in the flyingscotsman rake. Along with a hairdressing car ?
The first cl**** "mail" idea is interesti g but screws using mail as mail at the same time.
If the idea of a catering car boosting revenue on long journeys goes in most of this idea isn't needed since it will have a real effect anyway. May I suggest journeys over a different lenght get a bonus with sleeper cars?
As for it being a factory chain, not sure if player objects can be consumers, if they are mobile consumers would be a. Nightmare of course a station based catering centre is possible, as are a few station concessions, taking space but raising cash.
The idea here was to keep it simple, while providing for graphics that could be used for a later expansion
we having the game engine support the idea of 'first cl****' for both p****engers and goods would be ideal (e.g. they will only travel in 'first cl**** vehicles' and maybe require total journey time less than 'x' and with a lower maximum number of changes - i.e. worth more but more trouble to deal with) I'm trying to avoid changing the game engine for something basic. i.e to justify adding different types of coaches, specifically 'first cl****', 'composite' and catering vehicles all of which would generate higher revenue per seat, but with fewer seats. without requiring the game engine to actually care that the p****engers are different.
the parameter in the dat file isn't actually needed this way, you just frig the maintenance cost so the overall effect on revenue is the same. the downsides are as follows:
1, possible balance issue for shorter trains being all first cl**** if the stations are already present 2, unused/empty trains are less of a penalty
both of which can be offset to a degree by making the higher cl**** vehicles more expensive to buy initially. so you buy them where they will be needed, the goal being that after maybe 6 months the difference is paid off by the higher revenue if the utilisation is high enough. low utilisation and they never really make any extra cash.
the issue tends to be kitchen cars that historically had very few p****engers (if any) but this can be handled by having a required seating vehicle adjacent and splitting the differences so to speak.
note this idea only came about while thinking about articulated coaches, specifically the LNER kitchen triple and how it could be included (since one vehicle has no seats).
btw will be moving this year, at which point I will be on a 3G access thing, so still able to play just maybe not as able to host. I will however finally get a sodding desk and dig my mouse out & start actually making paks once more.
Been thinking for a while how to have several cl****es in simutrans, without breaking anything. See what you think.
Standard coach, x seats, y maint cost produces z revenue per km First cl**** coach has fewer seats, but needs a higher revenue per km so drop the maint cost. The penalty for this is the lower number of seats. Hence a need for a longer train to move the same number of people.
Thus if you have a station say four tiles long you could have a loco and seven standard coaches for max capacity. But on that loco be five coach long distance train you could now have a pair of first cl**** coaches
This also allows catering vehicles, composites etc to be added. You can set the number of seats and the maint cost, hence the cost per seat per mile. So the revenue from these vehicles per p****enger is slightly higher at the cost of reduced capacity.
This needs NO changes to the game, just to the pak files and maybe graphics.
While it seems a fiddle to just use first cl**** coaches to get more money, you end up having larger stations so in reality a mixture is better
the way to get round the pak issue is to have one machine designated the 'master' with the ability for the others to request paks from the master as required. hence everyone gets the same stuff, and one person gets to decide the set. essentially you have one person setting up a scenario and others playing it.
?