Search results

No you're right. As I stated: Just cleaning up prefixing 0's.

Jaaskinal Posted a far better solution than what I was trying to do.

I agree with OP, a [SEARCH] of some sort would be great In the meantime you can do something like: *Edit: Scroll down to see better solution from Jaaskinal* Copy the display module's content, run regex on that module: [REPLACE]\b(?!starmade\b).*?\b[WITH] (replaces anything that isn't the word...

Fellow Starmadian You're right, however it turns 10 into 09 w/o the repeated step 2. Atleast it turns 09 into 8. :).

And counting down is like: [REPLACEALL]\b([0-9]+)\b[WITH]$1~09876543210 [REPLACEALL]\b0|([0-9])(?=0*~[0-9]*?\1([0-9]))|~[0-9]*[WITH]$2 [REPLACEALL]\b0|([0-9])(?=0*~[0-9]*?\1([0-9]))|~[0-9]*[WITH]$2 Note, step 3 is the same as step 2, so you can just repeat that step w/ your logic. Cool hex'o...

Welp, yes please. I'm not convinced about using Zip to solve the problem. But this is clearly a problem that deserves attention by the developers.

I do not believe the depth of the of the folder structure is the cause of that error. - I'm not sure what is, but that certainly is an issue that should be addressed - under the category of bugs. Objects in the game can get very large, and adding a compression step E.G. Zip can very easily...

Join Display Module - [PARSE] The Sensor module tweak Crew Display block: option to transfer value of variable instead of reference

Want a long delay? RegEx Logic - Counter ez pz.

Endal Yeah... - I'm working on the problem now. - Two big things stand in my way though; - I'm sick, and... I don't know regex :D. I've gotten this far: [REPLACEALL]\b([0-9]+)\b[WITH]$1~09876543210 [REPLACEALL]\b0|([0-9])(?=0*~[0-9]*?\1([0-9]))|~[0-9]*[WITH]$2 It actually works pretty well...

It's... A solution. I feel like it's the worst-case solution, for when they give up on pathing. Part of what i'm looking forward to with NPC's is to watch them try and navigate the ships I make. - I'm actually hoping they include some purposefully bad pathing, and make it feel like they slowly...

No, unfortunately the displayblock's are viewed much like the sensor blocks views them when doing a [REPLACEALL]. That was actually solution #2 I proposed in your topic. Though, after some thought I don't think it would be for the best. - I feel like a middle-man like the [PARSE] suggestion...

So I was looking for cool things to do with regex and display modules. Here's one really cool thing i've found so far. A counter, It takes 2 steps to do it, but still, really awesome: [REPLACEALL]\b([0-9]+)\b[WITH]0$1~01234567890...

Ah, sorry I missed that topic Thalanor . Yeah, any solution to getting the data out of these display blocks would be pretty awesome. It's like, teased in front of us and we can't reach it! Thanks! I bet they will implement something to get to the data; it feels like an obvious next-step from...

Hi, I would like to suggest adding [PARSE] to the "Advanced Codes" in the display module. For reference please look at the table: Display Module - StarMade Wiki Much like [ADD], [REPLACEALL] it "must be in the very front". Here's what it does: You put "[PARSE]My Favorite Sector: [sector]" in...

Wrong; The output of "[password] + string" is " + string" Edit: removed sarcastic comment... >_> Sorry, frustrated. But stop looking at the display blocks, and start comparing them via sensor block. That's what this topic is about. Not the fact that you see a blank display block when...

They already specifically avoided possible performance issues by using a per-request method. That means the variables could only be requested per-second - which, simply can't cause an issue. The fact that it's able to show a player that information instantly is proof that getting that data once...

This statement is 100% incorrect. The exact opposite occurs. If this suggestion was NOT in place, the sensor would fail, but sense it IS in place already with [password] (but with nothing else), it succeeds. [password] is the only thing that is already following the suggestion of the OP. And yet...

Oh I think I just figured out why you guys are confused... I think you guys think that the "output" of display blocks with "[password]hello world" in it is null (blank). But from the sensor' block's point of view, it's not empty; it contains "hello world" You have block A: "[password]hello...

Wait, you just made the opposite argument. The string "[password]hello" sensor-compared to "hello" is true. That means it IS comparing the output of [password] not the input (which must be null). Because as you can see, those strings are NOT the same. But comparing "[sector]" with "2,2,2" fails...