Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: 666maslo666 on May 25, 2011, 05:51:44 pm
-
I am making a rather huge experimental mission, and I have already hit mission waypoint limit (32). Can it be bumped? ;7
Alternativelly, cant all limits just be made dynamic (so you can add new objects until your PC can handle it, like for example gravity wells in Sins of a Solar Empire dont have any artificial limit)?
-
I support this, and there's more people who would really like to see the limit gone or made dynamic.
-
Alternativelly, cant all limits just be made dynamic (so you can add new objects until your PC can handle it, like for example gravity wells in Sins of a Solar Empire dont have any artificial limit)?
No.
However, dynamic waypoints would be cool.
-
To elaborate, we would very much like to remove all of the hardcoded limits.
Unfortunately, doing so is impossible without some major refactoring of several critical areas of the code, which is not on anyones' list of favourite things to do.
The problem, in a nutshell, is that the engine implicitly assumes that pointers to things like ship data are valid for more than a single frame, or a single run through the engine's main loop. Which is an assumption that you simply cannot make when you make stuff like the Objects[] array dynamic.
-
Maybe it could be bumped to an enormous value then, something like 4096 waypoints.
I don't think we'd see somebody running into this one anytime soon.
-
And limits can't be bumped to ridiculous values because 1) the code might assume that the limit will always be below a certain threshold (the historical problem with the ship class limit); and 2) all those unused slots waste space that the computer must still keep in runtime memory.
-
And limits can't be bumped to ridiculous values because 1) the code might assume that the limit will always be below a certain threshold (the historical problem with the ship class limit); and 2) all those unused slots waste space that the computer must still keep in runtime memory.
Could you go into more detail on #1? I'm wondering if we're running into something like that with the Diaspora weapon/object limit bump.
#2, IMO, isn't that big of an issue a most of the time, especially when the contained object is small. Pretty sure 4096 waypoints would be measured in kilobytes, which is basically chump change.
-
#1: The assumptions don't have to be explicit. For example, 130 is the maximum number of ships that will fit into a multiplayer packet, or something like that. Bumping to 131 requires a different-sized packet, causing a cascade of compatibility errors. Something similar happens with the pilot file format. I don't know the details offhand, but chasing them down is the major reason it took so long to make ship classes dynamic.
#2: It is most certainly an issue. First, nobody in their right mind will ever need 4096 waypoints, it'll just be wasted space that's never used. Second, you may think that bumping some limit won't matter because the data structure is so small, but the problem is that there are a lot of data structures in the game, and a lot of arrays that have limits higher than they need to be, and all those little pebbles add up.
-
#1: The assumptions don't have to be explicit. For example, 130 is the maximum number of ships that will fit into a multiplayer packet, or something like that. Bumping to 131 requires a different-sized packet, causing a cascade of compatibility errors. Something similar happens with the pilot file format. I don't know the details offhand, but chasing them down is the major reason it took so long to make ship classes dynamic.
I remember the issue cause I was the one who fixed it based on Kazan's advice. If you had more than 130 ships you'd run out of space in the packet because it required a certain number of bytes per ship. The solution was to split the ships up into several packets and IIRC explain in the first packet that there were more packets to come.
Multiplayer makes several assumptions of that type and the more we bump limits the more likely it is that we'll hit one of them.
-
Still, 32 does seem kinda low - Is that the limit for the total number of waypoints, or the total number of waypoint paths?
-
Could waypoints actually be written as a vector, which would expand dynamically for any given ship? In such a manner, nothing would have to be hard-coded. I understand I'm not familiar with the code, but in concept, a vector should do the trick - an array is inherently fixed in how many variables it may contain.
-
That's what we'd do if we made waypoints dynamic. And I don't think there would be any show-stoppers for that.
-
Could waypoints actually be written as a vector, which would expand dynamically for any given ship? In such a manner, nothing would have to be hard-coded. I understand I'm not familiar with the code, but in concept, a vector should do the trick - an array is inherently fixed in how many variables it may contain.
AFAIK the only problem scenario is if you have a pointer to an element of the array, then the array gets resized (and relocated elsewhere in memory). The pointer that was being used previously is now garbage, causing strange and unpredicatable bugs.
In other words, making the waypoint array a vector is possible, but someone would need to carefully double-check all of the references to the array first to make sure that the change wouldn't cause problems.
-
AFAIK the only problem scenario is if you have a pointer to an element of the array, then the array gets resized (and relocated elsewhere in memory). The pointer that was being used previously is now garbage, causing strange and unpredicatable bugs.
In other words, making the waypoint array a vector is possible, but someone would need to carefully double-check all of the references to the array first to make sure that the change wouldn't cause problems.
This is also the reason why a number of our core data containers haven't been moved to STL types. At present, the structures often include an index within themselves into another container, so having dynamically resizing containers leads to breaks.
More work to do here with the STL containers other than simple Vector.
-
:nervous:
:bump:
Is a path limit bump possible?
-
:nervous:
:bump:
Is a path limit bump possible?
Its the same problem. The data-structure is an array of a arrays.
-
Okay, I checked the code and it looks like there are pointers which are saved from frame to frame. Specifically, if the AI is in waypoint mode, it stores a reference to the waypoint list it's currently following. This technique would lead to a bad pointer if the vector was resized and relocated.
It occurs to me that this might not be a problem if the waypoint list is never resized once the mission starts. Waypoints are static, after all. Of course, someone may decide to go and add dynamic waypoints in the future, so scratch that idea.
What if we made waypoints (as well as lists of waypoints) a linked list instead? That way it's the links which move around in memory, not the nodes themselves. And there usually isn't a need for random access to the middle of a waypoint list; all the AI needs to know is the start, end, and current waypoint.
-
Would that mean we'd be able to move waypoints around, and have the AI work with it? Or is that what's meant by making them dynamic?
-
Well, I used dynamic to refer to two different things in the post there. The purpose of making the waypoint arrays into vectors or linked lists is to remove the hard limit of 32 or so that it has now. When I said "dynamic waypoints" in the second paragraph, I was thinking of waypoints added during the course of the mission, although that would be tricky to implement.
Moving waypoints around is completely different from either of those.
-
this is one of the things that killed the fsrts mod. every time you hit the move command youd use up a waypoint, after you issued the command a number of times it just stopped working. if waypoints can expire and expired waypoint slots can be reused for something else that would be awesome.
-
Getting the AI to follow moved (as in the coordinates) is a fairly simple fix, I think I have an untested and possible incomplete patch at home that does just that. If I recall correctly (its been a while), the reason that the AI doesn't follow a moved waypoint is because of what appears to an oversight in the AI code. I believe I was working on this for a request in HPC, though I can't find the thread at this time.
-
Okay, I think there are no showstoppers for making waypoints dynamic via linked lists. I'll see if I can come up with something this weekend.
-
Okay, this looks like it's ready to go. Mjn.Mixael and I have already validation tested it a bit, and I found and fixed a few simple bugs. Here's the build and a patch. More testing is appreciated.
http://staff.hard-light.net/goober5000/temp/dynamic_waypoints.zip
[attachment deleted by ninja]
-
Hrmm, I went to give it a test but had trouble patching trunk r7565 cleanly.
patching file code/object/waypoint.cpp
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file code/object/waypoint.cpp.rej
(Stripping trailing CRs from patch.)
patching file code/object/waypoint.h
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file code/object/waypoint.h.rej
Because those sections are such large changes, I'm dreading having to apply the patch manually...
-
I patched it off the latest trunk, so it should be clean. But waypoint.h and waypoint.cpp were almost entirely rewritten, so you can just replace the entire files.
-
Waypoint related crash, log attached.
[attachment deleted by ninja]
-
Okay, after a lot more testing, a few minor changes, and a critical bug fix, this is now in SVN. It should be in the next nightly build.
-
Getting the AI to follow moved (as in the coordinates) is a fairly simple fix, I think I have an untested and possible incomplete patch at home that does just that. If I recall correctly (its been a while), the reason that the AI doesn't follow a moved waypoint is because of what appears to an oversight in the AI code. I believe I was working on this for a request in HPC, though I can't find the thread at this time.
Do want!
-
I found a bug. E fixed it. Zacam said he was going to murder you. I'm scared now. :(
-
Soooooo.......
This updates the Waypoint limit?
-
No. It removes it.
-
Please bump the limit. It caused an INFASA mission to break a while ago, one that took sooo many hours to complete. :(
-
Sure. Hang on a second
....
There. Bumped from infinity to infinity + 1.
-
Good to know I don't have to deal with that limit anymore, thanks :yes:
-
That was fast and helpful. Thanks! :)
-
Sure. Hang on a second
....
There. Bumped from infinity to infinity + 1.
Juuuust one more please :)
-
Just so you know, this feature wasn't coded because someone posted a request in the public forum. It was coded because at least two hosted projects had an immediate "strongly desire" request for it. :p
It properly should have been moved to the Hosted Collaboration forum, but I left it in public so that people could follow along.