Indomitus

Interesting. Didn't think to try SCALE. The first NONE would be the vehicle, of course. What about the second one? I thought that took a vector.

I could see that getting very complicated very quickly. Both from BI's perspective designing it, and from our perspective using it. BUT... Maybe it could work with a "source" coordinate (as if it were a player's position if they were using the Terraformer) and a target coordinate, plus a Terraformer action to perform on that location? With a few pieces of information, maybe it could simulate what the Terraformer would do.

Lately I've been using the Delay command to create timed loops that are completely internal to an object, no external code needed. I know that it would still not be good to have a loop timed to 0.03 or anywhere near it, just like with the timers. My question is this: Under the same conditions, would one method be better than the other? Would it, for example, be more resource intensive to have a loop built into an Entity Storage that is attached to every player, or a single timer object that sends a command to each player's ES to run the same logic in a FOR EACH loop. I've heard that Timers are currently considered unreliable in online MP, but I haven't done much testing of my logic online (yet). Not to get too technical, but I worry about how it might affect the stack if the loop runs for too long with a procedure essentially calling itself each time, even if it is the very last line in the sequence. (And just to make sure I mention this: My Delay loops normally have some way to activate and deactivate them, built in.)

Making adjustments to the cave creation algorithm?

Quick update: The trick seems to work with any container in your inventory. The only difference is that the Urn doesn't restrict what it can hold. (I just tried it with the Coal Bucket, and it worked.) And I tried it with a stack higher than 1 in the Coal Bucket. It multiplied the coal even faster. Wow, what a glitch.

I found it. Gate house, hidden lower room with the alchemy table. I opened the game in my editor and captured the Urn into a composition... for research purposes. Here's how I think it's glitched: While working on some game logic, I noticed that a player (container) doesn't just drop an object. It despawns out of one container and respawns into the other. Saw this with traded items losing their custom names and labels, and that there's not a direct command to make a player drop an item. The despawn simply isn't working right on this specific urn. How to do it: Place the urn in your inventory, and put a single unit of what you want to copy into it, alone. In the destination container (something you're not carrying) place at least 1 stack of 1 unit of the item to copy. You can use CTRL+Drag to make multiple stacks of 1. Open the destination container, then go into the Urn in your inventory. Start right-clicking on the item in the Urn. It will fill every stack you have started in the other container. You do have to click for each one, though. Since you have to have a stack started, the trick doesn't work with anything that doesn't stack (as far as I can tell).

I'm not sure if I'd want it to be permanently bound, but it would be nice to have a book/binder container that we could use to store and organize papers. I have a custom map in mind for later that would be a story/mystery with diary pages as clues.

It can be done. It just has that glitch sometimes. When you place a chest on the ship, go to the anchor and raise it. Let the boat rock a little, and check to make sure the chest is moving with it. If it is not, you should still have time to hit it and deconstruct it, then lower the anchor and try again.

Brick is a nice material to build with, but the main problem with it is that is consumes clay, which can be a valuable resource and hard to get enough to build anything. Mud Brick doesn't use clay. The real ingredients are basically mud, sand, and straw. In Ylands, that could be dirt, sand, and hay. Those are all very plentiful in the game. And since real mud bricks are usually hardened with fire, they could be made in the kiln. They would be less durable than clay bricks, but much easier to get the ingredients to make them.

The first thing I notice is the Pirate Chests at the rear of the ship. Were those meant to be placed on the deck? This might be the same issue we have seen, with objects being placed in the World grid rather than the Boat's grid. If that is the case, your ship might be pushed down because it is colliding with those chests. Since the chests won't move, the ship gets pushed under the water. The only fix I know of for that (if that is the problem) is to destroy the chests, OR open the map in the Editor and place the chests manually.

I thought it was fun as well, maybe just incomplete, and definitely too many servers of it. BI should consider more of a mixture of Gold Rush, explore maps, and possibly some other game modes that the community builds, if they're good enough.

While trying to create a hat that was scripted to automatically equip itself when picked up, I found a strange glitch. It does equip, but still remains in the player's hands if it goes into any slot of the hotbar. It makes it look as if there are 2 of the item. When it is active in the player's hands, they can press X to drop it. This removes the one from the player's head, but not the one from their hands. BUT there is nothing left in the inventory, and pressing X will not drop another hat. It also does not trigger the "Item Removed From Inventory" event in the hat (or in an Event Listener). If I manually unequip it and move it into Inventory, then drop it, the script triggers correctly. It's a strange error. Maybe the video can explain better: It happens with anything equipped on the body. Event Listener also does not detect item dropped directly from being equipped on the body. Attaching all logs, and the test scenario shown in the video (with a couple more test items added to it). output_log.txt output_log_clean.txt output_log_game.txt MY_GAME_NAME(8).zip

I'm working on an idea that would need a separate color for each player. Trying to make it work for up to 16 players, so I need 16 distinct colors. Do you think these colors are different enough from each other? I had to apply some alpha to a few to get it this far.

That's better. Still not fond of Gray, on the end, but that's #16 and there's plenty of time to fix it.

It would be super easy for griefers to exploit, and insert inappropriate images. And possibly increase load times for the game. I recall that being an issue when players figured out a glitch for importing artwork into Little Big Planet.

Thanks, I was worried most about those 2 rows. I'll try a few more options. Forgot to mention, the colors have to apply to blocks, too, to identify parts of the play area they've claimed. If I can only get 8 good colors, then I'll design it around that.

1-click to eat: I always reserve one of my hotbar slots for food. That way, I just hit the number key, eat, then switch back and continue what I was doing. Bags: I would love to be able to craft a backpack for extra carrying capacity. The trick is doing it in a way that requires it's worn on the back. Otherwise, a player could fill their inventory with those, and have almost infinite capacity. And I've seen that urn. I've carried it a few times, but never found that bug. That's interesting.

Today I started playing with options for building a game timer without using a timer object (using the DELAY tile instead) and realized that the same technique could be applied to "Move Or Die" style logic. If you've never played Move Or Die, it's a fast-paced VS game, and one of the main mechanics of it is that if you stand still for too long, you die and automatically lose that round. To stay in the game, you have to keep moving. I figured that could be a fun game mechanic to have in Ylands, if someone comes up with a game mode to use it. Here's the results. Have fun with it. I'm just posting screenshots for now, since it's actually pretty simple code. The main code is in an Entity Storage. All of the variables being used are listed under the "On Create" event. Those would need to be defined in the Variables section at the left. Certain ones are just values you can change to adjust the behavior of the logic. And of course the "DisplayTimer" routine can be changed or even removed depending on the needs of the game. To make it work, this is the code I added into a Player Role object. The Delay tile in this part is completely optional. One possible variation could be: If the move distance is higher than the minimum, where it currently sets "MyStandStillTime" to 0, it could instead subtract the "TimerInterval" (or a different value) to make the time act like regenerating health instead of resetting all at once. Another variation could use the player's actual Hit Points instead of a timer. That would give a built-in display and warning when it's running out.

A Return tile is basically an "END" command. It tells the script to exit the routine. There's a plain one, and one that can return a value, so you have to use the one that matches the block of code you're in. If that code was called from somewhere else, it will return to the next line back there. The Delay tile does kind of the same thing. It will end the block of code, so it has to be at the end, or inside a piece of logic where it's okay to exit the routine (like inside an IF block).

What if the game is hosted on a server?

Even though this might be considered a "community creation" I think it's more useful in the Visual Scripting section, so I'm putting the post here. In the P1 chat today, someone asked about the logic I was using to sort scores for the leaderboard. (I forget who asked, I'm sorry.) For the benefit of all the creators here, I have built a universal version of the logic, that can be easily added to any scenario. Feel free to use it, modify it, examine it and learn from it, whatever you want. If you have questions, please ask, and if you find bugs or have suggestions, please let me know. You can find it in the Workshop: https://workshop.ylands.com/asset/794

Everything stops when the script encounters an error, no matter where the error is, even if that error takes place in a separate method or instruction that is being called. I've seen this too many times to count. (If there is more than one running at the same time, I think only the one with the error will stop, but I'm not 100% sure of that one.)

If you like one you've generated in the editor: 1. Save the scenario. 2. Go to the "Games" menu 3. At the top, choose "My Local Games" 4. Your saved scenario should be in that list. Click it and choose "Start New Game" 5. Set the options as you would like, including setting online mode to "Multiplayer" 6. Have fun!

I just did a little testing, was easily able to replicate it of course, and here's a possible option: If you scale the zone on the Y axis to about 30-40 meters thick (or more) it will eventually trigger after they recover from the ragdoll. There is still the strange moment when they stand up in mid-air and start falling again, but at least it would put them back up onto your map like it's supposed to.

I don't know if there are already plans for such a feature, but I had an idea about it this morning and thought it best to at least mention it. We've requested before (or at least I know I have) for the ability to copy or move blocks of code from one object to another. I have a thought on how that could be done. In the script editor, on the left are the categories for script commands and methods. I would add a section (at the bottom, maybe) called "Clipboard" or something descriptive like that. Instead of containing a list of script commands, it would contain 1 or more SPACES where blocks of code can be dragged and stored. They would be spaces separate from the object where the code is not executable, just held as a copy for dragging out into a new location later. It could be persistent for that scenario at least, and possibly across all scenarios. A possible extension of this idea would be the possibility of being able to build a small personal library of custom routines, almost like compositions of nothing but script code, accessible through the script editor.