|
|
Post by CupcakeShiny on Oct 25, 2016 23:39:23 GMT 1
The logic of KoGaMa was thought to be something simple and easy to use, however when something is too simple is also too limited, so listed below improvements in logic that can keep it simple, this improvement only add more configuration options in some logic boxes:
(Configuration suggestions below will NOT replace the settings currently already present in the boxes, just add optionally):
1) set necessary minimum in (and box):
to connect 5 boxes in (and box) we could set the minimum of activated boxes is requered for the (and box) is activated, also we could mark if we want the option (minimum) turn (only ) example:
connect 5 boxes in (and box) I set the minimum required for 3 when 3 boxes or more become activated (and box) will be activated, if we mark the option (minimum) turn (only) if MORE than 3 boxes are enabled to (and box ) will not be activated.
2) set how many items will be activated at the same time (ramdom box):
(random box) enables only one item at a time, you could configure how many items would be activated simultaneously when random box is activated.
3) set for the (lever) to turn OFF when we stop pressing the button (E):
we could set up for that (lever) does not work only as (Troggle Box) but also a (pressure plate),when stop pressing the key (E) the lever will be .turned OFF
4) set the health to (shootable plate): we could set up how much health (shootable plate) will have, because now it can be activated with just one shoot of any weapon.
5) set up separate intangibility invisibility in (model Troggle box):
for those who do not know what it is intangibility (it's when something can not touch nor be touched) we could set up for a template to be intangible (able to pass through it) example:
2 boxes for mark (intangibility) and (invisibility), we could let the invisible model but still we could touch him, or we could leave him intangible but still we could fleece.
6) set up as many times (pulse box) had activated:
we could set up as many times (pulse box) to activate, so she voltase to turn endlessly, we would have to check the box (infinite).
Extra)can make loops with logic: it is impossible to make loops with logic boxes,
example: connected (box 1) in the (box 2) and (box 2) in (Box 3) but is inpossivel connect (box 3) in (Box 1), depending on what you are doing, this limits much when making large logic systems.
(Please developers consider my suggestion, took a long time to write and translate.)
|
|
|
|
Post by Jatsu on Oct 27, 2016 6:41:09 GMT 1
Glad to see other players who like logic. Not a dev, but if I may give some feedback...
1. I don't think they should mess with input/output functionality. Inputs should remain permanently OR'd for convenience. I'd rather see this as a separate box. In fact, the function you're describing is called a frequency or signal counter. Basically it outputs when it receives an equal or greater amount of signals according to a predefined threshold.
2. Use an AND box, or the fall-through box of your choosing, for each individual randomizer output. This will let you attach multiple objects to one random event.
3. Interesting idea, but how would you show that this Lever is different than normal? Also, the player using it wouldn't really be able to do anything else. Maybe it would be useful for a co-op game, but you could just use a pressure pad with an 'E' condition to accomplish the same thing.
4. I like this idea, but again, how do you show that this durable Shootable Plate is different from the default version? Any suggestions?
5. Also love this idea, even though I've been suggesting it for ages. A separate collision toggle setting for Model Enablers would be perfect for simulating glass at low cost to develop.
6. This is an interesting idea. I currently use Timers before Pulseboxes to achieve this, but I sometimes get off-by-one signals due to how unreliable Pulseboxes can be. A more precise way would be beneficial I think.
Extra. Feedback looping would be amazing. There's just a few exceptions that would have to be programmed in to protect the game server, but otherwise it would open up so much more versatility with logic, namely sequential logic.
|
|
|
|
Post by CupcakeShiny on Oct 27, 2016 18:12:10 GMT 1
Glad to see other players who like logic. Not a dev, but if I may give some feedback... 1. I don't think they should mess with input/output functionality. Inputs should remain permanently OR'd for convenience. I'd rather see this as a separate box. In fact, the function you're describing is called a frequency or signal counter. Basically it outputs when it receives an equal or greater amount of signals according to a predefined threshold. 2. Use an AND box, or the fall-through box of your choosing, for each individual randomizer output. This will let you attach multiple objects to one random event. 3. Interesting idea, but how would you show that this Lever is different than normal? Also, the player using it wouldn't really be able to do anything else. Maybe it would be useful for a co-op game, but you could just use a pressure pad with an 'E' condition to accomplish the same thing. 4. I like this idea, but again, how do you show that this durable Shootable Plate is different from the default version? Any suggestions? 5. Also love this idea, even though I've been suggesting it for ages. A separate collision toggle setting for Model Enablers would be perfect for simulating glass at low cost to develop. 6. This is an interesting idea. I currently use Timers before Pulseboxes to achieve this, but I sometimes get off-by-one signals due to how unreliable Pulseboxes can be. A more precise way would be beneficial I think. Extra. Feedback looping would be amazing. There's just a few exceptions that would have to be programmed in to protect the game server, but otherwise it would open up so much more versatility with logic, namely sequential logic. 1) the idea of the topic was only suggest improvements, and no additions, but it's a good idea to add in a separate box. 2) but it would not be possible to do the following: I connect (random box) in 3 more boxes, set (random box) to enable two boxes at the same time (random box) will randomly turn can make several different combinations as (box 1 and box 3, box 2 and box 3, box 1 and box 2), the more connected boxes more combinations are possible. 3) depending on what topic of your project would combine more have a lever that a pressure plate, and if it is something that needs to be activated several times if a pressure plate would have to be jumping on it, since if it is a so lever need press the button (E) sometimes 4) it would have a health bar above 5) would also be good to make invisible barriers if u do not want the players leaving a area espeifica 6)I hate when I can not do something with the logic because the limitations and have to do in a different way and that most of the times does not work right extra) for those who make large logic systems can not do loops always disrupts |
|
|
|
Post by Jatsu on Oct 28, 2016 4:53:15 GMT 1
Regarding randomizers, it is possible to select more than one event at a time. Using fall-through boxes, you have to define every possible combination. Here's your example:  Just note that if you have unbalanced or asymmetric events that you need to pay attention to each combination's probability. In the above example, each should be 33%, which matches with your scenario. But if you wanted, say [fire + smoke] to have a 50% chance, you would just add another AND box connecting those two events, for a total of four possible combinations (even though there would still only be three unique ones). Of course this absolutely sucks if you wanted to connect a randomizer to a huge amount of events. For example, if you wanted to select two random events out of ten, that would be 45 unique combinations you'd need to define. For three random events out of ten, it'd be 81 combinations. |
|
|
|
Post by CupcakeShiny on Oct 28, 2016 15:32:38 GMT 1
Regarding randomizers, it is possible to select more than one event at a time. Using fall-through boxes, you have to define every possible combination. Here's your example: Just note that if you have unbalanced or asymmetric events that you need to pay attention to each combination's probability. In the above example, each should be 33%, which matches with your scenario. But if you wanted, say [fire + smoke] to have a 50% chance, you would just add another AND box connecting those two events, for a total of four possible combinations (even though there would still only be three unique ones). Of course this absolutely sucks if you wanted to connect a randomizer to a huge amount of events. For example, if you wanted to select two random events out of ten, that would be 45 unique combinations you'd need to define. For three random events out of ten, it'd be 81 combinations. if my idea was implemented, we need to do something so big, does not require much effort developers implement my ideas mentioned above in the game, I already thought them to be something simple, I love making systems with the logic of the game, it's fun! however too limited out, what prevents me from doing really great things. |
|
|
|
Post by _kuba787_ on Dec 4, 2016 14:54:55 GMT 1
The thing that is also needed, is the logic which works only on your PC, not on the whole server. There should be another section in the inventory, which will be named "offline logic" or "local logic". When someone now creates an adventure logic system, it must have toggle boxes set to "set on only once". Then, if someone ends some task, it is ended for everyone on the game. We need something that will work only for the person who uses the logic and information about input/output isn't sent to the server. Also the winning condition can be offline - players won't earn xp but the game will restart only for the person who won the game, not for everyone on the game, so the player will be able to win this without resetting the progress. Other idea, is just to create offline projects - the game downloads and any information isn't sent further from the player's PC (only a +1 to players online counter). Local servers aren't offline servers, but I sometimes use them to play alone. But games for one person, even if only one person is needed to play them, can be just boring sometimes, because you don't have mostly anyone to speak with. That's why adding offline logic and offline advanced logic would be a better choice.
|
|
|
|
Post by antusiowskyy on Dec 12, 2016 19:52:27 GMT 1
Adminatoลผy the system is good, but from one I cannot oneself zgodzic from kubฤ
since the system should byc both to the laptop computer and to the computer
|
|
|
|
Post by _kuba787_ on Dec 13, 2016 14:10:59 GMT 1
(Translated by _kuba787_): Devs, the logic is good, but I can't agree with kuba, because the logic should be serverside Old: Adminatoลผy the system is good, but from one I cannot oneself zgodzic from kubฤ
since the system should byc both to the laptop computer and to the computer I understood what you have written here only because I am from Poland. I advise not to use the translator next time. I think, you didn't understand me at all. I didn't mean to change the whole logic. Tell me a game in which when you buy a thing, every person in the server gets that thing. There aren't any games like that. I only meant to add the clientside/offline logic, which will work only on one PC and input/output of this won't be sent to servers. The logic now isn't bad, but it is too limited for us, just because of the fact, that we can't make regular RPG games, even if we know how to make an unexploitable logic combination. But it can't be resetted during the game to make some mission needed to pass for everyone. Clientside flags and sky colors for example will give the possibility to not reset the whole player's progress if someone else wins our game. Clientside advanced logic will give more possibilities of making the gameplay. |
|
