jump_to_scene after rest_for_hours

[Winter]

I've noticed that jump_to_scene refuses to work after rest, which is getting to be a bit of an annoyance with some of the finer points of Storymod. I'm having to kludge a lot of alternate options because of this.

Are any other modders having a problem with this? should I make a suggestion to Armagan about it?

Machineably,
Winter

 

[Khalid ibn Walid]

Never noticed that.

Or maybe I misunderstand the set-up. You mean automatically jump in the same consequence bloc as the rest for hours? Or a new dialog?

 

[Winter]

Never noticed that.

Or maybe I misunderstand the set-up. You mean automatically jump in the same consequence bloc as the rest for hours? Or a new dialog?

I mean automatically jump in the same consequence block as the rest_for_hours, yes. That's exactly it. And it doesn't work.

Identifiably,
Winter

 

[Ancientwanker]

Alot of things dont like working in rapid sequence, tutorial boxes for instance will crash into each other and freeze.

In the case of the rest command, its probably trying to launch everything at once. So its sending you to the worldmap to watch the resting at the same instant its trying to launch a scene. There doesnt seem to be a queue of events within a single block.

You could try setting a special rest variable to 1 when the resting begins, then have a trigger detect it and move you to the next screen after x hours. Youd have to fiddle to get the timing right but it should work.

 

[Winter]

Alot of things dont like working in rapid sequence, tutorial boxes for instance will crash into each other and freeze.

In the case of the rest command, its probably trying to launch everything at once. So its sending you to the worldmap to watch the resting at the same instant its trying to launch a scene. There doesnt seem to be a queue of events within a single block.

You could try setting a special rest variable to 1 when the resting begins, then have a trigger detect it and move you to the next screen after x hours. Youd have to fiddle to get the timing right but it should work.

See, I really don't want to try kluding it like this, so that's why I'd like it to be possible to do it in the some operations block. Maybe some kind of delay command that delays all operations placed after it in the operations block for X seconds?

Negligibly,
Winter

 

[Khalid ibn Walid]

See, I really don't want to try kluding it like this, so that's why I'd like it to be possible to do it in the some operations block. Maybe some kind of delay command that delays all operations placed after it in the operations block for X seconds?

I doubt that is possible or even very practical. What if something happens in between those seconds, e.g. you get attacked, or you enter the wrong town town or scene? Sounds like more trouble than it's worth.

 

[svaucher]

Ah the joys of writing mods for software that is in beta...

Does the error occur if you separate the block in separate scripts? I'm not sure if I've understood exactly how the scripts are called, but if there is some weird stuff setup in temporary vars, they might be cleaned up when a script is called.

sv

 

[Winter]

I doubt that is possible or even very practical. What if something happens in between those seconds, e.g. you get attacked, or you enter the wrong town town or scene? Sounds like more trouble than it's worth.

That's why you would use it for operations where stuff won't happen in between, like resting.

I don't know. Obviously it'd be better to make the operations block follow some kind of order, waiting until each operation is executed before firing the next, but that sounds rather more complicated to code than the simple operation I had in mind. The way it is right now, you cannot rest inside a town without being kicked back out to the map -- that kinda breaks the suspense when you're in a situation where you can't or aren't supposed to be able to get back out until you do certain stuff.

Hypermetrically,
Winter

 

[Ancientwanker]

Thats probably because there is no time inside of towns. The worldmap is the only place that time moves forward.

It would be useful to have something like you suggested for some situations though. Right now Id settle for tutorial boxes that dont crash each other. I guess I should tell Armagan about that at some point.

 

[Khalid ibn Walid]

That's why you would use it for operations where stuff won't happen in between, like resting.

That would be the only case where it'd be applicable, would it not?

I don't know. Obviously it'd be better to make the operations block follow some kind of order, waiting until each operation is executed before firing the next, but that sounds rather more complicated to code than the simple operation I had in mind.

Actually, it's probably the other way around. I'm presuming in your "delay" operation, you'd have to specify the seconds to delay, right? (No one-size-fits-all for that). But then that would be no different than a trigger. So why not just write in the "triggers" file?

The way it is right now, you cannot rest inside a town without being kicked back out to the map -- that kinda breaks the suspense when you're in a situation where you can't or aren't supposed to be able to get back out until you do certain stuff.

It seems to me that your source of complaint should be about the resting per se, and where that kicks you to. A "delay" command would not solve that, methinks.

 

[Khalid ibn Walid]

Come to think of it, let me backtrack. I wouldn't mind some way to set up a timeless trigger, one that would be launched by another event immediately (as default), but with the conditions bloc adjustable so that we can specify x amount of time needs to pass before since event A fired before these consequences are applied (something we already have in the triggers).

That could have multiple uses than a simple "delay" command.

 

[Winter]

Actually, it's probably the other way around. I'm presuming in your "delay" operation, you'd have to specify the seconds to delay, right? (No one-size-fits-all for that). But then that would be no different than a trigger. So why not just write in the "triggers" file?

Because the timing of triggers in this case is variable depending on the exact millisecond you entered the town, and could therefore create problems and CTDs.

It seems to me that your source of complaint should be about the resting per se, and where that kicks you to. A "delay" command would not solve that, methinks.

Yeah, fair enough, but I don't think Armagan's likely to change the resting mechanism anytime soon.

Ideationally,
Winter

[EDIT] Yeah, I quite like your new idea -- you're referring to a way to call a particular trigger directly from another file, like dialogs.py, correct? [/EDIT]

 

[svaucher]

2 points in a saddly long post (rant?) on time and triggers:

1/ The short comment: avoid putting too much code in triggers. They are hard to debug. Instead put the code in a script and invoke the script by a trigger. You can then debug the script by using a dialog. Diagnosing a problem with scripts/dialogs is much simpler than hoping that a trigger will act okay. Also, scripts can be more easily copied from a module to another and they can also be stored in variables. If you want to do three separate things every game day, in one trigger, you can invoke three scripts which will be smaller than a large one (and easier to debug)

2/ Time:

i'm not surprised that triggers are buggy because parallelism is always a ***** when programming. I'd assume that gaming (no experience) is similar to simulation (more experience) in the sense that you want actions to be done following an internal clock. Resting simply accelerates an outdoor (internal) clock. In battle (which is probably the same gameplay as in town) there is another internal clock that says for every tick, characters can move a certain distance. Can there be an association between outdoor and indoor time...?? Defining such an association, would (naively) entail that in a battle that the program keep on calculating the position of units on the outside map. Armagan is probably trying to keep the "things" to do for every click pretty low (which is possibly the reason for trigger instability).

Adding the idea of executing a block of code after x sec/ms would entail a few things. Firstly, for every (few?) tick (s), you need to check the time. That slows things down. Secondly, you wouldn't be able to guarantee that something would be executed before or at time x, only after time x. As by the time you check, maybe the time has passed. Of course there are synchronisation issues as you might hope someone is still in town, but he's already pressed tab or asked the tavern guy to rest... oops (that sec lasts how long now?).

A more feasable solution might be to execute a trigger/script after the current block is executed.

 

[Khalid ibn Walid]

winter: Yes, that's right. I think it would solve your problem (and a lot of mine). Besides it would be nice to not have to always go through some inane dialogue to get something to 'happen'.

svaucher: if you ever saw my source files, you would have a heart attack.

Interesting what you say. The script-calling is a new thing with 710 that I thought was causing a lot of my instability, so I actually eliminated a lot of it and returned to 703's old heavy-on-the-trigger code. But if you are sure it is actually more stable, I might give it a second chance.

Also, delaying the execution after conditions evaluated as true is already modelled into the trigger files (it's that third integer).

 

[svaucher]

I haven't seen anything weird with scripts and I've done some pretty warped things with them. My experience with modding M&B is limited though and is limited to 710. Are you sure it was scripts causing the instability?

sv

svaucher: if you ever saw my source files, you would have a heart attack.

Interesting what you say. The script-calling is a new thing with 710 that I thought was causing a lot of my instability, so I actually eliminated a lot of it and returned to 703's old heavy-on-the-trigger code. But if you are sure it is actually more stable, I might give it a second chance.

 

[Khalid ibn Walid]

I haven't seen anything weird with scripts and I've done some pretty warped things with them. My experience with modding M&B is limited though and is limited to 710. Are you sure it was scripts causing the instability?

No, I'm not sure. I converted from the old triggers-sans-scripts into the new ones around the same time I hit that troop-limit bug. Since lots of weird stuff started to happen, I scapegoated the scripts and took them out. I have been sheepish ever since.

 

[svaucher]

No, I'm not sure. I converted from the old triggers-sans-scripts into the new ones around the same time I hit that troop-limit bug. Since lots of weird stuff started to happen, I scapegoated the scripts and took them out. I have been sheepish ever since.

Understood. What kind of errs you were getting?

sv

 

[Khalid ibn Walid]

Understood. What kind of errs you were getting?

some <= num_ids one. I presume a chunk of that was related to the troops bug. But some of them persist.

Anyways, I'm going to trust you and go ahead and restore those scripts and see if it eases some of the misfiring triggers. If it gets worse, I'll claim your first-born child as compensation.

 

[svaucher]

Anyways, I'm going to trust you and go ahead and restore those scripts and see if it eases some of the misfiring triggers. If it gets worse, I'll claim your first-born child as compensation.

Good luck, I hope scripts can help ease off the pressure off the triggers. That at least until we hit a limit on the number of scripts

sv

 

[Winter]

Good luck, I hope scripts can help ease off the pressure off the triggers. That at least until we hit a limit on the number of scripts

sv

I tried out your suggestion of using a script for resting. Unfortunately, it didn't work. Looks like I'm stuck waiting and kludging workarounds.

Opprobriously,
Winter