![[de]](/mwf/flags/de.png "Germany")
Development started, so this is should be the discussion about the practical implementation.See here for the concept and here for the conceptual discussion.
The testing scenario is found in Tests.ocf/CableLorrys.ocs
Current state
Crossings may be changed to stations by interacting with them (space). The flag indicates what is a station. Stations may be changed back to normal crossings.
You can engage the lorry to the system. Grab the lorry, push it to the station, press the interact hotkey (probably 2) while pushing the lorry. The station then snatches the lorry and you will get into the destination selection mode. You can select every possible station by pressing left or right. To start the lorry left-click or press space. To abort the selection right-click.
A lorry hanging at a station can be disengaged by grabbing + interact with the stations (probably 2 again) (and may then be engaged again to start off).
Construct new crossings with the hammer, connect them with the reel.
Known bugs
-
- It's possible to push the lorry while it's floating making it fly away.
- The cables disappear when one of the connecting stations is out of sight.
- It is possible to engage a lorry to a crossing in non station mode.
- Crossings lose their station mode when a clonk pushing a cable car interacts with them.
- Target station picking does not work properly.
Short time To Do
-
- support elimination of cables in the pathfinding - in progress
-
-
- Library_CableStation which is to include in buildings (and the crossing, so start off with sourcing the code out) - in progress
- delivery subsystem - in progress
- new graphics for the crossing, more steampunk style! - draft in progress
To Do - basics may change, so be warned!
- signs: this should not be something new but a big configuration set to the crossing. By now they only have the possibility to change into a station. Inspire yourself with the concept. To start off, I advise to pick one the following: trigger (delivers a signal to any object when a cable car passes) or 'drop objects' (makes the car to drop objects of kind x when it passes - every known object is to pick, cable cars may state that they do not drop anything)
Unnecessary To Do
- rework the pathfinding to increase performance. Think about a way to abandon the current saving of the whole network (every waypoint knows every other waypoint and the next waypoint to take if on the way to the targeted waypoint)
-- The pathfinding is more or less separated from the rest, so there isn't so much to care for but this: always take the shortest path!
-- and on a second thought: the network changes. So adding and removing paths mustn't be a problem
>Grab the lorry, push it to the station, press the interact hotkey (probably 2) while pushing the lorry.
Yeah, you probably had to do some hacking to make this work. The control system is not designed to be able to [interact] with something WITH something. Actually, from the control system design point of view, it should probably have been done like this: You grab the lorry, push it to the station and press one of the [Use] buttons.
> Yeah, you probably had to do some hacking to make this work
More like hacking the theory because clonk->GetActionTarget()->IsCableCar() does the trick ;)
> You grab the lorry, push it to the station and press one of the [Use] buttons.
That was my first attempt but unfortunately [Use] is already used by Library_ItemContainer. So you have 2 possibilities: controls are overwritten (i.e. the lorry responds in another than the usual way which may be confusing and the contents aren't accessible) or add a new menu button to the lorry's contents menu which simply sucks in coding and expanding to every possible vehicle function.
So I thought it was a better idea to let the station distinct the cases.
Library_ItemContainer is more of a provisional library. But: huh, why does that library need the [Use]?
That should be thrown out of the library. The library should just provide the basic "open and display contents" functionality, not the means how to access it. E.g. the content menu of the chest, the only other object which also uses this library, is openend on interaction.
Neither did I code the lib nor do I want to right now. And apart from that I can imagine vehicles using [Use] like cannons e.g.
That library is unimportant to my argument that vehicles could already use [Use].
I moved the objects to another folder, so that I/others can test them in other scenarios and in combination with other objects as well.
So structures are automatically cable stations? Wouldn't it make more sense if you construct a cable station attached to it?
>- Library_CableStation which is to include in buildings (and the crossing, so start off with sourcing the code out)
So structures are automatically cable stations? Wouldn't it make more sense if you construct a cable station attached to it?
> Wouldn't it make more sense if you construct a cable station attached to it?
Hm, why?
A door is a movable structure used to close off an entrance, typically consisting of a panel that swings on hinges or that slides or rotates inside of a space.you're welcome.
To be serious I guess he is concerned about the graphical representation of the interaction between the lorry and the building. If the building has some sort of "hook" in the model where you connect the cable to, this hook is most likely not in front of the door: how do the contents of the lorry go into the building then?
If the cable is connected to the door and the interaction looks nice, the position of the cable itself probably does not.
At least that's how I would understand that.
I meant the fact that structures generally do not have those gears which currently transport lorries.
Ah, okay. Well, yes, that's the designers' work and if they don't do it because they don't like the idea, well, then I have no choice but to rethink this. Until then, I think a graphical integration would look way more cooler than some attach hacking.
How is the interaction between the lorry and the building planned by the way?Does the lorry just drop in front of the building and you have to to the rest manually? Or does it put the items from the lorry into the building itself?
One of the ideas behind such a system was that the player can automatize some production lines. That needs some automatic interaction between building and lorry. :)
It's planned that the lorry interacts with the building's contents, putting and grabbing like it's needed
but only while the lorry is in front? For example if the chemistry lab has 10 slots for sulphur (but is empty) and I send a lorry with five sulphur to the lab, the sulphur stays in the lorry while I am not producing. So the lorry is practically out of the transportation net until I produce something in the chemistry lab?Can I tell a lorry to always bring the wood from the sawmill into the vehicle factory without having to do that manually every time?
> Can I tell a lorry to always bring time?
Yes, I described that in the basic concept.
Without having a production started in the vehicle factory (so that it actually does not "need" wood at the moment)? :)So that it just stores the wood there?
Yes. The sawmill e.g. shall has an option " whenever wood is produced deliver to X
And what happens when the lorry reaches X? That's what I am trying to figure out the whole time :)
![[no]](/mwf/flags/no.png "Norway")
PS: Is that only an extra for a few buildings or for all production buildings? ("Deliver all Flints to my mine" and "Deliver all weapons to the front")
Well, imho all production buildings should include Library_CableStation which shall provides the said functionality.
Do they have to specify the IDs of the objects that can be transported or can you just select everything or how do the buildings have a ItemsThatCanBeProcudedHere()-callback anyway?
I think the last seems ok, I don't know where we are on the settlement concept. But we wanted something like automated production were the player can add requests to a producers production queue. This producer can then request from the cable network to supply him with the raw materials needed for completing the queue. Buildings like the foundry can just have a queue of infinite metal production.
Just let you guide yourself by the old AutoProduction intelligence from the Clonk from CR. There as well every production building had a callback (though it was named IsProducerOf() which sounds more nifty).
On a technical note, these buildings which need to include Library_CableStation need to be moved to Test.ocf/Experimental.ocd. If you are ok with it I can source out the code from the crossing to the library and move the buildings.
Just out of couriousity: Why is the cable station in Test.ocf?It's something that we all more or less agreed on (independed from the implementation, be it cables or bumpers) - why is it not in Objects.ocd?
Cause we agreed on that once, to my knowledge. But agreements are there to be broken, and I can't think of any convincing reason to do it like that. Cause C4Script errors and warnings are neither wanted in Tests.ocf nor in Objects.ocd.
Well, I thought Test.ocf was for stuff where it is not sure whether it is good (gameplay-wise) enough for the main package or not. If you want to try out new items for example.But it does not make a lot of sense to put stuff there that is going into the main package with 98% propability! (even if it was going to be, for example, changed drastically later on)
Peter's still not cool with the idea, so there's some kind of opposition.
Yeah, but even Peter wants some sort of transportation system (that's why I had "(independed from the implementation, be it cables or bumpers)" in my post) :)
![[gb]](/mwf/flags/gb.png "United Kingdom")
I still think it's way too specific a solution. I'd rather go the Minecraft way: Dump levers, dump lorries, dump pressure plates. Then look what the minimal change is that allows for easy-to-set-up automation.
Am I really completely alone with this...? This is starting to frighten me. o_O
I'm in the "too long, didn't read" fraction, but also a strong believer in "those who do the work decide how it's done". Yes, that means that those with more time get to make the decisions instead of those with more expertise. But this is a game, given halfway competent developers the only downside of that is that the game will be fun for a somewhat smaller and/or different audience. So there's no reason to be frightened. ;-)
I don't claim to have the most expertise. I just thought I was decent at seeing everyone's viewpoint and finding a way that's involving everyone without sacrificing the grand scheme too much. So my complete lack of understanding for automatic cables is something that indeed frightens me.
The most positive thing that I can say about it is that it is probably quite fun to implement... But I would want the player to have this fun.
The most positive thing that I can say about it is that it is probably quite fun to implement... But I would want the player to have this fun.
No, you are not. I am also a bit torn between the two approaches to the transportation here.I am not especially worried about the other system providing less for the player. I am more worried that we will barely have cool Dwarf-Fortress-like mechanisms if not for the transportation (where else would you need them? ..maybe pump control..). And I really like cool mechanisms.
I didn't play minecraft so I can't imagine what some dumped levers/plates do and what is possible to do with that.
I didn't play minecraft either.I imagine them to be like those from Dwarf Fortress. That would mean the player is given possibilities to create simple checks ("if object is here activate this mechanism") through pressure plates, levers and mechanisms.
That way he can create huuuge machines and factories that work automatically. But he actually has to create them himself.
Also you can create a turing complete computer withing a computer game that way!!
In Dwarf Fortress it is a lot of fun to create automatic traps (that lock and flood parts of your defense, for example) or other automatic stuff that way.
I don't play either. My reference point are mainly YouTube tutorials, such as here.
![[pa]](/mwf/flags/pa.png "Panama")
The whole minecraft wiring is pretty limited in what it can do and is only good for doing some toying around with it (Spielereien). This is partly due to virtually no application for that which makes sense (only blinken lights, make sounds,...). So the redstone stuff in Minecraft should only be a source of inspiration rather than a system that is worth to adapt.What is fun about the redstone in Minecraft (apart from the toying around) is the prospect of possible automation, to build a... you know, autonomously functioning machine that just does stuff "magically"... its the same fascination that comes with programming. That by the way is the reason why Minecraft is mostly played by nerds (like us) who are really into that kind of stuff. However, as said there is virtually no application for the redstone wires in Minecraft but the hope is that they will come up with something until release. (I however dont put so much hope in that.)
So I agree with both of you. A balance between too much automation with too trivial setup and a too clumsy setup with a lot of interesting fiddling around need to be found. After all, the more basic the things you can construct your automation from (and thus less initial automation), the more possibilities you have to build... just, cool stuff. With settlement melees in mind and with real things that need to be achieved in a level, that thing should not be so difficult to set up that you have to spend 99% of the time playing the scenario to build up the automation.
>The whole minecraft wiring is pretty limited in what it can do and is only good for doing some toying around with it
Well, when I have a computer game where the player has a lot of fun toying around with the game mechanics, I'd call the game a success. :)
In fact, automatic minecart stations are quite useful. But other than that, redstone really is useless.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
