Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / Basic functionality for switches
1 2 Previous Next
- - By Marky [de] Date 2017-11-18 20:43
There was once an idea to create a basic functionality for switches, but I couldn't find the thread anymore, so I created a new one. Anyway, currently there are some switch implementations (normal switch, floor switch, keypad) and they both use different callbacks. Additionally, all of them implement their custom logic for opening/closing doors. Add custom packs, such as Hazard, and you have even more custom switches with their own logic and callbacks - however, I want to get rid of that and provide an interface for switches and switch targets, so that switch puzzles (or production lines, or whatever) can be created easily.

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).
Parent - - By Zapper [de] Date 2017-11-18 22:19
The original thread: http://forum.openclonk.org/topic_show.pl?pid=31561

Don't forget that the OC editor also has a similar system (for levers and switches), so a ingame system should be compatible :)
Parent - - By Marky [de] Date 2017-11-18 22:46
Ah, thanks. Well, that sounded a little bit different, but it makes sense, too. If we want something akin to a PLC (what Mimmo suggested) I could implement that, too. Makes things a lot easier, actually, because the three way switch would just set a different output for each state.
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.
Parent - - By Zapper [de] Date 2017-11-18 23:05

>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)
Parent - - By Marky [de] Date 2017-11-18 23:28
Yes, I know. My problem with that system is that everything is implemented differently, as described above.
Parent - - By Zapper [de] Date 2017-11-18 23:35
Oh, then I misunderstood you. So you want to extend the existing action system of the editor? Or do you want to have a common interface that uses that action system?

The old idea about the mechanism stuff had always been about allowing players to build stuff
Parent - By Marky [de] Date 2017-11-18 23:56
I want a common interface that:
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.
Parent - - By Sven2 [us] Date 2017-11-19 00:48
The editor itself has a common interface called "EditorActions", which control the action buttons you get when selecting an object (e.g. for opening and closing gates).

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.
Parent - - By Marky [de] Date 2017-11-19 09:56
I am pretty sure that this can be combined with the editor actions, too, very likely in a easy way. Looking back at what I wrote: It's not really an answer, just reflecting the problem and a proposal how to implement that, with a conclusion what I actually want to do.

-- 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.
Parent - - By Sven2 [us] Date 2017-11-19 19:15
Your proposal is pretty much what's already in the editor (but the actions would be the UserActions; not the EditorActions). Just the name "Signal" is weird; isn't that rather the "Slot" and the switch would be the "Signal"?

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.
Parent - - By Marky [de] Date 2017-11-19 19:34 Edited 2017-11-19 21:00
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"?

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.
Parent - - By Sven2 [us] Date 2017-11-19 21:03

> 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").
Parent - - By Marky [de] Date 2017-11-19 21:24

>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.
Parent - By Sven2 [us] Date 2017-11-19 21:36
Yes. One problem I see is that the editor actions work by selecting an action, and then its target(s). That's also why there's a global list of possible actions, etc. For a player connecting things with wires, it would make more sense to pick the target first, and then list available actions

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.
Parent - By Sven2 [us] Date 2017-11-19 21:04

> 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.
Parent - - By Marky [de] Date 2017-11-21 21:41
I had a look at the code again, and I think that I cannot use the EvalAct_* functions of the door, for example, since they require the props and context parameters that I do not have.
Parent - By Sven2 [us] Date 2017-11-22 02:47
Yes, you will have to create them if you want to use the evaluator functions.
Parent - - By Marky [de] Date 2017-11-19 22:26
Next question then: Should it be supported to pass data types other than boolean over wires? For example a factory could pass a required material to a conveyor belt, or to a different factory that produces this material. Or you could make a fake switch that triggers a trap and passes the operating clonk to that trap :)
Parent - - By Sven2 [us] Date 2017-11-19 23:25
Aren't you rebuilding the editor there?
Parent - By Marky [de] Date 2017-11-20 05:53 Edited 2017-11-20 06:16
I hope that I'm not. At the moment I am just getting an overview what we want to do, I am not actually implementing anything at the moment. I can see why you ask that, and the answer is: sort of. After all, most of this is doing things that the editor does, but allowing the player to do it, with more limitations than the editor has.

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.
Parent - - By Zapper [de] Date 2017-11-22 09:44
That should be focused around the things you want to be able to build with that (which you should know beforehand, otherwise creating such a system wouldn't make much sense).

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
Parent - By Marky [de] Date 2017-11-22 12:37
With factory I meant any of the production structures, such as armory, tools workshop, chemical lab and that experimental transport system that is floating around somewhere.

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.
Parent - - By Marky [de] Date 2017-11-22 21:17
Yes, a better interface than connecting wires is required if there were such an object. I mean, just take look back at Mimmo's thread. He suggests some sensors and switches that have "output signal" and you can send this signal to devices, such as doors, gates, traps, so that they become active. This is fairly basic.

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 :)
Parent - By Zapper [de] Date 2017-11-22 22:30

>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.
Parent - - By Sven2 [us] Date 2017-11-23 04:56
The wires could be very simple (just boolean signals), but if you want extra logic, they can be in extra objects.

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 :-)
Parent - - By Marky [de] Date 2017-11-23 05:49 Edited 2017-11-23 06:55
Speaking of wires - that could be comcomfortabled with something like the telegraph from the western pack?

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.
Parent - - By Clonkonaut Date 2017-11-23 14:48

> 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.
Reply
Parent - By Marky [de] Date 2017-11-23 16:47
Yes, that "although ..." was not referring to the mechanism stuff. If we have some kind of transportation system, then it should deliver things by itself without forcing you to build additional objects/switches/whatever.
Parent - - By Sven2 [us] Date 2017-11-23 22:53 Edited 2017-11-24 06:44

> 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.
Parent - By Marky [de] Date 2017-11-24 06:45
The electronics box is a good idea. This could simply be the end of the wire, like a detonator for the dynamite box, so it already comes with the wire and doesn't come up in construction menus at all.
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.
Parent - - By Marky [de] Date 2017-11-25 01:33
The first part is finished and can be tested here: https://github.com/gitMarky/openclonk/tree/switches

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.
Parent - - By Sven2 [us] Date 2017-11-25 06:04
Looks great (assuming you tested the scenarios and the legacy call to SetStoneDoor). Some suggestions:
* 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.
Parent - - By Marky Date 2017-11-25 10:23 Edited 2017-11-25 21:21
Addressed in  order:
* 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?
Parent - - By Fulgen [at] Date 2017-11-25 10:32

>* 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.
Parent - - By Marky Date 2017-11-25 10:38
I connect a switch and wire to a windmill/elevator/armory, and flip it. What do you expect to happen?
Parent - By Fulgen [at] Date 2017-11-26 14:58
Umm...not every building then =)
@armory: I expect it to produce a selected object.
How about buildings get some slots and the player can configure what they do at connection time? E.g. "produce object <select object>" or "start / stop pumping".
Parent - - By Zapper [de] Date 2017-11-25 10:34

>The igniter comes to mind, what else?


Wouldn't it rather be the dynamite box without an igniter?
Parent - By Marky Date 2017-11-25 10:41
Depends? If you lay out dynamite at certain positions and want to them to detonate from far far away?
Parent - - By Sven2 [us] Date 2017-11-25 23:15

> * 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.
Parent - By Marky [de] Date 2017-11-25 23:18
Good, only one callback then.
Parent - - By Sven2 [us] Date 2017-11-25 23:30

>  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).
Parent - - By Marky [de] Date 2017-11-26 19:48
Regarding spinwheels: Connecting them to doors makes sense, but otherwise I'd rather see them connected to something that has gears (mechanical connection), multiple states (the spin wheel being a "dial" here, or add a rope/chain to it and let it raise/lower things. Adding a wire to a spin wheel and then to a door feels strange - with a switch not so much.

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?
Parent - By Clonkonaut Date 2017-11-26 20:25

> 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.
Reply
Parent - - By Zapper [de] Date 2017-11-27 09:13

>- 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 / ...
Parent - - By Marky [de] Date 2017-11-27 12:12
This will need a distinction between player built switches and pre-placed switches again. I don't want players to accidentally destroy a key pad or spin wheel in a scenario.

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).
Parent - - By Zapper [de] Date 2017-11-27 13:47
But we have that for buildings, too. Actually, the building library allows and supports invincibility - you even get feedback in the interaction menu.

Don't forget that you can also not destroy e.g. the elevator in the tutorials. That's exactly the same
Parent - - By Marky [de] Date 2017-11-27 17:21
Ok, I'll use a different approach then: The player uses an "electronics kit" for connecting a wire to an "electronics station", or to an object that is explicitly a target for an electronics kit (such as the dynamite box).
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.
Parent - - By Clonkonaut Date 2017-11-27 17:29

> 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.
Reply
Parent - By Marky [de] Date 2017-11-27 17:32
I'd still give one for free to objects that would be useless without one, so those already have the station and you can attach the wire to them just like that.
Parent - - By Zapper [de] Date 2017-11-27 17:43

>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?!
Up Topic Development / Scenario & Object Development / Basic functionality for switches
1 2 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill