Messages

226

Modification Help / Re: How to Register Preferences (Support_Preferences)?

« on: November 17, 2017, 09:43:06 PM »

So apparently, if I run

Code: [Select]

ForceRequiredAddOn("System_BlocklandGlass");

instead of

Code: [Select]

ForceRequiredAddOn("Support_Preferences");

then registerPref works just as expected.

*shrugs*

227

Modification Help / Re: How to Register Preferences (Support_Preferences)?

« on: November 17, 2017, 09:27:35 PM »

Also, I'm not sure why

Code: [Select]

ForceRequiredAddOn("Support_Preferences");

doesn't work. I returns -3 ($Error:AddOn_NotFound) tells me "Support_Preferences" is not a valid add-on, despite Support_Preferences.zip being obviously in my add-ons folder.

228

General Discussion / Re: Favorite Old-School Blockland Minigames?

« on: November 17, 2017, 07:21:47 AM »

gamemode_zombie

I assume you're referring to Rotondo's Gamemode_zombie (the download for the original map is still available on that page, btw). I remember it's inception being as big a game-changer as the introduction of City RPGs.

229

General Discussion / Re: What Makes a Good (and Bad) Prison Escape?

« on: November 17, 2017, 07:13:31 AM »

What building features should a prison build have? Looking at prison layouts online, I gather

• Cell Block
• Guards' Quarters (with Armory)
• Front Gate
• Canteen and Kitchen
• Recreation Yard
• Study
• Hospital
• Warden's Residence
• Solitary Confinement
• Administrative Offices
• Storage
• Visiting Room

Let me know if I'm missing anything.

Which of these implements do you feel is good for a PE? Should they all be included to some extent, or should prison layouts be trimmed down for better playability?

230

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 06:59:04 AM »

I ran your script and it parsed perfectly. However, it will display a warning for the colors if they don't exist in the colorset. Also, I noticed that on line 21 it didn't have any delay, which will destroy the whole purpose. I've put 2000 delay on it and will update all my examples to this instead and credit you.

Woops! I was trying to demonstrate how you don't need brackets, but I forgot what my own events were supposed to do lol.

Looks like you are using an Add-On that might modify the default layout so when I read it I get bogus data. If so, please tell me and I'll find a fix around it.

I am using Make Events Great Again. I'll make sure to disable it if I do any more testing in the future.

I think that labels at all is dirty. It's frowned upon in all languages but where it came from. It is sometimes a necessity, though. In our case, we're not using it like others are using it, so adding labels in such a fashion might confuse people, or make it obvious to them.

Yes. Labels are typically considered bad practice in C. They are really only present for historical purposes. But, as you said, our use case is different. Eventing is not C. It's more like an instruction set. So for a more apt brown townog to event, look at any assembly language. In assembly, labeling and jumping is quite common (e.g. labels in x86 Assembly). In fact, it's pretty much necessary.

Keep in mind, that when labeling is used with indexing [from:to], it's not obvious that it's to-1. By having it at the event, it might make it more apparent that we are aiming at the event, instead of the event after it.

This is actually a bit of an oversight on my part. It hit me earlier what I had done wrong. It might be better to not auto-decrement the second value in an interval like I did implicitly. Rather, [from:to] should be written like [from:to-1] to avoid confusion. This would be more intuitive to programmers (who will probably be familiar with MATLAB and Python slices) and non-programmers.

I get what you're saying about aiming labels at an event. It makes more sense in the context of the auto-decrement critique. But of course, people could always choose to write labels as

Code: [Select]

# Turn light on
onStart: [x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled([offStart:offEnd], 1)
onEnd: [x][0]onActivate->Self->setEventEnabled([onStard:onEnd], 0)

# Turn light off
offStart: [][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([onStard:onEnd], 1)
offEnd: [][0]onActivate->Self->setEventEnabled([offStart:offEnd], 0)

Another benefit of explicit, non-bracketed labels is that it might actually make code a bit more intuitive, and hence make parsing easier to a certain extent. If we go with bracket notation, we have to consider four different cases:

• no brackets - default behavior
• 1 bracket - label (?)
• 2 brackets - no label, enabled and delay
• 3 brackets - label, enabled, and delay

This would require you to pre-parse each set of brackets, and then decide how to treat each of them.

But with labels declared separately with colons, we only have to consider two cases for brackets:

• no brackets - default behavior
• 2 brackets - enabled and delay

I imagine this would require less (or no) pre-parsing, as the presence of a forward brackets indicates that the second case is the one to consider.

Another option could be blocking instead of labeling, e.g.

Code: [Select]

# Turn light on
lightOn {
[x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled({lightOn}, 1)
[x][0]onActivate->Self->setEventEnabled({lightOff}, 0)
}

# Turn light off
offStart {
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled({lightOff}, 1)
[][0]onActivate->Self->setEventEnabled({lightOn}, 0)
}

Albeit less flexibly, this feels more intuitive, and it looks a bit nicer to me. If we want to increase the flexibility of this method, we could allow for the inclusion of multiple blocks in a block reference, i.e. {label1, label2, label3}. And as the cherry on top, this method would probably be the easiest to code up, as it doesn't allow/encourage the use of arithmetic inside intervals/block references.

I would say, too, that the ability to nest blocks need-not and should-not be implemented with this. Eventing is more 1-dimensional than most programming languages, and hence doesn't need such complexities. Plus, nesting would add a whole other layer of complexity to the code.

231

General Discussion / Re: Favorite Old-School Blockland Minigames?

« on: November 17, 2017, 04:55:01 AM »

Snipers vs Runners

Didn't realize this gamemode had a history. How far back does this gamemode go? This is the oldest record of it I can find (2011).

Bushido/Heedicalking TDM's

These were the best.

232

General Discussion / Re: EventScript - Eventing 2.0

« on: November 17, 2017, 04:46:59 AM »

Labeling was considered once while I was developing, but not something that was required. However, with your ideas I think it's entirely possible now. I've added an issue for it and will implement it while I'm redesigning the parsing algorithm. The redesign is important to solve several issues that was raised for the current design (Like: incorrect line numbering in certain cases; unable to locate certain errors).

That's good to hear! Best of luck on the redesigning. Making parsers is a bitch.

Due to how the function findText works, that is not possible. However, if I can somehow use the event global variables myself, then I would find a way around to add this sort of functionality. Don't hold your breath, though, but I've already added it as an issue.

Looking at the relevant code, I can see that now.

That is true. Would you mind to provide an example script? The current example is hastened just thrown together and does absolutely nothing of value and I'm not sure I can make a easy to understand event as possible.

Sure. How about this?

Code: [Select]

# Makes a brick change colors on a loop when toggled

# Start color changing (start with events enabled)
[x][0]onActivate->Self->playSound("Beep_Checkout.wav")
[x][33]onActivate->Self->fireRelay

# Stop color changing (start with events disabled)
[ ][0]onActivate->Self->playSound("Beep_Denied.wav")
[ ][0]onActivate->Self->cancelEvents

# Alternate between starting and stopping color changing
[x][0]onActivate->Self->toggleEventEnabled("0 1 2 3")

# Change colors
[x][0]onRelay->Self->setColor("0.898039 0.000000 0.000000 1.000000")
[x][500]onRelay->Self->setColor("0.898039 0.898039 0.000000 1.000000")
[x][1000]onRelay->Self->setColor("0.000000 0.498039 0.247059 1.000000")
[x][1500]onRelay->Self->setColor("0.200000 0.000000 0.800000 1.000000")

# Loop color changing
onRelay->Self->fireRelay

# Stop color changing when brick is blown up
onBlownUp->Self->cancelEvents

Please note that I couldn't get the latter code to import to a brick. In fact, I tried pasting

Code: [Select]

[ ][500]onBlownUp->Player->Kill

from your example, and it gave me an error. It tells me I have an invalid amount of parameters.

Also, copying code from in-game does not seem to work. For instance, when I copy the aforementioned events from a brick, it gives me

Code: [Select]

[ ][0]  -> "" -> 
[ ][0] 0 -> 0 -> 0(0, 0, 0, "onActivate", "Self", "playSound", "Beep_Checkout.wav")
[ ][0] 0 -> 0 -> 0(0, 0, 33, "onActivate", "Self", "fireRelay")
[ ][0] 0 -> 0 -> 0(0, 1, 0, "onActivate", "Self", "playSound", "Beep_Denied.wav")
[ ][0] 0 -> 0 -> 0(0, 1, 0, "onActivate", "Self", "cancelEvents")
[ ][0] 0 -> 0 -> 0(0, 1, 0, "onActivate", "Self", "toggleEventEnabled", "0 1 2 3")
[ ][0] 0 -> 0 -> 0(0, 1, 0, "onRelay", "Self", "setColor", "0.898039 0.000000 0.000000 1.000000")
[ ][0] 0 -> 0 -> 0(0, 1, 500, "onRelay", "Self", "setColor", "0.898039 0.898039 0.000000 1.000000")
[ ][0] 0 -> 0 -> 0(0, 1, 1000, "onRelay", "Self", "setColor", "0.000000 0.498039 0.247059 1.000000")
[ ][0] 0 -> 0 -> 0(0, 1, 1500, "onRelay", "Self", "setColor", "0.200000 0.000000 0.800000 1.000000")
[ ][0] 0 -> 0 -> 0(0, 1, 2000, "onRelay", "Self", "fireRelay")
[ ][0] 0 -> 0 -> 0(0, 1, 0, "onBlownUp", "Self", "cancelEvents")

which can not be pasted into another brick.

I just thought about an another way to add labels, by using existing syntax.

Code: [Select]

# Turn light on
[on1][x][0]onActivate->Self->setLight("Player's Light")
[on1][x][0]onActivate->Self->setEventEnabled([offStart:], 1)
[on1][x][0]onActivate->Self->setEventEnabled([on1, on2, on3], 0)

# Turn light off
[offStart][][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([on1, on2, on3], 1)
[][0]onActivate->Self->setEventEnabled([offStart:], 0)

As long as names within the square brackets doesn't contain only one x or only numbers(Nothing bad, as labels starting with numbers are not supported anyway), then it's considered a label. As before, this can be placed anywhere before the input name. This solution will allow the following:

• Labels are connected to the event, not confused to line, hence easier to read (Subjective)
• Opts to the current semantic of optional starting arguments (Might be confusing to some)

Of course, it has it disadvantages:

• Moving around events with labels might be more troublesome (Solved by placing it on its own line, wont break with semantic)
• Loss of labels named x (Who even want that?)

This is just a possibility. I still might end up using C-like labeling like Platypi suggested.

While this would be simpler to parse, it's a bit clunkier, as per the disadvantages you listed. It's probably a bad idea to have labels attached to events. Granted, your label could always be listed like this

Code: [Select]

# Turn light on
[on1]
[x][0]onActivate->Self->setLight("Player's Light")
[on1]
[x][0]onActivate->Self->setEventEnabled([offStart:], 1)
[on1]
[x][0]onActivate->Self->setEventEnabled([on1, on2, on3], 0)

# Turn light off
[offStart]
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([on1, on2, on3], 1)
[][0]onActivate->Self->setEventEnabled([offStart:], 0)

which would solve that problem. However, it doesn't change the weird naming problem. To fix that, you could simply pre-parse the square brackets at the beginning of an event listing, and allow the first to be named anything if 3 sets of square brackets are present instead of 2. It still feels a tad dirty from a coding perspective, though.

233

Modification Help / [SOLVED] How to Register Preferences (Support_Preferences)?

« on: November 17, 2017, 03:48:44 AM »

I can't seem to figure out how to create server preferences. All the examples I can find use RTB preferences, and I would prefer to use a more up-to-date standard. Namely, I want to create something that would work with Blockland Glass. I'm under the impression that Support_Preferences is the preference system that Blockland Glass uses, as per their documentation. But I can't get it to work. I tried mimicking the code found in this file. Here's my code:

Code: [Select]

registerPref("Test", "General", "Test", "number", "$Pref::Test::Test", "Support_Preferences", 50, "1 100 0", "updateServerSetting", 0, 0, 0);

I ran it, but it didn't work. I opened the Preferences tab in the Blockland Glass Server Settings. But nothing showed up. I tried

Code: [Select]

echo($Pref::Test::Test);

But it displayed nothing. However, when I run

Code: [Select]

echo(TestPrefs.getObject(0).variable);

it outputs $Pref::Test::Test. I did not get an error message when I ran registerPref, so I'm not sure what I did incorrectly.

234

General Discussion / Re: older blockland user check-in.

« on: November 17, 2017, 01:08:17 AM »

Thorfin25
I still miss my friend. I think many people do..
https://forum.blockland.us/index.php?topic=278417.0
https://forum.blockland.us/index.php?action=profile;u=30543

Oh stuff... I didn't realize he'd died... Can't say I knew him well, though. I'd just seen him and his name around.

235

General Discussion / Favorite Old-School Blockland Minigames?

« on: November 17, 2017, 01:05:13 AM »

I'm mainly talking about before version 9. Things things like pushbroom sumo.

I'm thinking about putting together a gamemode that alternates between revived versions of classic minigames. But I'm having trouble remembering much from a decade ago. Help jog my memory and jack off my nostalgia snake.

236

General Discussion / Re: older blockland user check-in.

« on: November 17, 2017, 12:52:11 AM »

Sorry if I forgot your name or doubled it, it happens, let me know and I'll correct it.

IGN: SadBlobfish

EDIT: just noticed you put "Platypi" instead of "SadBlobfish". I keep forgetting what my forum name is (yes, I know I've had it for years :P). Neeevermind...

237

General Discussion / Re: EventScript - Eventing 2.0

« on: November 16, 2017, 02:06:47 AM »

Honest to God, I was thinking about something like this the other day. It's one of those things we've needed for a long time, but no one has bothered to release until now. I love how simple and embedded the interpretation is. I might actually do something with events now that it's this easy. Thank you!

I appreciate that the debug info gives the line number for the script, not the event ordering.

I do think the script should be case-insensitive, though. TorqueScript is already case-insensitive, so it should cause any conflicts. Hence, making things case-sensitive seems to add an unnecessary level of complexity. Any reason why you opted for case-sensitive?

Also, does EventScript currently have anything to simplify setEventEnabled and toggleEventEnabled? Event toggling has always been the most frustrating part about eventing for me. Could you add some sort of labeling feature (similar to labels in C)? For example, take this script for a simple lamp:

Code: [Select]

# Turn light on
[x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled("0 1 2", 0)
[x][0]onActivate->Self->setEventEnabled("3 4 5", 1)

# Turn light off
[][0]onActivate->Self->setLight("NONE")
[][0]onActivate->Self->setEventEnabled("3 4 5", 0)
[][0]onActivate->Self->setEventEnabled("0 1 2", 1)

With labels, it could instead be rewritten as

Code: [Select]

# Turn light on
onStart:
[x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled([offStart:offEnd], 1)
[x][0]onActivate->Self->setEventEnabled([onStart:onEnd], 0)
onEnd:

# Turn light off
offStart:
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([onStart:onEnd], 1)
[][0]onActivate->Self->setEventEnabled([offStart:offEnd], 0)
offEnd:

Or

Code: [Select]

# Turn light on
onStart:
[x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled([offStart:offStart+2], 1)
[x][0]onActivate->Self->setEventEnabled([onStart:onStart+2], 0)

# Turn light off
offStart:
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([onStart:onStart+2], 1)
[][0]onActivate->Self->setEventEnabled([offStart:offStart+2], 0)

Also

Code: [Select]

# Turn light on
on1:
[x][0]onActivate->Self->setLight("Player's Light")
on2:
[x][0]onActivate->Self->setEventEnabled([offStart:], 1)
on3:
[x][0]onActivate->Self->setEventEnabled([on1, on2, on3], 0)

# Turn light off
offStart:
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([on1, on2, on3], 1)
[][0]onActivate->Self->setEventEnabled([offStart:], 0)

Labels have their own line and are followed by a colon, ":". Square brackets, "[]", enclose intervals. Colons fill in the gaps between two labels. A colon with nothing following it includes everything after. Likewise, a colon with nothing preceding includes everything before (think Python slices or MATLAB indexing). Labels can be incremented within an interval (e.g. onStart+2). Finally, commas separate separate labels. Each comma could include a separate sub-intervals (i.e. with colons). Hopefully that makes sense. Take it as a suggestion. Some cleaning up/reformatting is probably would probably be good.

I think this would be useful for many reasons. For one thing, the line number in your text editor would not necessarily correspond with each event's order number. If you had even one comment, it would put everything out of wack. Secondly, labels would make it a lot easier to reorganize events. This is something that is particularly frustrating and tedious to do with events in vanilla Blockland, and we should seek to make it more painless.

I would also recommend not including onActivate->Self->fireRelayNum in your example script, since it's a non-standard command. I was momentarily confused when I tried to paste your code, and it didn't work.

238

General Discussion / Re: Things you still cant do ingame

« on: November 15, 2017, 07:43:58 PM »

Finish anything.

Same...

sigh

239

General Discussion / Re: is blockland fun?

« on: November 15, 2017, 07:36:45 PM »

I would say yes, but I acknowledge that I have been conditioned from repeated exposure from a young age.

Badspot is basically an unwilling cult leader.

I am at least confident in saying the community is stuff.

I actually love you guys xoxo

240

General Discussion / Re: Servers you thought were short-lived

« on: November 15, 2017, 04:20:23 AM »

Rooftop Knife TDM and Rooftop bounty hunter
Idk why i have such fond memories of rooftops

Rooftop bounty hunters was so much fun.

Rooftop maps are just a good setting for anything resembling a DM if done right. It's just so fun to jump between buildings.