Topic Basic functionality for switches
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to Marky
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 :)
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 :)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill