Daemian Wrote:Hey, wait, I found another way to loop a function without timers!
This seems to be looping once every 0.01 seconds. (100 times per second)
Is that an acceptable number for your game Behe? Or you need it to loop faster?
I'm editing in a second with the code in case you wanna give it a try.
Basically it's an entity jumping from one area to another.
The areas fire a collide callback, throwing the object from area A to area B in a constant loop.
This process -according to tests- takes about to one unit of a second. (I can see the debug messages increasing by 100 every second). So it's fast, and kinda light to process too.
So, two areas and one entity.
You declare the entity callback on both areas, and use PlaceEntityAtEntity to send the object to the other area.
That will loop, and you can use the function to run your things.
You gotta hide these two areas and entity in your maps, somewhere safe from the action.
What else? I attached the entity I'm using, it has no gravity, no collision, nothing. Just what it needs to make this work.
Mmmmh Am I missing something? Anyways, there it is, I hope you like it.
Do you think there's a similar restriction to how many collide callbacks as there are timer callbacks?
Even so, why add a new callback every time? Can't you still just use the original with "false" on the second last parameter or does that affect the functionality of it?
You know your script best, Behemoth
See if you can get that method up and running. But if you have to adjust every 60/30/10 timer loop you currently have to a 100 timer loop, you might have to implement some skipping. Perhaps store the values in, not SetInts but primitive double variables? Ensure you have a large enough allocation ^^
100 loops per second is a strange number. 128 would make sense. Might be easiest to skip and split it into 50/25/10 if that's a desirable loop pace.
(02-22-2015, 08:30 PM)Mudbill Wrote: Even so, why add a new callback every time? Can't you still just use the original with "false" on the second last parameter or does that affect the functionality of it?
Yes, the thing is it doesn't like having the callback permanent.
It makes the switch twice and stops.
I moved the entity myself in-game to check and both areas were still functional, they did the same switch once and then stopped again.
Good news: Amn's loop seems to have a reliable speed. I was concerned that, because it is just running as fast as the engine can run it, that it would have a variable speed, depending on system load. It doesn't - I've done some extensive testing and it loops at a consistent 60Hz, even with me deliberately trying to slow it down by, for example, making it assign 1000 random floats at each iteration, or do physics or lighting operations, or having 3 instances of the engine running at once, or having an 60fps movie playing in another window. Good work there. Kudos to Amn!
Bad news: Completely as an afterthought, I let it run for 10 min, which went fine, and the speed only varied to something like 60.01Hz. But guess what happened the next time it (un)loaded a map? Access violation, that's what.
500s - 30,000 iterations - ok
520s - 31,200 iterations - ok
540s - 32,400 iterations - causes a crash on the next (un)load.
It's also cumulative over maps, as before.
Maybe this is a completely new problem, or maybe the existing problem has nothing to do with indexing timers.
If you want to see my test map, just let me know.
Jens got back to me, BTW. He said he couldn't answer the question on the technical side, but that he could confirm that there were no updates planned, barring the appearance of major bugs. He suggested that I ask Apjjm, so I've PM'd to bring this thread to their attention.
I really appreciate all the help and support, but once again I'm at the point of giving up.
Edit: Changed the numbers above as I realised that the reason I was getting 120Hz was because the counter was being incremented twice on each loop. I guess the engine "thinks" at 60Hz.
This sounds like the same issue, seeing as it adds new callbacks. If only it had worked with the same 2 callbacks multiple times, I'm sure this would be no problem.
But no, this is no time to give up. I think what we should try next, as we've tried before, is to find alternate methods to loop these. Ultimately, I think we need something small and simple, but consistent.
I never got that much into C++ to really understand how it all works, but have you seen the Script Pre-Processors on the wiki? It was written some time ago, last edited by yours truly Apjjm. Maybe there's a loophole here we can use.
(02-23-2015, 11:49 PM)Mudbill Wrote: I never got that much into C++ to really understand how it all works, but have you seen the Script Pre-Processors on the wiki? It was written some time ago, last edited by yours truly Apjjm. Maybe there's a loophole here we can use.
Damn you and your enthusiasm!
The preprocessor is something I should really be using (instead of what I currently do, which is use np++ macros to automatically copy/paste code between files), but ultimately all it does is combine text files in different ways to output an hps file - it doesn't do anything you can't code directly.
Maybe you're on to something though. Maybe the above method causes a similar crash because of a list of callbacks, as you say. I have an idea... watch this space...
Got the day off work today, so I've been able to spend the morning experimenting, and after a few hours I finally got somewhere...
I've tried a few different ways to make a loop using callbacks: buttons, multisliders, even looked into a zero length model animation, but none of those worked for various reasons. Then I decided to take another look at the collision callback method. After some tinkering I realised why the callback wouldn't stick and had to be re-applied.
Assuming that the engine "thinks" at 60Hz or fps or whatever, it can't recognise that an entity has stopped colliding until at least the next frame after it started colliding. So when using Amn's method, the enity is already back at the first area before the engine notices that it is gone. Removing and re-adding the callback forces it to re-notice the collision. I tried using 3 and even 4 areas, cycling the entity between them, but it was always back at the first one before the engine had time to "think" and noticed that it was gone. (Which is also why it doesn't appear to move at all, visually.)
So then I tried using just one callback for a single area, detecting when the entity goes in and out of it...... Bingo! This method works, loops as long as you need it to and only requires 1 permanent callback. It clocks almost exactly 60Hz (slightly faster, 60.011666...Hz after 10min) and doesn't cause a crash on (un)loading.
Now, I'm not going to get too excited until I've implemented it in the mod and playtested it... but keep your fingers crossed...
It you want to verify it, the map is attached below but SCREEN BURN WARNINGdon't try it with a visible entity and don't uncomment line 43 so that each loop displays a message. I left it running like that for 10 min and it burned a flickering box and column of messages on my screen. Luckily 45 min of screen cleaner video faded it out.
Ps. Sorry for double posting - I'm aware that I do that a lot. I figured it's ok if there's something new to say. If it's not ok just let me know.
Search
Member List
IRC
Help
Amnesia: The Second Dimension [READY FOR LAUNCH]
