|
|
Line 1: |
Line 1: |
| =Three-floor elevator: Project exposition=
| |
| *REMEMBER: | | *REMEMBER: |
| :'''WRITE THE PAGE''' | | :Write the page |
| :Check if something was forgotten
| | :'''Check if something was forgotten''' |
| :Check if everything is truly explained (have no timeline errors, or report errors, DOESN'T MEAN technical error that have truely happened)
| |
| :Add schematic pictures | | :Add schematic pictures |
| :Correct spelling mistakes | | :Correct spelling mistakes |
|
| |
|
| <div style="text-align: left; background: lightblue; font-weight: bold; margin: 5em 10%; padding: 20em 10em; border: red 3px solid;">
| | ==A global idea== |
| This article is currently written. Do NOT modify it until this message have completely disappeared. EVEN to correct mistakes.
| | When you want to do some specific subject which need entities that is not explained by any tutorial, what you have to do is to '''study the entities'''. At least remember the global description of the entities. Then you will '''be able to select in these entities those which you need in the accomplishment of your task'''. Write down '''what you need''' in your task. Then write '''what constraints''' inferfeer in the accomplishment of your task. This is particulary linked on the '''main entity''' where you will apply effects of other entities on. Only now you can '''select the entities''' you need in order to check the objectives and avoid the constraints. |
| This message won't disappear until complete end. This message will stay as long as it takes. Discuss about this page using related discussion page.
| |
| </div>
| |
| ----
| |
| '''Warning:''' This text is a personnal explanation where I put all I've found at the right time. What I find can be true or false. '''As long as these explanations are taken from real conclusions, do NOT modify the text to correct something even if that is FALSE. You are only authorized to correct spelling mistakes'''. Please understand what I mean, '''this is not an encyclopedial page''' but some kind of '''report''' and '''reports don't have to be changed'''. | |
| ----
| |
| The project began on September. It's a challenge that I successfully accomplish what I want: What I want globally is to make an elevator with 3 floors on Source Engine.
| |
|
| |
|
| This document shows you my procedure when I want to accomplish a technical task on Half-Life, Source or not.
| | '''For example''', you want to do a Scanner that spawns manhacks '''when it photograph you'''. '''The main entity is [[Npc_cscanner]]'''. Study this entity: You will see that the output OnPhotographPlayer exists. If you study it clearly, even if you are hidden when the Scanner flashes, the output is triggered. '''This is the constraint'''. |
|
| |
|
| ==My Task Procedure==
| | You will now think about the idea. You want the OnPhotographPlayer to work when it sees the player, but '''not when it is not seen'''. There are two outputs that activates when the Scanner finds the player(OnFoundPlayer), and when it loses him from its line of sight (OnLostPlayerLOS). The problem is that you don't want the scanner to send manhacks when it sees it '''but''' when it sees AND it makes a flash. |
| When you want to do some specific subject which need entities that is not explained by any tutorial, what you have to do is to '''study the entities'''. Then you will '''be able to select in these entities those which you need in the accomplishment of your task'''. Write down '''what you need''' in your task. Then write '''what constraints''' inferfeer in the accomplishment of your task. This is particulary linked on the '''main entity''' where you will apply effects of other entities on. Only now you can '''select the entities''' you need in order to check the objectives and avoid the constraints.
| |
|
| |
|
| '''For example''', you want to do a Scanner that spawns manhacks '''when it photograph you'''. '''The main entity is npc_cscanner'''. Study this entity: You will see that the output OnPhotographPlayer (not sure) exists. If you study it clearly, even if you are hidden when the Scanner flashes, the output is triggered. '''This is the constraint'''. | | '''If you have studied the entities''', you would know that the [[Logic_branch]] is an entity where you can output when the value is ''1''(True) or ''0''(False). We can say in another way: ''If it's true that the Scanner sees the player, trigger the output''. |
| | |
| You will now think about the idea. You want the OnPhotographPlayer to work when it sees the player, but '''not when it is not seen'''. There are two outputs that activates when the Scanner finds the player, and when it loses him. The problem is that you don't want the scanner to send manhacks when it sees it '''but''' when it sees AND it makes a flash.
| |
| | |
| If you have studied the entities, you would know that the logic_branch is an entitie where you can output when the value is ''1''(True) or ''0''(False). We can say in another way: If it's true that the Scanner sees the player, trigger the output.
| |
|
| |
|
| That's all! Now you have all the bases and you can easily connect the entities '''theorically''': | | That's all! Now you have all the bases and you can easily connect the entities '''theorically''': |
| * When the scanner sees the player : Set the branch value to 1. | | * When the scanner sees the player(OnFoundPlayer) : Set the [[Logic_branch|branch]] value to 1('''SetValue''' 1). |
| * When the scanner have lost the player : Set the branch value to 0. | | * When the scanner have lost the player LOS(OnLostPlayerLOS) : Set the [[Logic_branch|branch]] value to 0('''SetValue''' 0). |
| * When the scanner photograph the player : Test the branch. | | * When the scanner photograph the player(OnPhotographPlayer) : '''Test''' the [[Logic_branch|branch]]. |
| * When the test is true : Trigger the Manhack spawner (npc_template_maker) once only. | | * When the test is true(OnTrue) : '''Enable''' the Manhack spawner ([[Npc_template_maker]]) once only. |
|
| |
|
| All you need to do from now is to '''create it''' and '''see if the theory is true'''. If its not, you have to find '''why the theory is wrong''', or make other decisions.
| | These are the outputs we should make: |
|
| |
|
| This part shows a harder project that is still not finished. This applies my method.
| | {| |
| | |+Object outputs: scanner_tscanner - npc_cscanner |
| | ! || My Output || Target Entity || Target Input || Parameter || Delay || Only Once |
| | |- |
| | | [[Image:Io11.png]] || OnFoundPlayer || branch_tscanner || SetValue || 1 || 0.00 || No |
| | |- |
| | | [[Image:Io11.png]] || OnLostPlayerLOS || branch_tscanner || SetValue || 0 || 0.00 || No |
| | |- |
| | | [[Image:Io11.png]] || OnPhotographPlayer || branch_tscanner || Test || <none> || 0.00 || No |
| | |} |
|
| |
|
| ==Objectives==
| |
|
| |
|
| There are the objectives:
| | {| |
| * It needs a "call" button for each floor.
| | |+Object outputs: branch_tscanner - logic_branch |
| * It doesn't have to stop between two floors.
| | ! || My Output || Target Entity || Target Input || Parameter || Delay || Only Once |
| * It mustn't change direction while moving.
| | |- |
| * In the elevator, a "Go up" and "Go down" button are only required.
| | | [[Image:Io11.png]] || OnTrue || maker_tmanhack || Enable || <none> || 1.00 || Yes |
| * It doesn't need a "Go to floor 1", "Go to floor 2" and "Go to floor 3" buttons.
| | |} |
| * A "resend" button is not needed.
| |
| * It must move at the same speed.
| |
| * The elevator must have doors.
| |
| * '''It must work in multiplayer game.'''
| |
|
| |
|
| Any method can be used. The most important objective is: '''It must work in multiplayer game.'''
| | All you need to do from now is to '''create it''' and '''see if the theory is true'''. If its not, you have to find '''why the theory is wrong''', or make other decisions. |
| | |
| Because Multplayer can make conflicts, like an idiot that constantly calls an elevator or going up between floor 2 and 3, preventive methods have to be found afterwards.
| |
| | |
| ==First method: With a func_tracktrain==
| |
| | |
| ===Explaining===
| |
| | |
| First guess for me was the use of a func_train. I'd liked to do it with a func_train and an trigger_changetarget '''as it could be done on Half-Life 1 Engine'''.
| |
| But when I saw that func_train have disappeared, I thought I could do the same with func_tracktrain.
| |
| | |
| I've tried to do that the way I could do with HL1. The method was to changetarget the train to a certain path. That way was terribly easy. But the func_tracktrain doesn't mind. Why the hack did they delete func_train? I've remembered a scene during the psychidelic sequence, where we san the Test chamber running. I've mapped for HL1 and I saw how the test chamber was made. The floading things were func_train. And If I saw them on HL², I had to know how it was made. Hopefully, the sequence was given along with the SDK. I ran the .vmf, and It was a func_train with undefinied classname in the FGD. Why the hack? (Why the '''hack''' is a personnal expression I use)
| |
| | |
| After some research, I couldn't find out why func_train was left. So I tried my chance with '''func_tracktrain'''. It is the '''main entity'''.
| |
| | |
| First thing I had to do is to study the entity. Here are the conclusions:
| |
| * It doesn't use path_corners.
| |
| * '''When it is set to stop at a path_track, it really stops'''. This is bad to make 3 floors as long ad I need the elevator to directly go to first floor if I call it when it is stationned on the third floor.
| |
| * We can only say "Go forward" or "Go backwards". '''No "Go to this path"''' or other.
| |
| I call these conclusions ''constraints''.
| |
| | |
| ===Theory===
| |
| Theory is to find out how will I accomplish the objectives by avoiding the constraints using the main entity.
| |
| What explained in theory is ''What entities do I need? Why? How will I connect them? Why will I connect them that way?''
| |
| | |
| A theory can have of course unforseen problems.
| |
| | |
| ===Acting===
| |
| | |
| ===Conclusion===
| |
| | |
| ==Second method: With a hacked func_train==
| |
| ===Explaining===
| |
| ===Theory===
| |
| ====Recent reports====
| |
| ::These are reports that were recently made.
| |
| ====Last report====
| |
| ::This was the last report. Last report happened on (''YYYY/MM/DD''): 2005/10/??
| |
| | |
| Other reports may come when something is found.
| |
- Write the page
- Check if something was forgotten
- Add schematic pictures
- Correct spelling mistakes
A global idea
When you want to do some specific subject which need entities that is not explained by any tutorial, what you have to do is to study the entities. At least remember the global description of the entities. Then you will be able to select in these entities those which you need in the accomplishment of your task. Write down what you need in your task. Then write what constraints inferfeer in the accomplishment of your task. This is particulary linked on the main entity where you will apply effects of other entities on. Only now you can select the entities you need in order to check the objectives and avoid the constraints.
For example, you want to do a Scanner that spawns manhacks when it photograph you. The main entity is Npc_cscanner. Study this entity: You will see that the output OnPhotographPlayer exists. If you study it clearly, even if you are hidden when the Scanner flashes, the output is triggered. This is the constraint.
You will now think about the idea. You want the OnPhotographPlayer to work when it sees the player, but not when it is not seen. There are two outputs that activates when the Scanner finds the player(OnFoundPlayer), and when it loses him from its line of sight (OnLostPlayerLOS). The problem is that you don't want the scanner to send manhacks when it sees it but when it sees AND it makes a flash.
If you have studied the entities, you would know that the Logic_branch is an entity where you can output when the value is 1(True) or 0(False). We can say in another way: If it's true that the Scanner sees the player, trigger the output.
That's all! Now you have all the bases and you can easily connect the entities theorically:
- When the scanner sees the player(OnFoundPlayer) : Set the branch value to 1(SetValue 1).
- When the scanner have lost the player LOS(OnLostPlayerLOS) : Set the branch value to 0(SetValue 0).
- When the scanner photograph the player(OnPhotographPlayer) : Test the branch.
- When the test is true(OnTrue) : Enable the Manhack spawner (Npc_template_maker) once only.
These are the outputs we should make:
Object outputs: scanner_tscanner - npc_cscanner
|
My Output |
Target Entity |
Target Input |
Parameter |
Delay |
Only Once
|
 |
OnFoundPlayer |
branch_tscanner |
SetValue |
1 |
0.00 |
No
|
 |
OnLostPlayerLOS |
branch_tscanner |
SetValue |
0 |
0.00 |
No
|
 |
OnPhotographPlayer |
branch_tscanner |
Test |
<none> |
0.00 |
No
|
Object outputs: branch_tscanner - logic_branch
|
My Output |
Target Entity |
Target Input |
Parameter |
Delay |
Only Once
|
 |
OnTrue |
maker_tmanhack |
Enable |
<none> |
1.00 |
Yes
|
All you need to do from now is to create it and see if the theory is true. If its not, you have to find why the theory is wrong, or make other decisions.