Thoughts on My New Softcore Ascension Item Handling

[Eliteofdelete]

Intro: Hello, I am looking to re-write how my Softcore Ascension script handles items to allow for more versatility and easier scaling up.

Background: Currently, if you have ever looked at my ascension script item pulls (please don't ), it is a complete mess of if statements. At the time of writing it, I didn't really know anything better, maps were a new/hard concept, and I only figured out about user defined records a few days ago. To implement other classes, I would probably have add a switch statement for each main stat, followed by a million more if statements and items. It is already a pain to look at, and I'd probably go insane dealing with its current scaling up path. So, I am going to rewrite the entire thing.

The other problem I have with it is every time I change an item, I have to go an manually change/add it to my ascension checklist. This gets quite tedious if I am doing a lot of tweaking, and so I won't really update the checklist very often.

Idea: My current idea is to just combine the items that are pulled into the ascension checklist. I would modify the current record to look something like this

record ChecklistItem
{
	item checkItem;
	int required;
	int have;
	int Day
        int amount_used_on_day
	string type
	string class_stat
	string astral_item
};

I would then populate it with the information on how it would be used in the pulls. So, Day would be which day in my script it is pulled, type is if it is a food/gear/quest/etc, class_stat would be either a general prime stat or used for a specific class. And then astral_item would differentiate which items are used depending on the astral consumption item taken.

Then, when it is ran outside my script, so not being used to determine pulls, the user would input what class and astral item they will be taking. It would then build the checklist around that information, buy all those required items, and give some basic information. For instance, I'd like it to tell how many pulls are used for each day or if there is too much food/drink/spleen queued up on a particular day, etc.

Then, when my script runs it would base its pulls determined by the class, day, and astral item used.

Questions
Overall, is this a good idea or is there a better one I have not considered? Also, how hard would it be to have the user input strings for when I ask them what class/astral item they will be doing.

Anyways, any feedback is appreciated, and I apologize for any bad writing. I will probably edit this in the "morning" when I wake up. Thanks for reading!

 

[fronobulax]

I'm still drinking the first coffee of the day so I am not sure I understand your question completely, but...

The idea of defining a record, reading a collection of them from disk, modifying it and writing them to disk is fairly standard. I have several scripts that share the same data file and this works fine so long as you figure out a way to manage your record definition so it isn't different between scripts.

As for getting IO from the user I find ash somewhat lacking and if I was serious I would go for a relay script. BCCAscend and OCD both have good relay scripts that manipulate datafiles used by the corresponding script.

Now to finish the coffee and decide whether this was helpful, or not.

 

[Eliteofdelete]

Actually, your response is quite helpful as it touches on something I wasn't planning on doing, but maybe should, which is saving the map as a data file. Since I don't see myself tackling the problem of writing a relay script any time soon, I was planning on just generating the map when each time the script is run (based on certain criteria) and not saving the map, as I can't see any reason to save the map as a data file. Unless, saving the map in a data file is the best way to pass its contents off to another script?

Like, I can see its usefulness if I had a relay script. I could load the map, change the map in the relay script, and then save it to a data file to be used later either by the relay script or the ascension script. But if I am not using a relay script, what benefit is there to writing the map to a data file?

 

[Bale]

Unless, saving the map in a data file is the best way to pass its contents off to another script?

This.

You might also find a mapfile easier to edit than the script if you want to make changes.

 

[fronobulax]

Unless, saving the map in a data file is the best way to pass its contents off to another script?

+1 to Bale's comments.

Depending upon how you define the boundaries between scripts, there are some definitions where it is impossible to share data between scripts without writing it to a file and if you are going to write from ash to a file you might as well use a map. And, as noted, map files can be edited which is sometimes easier than scripting changes.

 

[Eliteofdelete]

Thanks for the feed back I'll look into doing it that way.