theRAPTLab / gsgo

GEM-STEP Foundation repo migrated from GitLab June 2023
1 stars 1 forks source link

Can't change the name of a blueprint #767

Closed jdanish closed 1 year ago

jdanish commented 1 year ago

To reproduce: click on a script / blueprint name. Select the top line. Change the text and press save line. Screen goes white and the following errors appear. This is happening in the 2 most recent branches (f64725295d0d063b48a5e6ab188fe08bb7ce275b and f12aee8af7a57ce291f3d08fd6bc3d878daad8ec)

Screenshot 2023-08-30 at 7 49 42 PM
benloh commented 1 year ago

@jdanish The basic problem here is that changing the name of the # BLUEPRINT ... pragma still leaves a ton of references to the original blueprint name, so the system is choking on the bad blueprint name.

e.g. if you change # BLUEPRINT Beaver to # BLUEPRINT Badger, you still have a ton of lines like...

featProp Beaver.Costume.costumeName setTo 'WL_beaver.png'
featProp Beaver.Costume.scale setTo 0.15
prop Beaver.zIndex setTo 200

..that still point to Beaver.

I suppose the proper solution is to do a full code search and replace. I could've sworn we've implemented this before but it's possible we only did it for the code view and not the Wizard view.

benloh commented 1 year ago

Thinking this through some more, a few possible approaches:

  1. Add a special "Blueprint" edit mode Instead of treating the # BLUEPRINT line as just another Wizard Keyword, we pull it out of the wizard interface and allow to change the name in a special location (e.g. a title bar), automatically replacing the existing name with a new name after you've confirmed the change. This could get complicated as we don't necessarily want to do a script text search and replace where we can inadvertently change other references to the old blueprint name (e.g. you duplicate a Beaver blueprint, adding a new Badger character and still want to reference Beaver in the code). The "smart" fix would be to find the code object references to "Beaver" rather than simple string replace. It's a bit more work but should be possible. This is probably not worth the trouble.

  2. Search and Replace after wizard / code update If we want to support editing the wizard or code view using the existing tools, then we need to add a review pass after the line is changed to do the search and replace. So we'd be adding a special code check to see if the user has changed the name, and then attempting to update all the references. The advantage here is we don't need to build a new UI, but we'd still have to do the "smart" object replace.

  3. Use "character" The js error is stemming from use of the old blueprint name. If you were to change the code references from "Beaver" to "character" (or "agent" if we are unable to fix #767) then I believe the error will go away. This is a cheap solution that requires no code, just a rewrite of the script. (Though we might want to add a way to catch the error without breaking.) This is the simplest solution, but it might make your script a little less readable.

  4. Block blueprint name changes The cheap fix is to basically disallow these changes. We can block wizard and code view changes to the blueprint name. So if you wanted to do that kind of change, you'd need to edit the project by hand. I'm guessing this isn't an option.

  5. Do nothing SInce changing the name results in an error, we probably can't afford just ignore the problem.

I'm guessing (2) is the most likely solution.

jdanish commented 1 year ago

Yes, number 2 would be nice, though I'd rather leave it to lower priority.

Either way, is there a way to change the name and have the old references appear as errors (red) but not crash the window? I thought that was how it was working for a while, but the screen going white means you can't even change the names to fix them. That was the main concern short-term?

benloh commented 1 year ago

I'm not sure that ever worked. Perhaps for other errors, but not blueprint name errors. In any case the pull request has a cheap solution now: no more error so you can continue working.

jdanish commented 1 year ago

Cool. That should be enough but I'll test and verify thanks!

benloh commented 1 year ago

Addressed with #770