search

calref / cboe

Classic Blades of Exile
http://spiderwebforums.ipbhost.com/index.php?/forum/12-blades-of-exile/
Other
168 stars 41 forks source link

[WIP] Replay system rebased #375

Open NQNStudios opened 5 days ago

NQNStudios commented 5 days ago

Rebased continuation of #365

CelticMinstrel commented 4 days ago

It doesn't look like the cloning issue in pop_next_action was resolved.

That aside, there's surprisingly little here for such a big change… though I guess part of that is that this just creates the framework and then you'll have to toil through to make everything actually use it…

NQNStudios commented 3 days ago

I couldn't find any way to make the code not crash other than taking the raw Element* pointer and trusting it gets deleted somehow. So I went back to that.

I think the best solution is to actually not remove the elements, just keep a pointer to the next one, and iterate through them leaving the data structure intact. Won't need to Clone() that way, and will only be returning references to the data.

Also, I finally looked at the XML printer class and I think I can use it for this.

NQNStudios commented 3 days ago

Well, there's one hitch with the printer class. It only saves when it's deconstructed. I think saving the replay log is desirable every time an action is added, in case a segfault or exception crashes the program. We want to record as much of a playthrough as we can up until the moment of failure, not rely on the program to run and finish normally to keep the log alive.

CelticMinstrel commented 3 days ago

I couldn't find any way to make the code not crash other than taking the raw Element* pointer and trusting it gets deleted somehow. So I went back to that.

I think the best solution is to actually not remove the elements, just keep a pointer to the next one, and iterate through them leaving the data structure intact. Won't need to Clone() that way, and will only be returning references to the data.

Just double-checking, because I can't really tell very well from the code, but… are you using the ticpp API here rather than the TinyXML API that it wraps?

Well, there's one hitch with the printer class. It only saves when it's deconstructed. I think saving the replay log is desirable every time an action is added, in case a segfault or exception crashes the program. We want to record as much of a playthrough as we can up until the moment of failure, not rely on the program to run and finish normally to keep the log alive.

If the printer class doesn't fit the requirements for what you're doing, then don't worry about it. I just wanted to make sure you hadn't overlooked that it exists, in case it made things easier for you. If it makes things more difficult instead, feel free to forget about it.