![[de]](/mwf/flags/de.png "Germany")
But those are quite limited.
Say a number. Edit: Of different redstone traps i should name :D
![[cr]](/mwf/flags/cr.png "Costa Rica")
![[no]](/mwf/flags/no.png "Norway")
Why? I dont see a reason why as long as there are no script errors. Are there? I mean, it doesnt matter too much at this point anyway as it is still unfinished/experimental, so why invest energy in moving it around?
Yeah, it's okay, but you still have to do some adjustments because the crossing's code is a little bit hardcoded here and there.
So I sourced out the CableStation library, and I am fiddling around a little with automated deliveries, if someone is interested I'll push a serie of commits to bitbucket soon.
Regarding reworking the pathfinding. What kind of solution would be preferred, I could implement something analogous to the power system - which is a dynamic system rather than static. But might be somewhat more resource intensive. With the current system though it isn't even possible to check whether a lorry is even on the network. And the system also fails if a connection of the network goes missing even if there is another path available. Some suggestions are welcome.
Regarding reworking the pathfinding. What kind of solution would be preferred, I could implement something analogous to the power system - which is a dynamic system rather than static. But might be somewhat more resource intensive. With the current system though it isn't even possible to check whether a lorry is even on the network. And the system also fails if a connection of the network goes missing even if there is another path available. Some suggestions are welcome.
Currently working at the pathfinding. Especially to conquer connection losses. Might take two weeks.
Okay, some more information than a "I'm tired right now"-post ;)I'm interested in your commits, especially because I'm working at Library_CableStation, too. I will rework the way the pathfinding informations (aConnectionList, which I renamed to destination_list) are collected. The basic principle will stay the same. As I said, I'm also working on connection losses.
Some things I wanted to implement according to the pathfinding; for pre-implementing purposes I will give you the intended scrupt functions:
- A lorry knows where it wants to go (destination) ->
GetCableDestination- A lorry knows where it comes from (origin) ->
GetCableOrigin- A lorry knows where it is (rail target) ->
GetRailTarget - this actually exists, returning a cable or a crossing- You may give the lorry a destination command (
SetDestination - existing will get a new parameter object origin) which starts the lorry. Providing origin will give you the possibility to have the lorry returned on arrival (new, third parameter to SetDestination bool return_on_arrival)So here are my thoughts on the automatic delivery system:
- A lorry does not need to know the path it must take to reach the destination
- When a lorry conquers a crossing (crossing is my generic term for crossing and stations, the difference is that stations may be selectable destinations for the player) it asks which waypoint to take next to reach the destination
- Two possibilities now: it gets the waypoint (moves on), it gets nothing (see Failsafes)
- To give the lorry some kind of delivery command, you may use SetDelivery (or whatever names suits you). I think of two possible applications: deliver ID or deliver object (ID means drop everything of this kind), the building should provide the accordant objects
Failsafes:
Destruction of cables is a serious thing. A lorry may want to reach a destination which is no longer in reach. We could make it return to the origin. Happens to be there is no origin or the origin is out of reach, too. This is as well a pathfinding worry. The lorry could fall off or so...
Furthermore on how I concepted the system (you may differ of course):The delivery is on demand. A guiding example is the auto production from CR's Clonk.
Initial situation: The player goes to production building x (e.g. forge) and wants to produce a sword.
A sword needs one piece of metal (simplified).
The forge does not have any metal nor has the clonk.
But the forge is connected to the network, so it starts the search for material in the network.
The search
This is the easy part. Cycle through destination_list and distinguish between two types of buildings: Storage & Producer
Ask every waypoint the following two questions: Are you a storage (IsStorage)? Are you a Producer (IsProducer)?
- If it is a storage, look for metal. A storage has always high priority because the material already exists.
- If it is a producer, ask whether it produces metal (IsProducerOf), if yes, save it for now
- If it is a producer, ask whether it already stores metal, list it as storage
Save the distances to the stations as well, destination_list already contains distance information (I created something like a local constant "const_distance", I try to push it asap, so you may use destination_list[x][const_distance]). Short distances are preferred of course, so determine the closest storage/producer.
If no storage is available, you need to know whether a producer is capable of producing metal. Call the producer let it do the same routine but for the production materials (I assume the producer is a foundry, so it needs fuel and ore). The foundry now checks the same storage/producer stuff, asking for say wood and ore. Let's say there is a storage containing these two objects. The foundry gives a positive respond.
The current state is: metal is needed, metal is not available, metal can be produced, the raw material is available.
Now start off the managing. For this we may postulate the following:
- A cable car which is not at a station is moving through the system, so unavailable for our job.
- Checking whether "I have a cable car" by anything means looking for an idle cable car currently idling at my position (cable car -> GetRailTarget == this)
I imagine three different methods:
1. Centralised system
This attempt focuses on the epicentre of the command stack. This is the forge. Check now whether the forge is provided with a storing (there may be cable cars which are incapable of transporting objects in the future) cable car. The forge calls the foundry, giving it a pointer the cable car. The foundry now commands the lorry to the storage, commanding it to acquire wood and ore.
You need to implement some kind of command stack for this otherwise the cable car will make two rides, one for the wood and one for the ore - this is also possible as kind of low tech approach.
The lorry starts off, delivering stuff to the foundry after acquiring, the foundry procudes and then delivers to the forge. Job done.
Pros of the centralised system: Only one cable car is needed.
Cons: Very slow in complex situations (make of the one storage containing wood + ore two and it take quite a lot of time).
2. Decentralised system
With this the forge does not need a cable car at all. But the foundry and the storage do. The forge does not send a cable car but the foundry checks whether itself has one, so does the storage. If not the whole process fails.
The storage starts, sending its cable car with wood + ore to the foundry, it returns after the delivery is done.
The foundry produces metal, then sends its car to the forge, the car returns afterwards. Job done.
Pros: Faster than the centralised system.
Cons: Probably needs lots of cable cars. You may call this a pro, because settling is kind of a process and not every building is part of the automated system by just attaching a cable on it. Automisation then requires some effort.
3. The Mix
Mix the two systems. Make it dynamic. Cable cars at the origin are always preferred over one at the destination but if worst comes to worst the destination provides its own car.
Epilogue:
I would strongly advise to not use any idle car in the whole system. Because these a player may have placed there for a reason. E.g. another player starting a job should not be able to steal his car away. If we may come to the conclusion that nobody wants idling cars somewhere for a reason we can change this. Than every car on the network will be available for every job.
Consider some kind of flagging system. Delivering every object may take time so make sure other cable car do not steal them away. A job marks every needed object down.
So my current implementation differs a little(or more depending on the viewpoint) from what you described here. Let me first comment on your example sword-forge-foundry, the method you described would take quite a while for a sword to produce, the main reason being the foundry still having to produce the metal. So in my implementation currently the foundry automatically produces metal whenever there is ore and fuel available. The secondary production buildings are rather controlled by hand, i.e. have a production queue to which the player can add specific requests.
Regarding requesting cable cars: I am in favour of a decentralised system there, my current implementation allows producers to add requests for objects to a cable car. Because the lack of finding a decent cable car currently, that is just any cable car, but in the future that would be the most suited cable cars. One could even think of cable cars idling, taking over orders of other cable cars :).
Well you can test the current system by pulling it from bitbucket:
https://bitbucket.org/maikel/openclonk/changeset/e98f0493ee36
https://bitbucket.org/maikel/openclonk/changeset/c0026f235007
https://bitbucket.org/maikel/openclonk/changeset/d0985b7a9b7a
I changed the test scenario a little, just activate the crossings in the lower part to stations and see what happens.
My implementation is anything but rigid, so we/you can change it to your/our liking ;)
Regarding requesting cable cars: I am in favour of a decentralised system there, my current implementation allows producers to add requests for objects to a cable car. Because the lack of finding a decent cable car currently, that is just any cable car, but in the future that would be the most suited cable cars. One could even think of cable cars idling, taking over orders of other cable cars :).
Well you can test the current system by pulling it from bitbucket:
https://bitbucket.org/maikel/openclonk/changeset/e98f0493ee36
https://bitbucket.org/maikel/openclonk/changeset/c0026f235007
https://bitbucket.org/maikel/openclonk/changeset/d0985b7a9b7a
I changed the test scenario a little, just activate the crossings in the lower part to stations and see what happens.
My implementation is anything but rigid, so we/you can change it to your/our liking ;)
> So in my implementation currently the foundry automatically produces metal whenever there is ore and fuel available.
Assuming you put the fuel and the ore into the foundry? Otherwise the foundry (or every producer) would be a wood stealing kraken.
And yes if there is metal available in the foundry it is taken (the foundry is taken for a storage then). In the example I just presumed that there is not.
> Because the lack of finding a decent cable car currently
That's not impossible, just cycle through destination_list (or aConnectionList in your version) and search for cars responding the destination when calling
GetRailTarget. Every car at a station does not move so it's idle.But again, I am opposed to the possibility to grant every station power over every car. In our first attempt they should only be able to command cars at the stations included in the current process (i.e. cars at the origin and the destination).
>In our first attempt they should only be able to command cars at the stations included in the current process (i.e. cars at the origin and the destination).
I like. That would actually make setting up a destinated car between the mill+bakery a lot easier. Maybe even neeearly without having to press buttons for that. Okay, maybe one. :)
>But again, I am opposed to the possibility to grant every station power over every car. In our first attempt they should only be able to command cars at the stations included in the current process (i.e. cars at the origin and the destination).
That would imply having to produce as many cable cars as one has buildings, I don't like that. Furthermore it would imply a lot of cable cars just idling around.
You could at least restrain the definition of an 'available car' to those waiting at buildings. A player should not be cheated of his vehicle waiting in a mine or wherever he wants it by the automisation. Though I can still imagine situation where one player wants the car at a certain position but another one calls it away for a stupid job, ruining the day.
Well, you could still allow the player so interact with the car in a way that he can set how the car behaves.Switching between: Available <-> Only for this building <-> Unavailable
We should avoid too much option setting and switching stuff. Let the system work properly itself and not by setting up some intransparent and obscure options.
Free some space for the day ruining situation:> You could at least restrain the definition of an 'available car' to those waiting at buildings.
But you will probably also have a cable station / crossing at your mine? Or did you mean only production buildings?And do you still want to have the possibility for cars to be just between two buildings? The mill+bakery example.
> Or did you mean only production buildings?
Yes, only producer/storages. When speaking of 'buildings' I don't refer to the crossing, even in the station mode. Crossings are the easy-to-build endings of the networks thus making them the first approach in accessing a mine or newly conquered area. The station mode crossing is the point from where you deliver your material from the mine. Therefore any cars connected to them should remain where they are because the whole idea behind the network is that you don't have to run back to your base and grab a lorry every time.
> And do you still want to have the possibility for cars to be just between two buildings?
The 'just be there' state would require a crossing in station mode between these two buildings and therefore any car connected has to be considered unavailable as stated above. On a second thought I don't see why you even want a car between two buildings anyway because placing a car at the mill (= deliverer) is clearly a superior solution. So far, the simple production lines in Clonk never showed up with the need of cross delivery between two buildings. So it's quite simple to label the buildings when regarding a certain task:
Sawmill - Deliverer, always
Foundry - Receiver of fuel & ore (never deliverer in this case), deliverer of metal (never receiver)
Forge - Receiver, always
For a fast and productive system you have at least to provide every always-deliverer with a car. The linker between always-deliverer and always-receiver, the foundry, does not necessarily need a car but can snatch one from the nearest deliverer. To accelerate your production however, it needs one. To further develop your system you can skip the 'on demand' production of metal and make it automatic. This was also in the concept:
So, you go to your sawmill and set it to 'deliver to foundry'. Then, when you drop a tree into it, it starts a car with the wood to the foundry dropping the wood there. The car returns, to be ready for the sawmill.
Your miner sends the ore and the foundry starts working (as always back in CR). Of course the miner wants his lorry back, so it returns as well.
You can even set the foundry to the automatic delivery mode, e.g. deliver the new metal to your storage.
Providing more cars will make your transportation faster. With the dynamic snatching, the foundry (presuming it lacks an own car) will grab the sawmill's car to deliver the metal to the storage. If the storage is to deliver something (because e.g. the forge asked for metal), it does the same thing (snatching from the sawmill or the foundry). Needless to say that one car for all these jobs can be really busy at a time. But there is one thing the buildings should by all means not do: stealing the miner's lorry. Because there's a player who did place the lorry here on purpose (to be there and grab his mined ore).
Now back to your idea: this is a simple example with 5 actors: sawmill, foundry, storage, forge, mining player. Assuming after a while everyone of them gets a cable car you end with 5 cars with 3 reaction options each! And you have to remember which one was set to what option, too. What a mess. And all because there's one out of four actors who doesn't want his lorry to get lost.
So as I got it now the cars ALWAYS return to where they came from, right?Also how do you differ between a car that should be used by all buildings and a car that should be only used by the building it belongs to (be it receiving or delivering)?
> So as I got it now the cars ALWAYS return to where they came from, right?
Only if sent to a building (!= crossing in station mode), which means it had a delivery job to do. Sending to a station could just mean providing the mining player with a lorry. However, in the concept I brought up some ideas for intelligent crossings:
>> The flag is to show what status the station is in (think of the signal)
>> I think there are two options suitable: 1 - Drop load and return to your starting point, 2 - Stop & disengage
(it's different right now, the car does not disengage automatically)
>> Signs
>> [...]
(the signs may be some advanced options to the crossing to create some cool machines and stuff)
> Also how do you differ between a car that should be used by all buildings and a car that should be only used by the building it belongs to (be it receiving or delivering)?
There is no difference because in Maikel's approach a building just searches for any available car. My counter-proposal was that buildings may only use 'their' car (idling at their position). But I think the ffa idea is better: every car positioned at a building is free for all buildings. A building just searches for the nearest one.
>But I think the ffa idea is better: every car positioned at a building is free for all buildings. A building just searches for the nearest one.
The approach is better than only allowing their own car, yes. But I really think you will have some priorities (for example, you will want to keep your food production running and not suddenly lose all your available lorries because they go on a quest to deliver a piece of wood to the other side of the map).
Can't think of any solution to this without landing in configuration hell. My suggestion would be 'more lorries'.
Meh. Sucks.Mh, you DO have interaction with the crossings, right? Because you mentioned some "station mode" earlier. Through the same interface (building interaction) the buildings could be set to "has local lorry" meaning any lorry waiting in front of the building can only be used for delivery to and from this building.
That would not clutter the interface a lot more (since the player is used to similar interaction for the crossings) and it would solve the issue of what happens when a lorry is lost: you would not have to reconfigure anything. All you would have to do is to put a new lorry in front of the building.
If even that would be too much interface (because it WOULD add a button to the building menu) you could use the signs for that: just set up a sign "exclusive owner" in front of the building. Tada, no additional interface needed!
Neat, might work.Interaction with the crossing is already possible in the testing scenario btw. To switch the station mode on or off (on is with the flag). By default, every crossing in a dead end becomes a station automatically.
>So in my implementation currently the foundry automatically produces metal whenever there is ore and fuel available.
That works for the forge. But what happens if you have an Anvil that can produce a) Gears and b) Swords? Both need one coal and one metal.
You cannot autoproduce something whenever you have coal and metal there.
It actually does not work for the forge either: Where does the fuel come from? Probably from some storage building or from a producer (be it refinery for oil or charcoal kiln). Since the forge is constantly producing when you have at least one coal+ore somewhere in your infrastructure, it actually slows down your system a lot more than Clonkonaut's approach.
Also how would the player decide whether he would not rather want the Oil at the Anvil for producing Fire Arrows?
It worked without a selection in Clonk Rage because you would have to bring the ressources there manually. :)
I didn't had the time so far to import your patches. Pushed the changes to the pathfinding today, mainly because you may refer to the modified variable names. Removing of cables is still not supported but that's nothing to bother the delivery process.Well, are your patches still up-to-date to justify the work of importing them?
I'll try rebasing/updating them and then I'll push
Edit: Did that, didn't incorporated any new requests made here yet though.
Edit: Did that, didn't incorporated any new requests made here yet though.
Care if I start editing that? By the way "IsConnectedToStation" is more or less useless. You can check this with either "GetNextWaypoint" or "GetLengthToTarget". But well, if you insist to write an own (boolean) function for this, copy one of them and replace the return values with true and false.
You can edit that if you want, and also replace IsConnectedToStation with the appropriate of those two options.
As an outsider I would say that "IsConnectedToStation" sounds a lot more like what I would want to call when I would want to know whether the lorry is connected to a station than "GetNextWaypoint" :)(Even if it is only a wrapper for !GetNextWaypoint())
![[ni]](/mwf/flags/ni.png "Nicaragua")
![[pa]](/mwf/flags/pa.png "Panama")
This topic again reached the point of TLDR for me, even though I find this all very interesting. Is there any point where I can split up the discussion? Or can anyone who dived into the discussion make a summary?
Well, the discussion is more or less ontopic, so there's no need to split it up. To sum it up, I wrote how the automisation of object transportation should work because of Maikel asked.To have a good overview I recommend to read the following postings:
http://forum.openclonk.org/topic_show.pl?pid=12905#pid12905
http://forum.openclonk.org/topic_show.pl?pid=12928#pid12928
http://forum.openclonk.org/topic_show.pl?pid=12933#pid12933
The other output from my train voyage: A sketch on the graphics of the cable crossing.These are the drafts:
Page 1
Page 2
--------------------
Page 1 contains more or less some ideas about the single components of the crossing. Page 2 a whole sketch and some thoughts on animation.
The big sketch on page 2 shows how big the whole thing would be. That's the pistons fault (I've mistaken the name for plunger on the draft...). With realistic proportions it's awfully long. So maybe trick the dimensions and bulge the whole construction. It's meant to look good not realistic.
The animation is the tricky part. Two little cranes shall swing out to and stay there to show that this crossing is in station mode. They grab the cable cars, lifting them to the cable. I don't whether or not it is possible to have the swing animation while the whole thing rotates. But it would be nice.
Sometimes the things erupts steam, because it's steam driven (but does not need any fuel...energy usage is another thing to discuss but later).
![[mx]](/mwf/flags/mx.png "Mexico")
Whats station mode again? I am not sure if I like the idea with the tiny cranes, the big sketch on page 2 though looks good.
Station mode means that you can engage cable cars there and select the crossing as a target for a car. By now it is remembled through the flag.The idea was to show some kind of lifting mechanism. Because the wheel of the crossing is higher than the ground (which is good because it's the connection point for the cable, so it provides more flexibility in 'midair'), by now the lorries are lifted by magic or the strongman clonk capable of carrying 50 tons of rock or so. Other ideas I had were an uprising platform or one big grappler crane.
![[ca]](/mwf/flags/ca.png "Canada")
Why not just have something like this? One could ride it and transport lorries.
So you want to create this as a new object? I don't think that would work.But we may adapt the hanging. I will sketch it later.
>So you want to create this as a new object?
I was suggesting instead of having a "reel-down-grab-lorry-reel-up" system we could just use cable cars instead (as per the "Lift" in that very old concept by Newton). Then far more than just lorries can travel the transport system.
>I don't think that would work.
Eh? :s
>Then far more than just lorries can travel the transport system.
With the current system also more than lorries should eventually be able to ride the railway.
Doesn't make a huge difference whether you need to grab a lorry or a catapult
> Then far more than just lorries can travel the transport system.
As Zapper said the cable car library is planned to be used by whatever vehicles you wish to.
Well, your idea is complicated. You want to use a new vehicle to transport all other vehicles. So now the player needs to construct a lorry and a cable car to transport objects - and whenever he wants to do that twice or so, he needs two new vehicles. No, I don't really like that...
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
