約 4,365,124 件
https://w.atwiki.jp/gtavi_gta6/pages/2287.html
Sam Austin Memorial Building 概要 解説 店舗、外見など 概要 日本語：サムオースティン記念館 業種：サービス業（記念館） 所在地：バックロットシティ - リチャーズマジェスティックスタジオ内。 解説 リチャーズマジェスティックスタジオ内にある4階建ての建物。 記念館の中にはソロモン のオフィスがある。 殺人事件の謎を攻略するといつでも入ることができる。 建物の名前にもなっているサムオースティンはリチャーズマジェスティックとライバル関係であるにもかかわらずリチャーズマジェスティックスタジオ内に記念館を建てた理由は謎。 店舗、外見など ソロモンのオフィス
https://w.atwiki.jp/gtav/pages/2287.html
Sam Austin Memorial Building 概要 解説 店舗、外見など 概要 日本語：サムオースティン記念館 業種：サービス業（記念館） 所在地：バックロットシティ - リチャーズマジェスティックスタジオ内。 解説 リチャーズマジェスティックスタジオ内にある4階建ての建物。 記念館の中にはソロモン のオフィスがある。 殺人事件の謎を攻略するといつでも入ることができる。 建物の名前にもなっているサムオースティンはリチャーズマジェスティックとライバル関係であるにもかかわらずリチャーズマジェスティックスタジオ内に記念館を建てた理由は謎。 店舗、外見など ソロモンのオフィス
https://w.atwiki.jp/dslbookwip/pages/12.html
このページはhttp //martinfowler.com/dslwip/Intro.htmlからの引用です | DSL-WIP Home | WORK-IN-PROGRESS - this material is still under development An Introductory Example Last significant update 06 Aug 07 Contents Miss Grant s Controller The State Machine Model Programming the Controller with a Domain Specific Language Languages and Model Using Code-Generation Using Language Workbenches Visualization Picking up this book, you may be asking yourself such questions as what is a DSL , how does it fit in with my usual development work and why would I find such a thing useful ? This chapter begins by looking at these questions. I ll talk about what a DSL is, the various types of DSL, the reasons to use a DSL, and the broader topic of language processing. At this stage I won t talk about how the various styles of DSL work - we ll get into that later. Miss Grant s Controller As is usual for me, I ll base this discussion on an example, as I find that a concrete example usually makes it easier to follow an abstract topic like this. Let s imagine a company that makes systems to control access to secret compartments. Their customers are people who are bored with numeric keypads and security codes, instead preferring something recalling bad movies set in gothic castles. So Miss Grant has a secret compartment in her bedroom that is normally locked and concealed. To open it she has to close the door, open the second draw in her chest, turn her bedside light on - and then the secret panel is unlocked for her to open. Mr G has the same basic system for a panel in his bedroom. He has to open his bathroom door and turn on the main light which allows him to open the panel. The panel reveals a safe, but it has an overriding lock that cannot be opened unless he turns his light off and on again. Mr C has a compartment in his office, he has to close his main door, take a picture off the wall, turn his desklight on three times, open the top draw of his filing cabinet, turn the desklight off - and then the panel s unlocked. If he forgets to turn the desklight off, he wants an alarm to sound. Although this example is deliberately whimsical, the underlying point isn t that unusual. What we have is a family of systems which share most components and behaviors, but have some important differences. In this case we have some kind of controller software which communicates with various devices around the room. The variability is in the sequence of actions that can be carried out and the actions that the software does as a result of these sequences. We want to arrange things so that the company can install a new system with the minimum of effort, so it must be easy for them to program the sequence of actions into the controller. Looking at their many customers they realize there is a common theme to the way they behave. The various devices send events as they are manipulated. The system reacts differently to events depending on the recent sequence of events. This style of thinking about behavior is that of a state machine. Thus it makes sense to build a model of a state machine that can be programmed for individual customers at each site. That way the general behavior can be resued for each customer and setting up a new customer just means writing the specific things for each case. The software is written in java, running on a job lot of toasters they picked up from a failed dot com. The State Machine Model There are many varieties of state machine models around, this one is simple, and with a little twist for the this particular case. There are frameworks out there to run state machines, but we can do with something much simpler that s more suited to this particular domain. By doing this we give up some power for an easier job working with it. This issue isn t really part of the DSL discussion so I won t explore it further. To help understand how the state machine model works, let s take Miss Grant s system. Figure 1 State diagram for Miss Grant The system has a controller that receives events and commands from the various devices scattered around. Each event and command has a four letter code that s the actual signal sent through the communication channels. I want to refer to these in the controller code with symbolic names, so I create event and command classes with a code and a name. I keep them as separate classes (with a superclass) as they play different roles in the controller code. class AbstractEvent... private String name, code; public AbstractEvent(String name, String code) { this.name = name; this.code = code; } public String getCode() { return code;} public String getName() { return name;} public class Command extends AbstractEvent public class Event extends AbstractEvent Figure 2 Class diagram of the state machine framework [TBD Add reset event association to class diagram] The key to the structure is that state class. Each state class keeps track of the events and commands. class State... private String name; private List Command actions = new ArrayList Command (); private Map String, Transition transitions = new HashMap String, Transition (); public void addTransition(Event event, State targetState) { transitions.put(event.getCode(), new Transition(this, event, targetState)); } class Transition... private final State source, target; private final Event trigger; public Transition(State source, Event trigger, State target) { this.source = source; this.target = target; this.trigger = trigger; } public State getSource() {return source;} public State getTarget() {return target;} public Event getTrigger() {return trigger;} public String getEventCode() {return trigger.getCode();} The state machine holds on to its start state. class StateMachine... private State start; public StateMachine(State start) { this.start = start; } Any other states in the machine are then those that are reachable from this state. class StateMachine... public Collection State getStates() { List State result = new ArrayList State (); gatherForwards(result, start); return result; } private void gatherForwards(Collection State result, State start) { if (start == null) return; if (result.contains(start)) return; else { result.add(start); for (State next start.getAllTargets()) { gatherForwards(result, next); } return; } } class State... Collection State getAllTargets() { List State result = new ArrayList State (); for (Transition t transitions.values()) result.add(t.getTarget()); return result; } There is one particular wrinkle to this problem. These controllers have a particular nature to them in that most of the time they are in their start state, which is effectively an idle state. There are events that advance the state machine, and there are events that take you back to that start state. For this case opening the door always takes you back to the start. So I let the machine keep track of reset events. class StateMachine... private List Event resetEvents = new ArrayList Event (); public void addResetEvents(Event... events) { for (Event e events) resetEvents.add(e); } I don t need to have a separate structure for reset events here. I could handle this by simply declaring extra transitions on the state machine like this class StateMachine... private void addResetEvent_byAddingTransitions(Event e) { for (State s getStates()) if (!s.hasTransition(e.getCode())) s.addTransition(e, start); } I prefer explicit reset events on the machine becuase that better expresses the intention of what I m trying to do. While it does complicate the machine a bit, it keeps the clarity of my intention of how a general machine is supposed to work, as well as keeping the intention of how a particular machine is defined. With the structure out of the way, now lets move on to the behavior. As it turns out, it s really quite simple. The controller has a handle method that takes the event code it receives from the device. class Controller... private State currentState; private StateMachine machine; public CommandChannel getCommandChannel() { return commandsChannel; } protected CommandChannel commandsChannel; public void handle(String eventCode) { if (currentState.hasTransition(eventCode)) transitionTo(currentState.targetState(eventCode)); else if (machine.isResetEvent(eventCode)) transitionTo(machine.getStart()); // ignore unknown events } private void transitionTo(State target) { currentState = target; currentState.executeActions(commandsChannel); } class State... public boolean hasTransition(String eventCode) { return transitions.containsKey(eventCode); } public State targetState(String eventCode) { return transitions.get(eventCode).getTarget(); } public void executeActions(CommandChannel commandsChannel) { for (Command c actions) commandsChannel.send(c.getCode()); } class StateMachine... public boolean isResetEvent(String eventCode) { return resetEventCodes().contains(eventCode); } private List String resetEventCodes() { List String result = new ArrayList String (); for (Event e resetEvents) result.add(e.getCode()); return result; } It ignores any events that are not registered on the state. For any events that are recognized, it transitions to the target state and executes any commands defined on that target state. Programming the Controller with a Domain Specific Language Now I ve implemented the state machine model, I can now program Miss Grant s controller like this. Event doorClosed = new Event( doorClosed , D1CL ); Event drawOpened = new Event( drawOpened , D2OP ); Event lightOn = new Event( lightOn , L1ON ); Event doorOpened = new Event( doorOpened , D1OP ); Event panelClosed = new Event( panelClosed , PNCL ); Command unlockPanelCmd = new Command( unlockPanel , PNUL ); Command lockPanelCmd = new Command( lockPanel , PNLK ); Command lockDoorCmd = new Command( lockDoor , D1LK ); Command unlockDoorCmd = new Command( unlockDoor , D1UL ); State idle = new State( idle ); State activeState = new State( active ); State waitingForLightState = new State( waitingForLight ); State waitingForDrawState = new State( waitingForDraw ); State unlockedPanelState = new State( unlockedPanel ); StateMachine machine = new StateMachine(idle); idle.addTransition(doorClosed, activeState); idle.addAction(unlockDoorCmd); idle.addAction(lockPanelCmd); activeState.addTransition(drawOpened, waitingForLightState); activeState.addTransition(lightOn, waitingForDrawState); waitingForLightState.addTransition(lightOn, unlockedPanelState); waitingForDrawState.addTransition(drawOpened, unlockedPanelState); unlockedPanelState.addAction(unlockPanelCmd); unlockedPanelState.addAction(lockDoorCmd); unlockedPanelState.addTransition(panelClosed, idle); machine.addResetEvents(doorOpened); I look at this last bit of code as quite different in nature to the previous peices. The earlier code described how to build the state machine model, this last bit of code is about how to configure that model for one particular controller. You often see divisions like this. On the one hand is library, framework, or component implementation code; on the other is configuration or component assembly code. Essentially it is the separation of common code from variable code. We structure the common code in a set of components that we then configure for different purposes. Here is another way of representing that configuration code. stateMachine start = idle event name= doorClosed code= D1CL / event name= drawOpened code= D2OP / event name= lightOn code= L1ON / event name= doorOpened code= D1OP / event name= panelClosed code= PNCL / command name= unlockPanel code= PNUL / command name= lockPanel code= PNLK / command name= lockDoor code= D1LK / command name= unlockDoor code= D1UL / state name= idle transition event= doorClosed target= active / action command= unlockDoor / action command= lockPanel / /state state name= active transition event= drawOpened target= waitingForLight / transition event= lightOn target= waitingForDraw / /state state name= waitingForLight transition event= lightOn target= unlockedPanel / /state state name= waitingForDraw transition event= drawOpened target= unlockedPanel / /state state name= unlockedPanel action command= unlockPanel / action command= lockDoor / transition event= panelClosed target= idle / /state resetEvent name = doorOpened / /stateMachine This style of representation should look familiar to most readers, I ve expressed it as an XML file. There are several advantages to doing it this way. One obvious reason is that now we don t have to compile a separate java program for each controller we put into the field - instead we can just compile the state machine components plus an appropritate parser into a common jar, and ship the xml file to be read when the machine starts up. Any changes to the behavior of the controller can be done without having to distribute a new jar. (We do, of course, pay for this in that any mistakes in the syntax of the configuration can only be detected at run time.) A second advantage is in the expressiveness of the file itself. We no longer need to worry about the details of making the various connections through variables. Instead we have a more declarative approach that in many ways reads much more clearly. We re also limited in that we can only express configuration in this file - limitations like this often are helpful because they can reduce the chances for people making mistakes in the component assembly code. These advantages are why so many frameworks in Java and C# are configured with XML configuration files. These days it sometimes feels that you re doing more programming with XML than you are with main programming language. Here s another version of the configuration code. events doorClosed D1CL drawOpened D2OP lightOn L1ON doorOpened D1OP panelClosed PNCL end resetEvents doorOpened end commands unlockPanel PNUL lockPanel PNLK lockDoor D1LK unlockDoor D1UL end state idle actions {unlockDoor lockPanel} doorClosed = active end state active drawOpened = waitingForLight lightOn = waitingForDraw end state waitingForLight lightOn = unlockedPanel end state waitingForDraw drawOpened = unlockedPanel end state unlockedPanel actions {unlockPanel lockDoor} panelClosed = idle end This is code, although not in a syntax that s familiar to you. In fact it s a custom syntax that I made up for this example. I think it s a syntax that s easier to write, and above all easier to read, than the XML syntax. It s terser and avoids a lot of the quoting and noise characters that the XML suffers from. You probably wouldn t have done it exactly the same way, but the point is that you can construct whatever syntax you and your team prefers. You can still load it in at runtime (like the XML) but you don t have to (as you don t with the XML) if you want it at compile time. This language is a Domain Specific Language, and shares many of the characteristics of DSLs. Firstly it s suitable only for a very narrow purpose - it can t do anything other than configure this particular kind of state machine. As a result the DSL is very simple - there s no facility for control structures or anything else. It s not even Turing complete. You couldn t write a whole application in this language - all you can do is describe one small aspect of an application. As a result the DSL has to be combined with other languages to get anything done. But the simplicity of the DSL means it s easy to edit and process. Now look again at the XML representation. Is this a DSL? I would argue that it is. It s wrapped in an XML carrier syntax - but it s still a DSL. This example thus raises a design issue - is it better to have custom syntax for a DSL or an XML syntax? The XML syntax can be easier to parse since people are so familiar with parsing XML. (As it happened for this example it took me the about the same amount of time to write the parser for the custom syntax as it did for the XML.) I d contend that the custom syntax is much easier to read, at least in this case. But however you view this choice the core trade-offs around DSLs are the same. Indeed you can argue that most XML configuration files are essentially DSLs. Let s go back a step further, back to the configuration code in Java I showed you earlier - is that a DSL? While you re thinking about that question look at this code. Does this look like a DSL for this problem? event doorClosed, D1CL event drawOpened, D2OP event lightOn, L1ON event doorOpened, D1OP event panelClosed, PNCL command unlockPanel, PNUL command lockPanel, PNLK command lockDoor, D1LK command unlockDoor, D1UL resetEvents doorOpened state idle do actions unlockDoor, lockPanel transitions doorClosed = active end state active do transitions drawOpened = waitingForLight, lightOn = waitingForDraw end state waitingForLight do transitions lightOn = unlockedPanel end state waitingForDraw do transitions drawOpened = unlockedPanel end state unlockedPanel do actions unlockPanel, lockDoor transitions panelClosed = idle end It s a bit noisier than the custom language earlier, but still pretty clear. Readers who have similar language likings to me will probably know that it s Ruby. Ruby gives me a lot of syntactic options that makes for more readable code, so I can make it look very similar to the custom language. Ruby developers would consider this code to be a DSL. I use a subset of the capabilities of Ruby and capture same ideas as our XML and custom syntax. Essentially I m embedding the DSL into ruby, using a subset of ruby as my syntax. To an extent this is more a matter of attitude than of anything else. I m choosing to look at the Ruby code through DSL glasses. But it s a point of view with a long tradition - Lisp programmers often think of creating DSLs inside Lisp. This brings me to pointing out that there are two kinds of textual DSLs which I call external and internal DSLs. AnExternal DSLis a domain specific language represented in a separate language to the main programming language it s working with. This language may be a custom syntax, or it may follow the syntax of another representation (like XML). AnInternal DSLis DSL expressed within the syntax of a general purpose language. It s a stylized use of that language for a domain specific purpose. You may also hear the termembedded DSLas a synonym for internal DSL. Although it is fairly widely used, I avoid this term because you also hear embedded language applied to scripting languages embedded within applications such as VBA in Excel or Scheme in the Gimp. So I use internal DSL to avoid confusion. Now think again about the original java configuration code - is this a DSL? I would argue that it isn t. That code feels like stitching together with an API, while the ruby code above has more the feel of a declarative language. Does this mean you can t do an internal DSL in Java? How about this? public class BasicStateMachine extends StateMachineBuilder { Events doorClosed, drawOpened, lightOn, panelClosed; Commands unlockPanel, lockPanel, lockDoor, unlockDoor; States idle, active, waitingForLight, waitingForDraw, unlockedPanel; ResetEvents doorOpened; protected void defineStateMachine() { doorClosed. code( D1CL ); drawOpened. code( D2OP ); lightOn. code( L1ON ); panelClosed.code( PNCL ); doorOpened. code( D1OP ); unlockPanel.code( PNUL ); lockPanel. code( PNLK ); lockDoor. code( D1LK ); unlockDoor. code( D1UL ); idle .actions(unlockDoor, lockPanel) .transition(doorClosed).to(active) ; active .transition(drawOpened).to(waitingForLight) .transition(lightOn). to(waitingForDraw) ; waitingForLight .transition(lightOn).to(unlockedPanel) ; waitingForDraw .transition(drawOpened).to(unlockedPanel) ; unlockedPanel .actions(unlockPanel, lockDoor) .transition(panelClosed).to(idle) ; } } It s formatted oddly, and uses some unusual programming conventions, but it is valid Java. It s java written in what is these days called a Fluent Interface style. AFluent Interfaceis an API that s designed to read like an internal DSL. This I would call a DSL - although it s more messy than the ruby DSL it still has that declarative flow that a DSL needs. What makes a fluent interface different to a normal API? This is a tough question that I ll spend more time onlater), but it comes down to a rather fuzzy notion of a language-like flow. Given this distinction it s useful to have a name for a non-fluent API - I ll use the termcommand-query API. Languages and Model There s an important inter-relationship here between the various DSLs and the underlying state-machine model. To implement each of these languages I wrote code that translated from expressions in the DSL into calls on the command-query interface of the model. So while I was parsing the custom syntax version and came across commands unlockPanel PNUL I would create a new command object (new Command( unlockPanel , PNUL )) and keep it to one side (in aSymbol Table) so that when I sawactions {unlockPanelI could add it to the appropriate state (usingaddAction). As a result each DSL I ve shown you created the same configuration of objects in the model. The model, as I discussed earlier, is the engine that provides the behavior of the state-machine. So once we have a populated model, we have a running program whose behavior is encoded in the inter-relationships between the objects in that model. This style is often called an Active Object Model, because in order to understand the behavior of the state machine you can t just look at the code, you also have to look at the way object instances are wired together. Of course this is always true to some extent, any program gives different results with different data, but there is a sense of a greater difference here as the presence of the state objects alters the behavior of the system to a significantly greater degree. When people discuss a programming language you often hear them talk about syntax and semantics. The syntax captures the legal expressions of the program, what in the custom syntax DSL is captured by the grammar. The semantics of a program is what it means, that is what it does when it executes. In this case it is the model that defines those semantics - which is why I will refer to it as aSemantic Model. In this example theSemantic Modelis an object model. ASemantic Modelcan also take other forms. It can be a pure data structure with all behavior in separate functions. I would still refer to it as an active model, because the data structure defines the program s behavior. Looking at it from this point of view, the DSL merely acts as a mechanism for expressing how the model is configured. I often refer to a DSL as a thin facade over a framework. Much of the benefits of using this approach comes from the model rather than the DSLs. The fact that I can easily configure a new state machine for a customer is a property of the model, not the DSL. The fact that I can make a change to a controller at run-time, without compiling, is a feature of the model, not the DSL. The fact I m reusing code across multiple installations of controllers is a property of the model, not the DSL. A model provides many benefits without any DSLs present. As a result we use them all the time. We use libraries and frameworks to wisely avoid work. In our own software we construct our own models, building up abstractions that allow us to program faster. Good models, whether published as libraries and frameworks or just serving our own code, can work just fine without any DSL in sight. But DSLs can enhance the the capabilities of a model. The right DSL makes it easier to understand what a particular state machine does. Some DSLs allow you to configure the model at run time. DSLs are thus a useful adjunct to some models. In discussing this example I described a circumstance where the model was built first, and then I layered a DSL over the model to help manipulate it. I described it that way becuase I think that s an easy way to understand how DSLs fit into software development. Although the model-first case is a common one, it isn t the only one. In a different scenario you talk with the domain experts and posit that a state machine approach is something they understand. You then work with the domain experts to create a DSL that they can understand. In this case you build the DSL and model simultaneously. Using Code-Generation In my discussion so far, I process the DSL by populating theSemantic Modeland then execute theSemantic Modelto provide the behavior that I want from the controller. This approach is what s known in language circles as interpretation. When weinterpretsome text, we parse it and immediately produce the result that we want from the program. (Interpret is a tricky word in software circles, since it carries all sorts of connotations for people, however I ll use it strictly to mean this form of immediate execution.) In the language world, the alternative to interpretation is compilation. Withcompilation, we parse some program text and produce an intermediate output, which is then separately processed to provide the behavior we desire. In the context of DSLs the compilation approach is usually referred to ascode-generation. In this case this might mean generating some java code to represent the particular behavior of Miss Grant s controller. Code generation is often awkward in that it often pushes you to an extra compilation. To build your program you have to first compile the state framework and the parser, then run the parser to generate the source code for Miss Grant s controller, then compile that generated code. This makes your build process much more complicated. However an advantage of code generation is that there s no reason why you have to generate code in same programming language that you use for the parser. In this case you can avoid the second compilation step by generating code for a dynamic language such as javascript or jruby. Code generation is also useful when you want to use DSLs with a language platform that doesn t have the tools for DSL support. I ve come across recent projects that generate code for MathCAD, SQL, and COBOL. Many writings on DSLs focus on code-generation, even to the point of making code-generation the primary aim of the exercise. As a result you can find articles and books extolling the virtues of code-generation. In my view, however, code-generation is merely an implementation mechanism, one that isn t actually needed in most cases. Certainly there are plenty of times when you must use code-generation, but there are even more plenty of times when you don t need it. Using code-generation is one case where many people don t use aSemantic Model. In this case you parse the input text and directly produce the generated code. Although this is a common way of working with code-generated DSLs, it isn t one I reccommend for any but the very simplest cases. Using aSemantic Modelallows me to separate the parsing, the execution semantics, and the code generation into separate problems. This separation makes the whole exercise a lot simpler. It also allows me to change my mind. I can change my DSL from an internal to an external DSL (say) without altering my code-generation routines. Similarly I can easily generate multiple outputs without complicating my parse. I can also use both an interpreted model and code generation off the sameSemantic Model. As a result for almost all of this book, I m going to assume aSemantic Modelis present and the centre of the DSL effort. Using Language Workbenches The two styles of DSL I ve shown so far (internal and external) are the traditional ways of thinking about DSLs. They may not be as widely understood and used as they should be, but they have a long history and moderately wide usage. As a result the rest of this book concentrates on getting you started with these approaches using tools that are mature and easy to obtain. But there is a whole new category of tools on the horizon that could change the game of DSLs significantly tools I call Language Workbenches. ALanguage Workbenchis tool designed to help people create new DSLs, together with high quality tooling required to use those DSLs effectively. One of the big disadvantages of using an external DSL is that you re stuck with relatively limited tooling. Setting up syntax highlighting with a text editor is about as far as most people go. While you can argue that the simplicity of a DSL and the small size of the scripts means that may be enough, there s also an argument for the kind of sophisticated tooling that modern post-IntelliJ IDEs support. Language Workbenches make it easy not just to define a parser, but also to define a custom editing environment for that language. All of this is valuable, but the truly interesting aspect of language workbenches is that they allow a DSL designer to go beyond the the traditional text-based source editing, to different forms of language. The most obvious example of this is support for diagrammatic languages, which would allow me to specify the secret panel state machine directly with a state transition diagram. Figure 3 The secret panel state machine displayed in the MetaEdit language workbench.(source MetaCase) Not just does a tool like this allow you to have diagrammtic languages, it also allows you to look at a DSL script from multiple perspectives. In Figure3there is a diagram, but also lists of states and events, and a table to enter the event codes (which could be ommitted from the diagram if there s too much clutter there). This kind of multi-pane visual editing environment has been around for a while in lots of tools, but it s been a lot of effort to build something like this for yourself. One promise of language workbenches is that they make it quite easy to do this, certainly I was easily able to put together a similar example to Figure3quite quickly on my first play with the MetaEdit tool. The tools allows me to define theSemantic Modelfor state machines, define the graphical and tabular editors in Figure3and write a code generator from theSemantic Model. However, while such tools certainly look good, many developers are naturally suspicious of such doodleware tools. There are some very pragmatic reasons why a textual source representation makes sense. As a result other tools head in that direction, providing post-IntelliJ style capabilities such as syntax-directed editing, symbol completion and the like to textual languages. My own suspicion here is that if language workbenches really take off, the languages they ll produce aren t anything like what we consider to be a programming language. One of the common benefits of tools like this is that they allow non-programmers to program. I often sniff at that notion by pointing out that this was the original intent of COBOL. Yet I must also acknowledge a programming environment that has been extremely successful in providing programming tools to non-programmers who program without thinking of themselves of programming - spreadsheets. In programming language terms spreadsheets are based on a quite unusual computational model. Their appeal comes from a very deep integration of the notions of language and tool. Thus it s no surprise that Charles Simonyi combines both a history of development of these kinds of user tools with a long history of developing ideas in language workbenches. As a result I think that language workbenches have a remarkable potential. If they fulfill this they could entirely change the face of software development. This potential, however profound, is still somewhat in the future. It s still early days for language workbenches with new approaches appearing regularly and older tools still subject to deep evolution. As a result I don t have that much to say about them here, as I think they will change quite dramatically during the hoped-for lifetime of this book. But I do have a chapter on them at the end, as I think they are well worth keeping an eye on. Visualization One the great advantages of using a Language Workbench is that this enables you to a wider range of representations of the DSL, in particular graphical representations. However even with a textual DSL you can obtain a diagrammatic representation. Indeed we saw this very early on in this chapter. When looking at Figure1it might have struck you that the diagram was not as neatly drawn as I usually do. The reason for this is that I didn t draw the diagram, I generated it automatically from theSemantic Modelof Miss Grant s controller. Not just do my state machine classes execute, they also are able to render themselves use the dot language. The dot langauge is part of the GraphViz package, which is an open-source tool that allows you to describe mathematical graph structures (nodes and edges) and then automatically plot them. It figures out how to lay out the graph, you just tell it what the nodes and edges are, what shapes to use, and some other hints. Using a tool like GraphViz is extremely helpful for many kinds of DSLs because it gives another representation. Thisvisualizationrepresentation is similar to the DSL itself in that it allows a human to understand the model. The diference between a visualization and the source is that it isn t editable - however it can provide options that are too hard in an editable form, such as a diagram like this. In the terms of a language workbench you can think of a visualization as a read-only projection. It s something that can be less important for graphical language workbenches, since you use a diagram anyway, but it s still sometimes a handy technique. Visualizations don t have to be graphical. I often use a simple textual visualization to help me debug while I m writing a parser. I ve seen people generate visualizations in Excel to help communicate with domain experts. The point is that once you have done the hard work of creating a component framework like this, adding visualizations is really easy. You ll note here that the visualizations are produced from the framework, not the DSL, so you can do this even if you aren t using a DSL to populate the framework. Indeed the techniques in this book can be used for creating visualizations above and beyond DSL usage. A partial parser for a general purpose language can be used to visualize useful aspects of a general purpose program. Any interesting data strucutre can be visualized in interesting ways. Significant Revisions 06 Aug 07 First Draft 09 Apr 08 Split example from general issues
https://w.atwiki.jp/tadaro/pages/88.html
Destiny Online http //www.usamimi.info/~destinyonline/ wiki http //www.wikihouse.com/Destiny/ ベース倍率100倍 ジョブ倍率100倍 ドロップ倍率80倍 転生レベルLv99 転生回数3回 レビュー （ここに書いてね） （以下はエミュサーチより引用） 接続人数は大体10～30人。 忍者・ガンナー・ホム・オーディン神殿まで実装。 倍率は100/100/80(B/J/I) 相場が変動する「ゴールドバー」システムや、特定のアイテムを収集する「アルバイト」システムもある。 ゲーム内でGMに意見出来るポストがあるので、バグ報告等がスムーズかつこっそり行う事が出来る。 頻繁に新しいパッチがアップされ、ゲーム内で告知されるが、手動で当てる必要があるので少々手間ではある。 垢登録がメールの後、更に確認メールを送る必要があるので手間はかかるが、その分住民は(基本的に)良識者がほとんどである。 程々の倍率で、ステも本鯖準拠なので俺TUEEEEしたい人には向かないだろう。（2006年05月09日）
https://w.atwiki.jp/englishlanguage/pages/927.html
AUS... Austin, Francis. 1994. "The Effect of Exposure to Standard English The Language of William Clift", Towards a Standard English, 1600-1800, ed. Dieter Stein et al., pp. 285-313. Berlin Mouton de Gruyter. Austin, J. Paddy M. 1990. "Politeness Revisited The Dark Side", in New Zealand Ways of Speaking English, ed. Allan Bell Janet Holmes, pp. 277-293. Clevedon Multilingual Matters.
https://w.atwiki.jp/utauuuta/pages/3691.html
【登録タグ CD CDF cilliaCD パンドリストPCD 全国配信】 前作 本作 次作 それでも、光は。 Faust - パンドリストP Raz cillia 兎灯 みのがしさらん 流通 即売 同人 配信 発売 2015年12月31日 2016年1月11日 2016年1月29日 価格 ￥ ￥1,333（税別） ￥150 サークル REXIA CD紹介 パンドリストPこと、ミナツキトーカ氏の1stアルバム。 リメイク、リマスター、そしてルカのグロウルも入った未公開楽曲も収録。 コミックマーケット89（C89）で頒布。 アリスブックスで委託販売が行われている。 タイトルトラックの「Faust」が1曲入り配信シングルとしてKARENTレーベルよりダウンロード販売が行われている。巡音ルカ7周年記念企画で配信された作品の1つ。 曲目 Faust （vo.巡音ルカ） sacrifice （vo.波音リツ） E.F.B～恒久の氷結～ （vo.波音リツ） B.R.D～叛逆の劫焔～ (Remake) （vo.波音リツ） Choir - Dedicated to BRAVEs - （vo.波音リツ） Baptism ～贖罪のロザリィ～ （vo.波音リツ） Prisoner's Gloria （vo.重音テト,重音テッド,欲音ルコ,波音リツ,健音テイ,櫻歌ミコ,ルーク） Creuzer - Das Schwarzes Requiem - （vo.波音リツ） - moonlight waltz - 月夜の舞踏譜 （vo.波音リツ,重音テト,巡音ルカ） Bonus Track リンク アリスブックス KARENT：「Faust」 KARENT：「巡音ルカ聖誕祭'16」特集ページ iTunes Store twitter コメント 名前 コメント
https://w.atwiki.jp/saintwrow3car/pages/61.html
Justice 概要 車体：高級セダン 会社：Dalton Moore 和音：ジャスティス ドア：4枚 駆動：FR 実車：Rolls Royce Phantom 性能 重量：普通 速度：速い 加速力：そこそこ 解説 初代Saints Rowから皆勤の高級セダン。 前作までの肉厚なボッテリした重圧感・重みのある雰囲気、極太のピラーなど威圧感を感じる車体から、 肉薄のスポーティーでスタイリッシュな車体に変わった。 耐久力は前作に比べると大幅に高くなった。旋回性能が若干悪いが、それ以外の欠点は無い。 改造によってオープンカー仕様にできる車両はいくつかあるが、 一般車両にもオープンカーを見かけることができるのはこの車両のみ。 ちなみに通常出現するオープン仕様はオレンジ色固定である。 これは実車であるファントムをベースとしたオープンカー、ファントムドロップヘッドクーペを意識しているためと思われる。 今作では敵対ギャング車両のため、前作よりさらに出現率は上がった。 一般仕様の出現率も上がり、SAINTS HQ周辺でも簡単に見つけることができる。 またInfuegoともどもモーニングスターの抗争スポットには何ヶ所か固定配置されている。 一般・ギャング仕様のどちらが配置されているかは場所によって決まっているので、 必要に応じて好みで選んで調達できるのも利点と言えよう。 「エスコート」「タイガーエスコート」などのアクティビティーでも使用する。 田舎であるはずのスティールポートでこの高級セダンが見飽きるほど出現するのと、 「正義」の名を冠する車が国際的な犯罪組織に愛用されているのはご愛嬌。 特別仕様、レアカラー Morning Star シンジゲートの中心者フィリップが率いる、ギャングが使用している。 赤/黒ツートン、ルーフに赤い星が付けられている。 エスコート アクティビティエスコートで使う。黒塗装、フルスモーク仕様。 タイガーエスコートでは黄色のオープン。 画像 Justice Justice(Morning Star)
https://w.atwiki.jp/xbox360gta4/pages/80.html
FINAL DESTINATION ～店内～ Women Hi, Dimitri. あら、Dimitri。 Man1 Hey, Dimitri, I took care of that thing for you. やぁDimitri、あんたのために、例の事を処理したぞ。 Dimitri Very good. I m proud of you. Good. 素晴らしい。君を誇りに思うよ。良いぞ。 Man2 Dimitri, Dimitri, hey, hey, uh...meet my girl, Natasha. Dimitri、Dimitri、なあ、なあ、あぁー･･･、俺の彼女の、Natashaだ。 Natasha So nice to meet you. 宜しくね。 Dimitri Oh, my pleasure. あぁ、こちらこそ。 Faustin Little delicious, my little knish... Dimitri Mikhail. Mikhail。 Faustin Hey! My brother, and Niko. Good. よう兄弟！ それにNiko。よく来たな。 Have a drink. Oh, baby... Dimitri Move up ladies. Move up. Um...Mikhail, we ve got something we need to talk about. どいてくれ、ご婦人方。どいてくれ。あぁ･･･、Mikhail、話さないといけない事があるんだ。 Faustin Okay, you can have Vera, I like Katerina. わかった、Veraの相手をしてもいいぞ、俺はKaterinaが気に入った。 come on no big deal.No that, in plivate? Dimitri Girls, can you give us a minute, huh? お嬢さん方、俺たちに少しばかり時間をくれないか、ん？ Please? Okay. Faustin Get out of here. この席から離れていろ。 Faustin Keep it warm. I won t be to long. So. What is it? こいつらとの話は、すぐに終わるから待ってな。それで、話は何だ？ Dimitri We ve got police trouble. The feds , or someone are all over us. Sergei told me that a friend of his in the courts told him thsy ve been authorized to tap our phones and they know about the pot we stole. サツとトラブってます。もしかしたらFBIかもしれませんが、思いっきり目を着けられてます。裁判所にいるっていうダチからSergeiが訊いたらしいんですが、連中はウチらの電話の盗聴も許可されてるそうです。あと、ウチの組織がパクったクサのことも、連中はとっくに気付いてるそうです。 Faustin Shit. Who is rat? 何てこった…。スパイは誰だ？ Dimitri It s no one. It s just the way we have been behaving. Making too much noise. This was inevitable. We re going to have to calm things right down for a while. スパイなんて居ませんよ。ウチらがこれだけ派手に暴れてたら、目を着けられて当然でしょう。しばらく大人しくしておいて、ほとぼりを冷ますしかないですよ。 Faustin It s that fucking guy, yeah, I know it is. I saw it in his eyes...you know? That guy. That guy, who bought the coke... いや、俺には分かるぞ。あいつだ…。あの目を見たらすぐに分かった…、お前も分かるだろ？あいつだ、コカインを売ってやった･･･ Faustin That s Lenny. Lennyだ。 ※ Lenny Petrovic(レニー・ペトロヴィッチ) - ペトロヴィッチ・ファミリーのボスであるケニー・ペトロヴィッチの息子。ちなみにミッションCRIME AND PUNISHMENTで、テレビの違法商取引を指示していたのがボスのケニー。 but he didn t buy the pot. いや、奴にはクサは売ってなかったか。 Dimitri He s my cousin s boyfriends. It s not him. Yes, he s a moron, yes, but he okay. あいつは俺の従兄弟のダチですよ。あいつじゃない。ええ、確かにあいつはアホですが、ヤバいヤツじゃないですよ。 Faustin I don t trust him. いや、俺は信用せん。 Dimitri What? I just told you. そんな･･･。ちゃんと話を聞いて下さいよ。 Faustin He knows too much. You, kill him. Lennyは内情を知り過ぎている。(Nikoに向かって)おい、ヤツを消せ。 Niko Are you sure? 本気で言っているのか？ Faustin Sure? No, I am not. Right now, I am wondering if it s him or you. It could be you. 本気か、だと？あぁ、本気じゃない。裏切り者はLennyじゃなくて、お前かもしれん。お前じゃないのか？ Dimitri Think for a second. This has been going on for months. よく考えて下さいよ。Nikoが手下になる何ヶ月も前の話ですよ。 Faustin Think? Look where your thinking has got us. You were in charge of security. Good job. Well done, Dimitri. よく考えろ、だと？お前の熟考とやらが、どんな結果を導いたんだ？ 確かお前がウチの組織の保安を仕切ってるはずだが、大した仕事ぶりだな。 Dimitri You pathetic idiot. （救いようのないアホだ…） Faustin You, prove you re loyal. Go and kill the guy. Niko、俺への忠誠心を証明してみろ。Lennyを消すんだ。 Niko Don t question my loyality. 俺の、あんたへの忠誠心を疑わないでくれ。 Faustin Then don t qestion my orders. He lives on Guantanamo Avenue in Bohan. Head up there, and call me, me personally, when you get there. なら、俺の命令に疑念を抱くのもやめるんだな。Lennyのヤサは、BohanのGuantanamo通りにある。急いで向かって、現場に着いたら電話しろ。俺の携帯にな。 Mikhail, please, don t do this. Mikhail、お願いだ、やめてくれ。 Shut up. 黙れ。 Dimitri I... 俺は･･･ Shut up the fuck up. 黙りやがれ。 I...I m begging you...please, ああ、頼む・・・お願いだ。 I said shut the fuck up. 黙れと言っただろうが。 don t do this. こんなことはやめてくれ Go. 行け。（Nikoに） Why don t you listen? なぜ聞いてくれないんだ？ Hey, give me a break. おい、ちょっとまってくれ。 You have to play by the rules. 掟どおりにやらなければならない。 Stop. I said stop. やめろ。やめろと言ってるんだ。 ～携帯電話～ Niko Mr.Fauntin, do you want call this off? Fauntinさんよ、コレは無しって事で良いのか？ Faustin No, I never change my mind. I ve heard he s at the Gauntanamo Avenue station. Go to the plat form and get rid of that rat. Shut up Dimitri, for the last time... いや、俺は決して考えを変えたりせん。やつはthe Gauntanamo Avenue stationにいるらしい。プラットホームに行って、あの裏切り者を始末しろ。 黙れ、Dimitri、これが最後だ･･･。 ～駅のホーム１（Lennyと同じホーム）～ Niko Hey, Lenny. Mikhail Faustin don t like you no more. It s nothing personal. やぁ、Lenny。俺には関係のない事だが、Mikhali Faustinはあんた事が気に入らないと言っている。 Lenny Faustin ain t nobody. Fuck off. Faustinなんて野郎は、なんでもねえ。くたばっちまえ。 Niko? He s enough of a somebody to get you killed. お前を殺すために、人を雇うぐらい人間ではあるがな。 Lenny Do what my papa pays you do. Shit. ～駅のホーム２（Lennyの反対側のホーム）～ Niko Hey, Lenny. Mr.Faustin thinks you re a rat. He ain t taking no risks. よう、Lenny。Faustinさんはあんたを裏切り者と思ってる。あの人はリスクを負わない。 Lenny I m into more shit than Mikhail could even imagine. Why would I rat? こっちだってMikhailが想像できねえくらいの修羅場をくぐってきてんだ。なんで俺がスパイなんだ？ Niko The decision has been made. もう決まったことさ。 Lenny? My dad pays you to ice crazy bitches like this guy. Hold on a second. 親父はお前がこの男のような基地外のビッチを殺すことに金を支払うんだ。ちょっと待ってくれ。 ～携帯電話～ Dimitri Niko, do you know wwhat you have done? Niko、お前は自分が何をしたかわかってるのか？ Niko I have followed Mr.Faustin s orders, not much more. 俺はFaustinさんの命令に従っただけさ、それ以上じゃねえ。 Dimitri this is a very dangerous man. He will not take kidney to this. 何て危ないやつなんだ。 Niko How was I do know? 俺が知るわけないだろう？ Dimitri You weren t. This is Mikhail s craziness. I will speak to people and see what I can do. だろうな。これはMikhailの狂気だ。俺はあいつら（Petrovic側の人間にか？）と話して、俺に出来る事を見つけるよ。
https://w.atwiki.jp/xbox360score/pages/948.html
Just Cause 2 項目数：50 総ポイント：1000 難易度：★★☆☆☆ 日本語版と海外版で別実績。 コンプまで80～100時間程度。前作と同様にマップが広大で非常に時間がかかり、特にゲーム進行度75％達成には結構な時間と作業を要する。難易度実績のため、最低難易度と最高難易度で2周するとよい。 JUST CAUSE 2 wiki http //wiki.livedoor.jp/justcause2/ トップエージェントTop Agent 難易度“ノーマル”でゲームをクリアBonus for completing the game on Normal difficulty. 20 ヒーローエージェントHeroic Agent 難易度“ハード”でゲームをクリア(難易度ノーマルもクリアと見なされる)Bonus for completing the game on Experienced difficulty. 30 伝説のエージェントLegendary Agent 難易度“エクストリーム”でゲームをクリア(難易度ハード以下もクリアと見なされる)Bonus for completing the game on Hardcore difficulty. 40 足場固めGaining a Foothold 3 件の拠点制圧ミッションを完遂Complete 3 stronghold takeovers. 10 パナウの征服者Conqueror of Panau 9 件の拠点制圧ミッションを完遂Complete 9 stronghold takeovers. 20 信頼できる協力者A Trusted Ally 45 件の勢力ミッションを完遂Complete 49 faction missions. 20 カオスの初心者First Taste of Chaos 初めてカオスを引き起こすCause chaos for the first time. 10 破壊者Saboteur 150 件の破壊工作を実行Complete 150 sabotages. 10 破壊神Destroyer 1000 件の破壊工作を実行Complete 1000 sabotages. 20 ヒットマンProfessional Hitman 25 人の指揮官を暗殺Assassinate 25 colonels. 20 意欲的な挑戦者Up to the Challenge 1 10 件のチャレンジをクリアComplete 10 challenges. 10 伝説の挑戦者Up to the Challenge 2 50 件のチャレンジをクリアComplete 50 challenges. 20 物資マスターLeaving No Rock Unturned 1000 個の支援物資を集めるCollect 1000 resource items. 25 物資コレクターFinders Keepers 100 個の支援物資を集めるCollect 100 resource items. 15 勢力貢献者Faction Benefactor 150 個の勢力アイテムを集めるCollect 150 faction items. 20 世界旅行者Globetrotter 100 のロケーションを発見するDiscover 100 locations. 20 フリーローマー1Freeroamer 1 15 のロケーションの制圧度を100%にするReach 100% complete in 15 locations. 10 フリーローマー2Freeroamer 2 100 のロケーションの制圧度を100%にするReach 100% complete in 100 locations. 20 百戦錬磨Body Count 敵を 750 人倒すKill 750 enemies. 15 非武装危険人物Unarmed and Dangerous 近接攻撃で敵を 50 人倒すKill 50 enemies using melee attacks. 15 重力の活用者Gravity is a Bitch! フックを使って敵を転落させて 30 人倒すKill 30 enemies by using the grappling hook and making them fall to their death. 15 俺についてこい!Follow Me! フックを使って敵を車で引きずって 5 人倒すKill 5 enemies by dragging them behind a vehicle with the grappling hook. 15 吊るし上げろ!Hang em High! フックで吊るした敵を 30 人倒すKill 30 enemies while they re suspended in the air with the grappling hook. 15 破壊鉄球Wrecking Ball フックで車につないだ物体を使って敵を 5 人倒すKill 5 enemies by smashing them with an object tethered to your vehicle with the grappling hook. 15 袋だたきPiñata Party フックで吊るした敵を近接攻撃で 5 人倒すKill 5 enemies with the melee attack while they re suspended with the grappling hook. 15 ジャグラーJuggler 空中の敵を 30 人倒すKill 30 enemies while they re in mid air. 15 ロードローラーRoad Rage 敵を乗り物で 30 人倒すKill 30 enemies by mowing them down with vehicles. 10 狙撃手Marksman ヘッドショットで敵を 50 人倒すKill 50 enemies with head shots. 15 シリアルキラーKilling Frenzy 60 秒間に敵を 20 人倒すKill 20 enemies in 60 seconds. 20 無敵の戦士Invincible Warrior ダメージを受けずに所持武器で敵を 50 人連続で倒すKill 50 enemies in a row with inventory weapons without losing health. 20 破壊王Destruction Frenzy 60 秒間に 30 個の目標物を破壊するDestroy 30 objects in 60 seconds. 10 テストドライバーTest Driver 30 種の乗り物を運転するDrive 30 different vehicles. 10 プロドライバーTrying Everything Once 104 種すべての乗り物を運転するDrive all 104 vehicles. 25 小旅行Road Trip 車で 75 キロ移動するTravel 75 kilometers by land vehicle. 20 運転手交代Please Step Out of the Vehicle 敵の乗り物を 50 台乗っ取るHijack 50 enemy vehicles. 10 スタントドライバーStunt Driver スタントドライバーポイントを 100 ポイント獲得するGet 100 stunt driver points. 10 ようやく半分Halfway there ノーマルモードかマーセナリーモードで達成度を 50% にするReach 50% completion in the normal mode or mercenary mode. 25 パラシュートクライマーParachute Climber パラシュートを開いて高度 300 メートルまで到達した後に着地するOpen the parachute and then land on foot 300 meters above the starting height. 10 ボクはきっと飛べる!I Believe I Can Fly 地上 1000 メートルからベースジャンプするBase jump 1000 meters. 10 ブリッジリンボーBridge Limbo 30 種の橋の下を飛行機で通過するFly an airplane under 30 unique bridges in Panau. 20 低空飛行Stunt Flyer 30 秒間地表近くを飛行機で飛ぶFly an airplane close to the ground for 30 seconds. 10 達成者Perfectionist ノーマルモードかマーセナリーモードで達成度を 75% にするReach 75% completion in the normal mode or mercenary mode. 25 世界の頂点Top of the World パナウの最高地点に立つStand on foot on the highest point of Panau. 10 秘密の実績 パナウへようこそWelcome to Panau エージェントミッション１をクリアComplete Story Mission 1. 10 カジノ襲撃Casino Bust エージェントミッション２をクリアComplete Story Mission 2. 20 ホワイトタイガーThe White Tiger エージェントミッション３をクリアComplete Story Mission 3. 30 マウンテン・レスキューMountain Rescue エージェントミッション４をクリアComplete Story Mission 4. 40 スリーキングスThree Kings エージェントミッション５をクリアComplete Story Mission 5. 50 悪魔の仲間Into the Den エージェントミッション６をクリアComplete Story Mission 6. 60 大義の名のもとにA Just Cause エージェントミッション７をクリアComplete Story Mission 7. 70 クリア実績 最終エージェントミッション出現に必要なカオスは435,000。 最高難易度でもストーリークリアする分には難しくないが、他実績を最高難易度で進行するのはいろいろと辛い。最高難易度でストーリークリアに挑戦、最低難易度で他実績を獲得する方が結果的に楽。 ストーリーはカオス稼ぎを優先した進行をすれば5～10時間程度でクリア可能。ある程度の強化ができるだけのパーツを集めたら、クリアで5000カオス稼げる勢力ミッションを消化していくと早い。マップ中央にある三日月形島の軍港は破壊できる施設が豊富にあるので、全部破壊すると18000カオス稼げる。 難易度エクストリームは敵の攻撃が強化されているため、HPゲージを5回強化できるぐらいはアーマーパーツを拾っておいたほうが安全。武器はグレネード・C4・両手武器を強化しておくと良い。 ゲーム開始時から基本オートセーブスロットのみで進行するため、難易度を切り替える際はポーズメニューから通常スロットにセーブをしておくこと。 ゲーム進行度 エージェントミッション：1.0% レースチャレンジクリア：0.10% ロケーションを100％にする：0.03% 勢力アイテム獲得：0.03% 支援物資獲得：0.01% 敵軍設備を破壊：0.005% 指揮官を殺害：0.14% パーセンテージの獲得に徹して1時間で1.0～1.5%ほど稼げる。マーセナリーモードとはストーリークリア後のモードで、達成率の進捗率が閲覧できるようになる。 伝説の挑戦者 飛行機とベースジャンプは挙動にクセがあるため、まともに挑戦する場合の難易度は高い。ただし、与えられた乗り物でクリアする必要はなく、あらかじめ用意した乗り物に乗り換えればクリアは簡単。 車のチャレンジはフルチューンしたバイク、飛行機のチャレンジはフルチューンのローリンソンK22があればすべてクリアできる。ベースジャンプは乗り物が使えないと注意が出るが、ローリンソンK22に乗って通過してもなぜかチェックポイントをクリアできる。 失敗しそうになったらポーズメニューからリスタートを選択することで、元の場所に戻る手間が省ける。 全部で75個あるので難しいものや苦手なものは後回しにしてかまわないだろう。 信頼できる協力者 海外版と日本語版で勢力ミッションの必要件数が異なるが（海外49 / 国内45）、全ての勢力ミッションをクリアしないといけないことには変わりない。 俺について来い! 敵と乗り物をデュアルフックで連結し、その乗り物で敵を引きずり殺せばカウント。 吊るし上げろ!、袋だたき 敵が宙吊りになるように、建築物や木などのやや高めの位置にフックで繋ぐ。この状態で射殺すれば吊るし上げろ!、撲殺すれば袋だたきがそれぞれカウント。 撲殺の際は、階段の中ほどや屋内のライトや屋根の軒下辺りに接続しないと届かないので注意。 破壊鉄球 軍事空港でクレーン車に戦闘機を連結してぶつける方法が非常に簡単。 http //www.youtube.com/watch?v=mlVBlJom_3E ジャグラー 敵をフックで引き寄せ、宙に浮いてる間に射殺する。 シリアルキラー 勢力ミッションの聖なる煙（X 13860、Y 30596）中に狙うのが楽。あらかじめグレネードを強化しておくか、ロケットランチャーがあれば楽に解除できる。 無敵の戦士 パーフェクトキルコンボを50まで繋げる。ダメージを受けずにとあるが、正確には「大きなダメージを受けずに」ということ。ある程度まとまったダメージを食らうと画面が赤くなるが、この状態になるとダメ。少しダメージを受けたら隠れて回復しよう。 ただ、画面が赤く染まってもキルコンボが途切れない場合もある。（体力に対する割合？）所持武器はミニガンや車載武器、乗り物以外を指す。 ストーリーミッション1の後半で2台のSAMの破壊後なら、敵が沸き続けるので狙いやすい。 プロドライバー 「行動記録＞乗った車両のタイプ」の数が海外版なら104、日本語版なら106になれば解除される。乗り物一覧に追加されないDLC追加車に乗った場合でもカウントはされるため、行動記録の乗った車種の数とはズレが生じる。 DLCで追加される車種は、海外版がLimited Editionの2種 + マーケットプレース4種(有料2、無料2)。日本語版はLimited Editionの車種ががあらかじめ一覧に追加されているので、マーケットプレースの4種だけになる。 当初はバグにより存在していなかったヴァンダービルドレジャーライナー(Vanderbildt Leiseureliner)は、海外版には修正パッチが適用されていて、それなりの数が走っている。日本語版は発見報告がなく、車両関係の修正がされていない疑いがある。 画像つきの車両一覧：http //justcause.wikia.com/wiki/Category Just_Cause_2_Vehicles MVコマンドMV Command 車両扉のないスケルトン型ジープ。砂漠エリアにてヒートLv4で出現 ストーリーミッション4や勢力ミッション「パラボラ・ハンター」でも出現 ヴァンダービルドレジャーライナーVanderbildt LeisureLiner 2階建てバス。バグにより出現しなかったが、現在はパッチがリリースされ海外版は雪山や砂漠で比較的容易に見つかるようになっている。日本語版では発見報告がなく、存在しないと思われる ドンタイアグリボス35Dongtai Agriboss 35 （X 6800、Y 27300）付近の離れの民家にドンタイ製トラクター全種がランダムで出現する。 ローチの拠点となるレンバ・フィルダウス施設でも同様に全種出現する。 ポカムタクノマドPocumtuck Nomad Pulau Berendam（X 25878、Y 3460）エリアに確実に出現 エージェントミッションの開始地点でも見かける キャバリエピアッツァIXChevalier Piazza IX 海外版は（X 3660、Y 12554）付近のビル裏に停まっているが、日本語版はいない 大きい雪山か砂漠の道路を走っている オーキューグランド21TTOrque Grandois 21TT レアなボート。在り処は諸説あるが、スリーキングホテル西の海が比較的出現しやすい。 （X 24515、Y 30449）の集落で他のボートに混じってランダムで出現する。 スタントドライバー スタントドライバーポイントを得るにはいくつか方法があるが、最高速が早い車種でハイウェイを突っ走るのが稼ぎやすい。 「伝説の挑戦者」を解除する過程でクリアできる場合もあるが、あえて狙うならバンダル・セレケ（X 9170m Y 11413）がサーキットになっているので、ピット部分にある車（マンキーニ カヴァロ1001）を使い周回すればよい。 パラシュートクライマー カンブン･ベンガリ（X 21829、Y 11028）から、南の峠を登ろうとしている車にパラシュート降下中の状態からグラップリングし車体に乗る。そのまま峠を登り、レースチャレンジのある場所付近で飛び降りると、何故かパラシュートクライマーのカウントとなり楽に解除できる。（日本語版にて確認） 離陸直前の飛行機に同じようにグラップリングし、適度な高さで飛び降りてもOKらしい。 正攻法で解除したい場合は、パラシュートを開いたまま連続でグラップリングし上昇する。一気に上昇させようとすると足をつけてしまうので、下記動画のように山肌に沿うように斜面に平行気味にグラップリングする。 http //www.youtube.com/watch?v=Tfa8UiiqIjo グラップリングで上昇、空中でA連打(パラシュートを開いて即閉じる)、グラップリングで上昇～(ループ)とやっても解除を確認。とにかく足が地面につかなければいい。 ボクはきっと飛べる! 飛行船マイルハイクラブ（X 29584、Y 11435）の風船の上からベースジャンプすれば解除。最後にパラシュートを開かないとベースジャンプとみなされないので注意。 低空飛行 障害物の少ない海か砂漠で挑戦するのが楽。海面で挑戦する場合は浅瀬でなければ判定されないので場所を選ぶ。 ペカン・テルク・テンガ（MAPほぼ中央）上部の浅瀬で解除するのが最も容易。ペルシルバーボルト6を購入、もしくはその近くのレースでポップさせた後、海側から橋を潜って進入し、そのまま低空飛行。RTで加速する必要は無いので、ゆっくり落ち着いて。 また、安定はしないが↓のように他にも方法は色々ある。 http //www.youtube.com/watch?v=LGlQ___3iWw 世界の頂点 （X 20538、Y 11836）付近のスカルのある位置。 http //www.youtube.com/watch?v=_gwF-dTVQvs
https://w.atwiki.jp/touhoukashi/pages/6479.html
【登録タグ C DOWNTOWN-5 リュウセイ 曲 白井舞 芥川龍之介の河童 ～ Candid Friend 茜音色タウン】 【注意】 現在、このページはJavaScriptの利用が一時制限されています。この表示状態ではトラック情報が正しく表示されません。 この問題は、以下のいずれかが原因となっています。 ページがAMP表示となっている ウィキ内検索からページを表示している これを解決するには、こちらをクリックし、ページを通常表示にしてください。 /** General styling **/ @font-face { font-family Noto Sans JP ; font-display swap; font-style normal; font-weight 350; src url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/10/NotoSansCJKjp-DemiLight.woff2) format( woff2 ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/9/NotoSansCJKjp-DemiLight.woff) format( woff ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/8/NotoSansCJKjp-DemiLight.ttf) format( truetype ); } @font-face { font-family Noto Sans JP ; font-display swap; font-style normal; font-weight bold; src url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/13/NotoSansCJKjp-Medium.woff2) format( woff2 ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/12/NotoSansCJKjp-Medium.woff) format( woff ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/11/NotoSansCJKjp-Medium.ttf) format( truetype ); } rt { font-family Arial, Verdana, Helvetica, sans-serif; } /** Main table styling **/ #trackinfo, #lyrics { font-family Noto Sans JP , sans-serif; font-weight 350; } .track_number { font-family Rockwell; font-weight bold; } .track_number after { content . ; } #track_args, .amp_text { display none; } #trackinfo { position relative; float right; margin 0 0 1em 1em; padding 0.3em; width 320px; border-collapse separate; border-radius 5px; border-spacing 0; background-color #F9F9F9; font-size 90%; line-height 1.4em; } #trackinfo th { white-space nowrap; } #trackinfo th, #trackinfo td { border none !important; } #trackinfo thead th { background-color #D8D8D8; box-shadow 0 -3px #F9F9F9 inset; padding 4px 2.5em 7px; white-space normal; font-size 120%; text-align center; } .trackrow { background-color #F0F0F0; box-shadow 0 2px #F9F9F9 inset, 0 -2px #F9F9F9 inset; } #trackinfo td ul { margin 0; padding 0; list-style none; } #trackinfo li { line-height 16px; } #trackinfo li nth-of-type(n+2) { margin-top 6px; } #trackinfo dl { margin 0; } #trackinfo dt { font-size small; font-weight bold; } #trackinfo dd { margin-left 1.2em; } #trackinfo dd + dt { margin-top .5em; } #trackinfo_help { position absolute; top 3px; right 8px; font-size 80%; } /** Media styling **/ #trackinfo .media th { background-color #D8D8D8; padding 4px 0; font-size 95%; text-align center; } .media td { padding 0 2px; } .media iframe nth-of-type(n+2) { margin-top 0.3em; } .youtube + .nicovideo, .youtube + .soundcloud, .nicovideo + .soundcloud { margin-top 0.75em; } .media_section { display flex; align-items center; text-align center; } .media_section before, .media_section after { display block; flex-grow 1; content ; height 1px; } .media_section before { margin-right 0.5em; background linear-gradient(-90deg, #888, transparent); } .media_section after { margin-left 0.5em; background linear-gradient(90deg, #888, transparent); } .media_notice { color firebrick; font-size 77.5%; } /** Around track styling **/ .next-track { float right; } /** Infomation styling **/ #trackinfo .info_header th { padding .3em .5em; background-color #D8D8D8; font-size 95%; } #trackinfo .infomation_show_btn_wrapper { float right; font-size 12px; user-select none; } #trackinfo .infomation_show_btn { cursor pointer; } #trackinfo .info_content td { padding 0 0 0 5px; height 0; transition .3s; } #trackinfo .info_content ul { padding 0; margin 0; max-height 0; list-style initial; transition .3s; } #trackinfo .info_content li { opacity 0; visibility hidden; margin 0 0 0 1.5em; transition .3s, opacity .2s; } #trackinfo .info_content.infomation_show td { padding 5px; height 100%; } #trackinfo .info_content.infomation_show ul { padding 5px 0; max-height 50em; } #trackinfo .info_content.infomation_show li { opacity 1; visibility visible; } #trackinfo .info_content.infomation_show li nth-of-type(n+2) { margin-top 10px; } /** Lyrics styling **/ #lyrics { font-size 1.06em; line-height 1.6em; } .not_in_card, .inaudible { display inline; position relative; } .not_in_card { border-bottom dashed 1px #D0D0D0; } .tooltip { display flex; visibility hidden; position absolute; top -42.5px; left 0; width 275px; min-height 20px; max-height 100px; padding 10px; border-radius 5px; background-color #555; align-items center; color #FFF; font-size 85%; line-height 20px; text-align center; white-space nowrap; opacity 0; transition 0.7s; -webkit-user-select none; -moz-user-select none; -ms-user-select none; user-select none; } .inaudible .tooltip { top -68.5px; } span hover + .tooltip { visibility visible; top -47.5px; opacity 0.8; transition 0.3s; } .inaudible span hover + .tooltip { top -73.5px; } .not_in_card span.hide { top -42.5px; opacity 0; transition 0.7s; } .inaudible .img { display inline-block; width 3.45em; height 1.25em; margin-right 4px; margin-bottom -3.5px; margin-left 4px; background-image url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2971/7/Inaudible.png); background-size contain; background-repeat no-repeat; } .not_in_card after, .inaudible .img after { content ; visibility hidden; position absolute; top -8.5px; left 42.5%; border-width 5px; border-style solid; border-color #555 transparent transparent transparent; opacity 0; transition 0.7s; } .not_in_card hover after, .inaudible .img hover after { content ; visibility visible; top -13.5px; left 42.5%; opacity 0.8; transition 0.3s; } .not_in_card after { top -2.5px; left 50%; } .not_in_card hover after { top -7.5px; left 50%; } .not_in_card.hide after { visibility hidden; top -2.5px; opacity 0; transition 0.7s; } /** For mobile device styling **/ .uk-overflow-container { display inline; } #trackinfo.mobile { display table; float none; width 100%; margin auto; margin-bottom 1em; } #trackinfo.mobile th { text-transform none; } #trackinfo.mobile tbody tr not(.media) th { text-align left; background-color unset; } #trackinfo.mobile td { white-space normal; } document.addEventListener( DOMContentLoaded , function() { use strict ; const headers = { title アルバム別曲名 , album アルバム , circle サークル , vocal Vocal , lyric Lyric , chorus Chorus , narrator Narration , rap Rap , voice Voice , whistle Whistle (口笛) , translate Translation (翻訳) , arrange Arrange , artist Artist , bass Bass , cajon Cajon (カホン) , drum Drum , guitar Guitar , keyboard Keyboard , mc MC , mix Mix , piano Piano , sax Sax , strings Strings , synthesizer Synthesizer , trumpet Trumpet , violin Violin , original 原曲 , image_song イメージ曲 }; const rPagename = /(?=^|.*