A lot of good concepts are in the current code already, such as evaluating the actions that can be assigned in editor mode. What I still have problems with:
* The easiest implementation is a switch that has two states, as most switches currently have. Still, I can see cases where you'd have 3 or 4 states, or an arbitrary number. Should the implementation be able to handle this, or not?
* What about the door stuff? I'd like to handle opening and closing doors the same way as interacting with any other switch target. However, the use action is currently executed in addition to opening/closing a door. A possible solution to this is allow multiple targets and actions for each state (such as: right position => open door to treasure, sound alarm; left position: close door to treasure; separate object: button for deactivating alarm).
Don't forget that the OC editor also has a similar system (for levers and switches), so a ingame system should be compatible :)
So far it was not meant to be connected with other objects by the player, but rather by the scenario designer. On the other hand: Why not? We'd just need a way for preventing the player to rewire the switches etc. to something else in a puzzle solving scenario, unless the puzzle consists of rewiring the switches.
>So far it was not meant to be connected with other objects by the player, but rather by the scenario designer.
Oh, but we have that system already. It's used for the editor (and was implemented by Sven)
The old idea about the mechanism stuff had always been about allowing players to build stuff
a) has the same basic logic and functions for manipulating things and behaves predictable, basically streamline the existing system and make it more flexible.
b) can be used in the editor
c) can be used by the player, if desired (e.g. like a line kit) <= this is the optional part
We currently have b), a) follows from Mimmos suggestions, so I'll have to work on that first, and c) is an optional part. Should I work on c), then I'd have to know how the progress on the cable car stuff is, maybe I'd have to extend those objects, too.
There's also "triggers". They are all fields that derive from UserAction.Prop and they allow you to do the point-and-click editor "scripts".
At the moment, you cannot connect EditorActions with triggers. It would be possible to allow that, but I decided against it because most of the object actions have parameters. I think you will run into the same problem with a switch library. Realistically, you will only be able to connect doors to switches, and everything else will need some custom script.
Of course it would make sense to have a Library_Switch, so at least all doors can be connected to all switches.
-- Reflection:
I'll sum up the idea from Mimmo's thread again - on the other hand, this solution is most likely to create an (unnecessary?) inner platform, because the idea behind it comes from programmable logic controllers which have some restrictions compared to programming languages. There, you have input- and/or output signals in mechanisms, and you can connect this directly, or connect them with logic modules in between, the complexity of this logic is up to you. Basically it's a more complicated version of writing a program, but it is also very modular.
From the perspective of efficiency I'd say that's somewhat useless, because in many cases you can just write a script that does exactly what you want: If all four switches are on, then open the door.
From the perspective of easy scenario design via editor and even ingame options (you cannot simply write a script there, obviously), it makes sense to have something like that.
So, back to the doors and logics stuff. Here it should become apparent why that would create an inner platform, if we stick strictly to the way PLCs handle that:
* a switch would have a boolean output signal for it's current state (local variable/property internally)
* a switch could have a boolean input signal that sets it's current state and therefore the output signal (internally I'd just set the same local variable/property as for the output signal)
* a door has the same, so you can just access whether it is opened or closed.
* connect switch output to door input (whether in editor or ingame) => the door opens when the switch is set to true, and closes when the switch is set to false. In the editor you would/could have actions/triggers that are evaluated when the door opens/closes.
* when connecting a signal to another one you could choose whether to invert the signal (so that you can have one door that closes when the switch is on the left side, and another one that closes when the switch is on the right side)
Now, this is a really basic example, and I think it already illustrates where this PLC stuff seems more complicated than it needs to be. On the other hand, it allows doing some nice stuff really easily. Let's say the steam engine offered an output signal that says wether it is at full pressure or something. Then you could have a door that opens on this condition, or have something else happen. You could connect them to some other modules, so that the door opens if the steam engine has full pressure and the elevator is down, or something like that.
-- Proposal:
Anyway, this feels a lot like being things that you could already do now by accessing local variables or calling functions, just not in an ingame plug-and-play fashion. In order for this to work in a more generic way it might be sufficient to describe the mechanisms "interface" with a proplist (which will most likely look very similar to an editor action, please correct me), such as:
open_door = new Signal { // no idea what the "signal" prototype would look like, just a proposal for now
Name = "Open door", // or some localized text, as an ingame and editor display
Description = "Opens the door when the value is 'true', closes the door when the value is 'false'", // same as above, for ingame and editor display
Action = ... // what happens when the signal is being set - I am being very vague here for now, because as I write this, it seems as if we already have all this in the editor actions, but I don't have access to that code right now
}
As you may guess, I am a little confused right now :) Actually, I want to not needlessly introduce new scripting formats and so on, if we already have such a thing, so if doing this is possible via editor actions, then I am glad.
-- Conclusion
First and foremost what I want is to remove the hardcoded interactions with doors from switches, and allow them to connect to and operate arbitrary mechanisms instead.
The editor interface isn't that nice to use for the simple case of connecting things without any extra parameters. The current syntax for connecting a switch to a door looks something like this:
my_switch->SetLeftAction({ Function="open_door", Target=my_door });
or if there is no setter function:
my_switch.left_action = { Function="open_door", Door=my_door };
The door definition registers its action as:
UserAction->AddEvaluator("Action", "Structure", "$DoorUp$", "$DoorUpDesc$", "open_door", [def, def.EvalAct_OpenDoor], { }, UserAction->GetObjectEvaluator("IsDoor", "$Door$", "$DoorTargetHelp$"), "Door");
And when the switch is flipped, it calls something like:
UserAction->EvaluateAction(left_action, this, clonk);
UserAction keeps a global registry of all possible action strings (like "open_door", "message", "game_over", etc.), into which object definitions register.
This is a bit different from the system you sketched, because actions in your example would always be bound to an object, which doesn't make sense e.g. for messages.
If you want to create a Minecraft-llike system where you can use e.g. wires to connect switches to doors, you could probably add a flag to the triggers and the actions to make them available for the player. There could also be a special game rule that makes all actions (including cheats like GameOver) available. In retrospect, I could also update AddEvaluator to automatically register an EditorAction if a flag is set.
Regarding that "signal" thing: We can name it differently of course. I used signal in that context, because in the real world you'd have an actual switch that is opened or closed. When closed, it sends the signal "1" over a wire to whatever it is connected to. The receiving object/mechanism then does something with that "1", for example: open a door. If you open the switch or remove the wire the mechanism receives a "0" and would close the door.
Update: Ok, the identifier has to be unique -> this kind of makes it impossible for the actions to be defined generically. I really do not want to have each action "open_door" with another identifier, such as the object number, if they all do the same internally.
> So, you have to register OpenDoor() with that handle "open_door" (or whatever name you want to have) and there is no way to call it directly? What if two objects define the action "open_door"?
Yes, actions live in a global namespace. That's because most actions for the editor are global anyway (like messages, game goals, create objects, etc.), and they all end up in a big dropdown list for the editor actions. It may make sense to introduce additional "per object" actions. For the editor, all actions must end up in a big dropdown list anyway, so there's no good way around that global list. It may have been a good idea to prefix action names though (e.g. calling them Door.open instead of open_door) to avoid conflicts.
> and there is no way to call it directly?
You can always call door->Open() (or whatever the function is called). I don't think the trigger system should replace all regular object calls.
> Regarding that "signal" thing
"signal" is fine. It's just that in Qt, "signal" is the trigger. You have signals, slots and connections between the two. I can see how the signal could also be the connecting piece (as in "a signal going over a wire").
>I don't think the trigger system should replace all regular object calls.
Of course not - it's just that the info in the user actions contains everything that I'd present to the player in a user interface if they were to connect two objects during play, so I wanted to keep as much of it as possible. So, as far as I can tell, this display problem would boil down to simply having a flag in the user action that allows it to be used in the user interface during play. That is, once we have a prototype for this mechanization thing going. Cool.
Of course the second could be built using the information from the first. E.g. the UserAction.AddEvaluator call could register the same action back into the definitrion to be used by the listing shown to players.
> Update: Ok, the identifier has to be unique -> this kind of makes it impossible for the actions to be defined generically. I really do not want to have each action "open_door" with another identifier, such as the object number, if they all do the same internally.
Actions are defined per definition; not per object.
Edit: the limitations being what we allow players to do ingame. I don't expect them and don't want them to write scripted actions during play. Evaluating a CastObjects() call when pressing a switch is also not the intention.
The players could do at most what buildable objects offer them, see: Mimmo's thread.
For example, I doubt that your factory example is realistic. We wouldn't have a factory object that is purely for developers, so they would have to add such an object anyway and also script it. And if we had a factory object for players, I guess it would need a 'better' interface compared to connecting wires
Regarding the applications: I can think up lots of things with the existing objects (for example a hatch made of two stone doors and two or three pressure plates) where you need more logic than just switch => open/close door.
This adds complexity to the implementation, and in order to avoid that I want to know what players would likely/realistically want to create. At the moment I feel that such a hatch is rather already there in a scenario and that can be done with the editor sufficiently.
The problem here is a tradeoff:
- the generic solution is a simple concept, but the possibilities might be confusing/overwhelming for the player, because there are many options at once
- the limited approach may be less confusing, but could leave the player frustrated because they have a good idea and cannot realize it due to the limitations. This also creates a morrsspecific implementation.
- I can post an example after I get home from work.
The next level from there is a connection of the signal with logical operators. At least at this point we'd need a useable interface that goes beyond "wires", because you'd have to visualize it in a meaningful way that a player can handle (yes, that would be low-level programming at runtime, with a clumsy graphical interface). Some examples:
- trap is activated if floor plate is down
- trap is activated if floor plate is down and a switch is in the correct position
- trap is activated if floor plate is down and the door is open
- trap is activated if floor plate is down or if a switch is in the correct position
The next level of complexity/design decision depends on the objects themselves:
- a door should have an input that opens/closes it. Makes sense
- a door could have outputs that say whether it is opened or closed. You could plug those outputs to different objects again: door B closes when door A is open, and vice versa.
From an internal point of view I don't need any of that. As a scenario designer I don't need any of that - I just write a script with the correct function and that's it. That's why I am asking questions here: I don't want to create an interface that is super generic and has lots of possible uses if 95% of its functionality stays unused. In such a case I'd keep it simple. However, I don't know yet what most people/players would like to be able do with this.
For example, if we decide to limit this to boolean "signals", then I'd use a callback SwitchOn(), SwitchOff() in the switch target. If it were an arbitrary type then I'd rather create a Send() function: Send(true), Send(Metal), etc.
The other question is: Is this actually interesting for players? Most likely I'd want a sentry gun or guard tower that works on its own, without me connecting it to a switch and switching it on first. Same thing for doors. You'd need something to control a door, and if you have something like that - then I'd rather have something that brings its own controls and does not need to be attached to an external switch.
So, if the thing should serve as an internal interface so that you can connect different types of objects with an on/off switch to switches in the editor more easily, then I'd design it towards scripting comfort.
I hope this turns out constructive :)
>I don't want to create an interface that is super generic and has lots of possible uses if 95% of its functionality stays unused.
Yes, that's what I fear, too
>Most likely I'd want a sentry gun or guard tower that works on its own, without me connecting it to a switch and switching it on first. Same thing for doors
I think so, too. Similar to your factory example
That's why I always try to push the actual application to the foreground: I would propose designing a hand full of gameplay elements (FOR PLAYERS!) that work well together and are usable ingame without an additional interface and enhance the gameplay.
E.g. think of situations in maps where you would use feature X and that feature would use a lever and a door.. blabla
The interface would then be designed to solve these actual ingame applications.
Also see Newtons reply to Mimmo's first post. A lot of theoretical applications are probably not of any use in any map we currently have. And I think the generic, core gameplay elements should work on a majority of our existing maps.
I think a big part of why we don't have these things yet is because we didn't really find any suitable applications. Even though I loved the idea when we discussed it back in the days (2011 or so) with PeterW.
For example, you can build an AND-gate as an extra object which accepts a number of input and output wires.
For building a specific object: When you connect a wire to a factory, you could get a menu asking you which command in the factory the wire should trigger. Or that selection could just be in the interaction menu of the factory (the interaction menu lists all connected wires, and then you can select their action).
If you want to do something crazy like "this switch triggers construction of five muskets", then you have to build that as a machine with a conveyor belt that transports five rocks, which fall onto a switch successively, which triggers both the construction of a musket and transportation back onto the original conveyor belt.
I think it's more fun for the player if we just give the basic logic objects and simple boolean wires, and let the player do more complex stuff in-game. Thinking about it, you could probably also build an AND-gate with conveyor belts and switches :-)
Yes, an and-gate, or-gate, etc. would be a separate object, and that is one thing that I don't like. You either need one object that has a good interface for selecting/changing its functionality, or you spam the construction menu.
Additionally these structures should be relatively cheap, so that you can build them easily.
Is there a conveyor belt already? I think there was one in Clonkraria, and there is the cable car.
Still, is there a situation where you want to build 5 muskets (yes, it was an example) repeatedly when operating a switch? Seems unlikely. Firestones more likely, and it would be neat to have them delivered to your mine automatically.
So, if we want a conveyor system it should help deliver materials to the individual factories, with a demand-based sorting mechanism maybe?
Another obstacle is how to make this comfortable to use. By the time you built 5 conveyor belts you'd already have mined a coal deposit manually and then the belts become useless.
> Firestones more likely, and it would be neat to have them delivered to your mine automatically.
> So, if we want a conveyor system it should help deliver materials to the individual factories, with a demand-based sorting mechanism maybe?
Automatic production is something the cable lorries are supposed to achieve without the need of an extra overhead like connecting everything with 'mechanisms'. This is already possible in the current, very primitive state.
> Speaking of wires - that could be comcomfortabled with something like the telegraph from the western pack?
Yes, that could look pretty cool
> Yes, an and-gate, or-gate, etc. would be a separate object, and that is one thing that I don't like. You either need one object that has a good interface for selecting/changing its functionality, or you spam the construction menu.
> Additionally these structures should be relatively cheap, so that you can build them easily.
Balancing can be done afterwards and geared at scenario goals. E.g. a wire can just allow you to build any number of logical gates, so they don't clutter the hammer. Or you have an "electronics box" that allows you to build all these things.
> Another obstacle is how to make this comfortable to use. By the time you built 5 conveyor belts you'd already have mined a coal deposit manually and then the belts become useless.
I don't think it will ever realistic that building a huge automated infrastructure is more efficient than just going into the mine with a pickaxe and/or explosives. It doesn't have to be. Automations can be useful in many other cases:
1. Just because you like to build a complex machinery in free settlement. Think about what people build in Minecraft. Or Clonk Rage players building and decorating castles. I think building a calculator with cable lorries and wires is more fun than building it by clicking through endless menus (just because the result is more visual). Bonus points if you can "see" the signal going over the wire. See e.g. the Mario Maker Calculator
2. Automated defenses (e.g. sensors on guns)
3. Traps. E.g. a lorry with firestones emptied above your head. Or a trigger on a dynamite box. You could build these things e.g. in a scenario like "Dark Mine".
4. Special scenario goals that require you to build some automation. E.g. you have to build an automated railroad track that allows a train to go through some complex terrain, including automatic re-routing of liquids, signals, maybe pick-up and deliver objects, etc.
5. Special scenario events that make it worthwhile to build automation. E.g. monsters spawn at regular locations. You build some automation that drops the last monster's carcass on top of the newly spawning monster and then transports the dead monster to be the next trap.
Seeing the signal is important, yes, especially if you have logic gates and you have to find out why your construction does not work as it should.
As for automated defenses: creating a custom trap is a nice idea, but constructable defensive structures should be able to work on their own without a sensor on top.
So yes, the more interesting contraptions are the creative ones, and emptying lorries is a good idea.
This is only the internal restructuring: a library for switches and one for mechanisms.
- when implementing a switch you can now call the generic functions DoSwitchOn(), DoSwitchOff() to operate the connected object. Could be replaced by one function with boolean argument if desired.
- focusing player view on the mechanism that is being operated (such as a door) is now handled by the mechanism itself, instead of the switch - so you don't have to code that anymore
- in the editor you can invert the logic of the switch target, for example pressing up on a spin wheel would then close the door instead of opening it. You can also disable auto-focus in the editor.
I'd like to merge this back to the main branch, so it would be great if someone could review the code, and testing is always welcome, of course.
* The name
Library_Mechanism
isn't very descriptive. dictionary.com defines mechanism as "a system of parts working together in a machine" (i.e. Switch+Door combined could be a mechanism). I think you could simply call it Library_SwitchTarget
? After all, the set-function in the switch is also called SetSwitchTarget
.* You have the function to flip the input in the target. I think it would be more convenient to have it in the switch instead. That way, you can have multiple switches control the same door, but using different directions.
* You do two callbacks when flipping the switch (OnInputSignalChanged and OnInputSignalSet). Remember that the first callback may have deleted the object. You should check for that.
Btw: While code reorganization is fine, I think it would be way cooler to have something new that the player can see! (like wires to connect switches and targets). See e.g. here: working backwards.
* I tested Dark Castle only, once before and once after replacing the call.
* Ok, and the library would then also implement IsSwitchTarget
* Makes sense
* I did not find a useful setup where you'd repeatedly set the same signal. You can do this with the spin wheel, though. It could make sense for a switch target that has multiple states and you can cycle through them or go up/down multiple times. In that case maybe a single callback is better, but the target has a setting for not doing a callback unless the signal changes. Edit: Even that may not be necessary after all.
Regarding the ingame stuff:
* does it make sense to build spin wheels or key pads? The latter only if the player can set a code initially, and if you can lock it again
* we can allow building switches
* what about pressure plates? They are cool, but take up space and a hostile player would suspect that they trigger something when stepping on it
* we'd need switch targets other than the stone door. The igniter comes to mind, what else?
>* does it make sense to build spin wheels or key pads? The latter only if the player can set a code initially, and if you can lock it again
Yes.
>* we'd need switch targets other than the stone door. The igniter comes to mind, what else?
Every building, cable lorries.
>The igniter comes to mind, what else?
Wouldn't it rather be the dynamite box without an igniter?
> * I did not find a useful setup where you'd repeatedly set the same signal. You can do this with the spin wheel, though. It could make sense for a switch target that has multiple states and you can cycle through them or go up/down multiple times. In that case maybe a single callback is better, but the target has a setting for not doing a callback unless the signal changes. Edit: Even that may not be necessary after all.
That was pretty common in CR. For example, a switch would control a moving platform and the platform gets stuck. You then dig it free and press the switch in the same direction again.
A door could also be multi-stage. E.g. the first up-signal moves it up halfway, and the second signal all the way.
> does it make sense to build spin wheels or key pads? The latter only if the player can set a code initially, and if you can lock it again
I think if we had a wire object to connect them, it would be really, really cool. Even if they are only enabled in some rounds so far (e.g. in Playground).
Additionally, I want to achieve some kind of distinction between editor-placed objects and something that is built by the player ingame. It should be possible to place a door or pressure plate in the editor as they are. When building this as a player, I'd like it to be somewhat handy: The stone door should/could have an "end piece" below and above that stops it (or make it fit in with other objects in a good way?) The pressure plate should have some kind of depression that it can sink into by default. Settings such as weight, etc. could be done in the interaction menu. Furthermore, those objects should have a box/station that serves as a visual connection point for the wire next to it, because it would look strange if the wire went to the center of the door and moved with it.
There probably is a callback in the hammer, such as ConstructionEffects() that allows for such a distinction, right?
Further questions:
- IsHammerBuildable() should be sufficient for the object to come up in the construction menu, regardless of category, right?
- including Library_Structure is necessary only if I want the structure to have hitpoints & repair, or a basement, right?
> IsHammerBuildable() should be sufficient for the object to come up in the construction menu, regardless of category, right?
That and any one of the standard categories: C4D_Structure, C4D_Vehicle or C4D_Object.
> including Library_Structure is necessary only if I want the structure to have hitpoints & repair, or a basement, right?
Yes.
>- including Library_Structure is necessary only if I want the structure to have hitpoints & repair, or a basement, right?
But think about the implications of letting players build indestructible buildings *). I think you do want them to have hitpoints.
*) e.g. protection against meteors / enemies / lava / vulcanoes / ...
Which leads me too the next question. Instead of adding two "modes" (player built vs. pre-placed) to one object I think it would be better if the objects thar are available to the player are a separate definition with everything they need (so you don't have to prevent the player from rewiring the switches in dark castle, or do some other unexpected stuff with the existing objects).
Don't forget that you can also not destroy e.g. the elevator in the tutorials. That's exactly the same
Certain objects, such as the door or switch, create their own electronics station when built as a construction site. The electronics station has the necessary interface for logic gates in the interaction menu.
This approach has the following advantages: 1) editor-placed objects can be invincible and without electronics station by default.
2) the door itself doesn't have to know anything about the wires
3) the player has a visual cue that a wire can be added to an object, because there is an electronics station next to it.
Now the remaining question is: do we allow electronics stations as separate structures, or is it better/sufficient if a connected electronics kit can be converted to a station? In the former case the workflow is: build target, build station, produce kit, connect station and target. In the latter case it's: build target, produce wire, connect wire to target, connect to other target or set up as a separate station.
> do we allow electronics stations as separate structures
That is what I thought best for the cable lorries. The stations can be attached left or right to already built buildings.
>The player uses an "electronics kit" for connecting a wire to an "electronics station"
Or just a "wire" object :)
But I think I like the approach. When you would need "and" or "or" gates, you would just manually build another electronics station next to buildings (and connect those, too).
On question remains: on which side of the door is the default electronics station?!
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill