|
|||
| Views: 692,061 | 06-28-21, 12:55 am | ||
|
|||
| Views: 692,061 | 06-28-21, 12:55 am | ||
code block | Thread review | |
|---|---|
| PillowShout |
Just a minor update to Scheduler. Also letting you know that I'm not dead yet. https://docs.google.com/file/d/0B_IgNCoukjzDQ1VuOTQ2ODY1SUE/edit |
| PillowShout |
OK, here's the next version. https://docs.google.com/file/d/0B_IgNCoukjzDSjZHeG12TzNMRUE/edit This one adds the FindAndGoto task to the list, completes the functionality of the Wait and Wander tasks and cleans up a bit of logic in the scheduler. I also added a function to the Dijkstra mapper that checks if a location on the map is a local minimum, which I'm using as my check for characters not being able to navigate any further. |
| Kawa |
Doors work by setting the tile underneath them to walls when the doors are closed, and floor when they're opened. The mapper literally hits a wall where the door is. What I'd do is have the Dijkstra mapper detect doors and just pretend there's not a wall there. That just leaves the question, will the NPC open the door when getting there? As for unreachability, if we pass our starting coordinates to the Dijkstra mapper we can have the mapper try to probe down the path it just created. If a target hotspot can't be reached, chances are good that the probe'll vaccilate between two spots or stop moving at all, which can be detected before returning the map. Addendum: if the spot on our starting coordinates is still the Very High Number, it's probably unreachable. This came to mind on reflection because when I click-pathed around for testing my character didn't move at all. Because he was on a VHN and surrounded by VHN. Edit: Appending the following to Dijkstra.UpdateWalls() fixes the first problem. <blockquote> foreach (var door in board.Entities.OfType<Door>().Where(d => !d.Locked)) </blockquote>walls[door.YPosition, door.XPosition] = false; Both the Player and any BoardChar end up using Entity.Move() to take the actual steps, and Entity.Move() is the where doors are opened, so that was already covered. |
| PillowShout |
Ok, I sort of have this up and running, but I'm having a few problems with the pathing. The BoardChars seem to be able to find their beds, but only if they're either inside their homes or if their doors are open. This leads me to believe that the pathing sees doors as impassable for some reason, but I'm not sure how to deal with this. There's one other thing I'd like to know: is there some way to tell if a path cannot be made to reach a target? For instance, does the djisktra map set any flags if it can't create a path to its intended location? Or is there some sure way of telling if a Boardchar is blocked from getting to its target? |
| Kawa |
For the record, and to assist in making characters actually go to bed instead of sleeping on the spot, the ID for a given character's bed is (now) Bed_characterNameAsID. That is, <code>character.Name.ToID()</code>, or "Bed_Suzu_Saito". Unclaimed beds get Bed_entityCountSoFar. It used to be buildingBaseID_Bed_characterFirstName, but I changed that because first names can be shared even in one board and the building base ID is superfluous now. On a related note I just changed the ID generation for wardrobes from buildingBaseID_Container_containerType_characterFirstName to just Container_containerType_characterNameAsID. Same here with unclaimed containers. |
| Kawa | Don't worry. I implemented comparison operators myself, and rewrote the part where it stores them myself. |
| PillowShout |
* Sees NoxicanDate content I forgot to send * Crap. I knew I missed something! >_< |
| Kawa | Well, if this works you'll be one step ahead from the scheduler I'd made and then #ifdef'd out. Let's see what this is... |
| PillowShout |
This one's a bit different as it's not a pure update so much as something of a prototype for the scheduler. (I know -_- ... I am trying to write, but I've been having trouble making anything I like well enough to use) https://docs.google.com/file/d/0B_IgNCoukjzDbXptNmtKVkg4OUk/edit This isn't something I'm expecting you to use, at least not right away, but it is something that I have wanted to have in the game for a while now as I've been getting pretty bored of the rather mindless behaviour of the AI. AI and intellegent systems are actually something of a minor obsession for me and I like making things at least seem smarter than they are. The basic idea behind this system is that I wanted a scriptable and generic means of adding more intellegent behaviour to town people, and so, over the past few days, I created a rough, though hopefully easy to build on, means of doing that. The only things that the system actually does right now are get a schedule (stored as a token tree) for each BoardChar in a town, use their schedule to determine which activity they should be performing given the current time of day, and then run the scripts contained in each activity type (These are all defined in an xml file). Currently, I've only got token replacement working the way I intended it to, but because the script is being run by the entity itself, you could theoretically make the script do whatever the entity's script handler is capable of. Right now, with their current (and only) schedule, the villagers will fall asleep around midnight - wherever they happen to be standing at the time - and then wake up at about 630 and continue wandering around. I know it's not much, and that's why it's a prototype, but I think that this could be a good foundation for any future system we develope. Anyway, feel free to mess around with it, clean it up or make it better, and then add whatever kind of functionality you like. Have fun! :LOL: Edit: Forgot to add these to the Code file, but you also need to add these lines to BoardChar.RunScript if you want things to work:
|
| Kawa | You really went to town on those descriptions, didn't you? I feel like I should do some major code work just to keep up. |
| PillowShout |
Whoo! I'm back! Well, sort of. Sorry about the hiatus, but there was some crap I had to deal with over the past month and I wasn't feeling up to writing because of it. Unfortunately, said crap is still not entirely dealt with, so I won't be doing too much from now until whenever it's resolved. That said, even if I didn't feel like writing, I did manage to get some coding done, and now I present the fruits of my labor. https://docs.google.com/file/d/0B_IgNCoukjzDQmhidDFOU3dkVmc/edit After I noticed you doing a fuckton of refactoring, I decided that I'd like to do the same thing to the descriptions. I hope that as a result, using the description functions should be much more universal. The biggest and most immediate change is that most of the descriptions for each token type have been moved into their own file (bodyparts.xml) rather than being hardcoded inside a function. This will hopefully create a more universal set of descriptions, and it means that even the LookAt functions can use them. Next is the condensing or replacement of the old description functions. These have mostly (with the exception of the random euphemism functions) been modified to use the universal descriptions, and all of them have been changed to only return either the adjective describing a body part or the name of a body part, but never both. I'm hoping that this more atomic approach will allow for greater flexibility and make these functions useful even outside of dialogue. Lastly, I've changed the names of several token replacement tags in dialogue to better use the new functions and to better adhere to the new atomic approach. The scene files I've included have all been updated to use these tags. I'm sure there's probably some ways to improve what I've got here, so don't hesitate to make any changes if you think it'll make for a cleaner design. |
| Kawa | Yay indeed. Yay in-fucking-deed. |
| PillowShout |
OK, this update finishes off what I wanted to get done for the select tokens. https://docs.google.com/file/d/0B_IgNCoukjzDc0ljLTQ3WTVDc1E/edit This one adds recursive traversal of the token tree for 'select' tokens and two new types of keyword tokens, 'addto' and 'overwrite'. To see what these do, check the readme file. One of the great thing about these new keyword tokens is that you can create certain class types for each bodyplan that can modify virtually any token within the plan to fit the class. This means that you could have random chances of encountering characters of one bodytype, but who may have something like different numbers of breasts, or people who've never been buttfucked and have both the virgin token and looseness: 0 versus those that have been, and don't have the virgin token and have some random looseness. Yay for more variety! |
| PillowShout | Very nice. I had wanted to do the same thing, but I was just too damn lazy. :LOL: |
| Kawa |
Just so you know, I rewrote your missing body parts method to return all missing tokens for a given plan in one exception, and call it from the game's constructor instead of Character.Generate. That way, I got a whooole lotta missing tokens down with only one restart per plan. Pushed all that and the missing tokens. |
| PillowShout |
Okay, new code time! I wrote most of this to accommodate my ambitions for the goblins, but there's also a bit there to deal with something that's been bugging me for while. https://docs.google.com/file/d/0B_IgNCoukjzDOHI0Wnd5UTdaQ3M/edit There are two big things I added this time. The first is the 'select' token and its evaluation function. (check the readme to see what it does.) The second is a utility function that checks through bodyplans and makes sure they have all of the necessary pieces. Hopefully with the latter, we won't have to worry about getting missing body part errors anymore. In addition to modifying the goblin bodyplan, I also cleaned up several bodyplans and added missing parts to them. |
| PillowShout | That's okay. I'm happy leaving it there as a monument to your wankery. ;) |
| Kawa | I am totally 0kay with all of the above, and your damnit moment will stop making sense the moment the server thinks it's tomorrow :) |
| PillowShout |
Not too much this week, just finished the generic rape cunnilingus scenes. (or at least as much of them as will be going into 0.1.15) https://docs.google.com/file/d/0B_IgNCoukjzDdVhKYWg2VEZILU0/edit I also had some ideas for the goblins that I wanted to run by you first before a got too far into them. Most of this is lore stuff, but there are also some things that affect gameplay. *** Incoming wall of text *** Goblins As far as I understand, goblins in Nox are supposed to be technical wizards of some sort, as well as dimensional refugees and so highly tainted that they're aroused nearly all the time. I wanted to go a bit further than that and try to add a bit of diversity to them. I thought that rather than have their civilization destroyed by some outside force, that it was actually the result of an anarchic breakdown caused by the creation of a highly addictive drug that also massively enhances the libido of the user. (+1 for long sentences?) The drug also has the effect of feminizing the user, which explains why there are no male goblins. (And yes the player can find and use this drug) I figured that this would tie together most of what we know about goblins already, but it would give them a more interesting history than, "Bad stuff happened. All the goblins in Nox are now, and they're really horny." So then, how does this affect things in Nox today? While the original components for the drug were lost when the goblins fled their realm, they've found a reasonable substitute in the tainted sexual fluids of the creatures that inhabit Nox. So - and I'm sure that you can see where this is going - in order to create more of the drug, goblins have to first find someone to extract the base materials from, and then afterwards they distill them into the drug. Gameplay wise, I thought that in the wild you would encounter either one of three types of goblins: the 'normal' every day ones out looking to get laid; desperate, hardcore addicts; and the dealers/manufacturers that collect the material. Each of them would have different types of scenes and would spawn with different types of loot and stats, so really, this is mostly just a way to make enemies more varied. So, while most of this stuff doesn't affect the anything I'm not already working on in the game, for some of this to work I would need to make some changes to the goblin bodyplan, and I just wanted to ask if you're okay with that? Also, god damn it Kawa: 
|
| Kawa | I see your point. |