2,992,348 events, 1,494,292 push events, 2,359,170 commit messages, 178,616,240 characters
Path the Pawns via Navigation!
Previously, we were just feeding the Pawns singular points, which they then mindlessly marched to. That was regardless of what was in the way - walls, rocks, ledges, other crap.
Obviously, pathing is a major part of any strategy game; and this prototype is no exception. We were gonna need a way to feed the Pawns coherent paths instead of just singular points.
This required a lot of work - not necessarily a rework, but a lot of small changes.
The first change was in KinematicDriver. The position of a node navigating a NavMesh needs to be determined by the node and the NavMesh. In other words, it is beyond the KinematicDriver's ability to calculate it's current position. To get around this, the KinematicDriver has a new signal: request_position(). This is a request for whoever's listening (i.e. the KinematicBody being driven) to update the Driver's position value. While asking for an update on a public variable via a signal isn't exactly kosher, I felt strapped for options. I suppose we could pass Navigation down to the Driver, but the driver is meant to go from point A to point B. Code should adapt and specialize around the Driver, not vice versa. Other than that, the KinematicDriver is largely the same.
The second adaptation was in Pawn (so long, UnitPawn!). The Pawn now accepts a NodePath to the Navigation node. This Navigation node is used for checking position, which is then passed to the driver via the request_position signal. It was important to me that the Pawn maintain it's old floor-point functionality, so the Pawn switches its functionality based on whether we have a navigation node provided.
The "destination" in Pawn has been superceded by the "current_path", which is an array of Vector3 positions for the Pawn to follow. These are passed piecemeal down to the KinematicDriver as appropriate. The paths themselves are given wholesale to the Pawn, and are assumed to be "fine" (i.e. we won't have to edit them). In the future, there will likely be some sort of HiveMind, PawnManager, or TownManager that will take care of feeding the Pawn's paths or location data of some kind.
The "ParadeGround" has been deleted. This was always intended as a demonstration of how the Pawns move and interact with their environment. It has been effectively replaced by our existing tests and our latest test - the PawnPathingTest. The PawnPathingTest has our navigation mesh and sample code for ordering a single Pawn around.
I noticed early on that the NavigationMesh was struggling a lot with putting down mesh inside the test buildings. It seemed to just LOVE putting it on the roof. To get around that, I did a rework of our collision layers.
The first three layers are now all terrain layers. First is Pathable, which is meant for ground and the like. Next is Nonpathable, which identifies terrain that needs to be pathed around but shouldn't be pathed over - like walls. Although I don't have a lot of control of pathing OVER things, I thought it was important to differentiate. The last terrain layer is the "Path Ignored" layer, which is meant for roofs and overhangs that never get accessed (and shouldn't be, really). This allows us to actually create mesh inside the buildings. Yay!
The rest of the layers are dedicated to enumerating specific item and thing types - I'm not sure what we'll need exactly but I'm pretty confident we'll layers for different groups.
The last four layers are dedicated to "Teams", numbered 1 through 4. This will be used for friend-versus-foe identification. Eventually.
There were two additional tweaks after observing the Pawn moving. First, the internal Driver's goal tolerance had to be increased to .2, since there seemed to be some funkiness happening whenever the Pawn was stepping up or down. Some sort of vertical mismatch I guess. Oh well, we don't need it to be too precise. The other problem was that the Pawn kept catching on edges - so I increased the agent radius until the clipping stopped.
Now comes the real hard part - doing this all on the fly...
Launcher3: Restart with change only on exit
This change allow the user to change everything they have to inside the homescreen activity and only restart on exit. Previously this was a pain in the fucking ass because you had to go in and set each option one by one with a restart inbetween. At least now is not that big of a pain.
- Restart on destroy (hitting the back button, actionbar arrow)
- Restart when a chance is made and the home button is pressed
** Thanks "Jack" for code to detect home button https://stackoverflow.com/a/27956263
- Cleaned up restart code
eyosen adapted to 10
Change-Id: I4962916ae0bd59d08247b59de585a97a2b9da3a1
OpenVSP Version 3.22.0
After more than three months of cooking, we have a little big release...
OpenVSP generally follows a version of the major.minor.patch versioning system. Major numbers are reserved for really big changes -- like the first open source release, or fundamental re-writes that cause input file incompatibility. Minor numbers typically accompany a bunch of features and also updates to the packaged libraries. Patch updates mostly contain bug fixes, but some features always creep in.
It may not look like it to everyone, but this release has a lot to it. Even so, I nearly released it as a patch release 3.21.3 - mostly because a lot of what is here is building to more things down the road. My excitement for what is to come makes me see these changes as a bit less. However, this release does include a small update to Code-Eli, so anyone building it themselves needs to watch for that.
The big change that most users will notice is that OpenVSP should now update significantly faster for complex models. The model Update() routine has been substantially restructured to be much smarter about what needs to be updated depending on which Parm was changed. It also caches more intermediate results to allow a variety of shortcuts when warranted.
This change required major surgery. This does not come without risk. Several volunteers have been testing this for a while, but there is still a chance that something is not right. The most likely problem to watch out for is something doesn't update when you think it should. Keep an eye out and if you have any problems, please post a bug report to the Google Group.
BTW, if you aren't aware (or subscribed) to the Google Group, it is the best place to ask questions or discuss OpenVSP.
Another big change is a big update to MeshGeom & Friends. (CompGeom, Mass Properties, Area Slice, Wave Drag, etc. These now support 'negative' components. The user can designate one or more Geoms as 'negative' and instead of contributing to the OML as a union (addition), they contribute as subtraction. CFDMesh has had this capability for some time and CAD export recently joined in the fun. Now MeshGeom & Friends can poke holes in your model too.
Negative component support for MeshGeom was actually a step towards another feature in this version. The ability to meaningfully handle non-watertight surfaces. Some may view non-watertight surfaces as a bad thing -- but they don't have much imagination. OpenVSP has long used non-watertight surfaces to represent things - actuator disks and wakes in CFDMesh, structures in FEAMesh, etc. CompGeom can now work with thin (non-watertight) surfaces mixed with thick watertight bodies. The thin surface representation is derived from the plate or camber Degen representation. So, CompGeom can now process a geometry with (for example) the wing, tail, and propeller surfaces modeled as thin camber surfaces and the fuselage and other things modeled as thick bodies. If this doesn't excite you, that is OK. Wait for the next version, it will be cool.
A new file format has been defined and set up for export from MeshGeoms and CFDMesh. The *.vspgeom file is similar to a *.tri file, but it adds some information. The surface u/v parameter values are provided at polygon vertices. This means they can be multi-valued where two objects intersect. Although files currently will only contain triangles, the format will represent arbitrary polygons. Furthermore, wake edges are explicitly defined in this file, so downstream analysis programs don't have to use heuristics to detect them.
For those of you still reading, one cool update is that various tables throughout the GUI now have resizable columns. So no more frustration because the columns are all the wrong size. Just resize them.
Features:
- Faster Update complex models should update more quickly than before.
- Negative components to MeshGeom & Friends.
- Thin (non-watertight) surface support for CompGeom.
- vspgeom file export.
- Enhanced wedge airfoil type (requested by Mike W. and Liam M.).
- Print out search path for VSPAERO (thanks Jason W.).
- Expand API to set VSPAERO search path.
- Updates to Python tools from Uber team.
- General code cleanups.
- API test framework for CFDMesh.
- Build support for Matlab API. Adds VSP_ENABLE_MATLAB_API CMake flag.
- Improved FEA Structure spar parameterization (suggested by Mischa P.).
- Option to rotate FEA Structure ribs with dihedral.
- Lots of API additions and cleanups.
- Tables now have resizable columns.
- Trimmed CAD intersection curve tolerance control.
- Automatic actuator disk hub diameter.
Bug Fixes:
- Improvements to automated build process.
- Fix cross platform browser launching.
- Fix bug in unit conversion in Python tool.
- Tag CFDMesh surfaces even when SubSurfaces are not intersected.
- Fix problems with SuperEllipse XSec Type.
- Bookkeeping for point masses in Mass Properties.
- Fix API update issues for VSPAERO, Wave Drag, and Parasite Drag.
- Many other fixes.
did... so fucking much end my suffering good luck future me, if you need more info, you bastard bitch
Add files via upload
Homework 4 Focus Classes Association As always: good coding Problem: We will [continue to] model a game of medieval times. Our world is filled with not only warriors but also nobles. Nobles don't have much to do except do battle with each other. (We'll leave the feasting and other entertainments for add-ons.) Warriors don't have much to do except hire out to a noble and fight in his behalf. Of course the nobles are pretty wimpy themselves and will lose if they don't have warriors to defend them. How does all this work?
Warriors start out with a specified strength. A battle between nobles is won by the noble who commands the stronger army. The army's strength is simply the combined strengths of all its warriors. A battle is to the death. The losing noble dies as does his warriors. The winner does not usually walk away unscarred. All his men lose a portion of their strength equal to the ratio of the enemy army's combined strenth to their army's. If the losing army had a combined strength that was 1/4 the size of the winning army's, then each soldier in the winning army will have their own strength reduced by 1/4. Hiring and Firing
Warriors are hired and fired by Nobles. Lack of adequate labor laws, have left the Warriors without the ability to quit, nor even to have a say on whether or not a Noble can hire them. However it is possible that an attempt to hire or fire may fail. Naturally the methods should not "fail silently". Instead, they will return true or false depending on whether they succeed or not. A Warrior can only be employed by one Noble at a time and cannot be hired away if he is already employed. As noted below, Nobles who are dead can neither hire nor fire anyone. (Note this will implicitly prevent dead Warriors from being hired.) When a warrior is fired, he is no longer part of the army of the Noble that hired him. He is then free to be hired by another Noble. How do you remove something from a vector. While there are techniques that make use of iterators, we have not yet discussed iterators so you will not use them here. (As a heads up, if you see a technique that requires you to call a vector's begin() method, that is using iterators. Don't use it.) While it may seem a slight burden, certainly it does not require more than a simple loop to remove an item from a vector. No do not do something silly like create a whole new vector. Soon we will cover iterators and then you will be freed from these constraints. Patience, please. Death It's a sad topic, but one we do have to address.
People die when they lose a battle, whether they are a Nobles or Warriors. Nobles who are dead are in no position to hire or fire anyone. Any attempt by a dead Lord to hire someone will simply fail and the Warrior will remain unhired. However curiously, as has been seen before, Nobles can declare battle even though they are dead. Note that when a Noble is created he does not have any strength. At the same time he is obviously alive. So lack of strength and being dead are clearly not equivalent. A test program and output are attached. Note that the output shown is what you are expected to generate. Pardon us, we don't like limiting your creativity, but having your output consistent with ours makes the first step of grading a bit easier. And also helps you to be more confident that your code works.
Programming Constraints What would a homework assignment be without unnecessary and unreasonable constraints?
Your classes must satisfy the following:
The battle method will announce who is battling whom, and the result (as shown in the example output). If one or both of the nobles is already dead, just report that. The "winner" doesn't win anything for kicking around a dead guy. And his warriors don't use up any strength. Look at the output for the sample test program to see what you should be displaying. A noble's army is a vector of pointers to warriors. Warriors will be ordered in the army by the order in which they were hired. That affects how you remove a Warrior thatgets fired. And some things to make life easier Just in case you are confused, let me point out that this problem does not involve the use of the heap. That means your program will not make use of the operator new or the operator delete.
058,2,Shadowear,dk/gh,In the morning this pokémon is very calm and sleepy, already at night its calm temperament changes to something dark and aggressive. Local tribes cite this pokémon as the real evil due to the nocturnal attacks caused by Shadowear. Its powerful claws can tear anything apart and can do a great injury to a human.
big updoot
ok so i 100% CBA to list all the changes here, so here is the important stuff:
The Free Worlds Wolfpack now rewards you in special technology, rather than punishing the player for making a subjectively wrong moral decision. (Taking the Uncle Billy route, detaching from your supply line, and burning the enemies crops is not objectively evil.)
Omega Station now has a giant neon sign (metaphorical) pointing to it. If you follow that giant neon sign, you can now participate in an combat-centric tournament which pays out stupidly well (WIP)
Planned: when you finish the tournament and win, you get to help with the development process of the Astraea and Elpis (The dreadnaught and its smaller counterpart)
Made it clear that Barmy is Edward's nickname, because everyone thought his canonical name was "Barmy Edwards" for some reason. (Barmy means crazy/foolish. He's an obvious reference to Crazy Eddie), gave Ed some personality, all that good stuff.
Brought back the "steal a ebeam" mission, but implemented it in a very different way
planned: Free Worlds Reverse Engineer of the Ebeam
and so, so much more.
Whoever created git: fuck you. fuck your momma. fuck your daddy. fuck your children. fuck your grandchildren. I spit and shit on your grave.
pain and suffering part 2
many things have been fixed, including the ability to actually play the fucking game
"9:35am. Now that I am done with BG, my vote for the best spell in the game definitely goes to Invisibility. You can't deal damage with it directly, but it has so much utility it is not even funny. You know the maxed out stealth thieves get at high levels? Invis is actually better than that and it is a level 2 spell. You can scout, you can set up traps, you can get away to rest on you burn through your spells, it lasts so long you can move between multiple areas without getting ambushed, literally nobody in the game can break it. Even if the enemy mage casts Detect Invisibility you can just cast it again or chug a potion.
I am tempted to continue playing with a different character, but I'll stop here.
9:40am. Let me get back to my usual pace. I'll do my morning chilling and then I'll do my programming. Tonight I slept well.
9:55am. Let me start. I've proven my spell casting mastery enough.
10am. There are some sore spots, but it is a real eye opener that I've been essentially soloing whole parties with just a single character for the entire game. I see now what they mean when they say that wizards are gods. I bet their advantage will only get stronger in BG2.
This was a good experience for me.
I bet what I've seen in BG is nothing compared to DnD where they have expanded spell lists.
10:05am. Focus me.
type TypecheckerStream = Typechecker of (Bundle list -> (Infer.InferResult * TypecheckerStream) Stream)
let typechecker package_id module_id top_env =
let rec tc s_old = Typechecker(fun bundles ->
let rec loop s (bs : Bundle list) = promise_thunk (fun () ->
match bs with
| b :: bs ->
match PersistentVector.tryNth (PersistentVector.length s) s_old with
| Some (b', r, _ as old) when b = b'-> Cons((r,tc s_old),loop (PersistentVector.conj old s) bs)
| _ ->
let env = match PersistentVector.tryLast s with Some(_,_,top_env) -> top_env | _ -> top_env
let r = Infer.infer package_id module_id env (bundle_top b)
let s = PersistentVector.conj (b,r,Infer.union r.top_env_additions env) s
Cons((r,tc s),loop s bs)
| [] -> Nil
)
loop PersistentVector.empty bundles
)
tc PersistentVector.emptyLet me get rid of the stream from here.
...Damn it, I really do like the stream versions.
type TokReq =
| DocumentAll of string
| DocumentEdit of SpiEdit
type TokRes = {blocks : Block list; errors : RString list}
type TokenizerStream = Tokenizer of (TokReq -> (TokRes * TokenizerStream) Job)
let job_thunk_with f x = Job.thunk (fun () -> f x)
let promise_thunk_with f x = Hopac.memo (job_thunk_with f x)
let promise_thunk f = Hopac.memo (Job.thunk f)
type TokenizerState = { lines : LineTokens; errors : RString list; blocks : Block list }
let tokenizer_state_def = { lines = PersistentVector.singleton PersistentVector.empty; errors = []; blocks = [] }
let replace (s : TokenizerState) edit =
let lines, errors = Tokenize.replace s.lines s.errors edit
let blocks = block_separate lines s.blocks edit
{lines=lines; errors=errors; blocks=blocks}
let tokenizer (s : TokenizerState) = function
| DocumentAll text -> replace s {|from=0; nearTo=s.lines.Length; lines=Utils.lines text|}
| DocumentEdit edit -> replace s edit
type ParserRes = {lines : LineTokens; bundles : Bundle list; parser_errors : RString list; tokenizer_errors : RString list}
type ParserState = {
is_top_down : bool
blocks : (LineTokens * ParsedBlock) list
}
let parse (s : ParserState) (x : Block list) =
let dict = Dictionary(HashIdentity.Reference)
List.iter (fun (a,b) -> dict.Add(a,b.parsed)) s.blocks
let blocks =
List.map (fun x -> x.block, {
parsed = Utils.memoize dict (block_init s.is_top_down) x.block
offset = x.offset
}) x
{s with blocks = blocks}
let parser (s : ParserState) (req : TokRes) =
let s = parse s req.blocks
let lines, bundles, parser_errors = block_bundle s.blocks
{lines = lines; bundles = bundles; parser_errors = parser_errors; tokenizer_errors = req.errors}, sLet me back this all up here. I'll go with what I had before and just get rid of the jobs...
No, no, no. For the tokenizer and the parser that might be doable, but what about the typechecker.
type TypecheckerStream = Typechecker of (Bundle list -> (Infer.InferResult * TypecheckerStream) Stream)Unlike the others, it outright returns a stream. I can't remove that from the out level.
...Forget it, I'll stay my current course. The streams are too restrictive design wise after all. But my thinking was on the right track with them for the first time.
10:10am.
type ParserState = {
is_top_down : bool
blocks : (LineTokens * ParsedBlock) list
}Oh yeah, if something is making me uncomfortable that would be this.
10:25am. Let me think. I had a clear vision of how streams should work, then...
let file_op (s : SupervisorState) uri req =
let (Tokenizer t) = Map.findOrDefault uri tokenizer s.tokenizer
let (Parser p) = Map.findOrDefault uri (parser (Path.GetExtension(uri) = ".spi")) s.parser
t req >>= fun (tr,t) ->
p tr >>- fun (pr,p) ->
pr, {s with tokenizer=Map.add uri t s.tokenizer; parser=Map.add uri p s.parser}I started doing this and that vision got wrecked.
type SupervisorState = {
tokenizer : Map<string, TokenizerStream>
parser : Map<string, ParserStream>
}I am confused now again. Why do the supervisor updates have to not be Jobs? I can update it inside a job.
That is how I originally meant to do it.
12:05pm. I am thinking.
12:40pm. Let me stop here. I've been thinking all this time. I am starting to get it. I have a lot of ideas. And I understand what is confusing me so much.
I'll definitely be doing some programming today. I might do the basic file stream. There are a lot of challenges to deal with, but I can do it."
Texture Coord bug fix, Bump node support, sort of
Texture Coordinate nodes threw an error, now, all of their outputs are being set to the single output of Unreal's TexCoord. This node should probably receive the same attention as the Math, or Material Functions, and spawn different Unreal nodes, depending on which output is used, as Unreal uses separate nodes for Camera vs Object data etc. That will be another update.
Added support for Normal and NormalMap nodes, in the form of Reroute nodes, if there are better approximations of the functions of Normal and NormalMap in Unreal then I'll swap them in.
Added Bump node support, and worked out bugs, only to find that Unreal's NormalFromHeightmap node won't accept an RGB input, only T2D! Hmmm, but it's a TEXTURE sample that's outputting the RGB, surely there's a way to get a TEXTURE2D output from a TEXTURE!?!??! No, there is not. The workaround for me, currently, is to create a Texture OBJECT, plug that into the Texture input of the Texture SAMPLE, then also plug the output of the Texture OBJECT into the NormalFromHeightmap node, but this then demands a Texture Coordinate to keep it aligned to the RGB output of the Texture Sample. Fuck.
In theory, I could add Texture Objects to the Post Load Nodes pass, I'd just have to check to make sure that approach isn't double loading texture data. But that does also pose some problems for making the connection, and I'm not sure how much that particular material function actually sees use in games.
This also lead to me finding a number of bugs:
1 - packed images retain their filepath from the original creator's PC - after downloading a number of files from Blendswap to test, I found that all the .blends with packed images were failing with error messages indicating the texture were stored in a location that didn't exist on my PC, leading me to the above conclusion. I could maybe unpack the images first, to avoid non-existent filepaths, but I'm not sure what's involved in that process, so it could take time to figure out, or if it's worth it.
2 - Mapping node is just a buggy pile of nonsense. Initial test were promising, but either I made some mistakes in modifying it, or the transition from 3D to 2D has a larger effect than I'd hoped. The node setup will recreate the same results in Blender as the Mapping node, but, in Unreal, it gives inconsistent/unpredictable results, and takes so damn long to compile on my machine that it also make me question whether it's worth pursuing further.
[fix] Fixes issues where script stopped working again.
(╯°□°）╯︵ ┻━┻ For some reason, the commit worked last night but all of a sudden, it's not working again.
Gosh I hate to work with JavaScript. Oh well, here's the buckload of changes on this commit:
chore: Remove webpack-dev-server as this is no longer used to test chore: Update webpack-cli to 4.2.0 after downgrading it to 3 in order for webpack-dev-server to work. But now it is removed and we are free to update it on newer one. chore: events.js is now events.json. chore: events is no longer included in support object. Now events are just imported at the script that processes the events. Well, in short, it is just an optimization. fix: This commit updates where script stopped working automatically for no reason. Though previous commit works after release but after it, it just gone. This fixes issues on regex on dates, changed up and tidied a little bit of wires and then it just works again. Expect again that this shit will stop working again soon. ヽ(✿ﾟ▽ﾟ)ノ
Frustrating but, I should return the table back again. ┳━┳ ノ( ゜-゜ノ)
CMSC22 has left the room: finished functionality but not gonna add modularity / proper standards / clean code. I hate my life
There were some misunderstandings. At first and the most important thing: The file 'Plot.py' is for now the file which is for the measurements. Also we have the 'Main_program.py' file which is only for garbage and shitty tryings to get comfortable with the Metropolis algorithm which was programmed by Lea Schmea, the queen of coffee Lagrangien and the hummus master. At least we decided to measure the volume effect, which contains the variation of the lattice size and the impacts on the observables. Then we want to look how that worked and on this basis we want to talk with Mr. Hoelbling what we can do for the second part - whether we measure some hysterese effects or we want to measure the observables with an external magnetic field and how they change with it. But at least we decided that the end decision stays with me, the queen of chaos and the most confusing girl in the world, what i think is the most comfortable solution. Also i promise, to add, commit and to push everything that we do not have the same problem like now. I hope this is a GOOD MESSAGE and we can work with it in the future. Thank you well and i hope you have a good day <3
Update from Forestry.io Amy Dunn updated content/blog/why-you-need-a-girlfriend-s-getaway-on-oregon-s-adventure-coast.md Amy Dunn updated content/blog/2016-11-03-where-to-find-the-best-holiday-treasures-on-oregons-adventure-coast.md Amy Dunn updated content/blog/where-to-find-razor-clams-on-oregon-s-adventure-coast.md Amy Dunn updated content/blog/where-to-find-2019-holiday-magic-fun-on-oregon-s-adventure-coast-1.md
intel/nir: Lower 8-bit ops to 16-bit in NIR on Gen11+
Intel hardware supports 8-bit arithmetic but it's tricky and annoying:
-
Byte operations don't actually execute with a byte type. The execution type for byte operations is actually word. (I don't know if this has implications for the HW implementation. Probably?)
-
Destinations are required to be strided out to at least the execution type size. This means that B-type operations always have a stride of at least 2. This means wreaks havoc on the back-end in multiple ways.
-
Thanks to the strided destination, we don't actually save register space by storing things in bytes. We could, in theory, interleave two byte values into a single 2B-strided register but that's both a pain for RA and would lead to piles of false dependencies pre-Gen12 and on Gen12+, we'd need some significant improvements to the SWSB pass.
-
Also thanks to the strided destination, all byte writes are treated as partial writes by the back-end and we don't know how to copy-prop them.
-
On Gen11, they added a new hardware restriction that byte types aren't allowed in the 2nd and 3rd sources of instructions. This means that we have to emit B->W conversions all over to resolve things. If we emit said conversions in NIR, instead, there's a chance NIR can get rid of some of them for us.
We can get rid of a lot of this pain by just asking NIR to get rid of 8-bit arithmetic for us. It may lead to a few more conversions in some cases but having back-end copy-prop actually work is probably a bigger bonus. There is still a bit we have to handle in the back-end. In particular, basic MOVs and conversions because 8-bit load/store ops still require 8-bit types.
Reviewed-by: Kenneth Graunke [email protected] Part-of: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7482
phase 2-ery.
i suck ass at things
-
fixed some team ai shit
-
fixed a crash related to coplogictravel
-
fruitless attempts at making the alaskan deal crash go away
Fuck you mother fuckers the world builds itself now, like my assssssssss