Just how stable are the string manipulation commands?

[Pastrey Crust]

Thanks for the limit Zeblote but I wasn't referring to using the names just to save. I was planning on using the name as the variable holder. How would that work out with a ton of string manipulation functions or am I better off just using the name to save/load?

Code: [Select]

function SomeBrickObject::onPlant(%this) //the parameters are different by default. this is an example
{
     parent::onPlant(%this);
     $variable[%this] = blah;
     or %this.variable = blah;
}
Using the objects name will apply the function to all instances of the object, regardless of the object's ID. As soon as said brick is planted in any way, the data will be applied to that object.
Correct me if i'm wrong, zeb


Alright, that makes sense. Thanks for clarifying. Also i'm assuming I should ignore that change if I'm intentionally making a variable that is destroyed when the player object is destroyed/killed, such as a health value, armor value, etc.

Path, your code is correct, but you're missing the point. Object IDs change with server reboots/shutdowns. They aren't static even with the same save. I need to set different values to different bricks with different parameters making what you're suggesting useless and a need-lessly mixup. What I need to do is save and load the values of the bricks in a hassle-less way which would be the .bls path. Also, take into account that onLoad(plant?)(%brick) is called when loading bricks rather than onPlant(%brick).

[Ad Bot]

[Dannu]

The most reliable way imo is still the event thing. Just learn about it, test it out. The capability of adding multiple events gives you the possibility of more easily seperating different fields.

[Zeblote]

Thanks for the limit Zeblote but I wasn't referring to using the names just to save. I was planning on using the name as the variable holder. How would that work out with a ton of string manipulation functions or am I better off just using the name to save/load?

No, that's a terrible idea. Use %brick.stuff to store the data normally.

[Dannu]

Use %brick.stuff to store the data normally.

The way I understood it was that he needed to preserve dynamic fields on bricks through server resets.

[Pastrey Crust]

The way I understood it was that he needed to preserve dynamic fields on bricks through server resets.

YEs, I do but if the server crashes, the .bls doesn't get updated so it would have the same effect as saving in the name and loading from the name so I'm going to do as Zeblote suggests.

[Dannu]

Then run a periodical saver. If the server crashes, you're going to lose the build progress past the last saving either bloody way.

[Pastrey Crust]

No stuff, Sherlock.

[Path]

I believe brick names are stored in .bls save files. You can easily use the brick name instead of the object id or object name.

If you name a brick test, i think test.variable = 1; will actually work, though I might be mistaken.
There's a function that is called when a build is loaded. You can just package the variable storage into the bricks when the function is called.

If you're picky and you want to narrow it down, you can check if the brick named 'test' is the child of a certain brick object you want to use by easily calling an if() statement

[Pastrey Crust]

Path, I don't want to be rude or anything but did you even read the thread? We've been discussing since page 1 whether or not it would be a good idea to save the data in the brick's name with the reason being that it gets saved in a .bls file.

As for the test.variable = 1; I'd need to try it to tell you and I'm aware of the load function in which I even mentioned it to you previously.

[Pastrey Crust]

No, nevermind. Character limit is 32 characters and I need much more than that. Dannu, how would you do your event procedure?

[Dannu]

I don't want to be rude or anything

That ship has long sailed, pal.

[Shift Kitty]

Why not use event parameters?
Make an input that doesn't do anything called special.
Target is only self.
Output event for fxdtsbrick called parameter.
Store long string on that.