A lot of mapping woes

[AccadaccA]

This is doing my head in.
I must have spent a full week on trying to make a simple brush move from waypoint A to waypoint B.
I even decided to replace the waypoints with "script_origin"s and still no luck.
So I tried "moveeast" and "movewest" but nothing is working.
That same map has an elevator that goes up and down through multiple levels, even express depending on the button pushed.
Yet a simple brush representing a sliding door (not part of the elevator) won't go from A to B.

I have re-re-re-re-rechecked my target names and the script a kazillion times.


Now I have moved onto another map. Again waypoints and script origins simply refuse to work for me.
Even the scripted "show" and "hide" are failing for some script objects in the map but not others.
When / if they eventually do work the script_object is totally black until I change to spectator mode. Then it is textured correctly. WTF is with that?
I researched the web and found that you could move "func_group" objects so I tried that too, to no avail.

I have a complex script ahead of me planned for this map yet the basics aren't working.

Its hard to keep in the mapping game and spirit of things when shit like this keeps happening for no apparent reason.
I don't know if using the Revival installation has anything to do with it.
Maybe that is what is also causing the scorch marks when compiled. Who knows?
Since getting this system I have only installed MOH Revival and have had a multitude of mapping woes.

Just wondering if any other mappers are currently editing with only the Revival installation?
I think I will install my MOH (War Chest) retail discs and see how things are then.

[1337Smithy]

Hey,

I've not tried Revival MOHAA.. I use the GoG version, and I'm not sure about the issues you're facing so can't be certain of the cause...

Personally, I've not actually made a brush move from position to position per se, but I have made it rotate. Here is part of my script of the Normandy mission I did:

$boss_door time 0.2
$boss_door rotateYdown 10
$boss_door waitmove

wait 1 

$officer1_boss anim grenade_kick_scripted

wait .5

$boss_door playsound snd_crate_wood2

$boss_door time 0.2
$boss_door rotateYdown 90
$boss_door waitmove

$boss_door is just a simple script_object of $targetname boss_door

Also, here is the part of the script in m6l3a that moves the train to a node's origin:

$solid_train_engine moveto $("trainnode" + local.i).origin
$solid_train_engine speed local.trainspeed
$solid_train_engine waitmove

The variables are set at the start of the thread, but to make it simpler:

$solid_train_engine moveto $node1.origin
$solid_train_engine speed 5
$solid_train_engine waitmove

Everything was bound together:

$ghost_train_engine bind $solid_train_engine
$train_boxcars bind $solid_train_engine
$train_engine_door1 bind $solid_train_engine
$train_engine_door2 bind $solid_train_engine
$train_boxcars_door bind $train_boxcars
$train_boxcars_door2 bind $train_boxcars
$train_playerclip bind $train_boxcars

Don't know if that helps...

[Major_A]

Yet a simple brush representing a sliding door (not part of the elevator) won't go from A to B.

Did you happen to try moveUp, moveDown, moveLeft & moveRight?

This is a crate elevator on my Brest map.
I realize it is continuouse moves, but
idk if it will help, just adding another option.

/////////////////////////////////////
    level waittill spawn
////////////////////////////////////
thread dm1


level.crate1 = spawn script_model
level.crate1 model "static/indycrate.tik"
level.crate1.origin = ( 264.71 -606.79 280.13 )
level.crate1.angles = ( 0 125 0 )



dm1:
while (1) 
{
wait 5
level.crate1 moveUp 682
level.crate1 waitmove
wait 5
level.crate1 moveDown 682
level.crate1 waitmove
}
end

I remember having that issue on my Star wars conversion too, let me look and I'll edit post.

Edit:
I had intended to release the .map file with the map, but I think it was forgotten.
If you download the map look for the lifts, I think there's 4.
Then see what I did in radient as I built it into it that way.
https://www.dropbox.com/s/rrfpbavlow...jor_A.map?dl=0

Full Map
http://www.mohaaaa.co.uk/AAAAMOHAA/c...haddaa-streets

[AccadaccA]

Thank you both 1337Smithy and Major_A. I will look into both of your suggest scripts.
I can't blame Revival for the lack of movement as I've now installed War Chest then decided to work in the Spearhead Radiant and its doing the same shit.
The thing that gets me is I know the methods I have recently tried have worked for me in the past. So why not now?
There's nothing complicated about it.

I don't need an elevator script as that part of the same map works flawlessly.
It's just a single brush door (turned into a script_object) that isn't bound to the elevator, won't perform a simple "move to" function.
I could make a regular sliding door but I want it to be activated by the elevator script and it simply refuses to move even when I tested with triggers.
I haven't tried "moveleft", "moveright" and so forth. I'll give them a go.

Thanks for the feedback guys. Much appreciated.

[Major_A]

That's what kept happening to me as well.
and then after that, one section would move out of sync with the rest.

I had to delete the targetnames and reset them, a couple times actually. I even found a piece of the wall and floor I had unknowingly gave the same targetname.

[AccadaccA]

That's what kept happening to me as well....

Doesn't it just rip the fork out of ya nightie? lol
I mean the complex part being the multi-level elevator works flawlessly (floor-by-floor or express) but a simple brush sliding from A to B just isn't happening.
Same map, same script, same method applied.

Unfortunately "moveleft 64" and "moveright 64" still didn't cut it.
Admittedly I tried this on yet another map, my most current one which requires a jail gate to slide shut upon a multiple trigger.
I'll be honest and say that I don't like to use those move methods (including "movesouth 64" & "movenorth 64", etc) because when the thread is set by a trigger it can be triggered multiple times moving your object further than anticipated.
Of course you can add the line "nottriggerable" to some applications but only if they return to the starting position, before making them "triggerable" again. Otherwise the next player to walk through the trigger will make it move even further.
Where as waypoints and scrip_origins have set coordinates to move to without room for error by multi triggering... rather than step left, step left, step right, line dancing to "Nutbush City Limits" or "The Rocky Horror Picture Show". lol
They were worth a shot though. Thanks. (perhaps a jello shot) lol

I'll give it a go deleting and re-entering the target names... a kazillion times.
With my luck, they might work if I change the target names to something totally irrelevant and stupid like "YoMumma". lol

[1337Smithy]

Doesn't it just rip the fork out of ya nightie? lol
I mean the complex part being the multi-level elevator works flawlessly (floor-by-floor or express) but a simple brush sliding from A to B just isn't happening.
Same map, same script, same method applied.

Unfortunately "moveleft 64" and "moveright 64" still didn't cut it.
Admittedly I tried this on yet another map, my most current one which requires a jail gate to slide shut upon a multiple trigger.
I'll be honest and say that I don't like to use those move methods (including "movesouth 64" & "movenorth 64", etc) because when the thread is set by a trigger it can be triggered multiple times moving your object further than anticipated.
Of course you can add the line "nottriggerable" to some applications but only if they return to the starting position, before making them "triggerable" again. Otherwise the next player to walk through the trigger will make it move even further.
Where as waypoints and scrip_origins have set coordinates to move to without room for error by multi triggering... rather than step left, step left, step right, line dancing to "Nutbush City Limits" or "The Rocky Horror Picture Show". lol
They were worth a shot though. Thanks. (perhaps a jello shot) lol

I'll give it a go deleting and re-entering the target names... a kazillion times.
With my luck, they might work if I change the target names to something totally irrelevant and stupid like "YoMumma". lol

It would be interesting to know what the script is, as I would have thought using nottriggerable would be possible, but maybe I'm not understanding the use case.

Have you tried global variables as flags? For example, the first contact with the trigger_multiple sets the 'level.gateopen = true' and you can then use that as the condition to stop. You can even play around with the 'wait' property of the trigger in Radiant so that you aren't constantly hammering the thread.

So it could look like:

//---------------------------//
level waittill prespawn
//---------------------------//

level.gateopen = false //assuming the gate is closed on level start....

//---------------------------//
level waittill spawn
//---------------------------//

//Open gate trigger_multiple
opengate:

   if (level.gateopen == false)
   {
       //OPEN DOOR CODE

       level.gateopen = true       

   }

end

//Close gate trigger_multiple
closegate:

   if !(level.gateopen == false)
   {
       //CLOSE DOOR CODE
       
       level.gateopen = false
   }


end

Then on your trigger_multiple you have a 'wait' of however many seconds you want to wait until it is fired again.

I don't know exactly what you're trying to achieve so it could be complete nonsense, so forgive me if it is.

Another way:

//---------------------------//
level waittill prespawn
//---------------------------//

$close_gate_trigger nottriggerable //if you can in fact get to this trigger to begin with...

//---------------------------//
level waittill spawn
//---------------------------//

//Open gate trigger_multiple
opengate:

       $open_gate_trigger nottriggerable

       //OPEN DOOR CODE

       wait 2 //or however long it takes for it to open

       $close_gate_trigger triggerable

end

//Close gate trigger_multiple
closegate:

       $close_gate_trigger nottriggerable

       //CLOSE DOOR CODE
       
       wait 2 //or however long it takes for it to open

       $open_gate_trigger triggerable

end

Or you could just have a single trigger_multiple and thread whilst using your global variables, along with protection from multiple calls:

togglegate:

       $toggle_gate_trigger nottriggerable

       if (level.gateopen == false)
       {
             //OPEN DOOR CODE
            
             wait 2 //or however long it takes for it to close - perhaps a waitmove??

             level.gateopen = true
       } 
       else
       {
             //CLOSE DOOR CODE
            
             wait 2 //or however long it takes for it to open - perhaps a waitmove??

             level.gateopen = false
       }

       $toggle_gate_trigger triggerable

end

Or you just open it, set the flag, make it nottriggerable, and then just make it triggerable during some other event I assume you have.

[AccadaccA]

Sorry 1337Smithy, I realized that I could use "nottriggerable" after writing the post but I didn't think of global variables at all.
Although that's not where the problem lies.
The bloody things just don't want to move.

To paint a picture of my current map setup, I have two axis jails and two allied jails each jail has one gate.
Because of their locations on the map I decided to refer to them as compass points. Axis jails are to the North & South of the map and Allies jails are located East & West.
Outside each jail is a trigger_multiple the escapees run trough about 5 seconds after exiting the jail gate which sets the thread to close the gate behind them.
Elsewhere in the map (near each jail) are four trigger_use alarm switches which set the respective thread to open the jail gate.
The gates have script_origins at their open and shut coordinates.
Nothing fancy.

lockeast:
	$eastgate moveto $eastshut
	iprintlnbold "Allies jail A is locked"
end

locknorth:
	$northgate moveto $northshut
	iprintlnbold "Axis jail A is locked"
end

locksouth:
	$southgate moveto $southshut
	iprintlnbold "Axis jail B is locked"
end

lockwest:
	$westgate moveto $westshut
	iprintlnbold "Allies jail B is locked"
end

openeast:
	$eastgate moveto $eastopen
	iprintlnbold "Allies jail A is unlocked"
end

opennorth:
	$northgate moveto $northopen
	iprintlnbold "Axis jail A is unlocked"
end

opensouth:
	$southgate moveto $southopen
	iprintlnbold "Axis jail B is unlocked"
end

openwest:
	$westgate moveto $westopen
	iprintlnbold "Allies jail B is unlocked"
end

I'm happy to send you both the map and script.

[Major_A]

Love the script sharing and multiple ways of things!

These types of things or special stuff no-one has will help in the future, it's great!

[AccadaccA]

Love the script sharing and multiple ways of things!

These types of things or special stuff no-one has will help in the future, it's great!

Absolutely. Its great to find other mappers or script writers still around and willing to help.
Its also funny how we tend to stick to our proven methods (well I do) thinking that's the only way something is done then we're shown alternative methods.
I've always used waypoints or scrip_origins to move anything and never "movenorth", "movesouth", .... etc or "moveleft", "moveright",... etc.
I like to keep the scripting as short and basic as possible but I guess that comes from programming.