Archive: 8 posts

---

So over the past week I've been trying to construct the logic for a dungeon crawler full with items, levels, skills, equipment, and all that jazz. However recently I have run into a little snag. While working on status effects I was trying to find an efficient way to calculate stacking resistances that could easily be turned on/off, added and subtracted. (All logic I had wanted designed to be self contained) I ended up creating a grid of magnetic key switches to determine how much resistance the character would have. [1 key being 1%]. In this way I thought I would be able to have each item with its own stats that I could easily turn off and on when equipped. Here are the problems I am facing: Magnetic key switches do not seem to read magnetic keys within the same microchip. So I would have to have the player status and equipment in separate entities. Magnet Key Switches don't read exact number of keys, rather they look at 'at least' which causes many issues to my intended logic with minimal logic. [Having to write conditionals for 'x keys and not more' would at least triple the logic needed/+1 magnetic key switch; +1 and gate]. So my question is thus, is there any easy way to rectify these issues or am I going to have to completely rewrite this setup? Thank you for your time and consideration, ~Manifusion

2011-02-08 23:43:00 Author: Unknown User

---

So my question is thus, is there any easy way to rectify these issues or am I going to have to completely rewrite this setup? You'll probably need a rewrite, but it's not exactly clear what you're trying to achieve.

2011-02-09 01:41:00 Author: Aya042 Posts: 2870

---

http://img16.imageshack.us/img16/716/dungeoncrawler.jpg I'm trying to create a script to manage resist % from 0% to 99% ; 100% = Immune. This is what my rewrite looks like so far. Was hoping I could minimize the logic instead of having 2 mag key checks per effect duration. What I plan to do is have the inventory as a separate entity that follows around each character, when a gear is equipped it will turn on tags equivalent to its stats. Thus something with 6 frost resist tags would give 6% resist and change the duration accordingly.

2011-02-09 02:32:00 Author: Unknown User

---

Just a tiny comment here, that looks awesome. Looking forward to it.

2011-02-09 03:02:00 Author: Cronos Dage Posts: 396

---

How about an AND/NOT gate combo? Example: You want 2 tags exactly. Tag sensor (2) -> AND Tag sensor (3) -> NOT -> AND This will give you a sensor that gets exactly two tags. For 100% you would unfortunately need to repeat this many times.

2011-02-09 03:55:00 Author: dcf Posts: 468

---

http://img130.imageshack.us/img130/7853/aphotoc.jpg What I have done is set 2 mag key sensors. 1 For the count you want, and 1 set 1 higher than what you want and set to reverse input connected to an and gate. This does cost 3 logic per microchip activation , and wanted to avoid. But it was inevitable. I finally set them all up, but now my issue is that timers have a tendency to switch priority of wires when it comes to input and reset when nested in microchips so that it will take the tag switch as input first and reset second, thus making it so it won't count up. [Making it so that the effect will not dissipate.] Is there a way to order the wires to always go in order without putting a delay on the input wire? Edit: Well I found a solution, however it requires 3 more logic per timer. Anyways I added an impact switch into the timer microchip itself along with another or gate and counter. It works properly even if the wires change priority. For some reason the microchip nesting seems to be the issue.

2011-02-09 04:16:00 Author: Unknown User

---

What I plan to do is have the inventory as a separate entity that follows around each character, when a gear is equipped it will turn on tags equivalent to its stats. Ah. That's a little clearer. First of all, that Tag Sensors can't detect tags on the same circuit board is a fundamental limitation, and there's no way 'round it really. If the goal is merely to count the number of nearby tags (for this example, let's say up to 5), create a 6-port Selector. Plug a battery into port #1, a Tag Sensor set to detect 1 tag into port #2, a Tag Sensor set to detect 2 tags into port #3, etc., so the 5 Tag Sensor will go into port #6. Since the Selector only activates the highest of the enabled input ports, then you end up with a system whereby the activated Selector output indicates how many tags are in the vicinity, where output port #1 means zero tags, and output port #6 means 5 (or more) tags. There might be a better solution involving the summation of analog signals, but I think it would only work if it were never possible to have two instances of the same item equipped at the same time.

2011-02-09 08:18:00 Author: Aya042 Posts: 2870

---

Ah. That's a little clearer. First of all, that Tag Sensors can't detect tags on the same circuit board is a fundamental limitation, and there's no way 'round it really. If the goal is merely to count the number of nearby tags (for this example, let's say up to 5), create a 6-port Selector. Plug a battery into port #1, a Tag Sensor set to detect 1 tag into port #2, a Tag Sensor set to detect 2 tags into port #3, etc., so the 5 Tag Sensor will go into port #6. Since the Selector only activates the highest of the enabled input ports, then you end up with a system whereby the activated Selector output indicates how many tags are in the vicinity, where output port #1 means zero tags, and output port #6 means 5 (or more) tags. There might be a better solution involving the summation of analog signals, but I think it would only work if it were never possible to have two instances of the same item equipped at the same time. Ah, thank you for the confirmation on that. I will have to make separate entities [Character Info; Items & Equipment; [Character] as a work around. I tried doing something like that originally, except having 2 selectors, one determining the ones digit and the other the tens digit, however it refused to work as I had intended as well as became very laggy to change due to wire distribution. I ended up scrapping the entire system before coming on here. I was first considering the use of analog signals for this, however I'm still not comfortable using and testing that logic to use it yet. It would be fantastic for armor, health, and damage calculations later on though - If I can find a way to properly use it. At the moment I have the status effect logic all ironed out and tested. It works beautifully, but now I'm wondering how I am going to manage the effect on movement speed adjustment, in conjunction with other movement altering effects and blocking. FYI. You're one of my LBP heroes Sir Aya042.

2011-02-09 08:30:00 Author: Unknown User

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.