OCD2

Another piggyback question -     My scripted elevators work as intended - though after using them once, they return to a resting position that is just a step lower than they started.

What would cause that / what did I do wrong?

33 minutes ago, NAB622 said:

You can just add that into the script, either by using move blocks on the doors or by having the script fire a func_door by targetname, with a use block.

Ideally, the doors should be part of the building and not the elevator, or bad things can happen.

Side note: instead of using a target_scriptrunner, you can put a usescript on the trigger_multiple, it should have the same result and save you an entity.

 

Thank you,  I will look up move blocks / use blocks.    And thank you for the tip about doors and placement.

Truly appreciate the help.

Second add on question:

How do I script the elevator to have doors that open when it reaches its destination?

4 minutes ago, mrwonko said:

The target_scriptrunner needs a count of -1

Thank you fast man, that was the problem.

I did have a working elevator, but ended up having surprise duplicate brushes on my lift that I had to delete, maybe deleting the extra trigger changed the values on the script runner?

Hello,

As per title, my scripted elevator only works once.

The triggers have a count of -1, and the elevator works, both up and down - but only one time. 

Then it will not function any longer.

What could I have done wrong?

Really looking forward to the contest,   I hope it's a map competition, and brings something fresh to the game.

I may even have something to submit!

5 hours ago, mjt said:

Are you planning to do this for SP or for MP? There are a few key differences regarding the functionality of func_train in MP and SP...

 

SP does support changing angles between path_nodes like yaw, etc. in MP this cannot be achieved the same way.

 

If you're doing this for SP you're lucky, because you can also make the moving platforms rotate around a N° Corner if set up properly. Also considering splitting up the physics and visual part... You can have path_corners trigger something, when they are reached. That way you can let each visual platform trigger the teleportation of the physical platform, when that was blocked realligning both.

Thank you for the information.

I understand most of what you wrote, through some was still outside my current skillset, though I'm willing and actively trying to learn!

So I could use a func train, and have it run its course, and trigger a teleport that resets it to the starting point - to make a sort of endless loop?

I was hoping to make at least a flat platform, that moves the player in a single direction.    With box's interspaced on it, so a player could "ride" it with some small cover to help them advance.

2 hours ago, BlindDaThief said:

Does anybody actually read these tho? I've seen some just sit there for literally years... I know people read these here. Just sayin

Also I would like to learn how to just make some. Is there a tutorial section I'm not aware of? I know most of you pros just say learn how to kitbash or whatever but never say how to learn..

If you ask, people will generally help, or point you in the right direction.

https://jkhub.org/forums/forum/153-tutorials/   

A quick glance at the tutorials section shows pages of modeling tutorials.  I believe the expectation is for people to read and try to learn on their own, and ask questions if youre stuck or confused. 

1 hour ago, AshuraDX said:

I messed with this for a bit, rof is sadly not an option if you want to have more than one escalator and that escalator is supposed to travel a sensible distance.

Based on that I'd guess that func_train is the best method to achieve a working escalator, here's an example map with an escalator using func_train: https://www.dropbox.com/s/9114k9nvi2hwisq/EscalatorJKA.zip?dl=0

The map consists of two rooms, one room where the escalator will be, and another room used to properly light the escalator steps, if you don't do this half of your escalator will turn out pitch black.

Very cool, thank you for all of the input, it is appreciated.

My main intent is to make a flat, moving conveyor belt, like you see in factories, mines, airports - I think I may be able to make one based off all the ideas you shared.   

Will try when I get a chance and share my results.

4 hours ago, AshuraDX said:

I'd probably use *.rof paths for this.

Here's an example:

Link to files used: https://www.dropbox.com/s/plrq0bgjaen2ry3/Minecart.zip?dl=0

This works by creating an animation in a 3d program like 3ds max or blender and exporting it using the respective *.rof exporters for them.

Currently only the blender exporter is publicly available.

Thank you for the idea, I'll look into it and see what I can make.

3 hours ago, NAB622 said:

Does anyone have any objections to this being renamed to "UpgRadiant" ? I need to change the name, and that describes what it is pretty well, but I'm terrible with names.

Noone likely minds the name, just appreciate the effort!

Sure, show more.

It's nice to see new work.

27 minutes ago, dark soul said:

It depends on how you manage them 、I guess

We have multiple loops running in different affects and it goes ok

So can I make a loop somehow to create a conveyor?

8 minutes ago, NAB622 said:

I don't believe there is a way, at least not without it being really janky.

Trigger_push and/or target_push are supposed to do it, but conveyor behavior wasn't properly added to the MP code.

Thank you for the reply.

I was playing a map named Citadel, and saw they added a line of moving "parts" that went down a path and disappeared into a hole, and repeated over and over.

I thought that might apply to making a conveyor belt.

I've been trying to think of a way to make a moving walkway/escalator, and I cannot determine how to make one work.

Is there a way to set up a constantly moving walkway?   

And if so, can you make it change directions to the x or y axis?  (So you can continuously ride it as it turns corners.)

I think I've got it, thank you for your help.

Though in using a func door to slide the bridge, how do you avoid having the bridge piece slide out dark from lack of lightning?

2 minutes ago, Ramikad said:

I generally make them usable func_door entities - they're simplest func_ entity with an already integrated basic movement, so they're pretty much flexible enough for me to use them as doors, bridges and elevators, anything moving on a straight line really. Otherwise you can have them as func_static (maybe with an origin brush too, not sure if it was needed or not) and move them through script.

Thank you!

What keys do you use to have them start in the "open" position?

As per title -   How do you make extending drawbridges?   

Do you have to write a script?

Good question.

Some people make terrain in other programs and export.   Maybe they will chime in?

Will she have an animation where she snarls with pointy teeth?

2 hours ago, NAB622 said:

Not really, since you're connecting them with corridors. What it does mean, though, is that you should use some HINT on those corridors to help the VIS process, but that's all.

Alright, I will be sure to add HINT to them as I build them out.

Really appreciate your input.

5 hours ago, Ramikad said:

Yeah, lowering blocksize to 0 isn't necessarily good for every map, but since there's no real need for VIS in this one I figured he may as well take it out entirely. There's only literally the two corridors to the sides that could cull parts of the map, and the geometry overall isn't that complex as to require VIS.

I was not done with the room/map yet when the problem arose - I just wanted to sqaush it before the map was built up.

With this map, there will be several corridors on the perimeter and at least two more rooms.

Will having a blocksize 0 impact the rest of the map as I build it out?

53 minutes ago, NAB622 said:

Don't forget to post the photos!

lol, yes that would help.

https://jkhub.org/albums/F2YVTUd

Edit :   I was able to resolve it by moving a few brushes. 

1 hour ago, NAB622 said:

blocksize 0 isn't a great idea, but I'm glad you were able to find the problem with it! As long as the map stays small, you should be fine using it. If it gets larger, try a different blocksize, like 2048 and see if the issue persists. Just remember that for the future, don't default to blocksize 0, as it will have effects on larger maps.

As for what blocksize is and how it works, here's an excerpt detailing how VIS works, taken from here:

http://nab622.com/tutorials/MappingErrors.html#show all:_:compile_time_errors-max_map_visibility-full_explanation

Somehow, between the blocksize slices and the portal slices, the compiler bugged up and was marking the offending geometry as being not visible. Also, thanks to the images you posted with showtris, there's some really odd slicing going on with that wall, which is weird because it shouldn't be slicing at all.....that's one thing I wish q3map2 had never done was slice brushes every place they intersect. But that does explain why part of it was visible, and part of it was not.

Thank you for the explanations!

I started plugging away at the map again, blocking out more areas, and now ive found that the wall opposite of the one which issue was solved now seems to not accept light!    

Not sure if its a separate issue, but in these photos, there is a 7000 unit light entity right next to the wall and its quite dark. 

2 minutes ago, Ramikad said:

Simply select any worldspawn brush and type in blocksize 0 (setting the blocksize value to 0).

I did it, compiled it and the map is functional again!

Thank you immensely for the help!

May I ask what blocksize does, and how you knew to change it to 0 to solve the problem?