Issues with your account? Bug us in the Discord!
New Buda.pkg and jumppoint working
Warlord II
Earthforce Officer
I felt that jumppoint is higher priority job than my skirmish because it's used in almost every mission. I don't know how well jumppoint have worked for you this far but for me it's been unreliable, too fast or too slow just to name few adjectives. Now I know at least some things which causes issues with it.
I have tried Director war and there it opened too fast and didn't open to the end before ships jumped (more about it in my notes). After that point closed even though it wasn't even half open. In "another" mission it at least seemed to open just okay which I'm amazed.
The funny thing is that in these both Indie's scenarios he uses jumping functions as function calls but Buda package's source in those mods have jumping functions as tasks. Compiler probably doesn't give errors because in Buda header file (in Indie's mods) jumping functions are normal functions. So compiler thinks Indie's mission code is okay but in game it shouldn't work because actual Buda package have them as tasks. In short jumppoint shouldn't open. I'm not gonna think any reasons because I have better things to do ;).
If you let compiler make your headers I just note that it doesn't make task functions as tasks. You have to manually add task in front of function name.
[CODE]Compiler created header entry:
prototype Buda.ShipJumpToJumpgate( hisim gate, hship ship );
Should be:
prototype task Buda.ShipJumpToJumpgate( hisim gate, hship ship );[/CODE]
So I have new Buda package and header. I also give you my jumppoint test missions to see if it works in your computer (feedback please!). I just copy-paste my notes from source file because other than scripters won't look it otherwise.
[QUOTE]Notes:
Jumppoint related
---
Jumping functions are tasks so mission can proceed even if some ships are still jumping. Just be sure that don't give orders too early (ships still jumping).
To make sure that jumping function goes to the end use Task.Detach( start Buda.ShipJumpToJumpgate(..) ); so that task is independent from your mission task (parentless). In case that mission task ends jumppoint won't stay there still forever as happened to me.
Jumppoint is faster and reliable now (at least for me). I tried and tried to make schedules faster but after certain point ships started to jump when jumppoint wasn't even half open and point started closing after that. So I tried something else. [COLOR=silver]Originally Simon made jumppoint to be from frame 0 to 1 but I made it from 0 to 4. It actually works.[/COLOR] Now point opens and closes quite smoothly and fast. Altough I wanted to make closing faster than opening but it doesn't seem possible without altering frame range (not possible with scripting?). Schedule speed doesn't seem to affect much to point speed, only how smoothly it opens/closes. I also tried to stop closing schedule and destroy point avatarchannel before it closes to end but it always just got smaller and smaller without just disappearing. Fortunately it's faster now than before.
I would also like to know if jumppoint speed is computer specific (fps related?). Quite longshot but these days I would believe just about anything from I-War 2 and Pog =). It's just quite hard to say if one person has faster speed than others. You could still tell if it's now different for you than it was before. For me it's a lot better and now it works always (I hope).
---
[/QUOTE]
So the files -> [url=mods.firstones.com/buda5/temp/Buda_package.zip]Buda package[/url] containing .pkg, source and header; [url=mods.firstones.com/buda5/temp/Buda5_ShipJumptest.zip]ShipJumptest[/url]and [url=mods.firstones.com/buda5/temp/Buda5_GroupJumptest.zip]GroupJumptest[/url].
Also [url=mods.firstones.com/buda5/temp/setup2.lws]setup2.lws[/url] to be putted in Ship Pack/avatars/jumpgate/ - so the jumppoint works. Also I'd like that LogicSequence makes new jumpgate/point so that it has "door" channel from 0 to 4 frames. Nothing else is changed in setup2 file than frame range.
One thing I don't understand (which [color=skyblue]Logic[/color] could hopefully answer) is that when I debugged these functions jumppoint was fully opened before fourth frame. And you could also tell what those values in ObjectMotion are ("door" channel info I posted in other thread) since I don't have Lightwave.
If you want point moving faster say so. One issue now is that loader.exe crashes when you exit game (I think it's because jumppoint) but it's small bad compared to working jumppoint :D.
To scripters: Unfortunately I want you to check your missions for Jump function calls and check if you "start" them as tasks instead normal function call to prevent any further issues. And also use Task.Detach . It shouldn't be too hard if you use text editor's search function and search Buda.ShipJumpToJumpgate and Buda.GroupJumpToJumpgate.
[i]As last note I noticed in temp folder while uploading that there was new Buda5_SkGen which I apparently have missed so I hope Roi haven't changed Buda.pkg there or I have to check it. Been long day already.[/i]
I have tried Director war and there it opened too fast and didn't open to the end before ships jumped (more about it in my notes). After that point closed even though it wasn't even half open. In "another" mission it at least seemed to open just okay which I'm amazed.
The funny thing is that in these both Indie's scenarios he uses jumping functions as function calls but Buda package's source in those mods have jumping functions as tasks. Compiler probably doesn't give errors because in Buda header file (in Indie's mods) jumping functions are normal functions. So compiler thinks Indie's mission code is okay but in game it shouldn't work because actual Buda package have them as tasks. In short jumppoint shouldn't open. I'm not gonna think any reasons because I have better things to do ;).
If you let compiler make your headers I just note that it doesn't make task functions as tasks. You have to manually add task in front of function name.
[CODE]Compiler created header entry:
prototype Buda.ShipJumpToJumpgate( hisim gate, hship ship );
Should be:
prototype task Buda.ShipJumpToJumpgate( hisim gate, hship ship );[/CODE]
So I have new Buda package and header. I also give you my jumppoint test missions to see if it works in your computer (feedback please!). I just copy-paste my notes from source file because other than scripters won't look it otherwise.
[QUOTE]Notes:
Jumppoint related
---
Jumping functions are tasks so mission can proceed even if some ships are still jumping. Just be sure that don't give orders too early (ships still jumping).
To make sure that jumping function goes to the end use Task.Detach( start Buda.ShipJumpToJumpgate(..) ); so that task is independent from your mission task (parentless). In case that mission task ends jumppoint won't stay there still forever as happened to me.
Jumppoint is faster and reliable now (at least for me). I tried and tried to make schedules faster but after certain point ships started to jump when jumppoint wasn't even half open and point started closing after that. So I tried something else. [COLOR=silver]Originally Simon made jumppoint to be from frame 0 to 1 but I made it from 0 to 4. It actually works.[/COLOR] Now point opens and closes quite smoothly and fast. Altough I wanted to make closing faster than opening but it doesn't seem possible without altering frame range (not possible with scripting?). Schedule speed doesn't seem to affect much to point speed, only how smoothly it opens/closes. I also tried to stop closing schedule and destroy point avatarchannel before it closes to end but it always just got smaller and smaller without just disappearing. Fortunately it's faster now than before.
I would also like to know if jumppoint speed is computer specific (fps related?). Quite longshot but these days I would believe just about anything from I-War 2 and Pog =). It's just quite hard to say if one person has faster speed than others. You could still tell if it's now different for you than it was before. For me it's a lot better and now it works always (I hope).
---
[/QUOTE]
So the files -> [url=mods.firstones.com/buda5/temp/Buda_package.zip]Buda package[/url] containing .pkg, source and header; [url=mods.firstones.com/buda5/temp/Buda5_ShipJumptest.zip]ShipJumptest[/url]and [url=mods.firstones.com/buda5/temp/Buda5_GroupJumptest.zip]GroupJumptest[/url].
Also [url=mods.firstones.com/buda5/temp/setup2.lws]setup2.lws[/url] to be putted in Ship Pack/avatars/jumpgate/ - so the jumppoint works. Also I'd like that LogicSequence makes new jumpgate/point so that it has "door" channel from 0 to 4 frames. Nothing else is changed in setup2 file than frame range.
One thing I don't understand (which [color=skyblue]Logic[/color] could hopefully answer) is that when I debugged these functions jumppoint was fully opened before fourth frame. And you could also tell what those values in ObjectMotion are ("door" channel info I posted in other thread) since I don't have Lightwave.
If you want point moving faster say so. One issue now is that loader.exe crashes when you exit game (I think it's because jumppoint) but it's small bad compared to working jumppoint :D.
To scripters: Unfortunately I want you to check your missions for Jump function calls and check if you "start" them as tasks instead normal function call to prevent any further issues. And also use Task.Detach . It shouldn't be too hard if you use text editor's search function and search Buda.ShipJumpToJumpgate and Buda.GroupJumpToJumpgate.
[i]As last note I noticed in temp folder while uploading that there was new Buda5_SkGen which I apparently have missed so I hope Roi haven't changed Buda.pkg there or I have to check it. Been long day already.[/i]
Comments
EDIT: Corrected [url=mods.firstones.com/buda5/temp/Buda_package.zip]Buda package[/URL]
[B]So Roi had one function in Buda.pkg which I'm gonna include in my packet and post here in say fifteen minutes.[/B][/QUOTE]
Thx for updating it self-reliant!
I've tried your two test scenarios. The jump animation looks all right although the diameter is a little bit too big for the jumpgate. The speeds of opening and closing are good .... I wouldn't change it at all.
@Compiler problem with tasks: Yes, I recognized it last christmas ... one more "funny" thing about the flux engine *juhu* :p .
PS: I didn't tested it in my mission b/c I currently have no jumppoint in it. I'm waiting for the Geo Tool ;) .
EDIT: Btw, on my system nothing crashed as I exit the game.
[QUOTE][i]Originally posted by Roi Danton [/i]
[B]Btw, on my system nothing crashed as I exit the game. [/B][/QUOTE]Great, then it's just on my system. What would you suggest as reason this time :confused:
Just thought this might make it seem as though it's travelling through the tunnel rather than emerging from a flash :)