Just how stable are the string manipulation commands?

[Pastrey Crust]

I need to save a stuffton of data (by stuffton I mean a stuffton) in many, many bricks and I've read that local object variables are inefficient and using global variables would be a pain in the ass due to object ID changing. So I was thinking "The names are saved in the .bls file, why can't I use the brick's name to store my stuffton of data?" so here I am.

How stable are the string manipulation functions and how long can a brick's name be?

[Ad Bot]

[Zeblote]

http://xyproblem.info/

What is this data, where does it come from, why/how do you want to store it, wtf do bls files have to do with this, etc...

[portify]

"object variables are inefficient"
"why can't I store it in strings instead"

This is completely the wrong direction to go in if you care about performance.

[Pastrey Crust]

What is this data

If a brick is flammable, if it was burnt, if it's blazing, its edible values, its properties values, its dryness values, its impurities values, its wetting modifications, its purifying modifications, and so on and so on.

where does it come from

When the brick is placed.

why do you want to store it

To be able to reboot the server without players losing their progress.

how do you want to store it

.bls files.

wtf do bls files have to do with this

"Save Bricks"

etc...

Etc.

"object variables are inefficient"
"why can't I store it in strings instead"

This is completely the wrong direction to go in if you care about performance.

The name string is stored by Blockland, requiring no effort in my part. On the other hand, to easily store all of the data without a salad, I would need to use arrays.

[Dannu]

There is no way to save dynamic fields as such in .bls files. The solution I'd advise is to create mock events. Mock events such as a special event, which takes two fields for example. Run a script before shutting down that loops through every brick, if it has the dynamic fields you're looking for, save the dynamic field name in the first input box as an event and in the second one place the value. Then simply run an brown townogical script when booting up, which applies the dynamic fields and removes the mock event.

Edit: Obviously, you should block off the event to standard use. Just to be sure, you should include a fail-safe, that removes any occurrence of the mock event before anything is added by script.

[Pastrey Crust]

I'm going to need some help with event registering though and its application. I've attempted it in the past and failed miserably. As for the saving in .bls, that's why I was considering using the brick names since no one is going to use it and it indeed gets saved in the .bls file.

[Path]

start off by planting a brick, giving it a name, and then typing name.dump(); in the console.
I don't work with brick objects too often but i'm pretty sure there's a function for finding a brick's object by name or name by object, object id, etc.

Also your best bet is to register object values when the brick object is planted. There's really no better way to do this. You could also create your own script objects with a custom class and assign the scriptobjects to the respective brick. That's the best way to assign data to objects.

And to answer the topic question, they are as stable as the engine itself.

[Zeblote]

You could also create your own script objects with a custom class and assign the scriptobjects to the respective brick. That's the best way to assign data to objects.

No, that's the slowest possible way to assign data to objects.

I think this topic is more about how to save/load stuff in a bls file than coming up with a data structure.

[Path]

No, that's the slowest possible way to assign data to objects.

oh
then what's the fastest? object.value = value?

[Zeblote]

oh
then what's the fastest? object.value = value?

$va[object] = value

Once you start shoveling millions of variables like new dup, the difference can be extreme. Obviously, this isn't suitable for everything.

[Pastrey Crust]

And as mentioned before, that brings me up with the object ID problem. The IDs change with game instances so brick 38390 won't be the same brick in a reboot which is why I want to aviid the coding salad to set the data with it. Back ontopic, are they stable and how long can a brick's name be?

[Path]

so instead of findclientbyname(name).player.armorValue = 1.5; or a similar object value I could do

Code: [Select]

$armorValue[findclientbyName(name).player] = 10;
would this be acceptable syntax-wise

[Ipquarx]

would this be acceptable syntax-wise

syntax-wise yes but not from a practical standpoint
you should use findclientbyname(name) instead of findclientbyname(name).player since player objects are created and destroyed relatively often compared to client objects which are only created/destroyed upon connecting and leaving. It just means less manipulation and creating/destroying variables.

[Path]

And as mentioned before, that brings me up with the object ID problem. The IDs change with game instances so brick 38390 won't be the same brick in a reboot

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

syntax-wise yes but not from a practical standpoint
you should use findclientbyname(name) instead of findclientbyname(name).player since player objects are created and destroyed relatively often compared to client objects which are only created/destroyed upon connecting and leaving. It just means less manipulation and creating/destroying variables.

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.

[Zeblote]

so instead of findclientbyname(name).player.armorValue = 1.5; or a similar object value I could do

Code: [Select]

$armorValue[findclientbyName(name).player] = 10;
would this be acceptable syntax-wise

You can, but it doesn't seem useful in this case, you're probably not accessing that value thousands of times. As I said, it's not suitable for everything.

Global variables are also not deleted automatically if the object is removed, so you'll have to deal with deleteVariables and memory leaks.

And as mentioned before, that brings me up with the object ID problem. The IDs change with game instances so brick 38390 won't be the same brick in a reboot which is why I want to aviid the coding salad to set the data with it. Back ontopic, are they stable and how long can a brick's name be?

There shouldn't be any problem with copying data to brick names before saving and back after loading. It won't be fast, but it'll work.

Creating strings longer than ~4000 characters causes memory corruption, so there's your limit