CMND - Enters console commands
-
@CubicApocalypse (View Post)
@boxmein (View Post)
I don't understand why it has to be limited even, I wouldn't do that. But I wouldn't expect it soon, it's been sitting in my todo list for a long time, I am going to put it in my tpt++ mod, which I haven't even started yet. -
@jacob1 (View Post)
The point is not to let saves grow too big. Some ctype, etc metadata would solve saving the command as a string... -
@boxmein (View Post)
yeah, and even if it was saved as a string, I don't think saves would be too big. The largest size allowed is 3MB, and I don't think anything has gotten close. I've saved a 53KB lua script to a save once, and that was a huge script. Nothing would come close to 3MB. (and that save doesn't even load right anymore, I had to break some old mod saves because I designed how they saved badly) -
I don't think that property setting elements, or elements that run console commands, are a good idea.
1. It means that saves rely on the exact details of how elements are implemented, which makes it a lot harder to change things or tidy up the code without breaking saves.
For example: merging all life elements into one and reusing the element IDs. If an element that could set ctype had existed, any saves that used it to set clone to produce a particular life element would have been broken.
2. If you change any particle properties except through normal element interactions (e.g. by using the console or a property setting element), you do so at your own risk. The game may crash, or elements may not work as they are intended to. I try to make elements do sensible things when people clobber them with the console, but loads of them still don't behave well when fiddled with. Mostly, I haven't bothered fixing any strange effects that don't survive being saved. Console commands in saves would be opening a whole new can of worms.
If you can only make it using the console (molten stkm, frozen sing, bomb powder etc), don't be surprised if it stops working at some point in the future, and don't rely on it doing anything predictable. The only things you can expect to work in the future are things achievable through normal element interactions (and even then, changes are sometimes made if there is a good enough reason to do so).
I would prefer not to see saves relying on things that might not work in the future. People complain when things break. -
@jacksonmj (View Post)
Yeah, that's why I would only put it in my mod. It causes problems, and sometimes I break things anyway (like, I had to break PWHT once, and saving of moving solids, ANIM, and INDI a few times because I didn't design it well. I hope I won't have to break things in the future, I always try not to, but i'm prepared if I have to)
Your first point isn't really a problem, because that actually happened once. There was CLNE(BRAN) in saves, and we just replaced it with other things. I also already have a function to replace element types in every single element that uses ctype (to store elements), and also PIPE too. Because when a new tpt element is added, it shifts all my mod's elements up 1 slot. The function works in replacing everything correctly. That's why my method would work much better than a string, it just saves things like that in ctype.
For the second, yes. It's good that only the console can change things now, because there could be crashes, and people always find crazy glitches and use them like they should happen normally. I'm still adding it anyway though.
I hope that the uses of the console aren't ever limited. Like, limiting everything's life value to 65535 because it doesn't save. It doesn't save already, so there is no point in adding extra checks to elements. I did limit VIBR to only >0 tmp, but that was because it could go under 0 tmp in normal conditions. Limiting molten STKM and molten SING and stuff would also be pointless, and that would actually break a lot of saves.
I think, at least for my mod (and probably most of tpt), people would understand if elements were changed for a good reason, and a few minor things were broken. I didn't complain when SPNG's life was limited, because then there were other new uses, like sponge as a water filter. Things like that are not changed often for no reason. -
Converting it when loading an old save: true, but that only works if the property setting particle can only affect one element (i.e. no "!set ctype all aaaa"), which isn't the case for the original suggestion in this thread and many of the previous property setting particle suggestions.
-
@jacksonmj (View Post)
ok, is there something I am missing though? I don't understand why that doesn't work. It seems to work well for all the other ctypes in my mod. I know at one point, it checked the entire tmp variable of PIPE, which broke loading single pixel pipe, but I fixed that so it would only check the first 8 bits now. -
Because if a property setting element sets the ctype of all elements, you can't just change the value it sets the ctype to (e.g. changing the value from BRAN to LIFE) to make clone work when element numbers change. Different particles use ctype for different things, it doesn't necessarily refer to an element.
-
@jacksonmj (View Post)
oh, ok. So like, if the CMND did "!set ctype CLNE BRAN" before, changing BRAN to LIFE in the CMND element wouldn't work, because then it would create GOL instead. And it can only set one property at a time, so there is no way to also tell it to set the tmp too to make it clone BRAN again. At least I think this is what you mean, if it isn't, it's still another reason that that wouldn't work perfectly.
Another thing you might have meant, is maybe it did "!set ctype GLOW 200". In that case, it wouldn't be right to change the element number, because it wasn't referring to an element in the ctype. That would be a simple fix though, I only do that in my mod for a certain list of elements, and I could easily let it know if GLOW is in that list and then decide not to change it.
After that, there is only one problem, and that is "!set ctype all 200". There really is no way of knowing, which is probably what you meant. This is only my mod, and i've broken things before, so i'm sure people just expect it. I would in this case raise the 200 anyway, because 90% of the time they were referring to an element. All of this is what I will do when I make it.
Edit: Maybe I should try doing something like I just said for PIPE. It changes the type of the element inside of it, but not the ctype (or the tmp of any PIPE inside the PIPE, but I really don't need to check that when there is multiple cases of PIPEception)
Edit2: That gives me an idea for a save. PIPEception
Edit3: I'll probably forget. Maybe I should add a todo list feature in my mod? -
I was wondering, why can't we say !set type metl lot? We can only do LIFE and it doesn't make sense for me. Like there's a trick when you place DMND change it to PHOT while paused and give it 0 life then say !set ctype phot life and it's stationary and Blue. Plus it has strange conduction capabilities. Same can be done with ELEC and NEUT (NEUT, not so well.)
