Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Goober5000 on February 06, 2011, 01:43:01 am
-
This build is for things like Black Wolf's ship maintenance facility, and whatever sekret features other mods would like to use it for. At least three mods have requested it to my knowledge. Test it out by setting the "does not move" flag on an installation, ship, fighter, or whatever via the ship flags dialog; or via the set-immobile sexp.
http://staff.hard-light.net/goober5000/temp/immobilize.zip
I'm particularly interested in how immobile ships act when they're docked to things, or when things collide with them.
-
Now you post it, just as I'm going to bed. Bah. DLed, will test tomorrow first thing after work.
-
Sadly, Immovable and no-ets tick boxes in FRED don't work in this package, so it's actually nigh on impossible to test properly.
And I don't see immobile as a ships tbl option, just as a sexp, so not sure how that is completely helpful.
And why 2 sexps when you can have it state-based and the argument structure, does it allow just ships, or does it do wings/iff groups/etc?
And if you tested this, how did you make it work?
-
I've fixed the checkboxes in FRED. This was due to an error in the checkbox settings. When you create a new checkbox in FRED, you're supposed to copy a previous checkbox so you get the settings right. I copied the "disable ets" checkbox. Well, it turns out whoever added "disable ets" didn't himself copy a box. :doubt: And somehow managed to get the DDX event processing wrong as well.
I've also fixed a bunch of schizophrenia between the same exact concept alternatively being called "allow ets" and "disable ets". Furthermore, I fixed the load/save behavior of the ETS flag, which had never actually been implemented.
So, the last commit was essentially a giant "no-ets" infrastructure fix, which, as a tiny auxiliary detail, also happened to fix the checkbox bug with the immovable ship flag. Update to last trunk and try again. The diff for object.cpp hasn't changed.
To answer your questions:
1) Fixed
2) It isn't in ships.tbl because it's a ship flag, not a ship class flag
3) The ship flag can be toggled via sexp or via the ship flags dialog in FRED
4) It only works with ships currently, just like every other sexp in that family (set-visible, ship-vaporize, etc.)
5) Haven't tested the immovable behavior, that's why I posted a testing thread
-
Well... um... even so, the checkbox seems to be broken :p However, I did run a test setting the flag with SEXPs. Here are the results:
1) Things with the flag stay still. No matter what. This is good. Tested ramming, missile hits and morning star hits, and nothing moved the target.
2) Things also stay still (and intact) when they're 'killed'. This could actually be an interesting mechanic for derelicts and space hulks, as you can show that the ship is dead yet keep it in one piece if you need to.
This was all in single player though. Going to need to run a multiplayer test as well to make sure it works there as well. And I know just the mission to test it on, too.
-
Well, when I said update to trunk, I meant just that: update, patch, and build from source. I didn't have time to make a new build until now.
So, new set of builds uploaded. Same patch as before, same link as above, but latest from trunk.
-
Whoops. I should read more carefully it seems.
-
Doesn't the sexp need to send the flag to client? Client handles the draws and while the host may send the position of the object I think this is going to result in the same "jumping" behavior we are trying to avoid if it's not sent.
-
The flag is sent to the client because the set-mobile/set-immobile sexps use the same infrastructure as all the other ship flag sexps.
I don't know enough about the multi code to know whether it will jump or not. It shouldn't. Why don't you give it a test? :p
-
No it's not read your patch. You do not supply the optional 10th argument to send it to client. Default is false. Same with the 11th argument but no idea if that needs to be true or not.
-
Oh, I see what you mean.
Hmm... why have that variable in the first place? On what occasions would one not want to send the flag to multiplayer clients?
-
Anything that is processed only on the host. Only flags that actually do something client side need to be sent.
-
Does not work at all with docked containers. Tested 6 containers docked to a ship. Shot one container with a bomb. This apparently destroyed 2 others as well. Those 3 containers became stationary and untargetable. The parent ship (no immobile flag on it) shot off with a speed in excess of 600 with the remaining 3 docked containers. Destroying one of those resulted in the same behavior with the destroyed one becoming an unmovable dead object and the ship shooting off sideways at high speed with the other 2.
Some excerpts from the log:
speed reset in physics_collide_whack [speed: 12520.605469]
speed reset in physics_collide_whack [speed: 1090.697876]
Num_particles high water mark = 23
Num_particles high water mark = 24
Num_particles high water mark = 25
Num_particles high water mark = 26
Num_particles high water mark = 27
Num_particles high water mark = 28
Num_particles high water mark = 29
Num_particles high water mark = 30
Num_particles high water mark = 31
Num_particles high water mark = 32
Num_particles high water mark = 33
speed reset in physics_collide_whack [speed: 12507.908203]
speed reset in physics_collide_whack [speed: 1495.591309]
Num_particles high water mark = 34
Num_particles high water mark = 35
Num_particles high water mark = 36
Num_particles high water mark = 37
Num_particles high water mark = 38
Num_particles high water mark = 39
Num_particles high water mark = 40
Num_particles high water mark = 41
speed reset in physics_collide_whack [speed: 12509.028320]
speed reset in physics_collide_whack [speed: 1498.049927]
-------------------------------------------------------------------------------
speed reset in physics_collide_whack [speed: 73194.601563]
rotvel reset in physics_collide_whack
speed reset in physics_collide_whack [speed: 6238.752441]
OpenAL ERROR: "Invalid Enum" in c:\fs2_open_diaspora\code\sound\ds.cpp, line 1616
speed reset in physics_collide_whack [speed: 538.495667]
speed reset in physics_collide_whack [speed: 591.880676]
Noticed the log file contained no "SHIP DESTROYED:" entries.
-
So was this single or multi, and which ship(s) had the flag?
Could you post the mission you used to test?
-
It was in single and you won't have the models. It was a simple transport with 6 docked containers (all 6 containers had the flag) doing a waypoint path. Flag was set in ships editor not via sexp.
-
New patch attached, with a very small change that should fix the destruction bug. Apply to trunk.
Can you upload the model you used for testing?
Index: code/object/object.cpp
===================================================================
--- code/object/object.cpp (revision 7007)
+++ code/object/object.cpp (working copy)
@@ -1369,104 +1369,93 @@
MONITOR_INC( NumObjects, Num_objects );
- objp = GET_FIRST(&obj_used_list);
- while( objp !=END_OF_LIST(&obj_used_list) ) {
+ for (objp = GET_FIRST(&obj_used_list); objp != END_OF_LIST(&obj_used_list); objp = GET_NEXT(objp)) {
// skip objects which should be dead
- if ( !(objp->flags&OF_SHOULD_BE_DEAD) ) {
- vec3d cur_pos = objp->pos; // Save the current position
+ if (objp->flags & OF_SHOULD_BE_DEAD) {
+ continue;
+ }
- // if this is an observer object, skip it
- if(objp->type == OBJ_OBSERVER){
- objp = GET_NEXT(objp);
- continue;
- }
+ // Goober5000 - skip objects which don't move, but only until they're destroyed
+ if (objp->flags & OF_IMMOBILE && objp->hull_strength > 0.0f) {
+ continue;
+ }
- // if we're playing a demo back, only sim stuff that we're supposed to
- if((Game_mode & GM_DEMO_PLAYBACK) && !demo_should_sim(objp)){
- objp = GET_NEXT(objp);
- continue;
- }
+ // if this is an observer object, skip it
+ if (objp->type == OBJ_OBSERVER) {
+ continue;
+ }
+ // if we're playing a demo back, only sim stuff that we're supposed to
+ if ((Game_mode & GM_DEMO_PLAYBACK) && !demo_should_sim(objp)) {
+ continue;
+ }
+
+ vec3d cur_pos = objp->pos; // Save the current position
+
#ifdef OBJECT_CHECK
- // if(! ((Game_mode & GM_MULTIPLAYER) && (Net_player != NULL) && !(Net_player->flags & NETINFO_FLAG_AM_MASTER)) ){
- obj_check_object( objp );
- // }
+ // if(! ((Game_mode & GM_MULTIPLAYER) && (Net_player != NULL) && !(Net_player->flags & NETINFO_FLAG_AM_MASTER)) ){
+ obj_check_object( objp );
+ // }
#endif
- // pre-move
- obj_move_all_pre(objp, frametime);
+ // pre-move
+ obj_move_all_pre(objp, frametime);
- // store last pos and orient
- objp->last_pos = cur_pos;
- objp->last_orient = objp->orient;
+ // store last pos and orient
+ objp->last_pos = cur_pos;
+ objp->last_orient = objp->orient;
- // if this is an object which should be interpolated in multiplayer, do so
- if(multi_oo_is_interp_object(objp)){
- multi_oo_interp(objp);
- } else {
- // physics
- obj_move_call_physics(objp, frametime);
- }
+ // if this is an object which should be interpolated in multiplayer, do so
+ if (multi_oo_is_interp_object(objp)) {
+ multi_oo_interp(objp);
+ } else {
+ // physics
+ obj_move_call_physics(objp, frametime);
+ }
- // move post
- obj_move_all_post(objp, frametime);
+ // move post
+ obj_move_all_post(objp, frametime);
- //Equipment script processing
- if (objp->type == OBJ_SHIP) {
- ship* shipp = &Ships[objp->instance];
- object* target;
- if (Ai_info[shipp->ai_index].target_objnum != -1)
- target = &Objects[Ai_info[shipp->ai_index].target_objnum];
- else
- target = NULL;
- if (objp == Player_obj && Player_ai->target_objnum != -1)
- target = &Objects[Player_ai->target_objnum];
- Script_system.SetHookObjects(2, "User", objp, "Target", target);
- Script_system.RunCondition(CHA_ONWPEQUIPPED, 0, NULL, objp);
- }
+ // Equipment script processing
+ if (objp->type == OBJ_SHIP) {
+ ship* shipp = &Ships[objp->instance];
+ object* target;
+
+ if (Ai_info[shipp->ai_index].target_objnum != -1)
+ target = &Objects[Ai_info[shipp->ai_index].target_objnum];
+ else
+ target = NULL;
+ if (objp == Player_obj && Player_ai->target_objnum != -1)
+ target = &Objects[Player_ai->target_objnum];
+
+ Script_system.SetHookObjects(2, "User", objp, "Target", target);
+ Script_system.RunCondition(CHA_ONWPEQUIPPED, 0, NULL, objp);
}
- objp = GET_NEXT(objp);
}
// After all objects have been moved, move all docked objects.
- if(!(Game_mode & GM_DEMO_PLAYBACK)){
- objp = GET_FIRST(&obj_used_list);
- while( objp !=END_OF_LIST(&obj_used_list) ) {
+ if (!(Game_mode & GM_DEMO_PLAYBACK)) {
+ for (objp = GET_FIRST(&obj_used_list); objp != END_OF_LIST(&obj_used_list); objp = GET_NEXT(objp)) {
dock_move_docked_objects(objp);
// unflag all objects as being updates
objp->flags &= ~OF_JUST_UPDATED;
-
- objp = GET_NEXT(objp);
}
}
- // Now that all objects have moved, we should calculate the
- // velocities from how far they moved.
- // DA: Commented out 2/23, unnecessary since colliding objects calculate their post collision velocities through physics.
- /*
- objp = GET_FIRST(&obj_used_list);
- while( objp !=END_OF_LIST(&obj_used_list) ) {
- if ( !(objp->flags&OF_SHOULD_BE_DEAD) && (objp->type != OBJ_OBSERVER) && (objp->type != OBJ_ASTEROID) && (objp->type != OBJ_DEBRIS)) {
- objp->phys_info.vel.x = (objp->pos.x - objp->last_pos.x) / frametime;
- objp->phys_info.vel.y = (objp->pos.y - objp->last_pos.y) / frametime;
- objp->phys_info.vel.z = (objp->pos.z - objp->last_pos.z) / frametime;
- }
- objp = GET_NEXT(objp);
- } */
-
- if(!(Game_mode & GM_DEMO_PLAYBACK)){
- find_homing_object_cmeasures(); // If any cmeasures fired, maybe steer away homing missiles
+ // If any cmeasures fired, maybe steer away homing missiles
+ if (!(Game_mode & GM_DEMO_PLAYBACK)) {
+ find_homing_object_cmeasures();
}
// do pre-collision stuff for beam weapons
beam_move_all_pre();
- if ( Collisions_enabled ) {
+ if ( Collisions_enabled ) {
obj_check_all_collisions();
}
- if(!(Game_mode & GM_DEMO_PLAYBACK)){
+ if (!(Game_mode & GM_DEMO_PLAYBACK)) {
turret_swarm_check_validity();
}
[attachment deleted by ninja]
-
I'll give it a try in a bit. Unfortunately I can't upload that model. Maybe I can toss together a version of it out of lod3 with a retail fs2 texture or something. Have to check with Kara.
-
Fine with me.
-
Well the ships are dying now. Still have the issue with the transport getting whacked at huge speed. If it set it to immobile as well it doesn't do the waypoint path, containers docked to it show they have a speed of 10, but it also doesn't get shot around by the container explosions. I'll work on getting that test model in a bit.
-
This is why testing needs to happen with retail assets. :rolleyes: The transport has model issues that cause problems even without the flag in place. Sometimes it will behave itself just fine, and sometimes it will swing wildly all over the map. The whack problem exacerbated this, true, but the model didn't behave properly even when used as a control.
I created a separate testing issue and decided that the whack was a consequence of skipping the pre- and post- processing of objects. I narrowed the scope of the flag to just the actual object moving, and it seems to work fine. So I committed it.
-
But that is one of the issues we hoped this flag would solve. There is nothing wrong with the model itself it's something in the engine and that issue has been in mantis for ages. It's reproducible with retail assets as well just hard to do due to insufficient docking points and locations.
On that same model in prior testing the following works:
1 container docked anywhere
2 containers docked as long as one is at the front and one at the back (although this behavior seems to be somewhat different either in recent builds or due to having the flag enabled)
3 or 4 containers docked as long as 2 or 3 are on either front or back and you destroy the single one on the other side.
So something goes wrong with the engine when those containers are docked at angles. Doesn't matter what is docked, size, etc. I even reproduced the behavior with a simple long rectangle (which I think is attached to that old mantis report).
-
What is the mantis ticket?
And if it's reproducible with retail assets, is that information in the mantis ticket?
-
http://scp.indiegames.us/mantis/view.php?id=2112
Figured you knew as it's assigned to you. It's not quite reproducible with retail but some modified assets were attached.
-
Well, it was assigned to me automatically; I didn't assign it to myself. But now I see what you mean.
-
Eek - I was supposed to test this weeks ago. My bad, sorry goob. FWIW, it does exactly what it's supposed to for my stuff, solved a problem I'd been having with one particular shipyard setup tending to spontaneously tear itself apart - no such problem now. Only issue I came across was stuff didn't blow up, i.e. if you set the flag for the TGas-1, then kill it, it doesn;t convert to debris, juts sits there untargetable. But that's not an issue for my stuff at at the moment as the things you might want to kill are often not the things that ought to be immobile.
So yeah. Delayed though it may be, thanks muchly for this. :D
-
Cool, you're welcome. :)