搜索结果: *

Yeah, a lot of us here are or were software engineers and know our software engineer stuff. Iirc, 70% of new code is copy-pasted and edited for a good reason - it saves time and syntax errors, at some risk of bugs from overlooked extraneous code.

点击展开...

I am a software engineer and I can tell you that this is not true. Copy and pasting code is looked down on. You're much better off reusing code by defining it in a function, using some sort of generics, a macro, a library etc. Also the mentality that you can just "copy and paste" code is a mentality I've seen bite people before as well. They think they can just copy stuff elsewhere in the project or off of stackoverflow for everything and the moment they have to actually solve any sort of problem on their own they're totally lost. Again code reuse is good but not by means of copy and pasting.  Copy and pasting makes your code look repetitive, bloated, and anytime you copy and past some code that requires a change, you have to update each and every instance of that code, rather than at one place. Please don't advise people that they should copy and paste, it really isn't good practice.

As far "language compatibility" goes I get what you're saying, but I think you're dramatizing it a bit. The languages map to one another very one to one, it's easy to read one and know how to express it in the other both ways. This mindset also makes me chuckle a bit, because I can just imagine this scenario. "You cannot insert useful snippets from elsewhere or post code for others to use in C without proprietary compilers, and no one is going to bother with that. This is why we don't have alternative syntax to create assembler programs, and so why we will use assembler and only assembler forever." It's true you can't just copy and paste anymore, but that was not much of a loss from my perspective (if you're just copying and pasting snippets there's a good chance you don't know how your code works). We're probably just going to disagree on that one no matter what. One other small nitpick, this tool isn't proprietary, I'm intentionally making the source code publicly available for public domain.

The maintenance is a good point to bring up but that could be argued for basically anything that touches the modsys. What if Talewords slightly changed any of the formats outputted by the process_*.py files and outdated W.R.E.C.K? Not likely, but then neither is changing the data structure of script objects. I've written alternate faster compilers for select pieces of the module system. Why should I expect you to say anything different were I to share one of those? If you're really worried about this then don't use anything but the native modsys. I'm not sure why WSE is your example, because that's probably one of the hardest possible things to maintain to have ever sprung up here. It's in the same vein as SKSE over in the Skyrim community, every time a new binary comes out they have to relocate everything. Most of the tools here don't work with something nearly so volatile, including this one. In general this is not even remotely close to being as complicated as WSE.

Lastly, and again, to me there is a problem that I aim to solve with this, but it's what we'd classify more as a "non-functional issue". We already have a functional requirement met for a method to create scripts, that doesn't mean the method is ideal however. If you don't find writing M&B scripts the old-fashioned way problematic at all, awesome, that's totally cool. Please don't come in here tell me that my issue isn't real simply because we don't share it however. I'll 100% agree that this is not even close to the biggest issue or most useful tool to be posted here. I wouldn't trade something like Cartographer for 10 of these. This tool took a few hours to write and about 20 minutes to make a readme for though. It's a pretty simple module that didn't take too much effort to write and doesn't have a very big problem space. The chance of it seriously breaking after getting a stable version out isn't very likely, so even if I were to die the next day it'd probably continue working fine.

I'm sorry, but as a software engineer I have to strongly disagree with that. Copy and pasting code != good reuse. Reusing code is good, but we absolutely do not do that by copy and pasting.

Anyway, I'm curious if you've actually taken a look at how this module works before giving advice?

It outputs the exact same tuple format for scripts. It doesn't even slightly touch the compilation process, there are no compatibility breaks anywhere. Something like Lav's enhanced compiler wouldn't know the difference between a traditional script and one loaded from a .mbs script. That was very intentional on my part. You can plug it in with minimal effort and very little disruption.

It depends on your use case. If you're just making tweaks then I wouldn't use this either, but sometimes new code is necessary. I'm not trying to force this on anybody, it's just an option. It's 100% fine if you guys feel it's not useful to you.

Rodrigo Ribaldo 说:

Another proof that programmers are great at devising solutions that no one needs. 
You can't change the syntax of a programming language that's not controlled by you just because it saves you some typing. No one is going to use your alternative.

点击展开...

Actually I can, I just did. 

In the end I made the tool because I plan on using it. The purpose I had in mind when making it is written in the readme. Basically I just find writing scripts through python lists and tuples clumsy and unpleasant. This lets you write your scripts without all the annoying cruft. I'm just sharing it in case anyone else has had similar frustrations and wants to try  an alternative. I'd agree that most likely 99% of people here won't care, but I'll work on it either way for myself ¯\_(ツ)_/¯.

Well, there are plenty of mods who managed to get developed with the module system and the sources we have ^^

点击展开...

Sorry, can you clarify? I didn't mean any sort of offense. This python module is written in native code, so I just figured most people wouldn't want to go through the trouble of building the .pyd themselves.

I wouldn't be surprised is someone has done something similar to this, but I haven't seen it before.

So if you are gonna use a new scriptting system stuff like KISS, DRY, injection, low cyclomatic complexity, proper IDE support, ... can be part of your own framework. It doesnt matter how you create the .txt files after all. Be it Python, C#, Java, Javascript, or any other language, and be it a scripting language, a functional framework, a OO, ... as long it works for you, it is fine.

点击展开...

At first stage at least Oxid isn't going to be very fancy. I plan to add nice features to it as time goes on but for the initial stage it's mostly just an alternative grammar to what people call "MBScript". It has some small sugary conveniences in right now, but nothing hugely different. There are some things I could add I believe that would be more major e.g. a nice abstraction over arrays. It's already been discovered how to do arrays by abusing using slots, but Oxid could theoretically glaze over the part that feels like a hack. Functional paradigm goodies is another possibility. We'll see as the project grows.

It was created to be used by game designers on the TW side, as trying to code game features in C++ would definitly limit who they would be able to hire, right? For that purpose the language itself is quite sucessful, as it has over 10 years and hundreds of projects and thousands of developers that used it at one point or another.

点击展开...

Yeah, while I said I don't like the native modsys, I don't think it's this way because the TW devs were dumb or anything like that. I imagine they had a few devs who started this game at a time where embedded Python or Lua was less viable, and they didn't want to spend a large amount of time on language/tool development in place of the game itself. They took a path that was probably quite clever concerning time budgeting.

Oh wow, I had no idea that existed, it has mixed reviews but I might just purchase it anyways, thanks, I wasn't expecting something like that to exist on Steam!

The first project you mention seems to be a different beast really. Oxidsys still just compiles down to the same bytecode the native module system does. From what I can tell that Lua version is using WSE to actually get straight to the engine and skipping the bytecode step? Correct me if I'm wrong. It's a really cool project but seems to be taking a fundamentally different approach.

I can't find this Carribean! module system you mention sorry, if you have a link I'll happily check it out.

WRECK is somewhat my inspiration for doing this project, it's a proof of concept that you can build something better than the native module system, it's just while WRECK makes improvements Oxidsys is completely pulling things up by the roots.

xenoargh 说:

Oh, and... there's the stuff that wasn't meant to be compiled / included, too, because MS expects a really specific, rigid build order so that integer references match when includes happen.  That's another fun story.  Basically, there's bits in Blood and Steel that requires two compiles to work right- the first pass builds ids that the second pass needs to be properly constructed

I wrote a lot of that years ago, so I'm not sure I should dig it out for people to laugh at my lame Python skills, but it's a thing that's done.  In my case, IIRC, it was mainly to make compiling skyboxes, flora_kinds and post_fx all fit nicely, and again IIRC, I had to do something really kludge-y to allow mission_templates to get referenced in a place it wasn't originally supposed to be, or something.  Sorry if that sounds terrifically vague, it was just so long ago I've largely forgotten what all I had to do to make that part of it work, lol.  I'll see if I can dig it up later on with some reasonable explanation of flow; hopefully I left myself some documentation, lol.

点击展开...

I've read a few cases where people have had funny issues with the build system in the native modsys, e.g. double compilation as you mention although probably for somewhat different reasons. Currently oxidsys has build targets you can specify and it just runs on that. My idea for how it'll work in the end though is that it actually has a build tree worked out. For example if you make a change in items and run

oxidsys build items

点击展开...

it'll recognize the bits that are dependent on items and recompile them also automatically for you. Chicken egg dilemna issues like having to build to update your ID scripts and then reference the new ID are getting eliminated because ID tables will get generated first before anything else, so you'll never have to worry about your ID being unrecognized unless it truly doesn't exist.

That's a cool use case you've detailed. Oxidsys could probably expose control for something like that if I were to place optional build script hooks in the build process.  Right now the build "pipeline" needs to generate ID tables then proceed to actually compile to MB bytecode. I could possibly add a step inbetween however where Oxidsys checks if a build script has been identified and execute it. This would probably be done through an embedded Lua interpreter, the build script would work through an API Oxidsys defines allowing you to read and alter the mods content before it's compiled to bytecode. There are some good libraries for running embedded Lua VMs in Rust already, so this probably wouldn't be too much work.


The headers that you say must be exposed, this is an issue that can be handled on a case by case basis I think. For example I could probably add an item kinds manifest for the items system that lets you work from the base item types in the game at your own peril  . Adding new races in the troop system as you pointed out is another good example. These will just have to be approached case by case I think. I certainly don't want Oxidsys to be restrictive however, so I will opt in to letting the user do more even if it means have to loosen safety a bit for them. In most cases I suspect we can probably have both though.

But don't be fooled into thinking it's enough to build something that can output valid bytecode.  The minimum acceptable "hello world" for something like this is something that, out of the box, compiles a compliant single-player start, Tutorial, Quick Battle, MP landing, mandatory Dialogs, etc., etc., etc.- there's a heck of a lot of work to do before you get to write your first "real" feature.  Plus documentation, which needs to be quite copious in the areas where it's going to be alien to MS veterans.

点击展开...

Of course, the idea is that when this "releases" there will be a port of the native mod to Oxidsys that builds the same game from a players perspective. Oxidsys might even come with inbuilt support for "templates", where the user could specify a native or barebones template perhaps.

oxidsys new --template <native/bare>

点击展开...

I haven't settled on this aspect yet though.

The documentation is important to, I haven't expressed here well what the differences Oxid introduces are, but that's largely because it'd be premature to talk about Oxid in detail too much at this point. Basically I've written a parser but there are other stages that need done. A basic implementation that'll at least allow you to port the native scripts however isn't too far off. The catch is I want Oxid to offer things like checking operation calls for example, which requires me to simply write out details about every single operation so that the compiler can see "Is that a correct number of arguments, are any of them nonsensical". There are fancy ideas like a pseudo-type state machine where I could strongly type data so that a user can't arbitrarily specify an agent id when one is expected. It depends on where I set the bar, and some bits will simply be a lot of grind to implement. (There are a little over 1000 operations from what I can tell).

The biggest "gotcha" I think you'll find, besides the hard-coded stuff, is that the headers we aren't supposed to modify... get modified.  Sometimes heavily.  Some of them are merely collections of mutable data that people modify to get from A-->B, such as header_items, where every time I update the MS core from TW, I have to carefully port over my modified stuff (fun!).  And of course, big projects like mine also use bytecode tricks in the process_*.py, too, and other fun Stupid Tuple Tricks.

点击展开...

This is one bit I need to look into more admittedly. I've seen several mods now that modify the header and process files. Oxidsys being written in Rust can't just be tweaked and run differently, the binary you build is what you get. I need to determine if it's feasible for Oxidsys to make these changes modders make unnecessary or if there is some level of extra control I need to try to expose to users. If you could detail these "bytecode/tuple" tricks further it can help me with this. Thanks  .

if I ever get Blood and Steel's next major iteration done.

点击展开...

Please do, I'm a big fan of the first iteration!

Sorry to raise up such a long since dead post, but I'm curious if anyone can illuminate  on the last potential list member? This thread helped a lot being the best one I could find, but things are still a bit unclear to me. From what I can find the documentation for module_animations.py is still pretty poor.